My gut impression here is that because the graphics card is an integrated one, it is not behind an ISA bus, but provides really fast VGA I/O port read performance, which causes the problems.

Commander Keen 4-6 games have a known programming error from iD's side that they assumed that I/O port reads would always be "slow enough", so that they would be able to distinguish a horizontal blank from a vertical blank by performing a suitable fixed number of VGA I/O port reads. I.e. they wrote a hack that assumed that I/O reads must be slow on all VGA adapters ("VGA cards are always behind a slow < ~10 MHz ISA bus, right?").

Then later on when they realized that their hacky assumption did not hold, they just layered another hack on top of it, in the form of the "Fix Jerky Motion" option in the menu. This option simply halved the expectation of how long a VGA I/O port read would take. (by doubling the number of I/O port reads performed when attempting to distinguish between hblank and vblank)

We had a long thread at Vogons discussing this Keen problem at Why does Commander Keen 4-6 hardware scrolling glitch on ATI (Mach) PCI video cards?

If you haven't yet tried, try using the Fix Jerky Motion checkbox in Keen to see if that will help it. If your Keen 4-6 game does not have that checkbox, verify that the game version is 1.4, since there are also older Keen versions (1.0, 1.1 or similar) that did not yet have that option. I.e. the compatibility checkbox only came in a later updated version.

If the checkbox doesn't work, there are two attempts to fix:
- K1n9_Duk3 provided one patch to Keen 4-6 that reverted the vblank synchronization code to an earlier version that iD had used in their other games: https://pckf.com/viewtopic.php?f=4&t=6192
- As a proof of concept, I rewrote the Keen vsync synchronization code for smoother motion, at https://github.com/juj/KEEN70HZ/ . This code avoids the hacky bus speed assumption as well.

You can try those to see if that would affect the behavior. Also something you can try to poke the graphics adapter's behavior is this hardware scroll test code: https://github.com/juj/crt_terminator/raw/mai … /bin/SCROLL.zip
(see this post for cross-reference information: Re: Solved(?): Why does Commander Keen 4-6 hardware scrolling glitch on ATI (Mach) PCI video cards ). I'd be curious to know which scroll methods work ok on that S3 Unichrome graphics adapter.

Issues with Jazz Jackrabbit is something that I'm not that familiar with. Maybe the root cause stems from the same fast timing property, or maybe there is some other compatibility problem. If you are able to record a video of what the issue looks like, that would be nice to document.

Hadn't tried the Fix Jerky Motion checkbox, but it didn't change a thing either.

I haven't tried the K1n9_Duk3 patch or your vsync synchronization code rewrite yet - but the scroll.exe test tool. And basically with any of the 8 different options I see a lot of colourful horizontal lines flickering vertically.

Not sure if this even has to do anything with CKeen and Jazz Jackrabbit, as both exhibit the same behaviour: the screen (or parts of it during the intro) jump back and forth horizontally.

Here is a slow motion (1/5th playback speed) recording of what type of glitch the Fix Jerky Motion in Keen 5 attempts to fix: https://www.youtube.com/watch?v=VhZfStu5GYg

There are two hardware registers on the VGA adapter: "Display Start Address (DS)" and "Horizontal Pixel Shift Count (HS)" that when interpreted together, specify the horizontal pixel scroll offset.

These registers cannot be updated atomically together, but must be sequentially written in two separate I/O commands.

So if these two registers are updated at a bad time, then the VGA adapter might temporarily "see" only one of the updates taking place, and miss the other register update for the next frame. This is what results in the picture jumping left and right horizontally.

Keen attempts to find a good time for an update by estimating when vblank starts (so therefore it needs to distinguish between hblank and vblank).

It is also possible that the latching behavior of the card is unconventional, and thus a good time to update the registers would differ from other cards. The different test modes in SCROLL.EXE should definitely find at least one mode that should work. You can try running "SCROLL wrap" to see if that might help anything. (it adds a SVGA workaround in the code). When you write "I see a lot of colourful horizontal lines flickering vertically", I am not immediately sure to imagine what that looks like. It would be nice to see a recording in action.

https://x.com/mdscntstmgm/status/1807828023485341822

I recorded how Keen 4 looks on my card, Jazz Jackrabbit basically behaves the same.

