The glitchy ATI Mach64 card in question:

Keen also has issues on Neomagic laptop chips as well... would be interesting to see if it's the same problem

Oh, just realized that my Keen 5 version was 1.0. There is the 1.4 update available for Keen 5, which adds the "Fix Jerky Motion" option.

That option does fix up ATI support for Keen 5. Maybe what that fix does is to exactly restrict scroll updates to occur only during vblank.

Updated SNOOP to detect this scenario:

keenmaster486 wrote on 2023-08-31, 17:48:

Keen also has issues on Neomagic laptop chips as well... would be interesting to see if it's the same problem

Looks like that chip is only available as an integrated motherboard/laptop adapter(?) - couldn't find any discrete cards. Would certainly be cool if someone has a setup to test.

Browsing through http://gona.mactar.hu/DOS_TESTS/ for cards that have been reported to not work well with Keen 5, I find I have this Matrox MGA2064W card that is marked there to scroll bad:

Sure enough, the card does glitch with horizontal scrolling in Keen 5 1.0:

and the "Fix Jerky Motion" option in Keen 5 1.4 fixes that issue up.

In HSHIFT.EXE test the Matrox card behaves just like the ATI Mach64 VT card above, latching onto the Horizontal Pixel Shift Count at each hblank:

SNOOP giving a nice diagnostic about it.

clb, video card research king 2023.

How's the Terminator going?

I have a matrox millennium (IS-STORM) and even with the "fix jerky motion" option on in keen4 it still doesn't scroll smoothly. It requires king duke's patch.

maxtherabbit wrote on 2023-09-01, 01:28:

I have a matrox millennium (IS-STORM) and even with the "fix jerky motion" option on in keen4 it still doesn't scroll smoothly. It requires king duke's patch.

Yep same here.

> I have a matrox millennium (IS-STORM) and even with the "fix jerky motion" option on in keen4 it still doesn't scroll smoothly.

Thanks for the data point. To be more precise, the logical conclusion that I am inferring here is "has_hshift_bug" -> "scrolling_in_unpatched_keen5_1.0_ will_periodically_tear", or equivalently, "scrolling_in_keen5_1.0_is_smooth" -> "no_hshift_bug".

What kind of scrolling artifacts does the IS-STORM card exhibit? Or are there no artifacts, but timing is incorrect and as result the visuals are stuttering?

Would be interesting to see a video capture of it in action in Keen5 1.0 and/or Keen5 1.4, as well as the results of SNOOP.EXE and HSHIFT.EXE on that card.

Pierre, CRT Terminator hardware wise is currently in a wait mode. We are waiting for the FPGA manufacturer to finish baking us a batch of chips. The estimated shipping time is marked for early November atm. Meanwhile, I am working on the software side, and writing a user manual for the card.

clb wrote on 2023-09-01, 06:48:

Pierre, CRT Terminator hardware wise is currently in a wait mode. We are waiting for the FPGA manufacturer to finish baking us a batch of chips. The estimated shipping time is marked for early November atm. Meanwhile, I am working on the software side, and writing a user manual for the card.

Appreciate the update!

clb wrote on 2023-09-01, 06:44:

> I have a matrox millennium (IS-STORM) and even with the "fix jerky motion" option on in keen4 it still doesn't scroll smoothly […]
Show full quote

> I have a matrox millennium (IS-STORM) and even with the "fix jerky motion" option on in keen4 it still doesn't scroll smoothly.

Thanks for the data point. To be more precise, the logical conclusion that I am inferring here is "has_hshift_bug" -> "scrolling_in_unpatched_keen5_1.0_ will_periodically_tear", or equivalently, "scrolling_in_keen5_1.0_is_smooth" -> "no_hshift_bug".

What kind of scrolling artifacts does the IS-STORM card exhibit? Or are there no artifacts, but timing is incorrect and as result the visuals are stuttering?

Would be interesting to see a video capture of it in action in Keen5 1.0 and/or Keen5 1.4, as well as the results of SNOOP.EXE and HSHIFT.EXE on that card.

It's just stuttering as far as I can see

In case we really didn't have enough VGA hardware scrolling test cases, I wrote a VGA hardware scrolling bitmap demo at
- https://github.com/juj/crt_terminator/blob/ma … /bin/SCROLL.zip
- https://github.com/juj/crt_terminator/tree/main/DOS/SCROLL

It pans a very large 2MB 1920x1097 pixel 256-color bitmap by one pixel per vertical refresh in 320x240 Mode X.

The program can be run in two modes. Just running

1SCROLL

implements scrolling that is synchronized to occur inside vblank, whereas

1SCROLL hblank

