First post, by clb
There was an earlier thread about Commander Keen 4-6 having choppy hardware scrolling on EGA cards: Keen 4-5-6 choppy scrolling on EGA card
There @K1n9_Duk3 was able to explain that the root cause for that was that Keen assumed vertical retrace would be 70Hz, whereas on EGA cards it is 60Hz. (see also this PCKF thread about the same topic) As result, the code timed out waiting for vblank checks, and updated the scrolling registers during visible scan line area: Re: Keen 4-5-6 choppy scrolling on EGA card
However, in addition to those EGA cards and the 60Hz/70Hz programming bug that some Keen versions had (apparently by Keen Dreams the code was fixed), it is well known that several ATI PCI VGA cards suffer from a similar choppy scrolling issue:
1. there is a PCKF forum thread about this observation: PCKF: Jerky motion on ATI cards: possible community fix?, but no root cause was found
2. and @Gona's test chart widely reports the glitchy scrolling problem on ATI cards as well: Gona's PCI and AGP video card DOS compatibility chart
For these ATI cards, the 320x200 mode vertical retrace is 70 Hz, so the earlier EGA 60Hz/70Hz mismatch would not explain the root cause of the issue for these ATI cards - something else must be amiss.
I have an ATI Mach64 VT PCI card, which showcases the glitch.
What happens is that scrolling the map vertically is butter smooth; but scrolling the map horizontally shows these types of tearing artifacts:
I've uploaded 20% slowed down video to YouTube using that card, that illustrates the issue: https://youtu.be/VhZfStu5GYg
At first impression, one might think "hey, that looks like a typical lack of vsynced screen framebuffer update" artifact that happens in all games if one disables vsync.
However that cannot be the root cause, because a) Keen does not repaint the visible map each frame, but instead it updates the screen start address registers to do hardware scrolling, and b) the artifact never occurs when walking straight up and down in the game map, but that always updates smoothly.
While developing some VGA test code for CRT Terminator Digital VGA Feature Card ISA DV1000 in the SNOOP.EXE: (S)VGA adapter info tool and CRT Terminator config utility utility program, I think I may have found the root cause of this ATI quirk.
It turns out that the ATI cards latch on to changes to the EGA/VGA Attribute Controller register's Horizontal Pixel Shift Count field on each hblank, whereas other cards that I have tested so far (Headland, Cirrus), the adapter latches on to changes to that register only at each vblank. This hshift count register lives in I/O port 3C0h, register index 13h, bits [3:0], see Horizontal Pixel Panning Register at http://www.osdever.net/FreeVGA/vga/attrreg.htm.
I've created a test program that tests whether the VGA adapter reads Horizontal Pixel Shift Count register at each hblank or only during vblank, by feeding random noise to the register during visible picture area, and resetting it back to zero during vblank.
If the adapter only updates Horizontal Pixel Shift Count register at each vblank, the noise should be ignored, and the program will print a solid one pixel wide green line on the screen.
On my Headland VGA adapter, which does not have scrolling issues in Keen, that is what happens:
On the ATI Mach64 VT card, the program instead displays a wide wiggly green line as the ATI adapter latches on to a random value in the Horizontal Pixel Shift Count register on each scanline:
I do not have a 100% connection to the ATI Keen scrolling issue, but it does look plausible that this might be the cause. If Keen ends up adjusting the Horizontal Pixel Shift Count register outside vblank, then these types of artifacts would occur specifically on ATI cards only - whereas on other VGA cards changing the register outside vblank is safe and glitch-free, and the change will only apply after the next vblank (just like changing Display Start Address register also does change only at each vblank on all tested cards)
What I would be curious to find out: does someone have a graphics card that exhibits horizontal scrolling tearline glitch issues in Keen 4-6 games, but at the same time HSHIFT.EXE displays a straight green line? That is, is there a counterexample that would show that HSHIFT.EXE is not capturing the root cause?
If the above root cause is accurate, then it is plausible that Keen games should be possible to patch for ATI cards by ensuring that the game engine only adjusts the Horizontal Pixel Shift Count register when inside vblank.