If you update after end of vsync but before active display, then the card will latch display start and pel pan on the next vertical end *whether you want it to or not* - you may be in the middle of drawing a new frame.

There needs to be some method of checking whether a new frame is ready on the drawing (non-visible) page, and then immediately updating display start and pel pan and having the card latch them right away.

If you're in the middle of drawing a new frame when the card latches those registers, then you may get sprite flickering unless you use a buffer in VRAM to draw background and sprites onto your draw page at the same time. In that case you would only get some screen tearing.

clb wrote on 2026-02-28, 19:37:

If your game was double-buffered (i.e. draw to offscreen framebuffer before presenting), then updating DS and HS after the end of vsync would require enough memory to implement triple-buffering, no? And it would cause +one frame extra latency?

I don't think so. I think you could set the DS/HS after latching to the value of the next frame, then build that frame like normal. Of course that does mean one frame latency with regards to the scrolling itself, so if the scrolling depends on the movement of the player, you'd have that latency. But I doubt whether that's noticeable.

JAL

jal wrote on 2026-03-01, 10:29:

clb wrote on 2026-02-28, 19:37:

If your game was double-buffered (i.e. draw to offscreen framebuffer before presenting), then updating DS and HS after the end of vsync would require enough memory to implement triple-buffering, no? And it would cause +one frame extra latency?

I don't think so. I think you could set the DS/HS after latching to the value of the next frame, then build that frame like normal. Of course that does mean one frame latency with regards to the scrolling itself, so if the scrolling depends on the movement of the player, you'd have that latency. But I doubt whether that's noticeable.
JAL

That does not work unfortunately. It requires either triple-buffering, or assuming 35Hz instead of 70Hz gameplay. And it will stutter on ATI, Paradise and Matrox cards like mentioned before.

Note that the DS and HS registers are not used just to scroll by a few pixels at a frame, but they are used to set the display start address every frame, ping ponging between framebuffers in double-buffered mode. You'll need a third framebuffer, or halve the update rate to 35 Hz.

clb wrote on Yesterday, 17:07:

And it will stutter on ATI, Paradise and Matrox cards like mentioned before.

To clarify the ATI, Paradise, Matrox limitation:

in the SCROLL demo at https://github.com/juj/crt_terminator/blob/ma … L.CPP#L491-L494 a couple of years back , I implemented that exact "right-after-vsync" DS+HS scrolling (to scroll a single-buffered static image), and tested it on about 50 different SVGA graphics cards, and wrote up the details here: https://oummg.com/manual/adapters.html . That exercise is what uncovered the limitation about these cards.

If the goal is to support only authentic/original IBM EGA/VGA, then definitely that won't be an issue.

Thanks for the clarification. It's been a long time since I personally dabbled with this 😁.

JAL