can be used to test how the VGA adapter behaves if hardware scrolling registers (Display Start Address, Horizontal Pixel Shift Count) are modified during active display area.

The whole 256KB VGA memory is used, so this test exposes the Tseng ET4000 and S3 Vision buggy 256KB wraparound.

EDIT: My bad, I completely misremembered the S3 Vision for another card, and it was instead a Alliance Semiconductor ProMotion 3210 that had the wraparound bug. See Which >256KB SVGA adapters forgot to implement the VGA address space wrapping after 256KB mark? for details.

On my Matrox MGA2064W and ATI cards, default SCROLL is smooth, whereas SCROLL hblank is glitchy.

Oh my.. This weekend I've dug deeper into the behavior of different cards, and there are certainly many quirks to be surfaced in this area. This has given an appreciation to why it is so difficult to write a single hardware scroll implementation that would work on all cards. (it is possible, but the best method I was able to come up with is still somewhat awkward)

Before this weekend, I thought that ATI behavior was particularly "bad", but actually, I am now of the opinion of all the cards, ATI might not have done what was IBM compatible, but they did what made more sense than what the other cards do.

Although thinking about this more, to me it seems that no manufacturer has implemented hardware scrolling according to what would be most ideal/"best practices".

I have this Paradise PVGA1A card:

which stuttered horribly when I ran the earlier SCROLL demo on it. That prompted to investigate even more carefully how the latching behavior of the Display Start Address (DS) and Horizontal Pixel Shift Count (HS) registers is implemented on different cards.

I ended up discovering the following data:

1Card            | DS Latched  | HS Latched  | SCROLL demo compatible sync methods
2----------------+-------------+-------------+-------------------------------------
3Oak             | Vsync start | Vsync end   | 2,3,5,6
4Trident         | Vsync start | Vsync end   | 2,3,5,6
5Cirrus          | Vsync start | Vsync end   | 2,3,5,6
6Headland        | Vsync start | Vsync end   | 2,3,5,6
7AHEAD V5000B    | Vsync start | Vsync end   | 2,3,5,6
8ATI Mach64      | Vsync end   | Every Hsync | 1,3,6
9Matrox MGA2064W | Vblank end  | Every Hsync | 1,2,3,4,6
10Paradise        | Vsync start | Every Hsync | 6
11Tseng ET6000    | Vsync start | Vsync start | 1,2,3,4,5,6
12S3 Trio64       | Vsync end   | Vsync start | 2,3,5,6
13SIS 6326        | Vsync end   | Vsync end   | 1,2,5,6
14(ideal)         | Vsync end   | Vsync end   | 1,2,5,6

Combining all the above constraints together, the only timing where scrolling registers could be updated so they will be guaranteed to be properly synchronized on all cards would be to reprogram the registers after vblank start (but before vsync start).

However, there does not unfortunately exist a mechanism on the VGA adapter to synchronize to vblank start. One can cleanly only synchronize to operate after vsync start or after vsync end.

In my opinion the ideal ("best practices") hardware design mechanism would have been to have the VGA adapter latch DS and HS registers both at vsync end. That way one could have either a) cleanly synchronized hardware scrolling at vsync start (using simply this code), or b) the scroll registers could have even been programmed without any synchronization whatsoever! (with a very rare once in a blue moon possibility for a glitchy race condition)

I presume the original IBM VGA behavior was to have DS latch at Vsync start since so many cards above have that behavior, but I would call that an outright hardware flaw. Maybe ATI also observed this behavior as undesirable, and consciously changed their DS implementation to sync at Vsync end. (or maybe it was just a random fluke, 🤣 who knows) Although it would have been better if they would have also had HS register latch at Vsync end, and not every hsync, as that would have enabled programmers to modify the DS and HS registers completely unsynchronized.

Anyhow, I created an interactive set of different synchronization methods into the SCROLL program that one can play around with to check what the latching behavior of a particular card is.

SNOOP will also diagnose these combinations. Maybe it will help e.g. emulation developers one day.

If someone has a card that does not follow any of the conventions in the chart above, I'd love to know.

UPDATE: Tested and added Tseng ET6000 (G-Force Jazz 128), which was developed to latch DS and HS on Vsync Start. That is a super compatible method, the best tested so far! (although Tseng has the other 256KB wraparound issue still, which needs custom handling)

UPDATE #2: Tested and added SIS 6326, which implements the most preferable DS,HS both latched at Vsync end form.

UPDATE #3: Tested and added Matrix Millennium MGA2064W.

Looks like this SIS 6326 AGP (PCI bus) graphics card