In the post below, I documented the behaviour of the scroll.exe, however I could see no difference aside from the colours being a bit different, I first noticed at the bottom.
It's hard to capture with the potato phone camera, but basically the flickering is due to phone vs CRT while the actual problem is that the lines jump a pixel or two up and down rapidly.
Don't know if this has anything to do with the behaviour in Keen 4, since that one has entire sprites or the entire screen jump left and right only twice or so per second but bigger distances.

Ooh that video glitch is definitely something else.

It looks like in the video the hardware scrolling is well synchronized, but the S3 VGA adapter definitely combines the value of the Horizontal Pixel Shift Count (HS) register with the Display Start (DS) register somehow different than what it is supposed to. The constant jumping left to right happens so steadily or "rhytmically" that it does not feel like a mis-synchronization issue. This suggests like the problem could be some kind of adapter hardware design issue.

To test out if that might be the case, I put together a quick test program that can be used to interactively scroll a screen by one pixel at a time. You can grab it at https://github.com/juj/crt_terminator/raw/mai … /DOS/bin/HS.zip

There are five different test modes: https://github.com/juj/crt_terminator/blob/3b … /HS.CPP#L22-L61
Test mode 0 is what correct VGA scrolling uses. Modes 1 to 4 are other ways to write to the registers.

See this video on how I would expect the output to look when run in different modes on an adapter that does implement the scrolling registers properly (Hercules Stingray Pro with ARK1000PV chip) : https://youtu.be/40QGjZ0xYmg

See instructions by running the HS.exe program.

Do any of the modes 0-4 result in correct scrolling behavior on the S3 card?

Danger Manfred wrote on 2024-07-01, 17:34:

In the post below, I documented the behaviour of the scroll.exe

Is there a second post you uploaded to x.com? I was not able to see it via the first link at least.

clb wrote on 2024-07-01, 19:16:

Is there a second post you uploaded to x.com? I was not able to see it via the first link at least.

Weird, it's directly under the first one.
Here is its own link:
https://x.com/mdscntstmgm/status/1807828988456247598

Ok, looks like that SCROLL.EXE is royally broken. Here is what it should look like: https://youtu.be/geWx170_LsA . (The video overlay on top right is not part of the program, but from CRT Terminator video upscaler)

Not sure if it is SCROLL is broken due to a programming error from my behalf, or if there might be something due to the S3 card though.

https://x.com/i/status/1808013389978910733

This looks better I guess, no flickering visible to the human eye, just out of sync potato phone).

It looks like HS.EXE 0 produces correct result, which confirms that the S3 chip does interpret VGA scrolling correctly. However the modes 1-4 look off, although those modes should not be used with VGA modes anyways, so discrepancies in decoding that do not matter. (though it does indicate that S3 does something different there)

However, now I facepalm to realize that of course Keen is an EGA game, so the above test should have tested EGA video mode instead. (Although Jazz is a VGA game, so if that gives the same horizontal jumping issue, then it seems the root cause might be something else)

Anyways, if you want to still test, I made an EGA version of the test program: https://github.com/juj/crt_terminator/raw/mai … S/bin/HSEGA.zip

In EGA mode hardware scrolling should work a bit differently. Running HSEGA 0 should give a view that scrolls by two pixels every time a key is pressed. And running HSEGA 3 should give a view that scrolls one pixel every time a key is pressed. (HSEGA 1,2 and 4 are expected to glitch on EGA)

I.e. it should show like this: https://youtu.be/2qw5QSK7n68

If that also works correctly, then I'm not quite sure where a difference could come to play. If you'd like to try the Keen 70Hz mod: https://github.com/juj/KEEN70HZ/raw/main/DIST/KEEN70HZ.ZIP I wonder if that makes any difference.

In particular Keen70hz.zip has a "1 pixel panning" option in the menu, it would be interesting to know if enabling or disabling that option would make any difference whatsoever.

Also there is a Keen mod "Foray in the Forest": https://files.shikadi.net/keenwiki/mods/Sourc … .2023-12-25.zip (see https://keenwiki.shikadi.net/wiki/Foray_in_the_Forest). My understanding is that mod rewrites the hardware scrolling code as well, so that might be something to try as well.