outrun: large objects may show a partially blank line on the left side

[jotego]

Missing pixels at the top left of the screen only for some scenes with many sprites

Seen in 5b3830c6.

• Not related to https://github.com/jotego/jtcores/blob/a4b5b39a2a3238168ef84ad4a49cfd28db0f2e87/cores/outrun/hdl/jtoutrun_obj_draw.v#L141

• Related to the line-based frame buffer?

[jotego]

The blank lines appear at the same relative horizontal position in the object. Varying the horizontal zoom shows how the blanks follow the object and can appear closer to the border or the screen centre depending on the h-zoom setting. The point at which the blanking turns to solid object is not fixed... bad data from the rom?

[jotego]

• not related to the safe re-start in the obj drawing: https://github.com/jotego/jtcores/blob/a4b5b39a2a3238168ef84ad4a49cfd28db0f2e87/cores/outrun/hdl/jtoutrun_obj_draw.v#L148
• not related to the safe re-start in the obj scanning: https://github.com/jotego/jtcores/blob/a4b5b39a2a3238168ef84ad4a49cfd28db0f2e87/cores/outrun/hdl/jtoutrun_obj_scan.v#L246

[jotego]

The problem occurs in the frame buffer. Some lines are not drawn because the request occurs too late. Making hlim larger has a clear effect. hblenis $4F, by making:

hlim <= hcnt - (hblen-st_addr);

It is possible to stabilize the lines gaps vertically setting st_addr=$8. The problem cannot be completely removed with this approach, though.

[jotego]

The problem occurs because a write burst takes too long and that makes the read burst finish after H blanking. At the point at which the read burst finishes, the line is swapped and becomes solid.

[ksdomino]

This might not be a fixable bug. Outrun arcade can only " display 76 scenery sprites at any one time" so some arches are broken in the arcade version. source: https://reassembler.blogspot.com/2012/01/gateways-broken-arches.html

further to that this comment (from the comments on that page) is very helpful: "To be clear, the statement "the precise nature of the breakage isn't consistent" is not accurate. It is consistent at least within a given playthrough (though not from play to play). Note the video of play on arcade cabinet: https://youtube.com/watch?v=EZW8yglpvRY&t=5m37s (Press SPACE to pause, and use , COMMA and . PERIOD to frame step.)

The breaks in the arches is consistent variation that helps message the motion. This is almost certainly a feature (even if arrived at by a bug / limitation, it was almost certainly intentionally left in). The sprite index for the object must remain for its lifetime, ensuring no flickering of objects - which is great programming design. All forms of pattern inconsistencies in the game help message motion, including -- variations of trees, houses, surfers, rocks in grass, signs, mountain heights, to name a few."

[jotego]

Limiting it to 76 does not solve the issue as that limitation came from the software side of the system, not the hardware (the FPGA in our case). I think I'll settle with the current approach until an FPGA that enables a proper frame buffer shows up.