keenmaster486 wrote on 2026-02-25, 07:36:
Is the vertical retrace interrupt not intended as a vblank detection method? I implemented it as such, but testing in DOSBox with machine=ega shows that although the interrupt is firing at 60Hz as it should, updating the display start offset and pel pan registers in the interrupt is causing significant stuttering, as though I were updating them during active display time.
The vertical retrace interrupt is a vsync detection method, not a vblank detection method. It should work out for that quite well - on EGA/VGA cards that support it.
There is a vertical front porch (VFP) area that precedes the vertical sync area. This vertical front porch is a couple of scanlines long, and only after that the vsync line is activated.
The vsync interrupt will fire at the start of the first vsync refresh scanline.
It is wholly expected that if you update Display Start (DS) and Horizontal Offset (HS) registers as response to receiving the vsync interrupt, then on original IBM *VGA* adapter, you will get significant stuttering.
This is because IBM screwed up big time (or, it was an unfortunate limitation of the time). The VGA card latches (i.e. captures == records == reads) the value stored to the DS and HS registers at different times.
-> The Display Start (DS) register is latched at start of vsync. So, when the vsync interrupt fires, you are already too late to update the DS register for the next frame. At this time, the card has already read what DS start value it will use for the next frame.
-> However, the HS register is latched at end of vsync. So, if you set the DS+HS registers while in vsync, then effectively only the HS register change will take effect for the next frame, and the DS register update will take effect only for the frame after the next frame. (when the next vsync will start)
This was a massive hardware screw-up/design oversight from IBM, and is exactly the reason why hardware scrolling is so difficult to implement on DOS. If it weren't for this fact, then hardware scrolling on DOS VGA would have been absolutely superior compared to NES and C64 for example. (neither of which can set arbitrary display start with flexible display scanline stride, like IBM EGA and VGA can) But because of splitting the framebuffer starting address into two separate registers: DS+HS, and screwing their latching behavior design to occur at different times, it became very difficult to do smooth hardware scrolling on the PC.
This was exaggerated by the fact that there was no official VGA hardware standard, or hardware conformance test suites, so many clone manufacturers would accidentally implement different latching semantics for DS and HS (hence the table at Re: Solved(?): Why does Commander Keen 4-6 hardware scrolling glitch on ATI (Mach) PCI video cards being investigated)
If IBM had implemented the latching semantics to occur synchronously, so that DS and HS would be read at the exact same time, then none of this would have ever been a problem, and it would have been dead easy to implement smooth hardware scrolling updates - even without any vsync synchronization at all practically. This would have been the case for example if they had also made the DS register to latch at the *end* of vsync, and not at the start.
--------
Now, all that info is based on my research on the original IBM *VGA* adapter. I believe that IBM EGA adapter behaved identically with respect to all of the above info, i.e. DS register was latched at start of vsync, and HS register was latched at end of vsync. But I have not actually tested that.
The reason I believe that EGA has identical behavior to VGA, is that VGA largely grew as a superset of EGA, and both were implemented with a bunch of discrete IC chips. So coordinating synchronization between the chips that affect the DS and HS at scanout was very much the same. If you want to be 101% sure, it may be worth re-testing. (would be quite the unexpected surprise if this hardware design bug was a regression that occurred only when going from EGA to VGA)