does implement the ideal format: both Display Start Address and Horizontal Pixel Shift Count registers are latched at Vsync end. This means that it is very easy to program code that updates the scrolling registers without glitching or without awkward polling performance losses. Fancy!

Matrix Millennium MGA2064W (from this earlier comment: Re: Solved(?): Why does Commander Keen 4-6 hardware scrolling glitch on ATI (Mach) PCI video cards ) takes the crown as the most uniquely peculiar card yet: it latches DS register at the end of vertical *blank*, not at the end of vertical retrace. No other card has synchronized to blank period so far. Well, that is quite compatible fortunately at least, but it does have the quirk that it latches HS at every hsync, giving Keen the creeps.

I went through and disassembled and decompiled Keen 4 1.0, 1.2 and 1.4 versions to figure out exactly how they are synchronizing, and what that Fix Jerky Motion option does.

(sidenote, this is not "new" information, as many Keen modders have already discovered this information and delved through this area of the code; although I am not sure if a writeup of this area existed anywhere)

Original Keen 4 v1.0 had this code:

That is, it looks like they try to find the start edge of vertical blank by observing a period of five consecutive "display in blank area" status register reads. "Horizontal blanks are short, shorter than it takes time to do 5 ISA bus I/O port reads, right?"

That kind of code is likely brittle to ISA bus overclocking, and display card I/O read speed. And once you have a graphics card on the PCI bus, I/O port reads become mighty more faster, so the above code would then think hblanks were vblanks, and lead to incorrect synchronization.

Another problem are interrupts: they play against this code to mess the timings. In Keen 4, the PIT0 timer ticks at 8*70 = 560 Hz, which is about ~25% more often than there are scanlines in the output image (449), so it could make the code occassionally miss finding the short vertical front porch window.

Keen 4 v1.2 scrolling code is very much the same, but they added a new /NOPAN command line option:

There are two possible reasons for this:
a) there were some graphics cards where the Horizontal Pixel Shift Count register (also called the Pixel Panning or PEL Panning register) was buggy (I haven't found one yet), or, to me more likely is that
b) ID got reports that there were some graphics cards where the synchronization interaction with Display Start Address and Horizontal Pixel Shift Count registers was working unexpectedly. From the ASCII table in the earlier comment, we know that such cards were in abundance; there was no standardization whatsoever on the latching timings between manufacturers. Disabling panning effectively removes one source of synchronization headache, and better to have an option to revert to blocky scrolling than to have outright tearing/glitchy scrolling.

The /NOPAN option would have been an easy way for tech support to help people mitigate/diagnose their setups.

And then, we get to the Keen 4 v1.4 scrolling implementation:

Oh boy. If 5 ISA I/Os isn't enough to distinguish a hblank from a vblank, "let's just repeat for a five more, that oughta do it!". They could have automated the mechanism by actually benchmarking the durations of hblanks and vblanks, and no "Fix Jerky Motion" option would have been necessary. This fix looks like something that software near the end of its lifecycle would receive, when late bug reports are piling in and only one sorry maintainer guy is left to work on the codebase. We can only wonder 😁

Anyhow, even after I applied the Fix Jerky Motion option to the ATI card, I found that the game was still stuttering. But now it was stuttering like "I remember it used to". Back in my day, I had played Keen on a 16MHz 386 SX, so it would be obvious not to run smoothly. But now in this instance I have a 80MHz 486 with a PCI graphics card, so surely Keen should be able to run perfect smooth without stutters?

With help from PCKF community at https://pckf.com/viewtopic.php?t=11505&start=45 (more conversation at https://pckf.com/viewtopic.php?t=16773 ), the experts there were able to point out that the game logic is ticked at a timer that is decoupled from the vertical refresh rate - likely due to the lack of reliable vertical refresh interrupt.

With help, I was able to rebuild Keen 4 from reverse engineered/recreated sources, and I added some hardware assistance via CRT Terminator to acquire such a reliable frame timing source (a frame counter and a scanlines-until-vblank counter), and now I have a very smoothly running Commander Keen 4. Well, not only is it running at smooth locked at vsync 35 Hz, I adjusted its refresh rate to run at 70Hz! Oh boy is this the smoothest Keen I've ever seen.

The relevant synchronization code can be found at https://github.com/juj/crt_terminator/blob/ma … L.CPP#L255-L333 . I really really hope to make these features into the production version of CRT Terminator so that developers can leverage them, although I have no clue yet as to how useful they would actually be, and the tricky part is that the board is so full already that I am unsure where to make it all fit.

On cards that do not generate Vsync interrupts would an AND gate on VGA V H and going straight to one of ISA interrupt lines accomplish same thing?