Wow, amazing that went so long without anyone patching it.

Did you think of taking a look at the Voodoo 2 drivers to see what they did there?

Otherwise, maybe use tricks from the slowdown utils, but only for a beat or two, not looping.

Great news. Excellent work!
Keepin' my fingers crossed 😀

BitWrangler wrote on 2026-05-29, 12:28:

Wow, amazing that went so long without anyone patching it.

Did you think of taking a look at the Voodoo 2 drivers to see what they did there?

Otherwise, maybe use tricks from the slowdown utils, but only for a beat or two, not looping.

I have looked at the Voodoo2 code as well and it is very similar to the Voodoo1, at least in terms of initialization. It also contains these "delay loops", so I am a bit surprised that Voodoo2s are not affected by speedy CPUs. But maybe the V2s are simply fast enough on startup and the delay times in the driver are still sufficient even on modern systems.

I'm still working on getting a usable Windows DLL from the source code. As a quick fix I'll probably just add another delay for-loop to this status function, but for a "proper" solution several parts of the init code need to be rewritten.
My coding skills are not really that great so I don't know if I want to do this...
Anyway, right now I'm fighting with the MinGW compiler to actually produce a working DLL file in the first place.

Would a simple sleep(1) solve the issue? I mean no one would complain waiting 1sec if the card works flawlessly then.

AncapDude wrote on 2026-05-29, 18:50:

Would a simple sleep(1) solve the issue? I mean no one would complain waiting 1sec if the card works flawlessly then.

Unfortunately this function which reads the status bit is called ~20-30 times during init (for-loops not included) so the waiting time would be much longer.

Anyway, I was able to finally compile a set of new DLLs which actually work. I took the "cheap" shortcut and just added another delay loop in the sst1InitReturnStatus funtion. Not the prettiest solution but it seems to do the job.
I hat to use MSVC 6.0 to compile these, neither MinGW nor OpenWatcom produced anything useful.

To make things a bit more flexible, I also added a new environment variable: SST_INITDELAY
It takes a positive non-zero number which defines the number of for-loop runs in said function. It defaults to 250, which is the value that works on my 1GHz Athlon system.

I also created a Glide 2.1.1 compatibility dll (named glide.dll) which is required for some older 3dfx titles like Mechwarrior 2. I checked MW2 with that dll and it works for me, but it's not guaranteed to work with other games...

Check the files attached if they work for you, feedback is appreciated.

This is a great find! Do you think it might be possible that the glide2x.ovl dos driver might be fixed in a similar manner?

Awesome!

Spark wrote on 2026-05-30, 18:09:

This is a great find! Do you think it might be possible that the glide2x.ovl dos driver might be fixed in a similar manner?

Probably. But first I have to find out how to build that thing. This ovl file is some weird dll format for this DOS extender, dos4gw. No clue what compiler can build this. Watcom maybe.

This is awesome! Nice job!!

It's amazing that people are still figuring things like this out after all these years.

I wonder if one would write a simple calibration program that observes how fast the delay loop runs and suggests a value for SST_INITDELAY using a safe target delay time (or even installs the variable permanently)

There's an example of that I think in Linux, older kernels at least, where the Bogomips calibration loop runs to set a delay loop or timing variable.

Excellent work pyrogx! 😀

Spark wrote on 2026-05-30, 18:09:

This is a great find! Do you think it might be possible that the glide2x.ovl dos driver might be fixed in a similar manner?

This would probably fix Archimedian Dynasty (Schleichfahrt) on faster systems and I hope it'll be possible.

I tried to run that on a Voodoo 2 and it reliably works with a P3 500Mhz, I got it to run once on 800MHz and never on my 1.4GHz Tualatin.

schmatzler wrote on 2026-05-31, 23:50:

I tried to run that on a Voodoo 2 and it reliably works with a P3 500Mhz, I got it to run once on 800MHz and never on my 1.4GHz Tualatin.

That's pretty interesting as I had it working reliably on a celeron 766 at 66mhz, which must be near its limit.
Not that it matters now that pyrogx has isolated the actual cause.

Managed to build the DOS driver. This OVL file really needs to be built with Watcom. I used OpenWatcom 1.9 (v2 wouldn't work) and some special dos4gw dll startup code.
Tomb Raider and Descent 2 worked just fine, didn't check any other DOS Glide game, though.

Maybe I'm crazy (okay I know I am, but hear me out). What if we thought about this like the engineers at 3DFX in like mid 96. We could write a small program to track the wall time for running that delay loop and gather data from volunteers with period correct systems (say P133 or so). Basically have them run it and calculate an average "initialization time" so that we can migrate to a sleep for X milliseconds delay approach that should be universal for all hardware. Basically take this from a quick and dirty lab fix to something actually robust.

Edit: Holy run on sentence. I definitely needed a cup of coffee before posting that. I'll leave it mostly intact but edit it to, you know, be somewhat coherent. Also it's fascinating that they stuck with this delay loop approach with Voodoo II. Perhaps it was less pressing of an issue given that it initialized faster or maybe they just had more pressing issues.

NeoG_ wrote on 2026-05-31, 03:20:

I wonder if one would write a simple calibration program that observes how fast the delay loop runs and suggests a value for SST_INITDELAY using a safe target delay time (or even installs the variable permanently)

Could we do something even simpler and just multiply all loops by the CPU clock speed vs a "baseline"? It seems like up to around 500MHz most people don't have an issue, so maybe that could be the baseline of "1.0". Any CPU speed up to and including 500MHz just gets the default loop time. Any CPU speed over that, multiply the loops by the clock speed ratio. E.g., 750MHz => loops * 1.5. 1GHz => loops * 2.0. If you wanted to add a "buffer" to account for different architectures, etc., you could even drop the baseline to 400MHz, or 350Mhz.

I know that not all CPU architectures are equal, and speed doesn't scale linearly with clock speed across multiple architectures, but my guess would be a simple system like this could probably cover all use cases, and would be simpler than needing to benchmark the CPU to establish a multiplier?

DrAnthony wrote on 2026-06-01, 22:46:

Maybe I'm crazy (okay I know I am, but hear me out). What if thought about this like the engineers at 3DFX in like mid 96. What if we wrote a small program to track the wall time for running that delay loop and got some volunteers with period correct systems (say P133 or so) to run it and just calculate an average "initialization time" and migrated to to a sleep for x milliseconds delay rather that should be universal for all hardware?

Or this! Just wait for X seconds, rather than a loop. 😀

Looked a bit more thoroughly into that issue. Turns out that these for-loops around sst1InitReturnStatus are not the actual problems, although slowing it down fixes the crashes. The real culprit was a single function which queries the "BUSY" status of the FBI chip. This needs to be either slowed down or a command clearing the graphics pipeline needs to be executed first.

There are two functions in the driver code which poll the FBI status, one of them issues this "clear pipeline" command, the other one doesn't.
...and for some reason, only the latter one is actually used in the driver, and that's why the whole thing face-plants the card without a slowdown.

I now changed the source code that the clear pipeline command is always sent to the FBI chip first before polling its status bit. It seems to work just fine, so I removed all the extra delay loop crap I added earlier. Everything looks okay, my Voodoo1 now even works on my old AMD FX-8350 system, the newest one I have with a PCI slot.

I also managed to patch the Win9x Direct3D driver, so that one also works fine now on my Athlon system.

Updated driver package attached.

Brilliant work! It makes sense that the delay loops helped, and honestly may have been inserted as a bandaid to fix this oversight. Maybe they had every intention to move that clear pipeline logic to it's own subroutine and then just forgot to finish the job after a long weekend. It would be interesting to see if the same issue is present in later drivers for the Voodoo II.