meljor wrote:

@vetz : can you please fix the dead link on page 2 about the v3 compatibility list?

Fixed 😀

Hi, I have a PIII-500 with a SLI of A-Trend Voodoo 2 12mb, a Geforce 4 Ti4200 on an Asus Tusl-2 motherboard

Every windows glide game plays perfectly, GTA 3DFX plays fine in DOS, Tomb Raider 1 plays fine with the Voodoo Rush patch. Everything seems fine you would tell me ?

Well, i have a problem with some of the DOS Glide games. For example, Screamer 2 won't detect my Voodoo 2 setup with any of the patch available, even with env variables. I am unable to have the Tomb Raider Voodoo 1 patch to recognize my cards (not a big deal as the Rush patch works, but it seems to show there is a problem).

After a long time testing (trying only one card plugged, trying to change the slots as advised by some people), i came to what seems to me an obvious conclusion : It seems like environment variable have no effect on my voodoos 2. Either the game detect correctly the cards (like GTA) and i don't need env variables, or the cards are not detected and then no env settings would change anything (that is not a env memory space problem as it is set correctly in my autoexec.bat/config.sys files)

Does somebody got the same problem with A-Trend helios Voodoo 2 12mb ? Is there a simple test (instead of game detection) that would show me if there is an effect with a env variable or not ?

I had a lot of problems getting my Voodoo cards to be detected correctly with various drivers & games. In the end the fix was simply to slow down my system a bit. Check and see if there are any tools for your MB that will allow you to change FSB & such on the fly. That's the solution I ended up going with.

remax wrote:

Screamer 2 won't detect my Voodoo 2 setup with any of the patch available, even with env variables.

Voodoo2 plus a statically linked glide game work only with a slow CPU. Known "feature".
Affected games are: Battle Arena Toshinden, Descent II (d2voodoo.exe), EF 2000: Tactcom, Screamer 2 (s23dfx.exe), Starfighter 3000, Tomb Raider (1114 KiB tomb.exe), UEFA Champions League, VR Soccer '96, Whiplash, Xcar: Experimental Racing (unpatched).

Hm, I guess I have a question here. Sometimes I play the old Tomb Raider with Voodoo cards and once I had a batch file full of environment variable settings for Voodoo 2. Then I had data corruption on that HDD and no matter how long I googled I couldn't find the right settings anymore. So Tomb Raider runs with awfully garbled colors on V2 while it's perfect on V1. Does anyone know what settings I should use?

Please define "slow cpu"

In this context, Slow CPU = to reduce the speed of the CPU in use. Usually accomplished by reducing the FSB (Front Side Buss) speed. The PIII-500 Mhz is probably FSB 100 Mhz with a x5 Multiplier (IIRC.) So, dropping the FSB to 50 Mhz would slow the system down to 250 Mhz. Which is more in line with what early Voodoo cards were expecting. Depending on the MB, there are DOS utilities that can change these on the fly. So, in the batch file (that sets your environment variables & runs the game,) you would change the FSB, set the variables, run the game, remove the variables, and finally restore the normal FSB. With P-III and beyond, IIRC, the multiplier became locked, so you usually cannot change that 🙁 Though I've heard of some P-IIIs that weren't locked. The other options for slowing down the CPU are to disable the L1 and/or the L2 cache. Those are a little more drastic in reduction, though. Usually when you are trying to match 8088, 286, or 386 speeds.

FeedingDragon wrote:

In this context, Slow CPU = to reduce the speed of the CPU in use. Usually accomplished by reducing the FSB (Front Side Buss) speed. The PIII-500 Mhz is probably FSB 100 Mhz with a x5 Multiplier (IIRC.) So, dropping the FSB to 50 Mhz would slow the system down to 250 Mhz. Which is more in line with what early Voodoo cards were expecting. Depending on the MB, there are DOS utilities that can change these on the fly. So, in the batch file (that sets your environment variables & runs the game,) you would change the FSB, set the variables, run the game, remove the variables, and finally restore the normal FSB. With P-III and beyond, IIRC, the multiplier became locked, so you usually cannot change that 🙁 Though I've heard of some P-IIIs that weren't locked. The other options for slowing down the CPU are to disable the L1 and/or the L2 cache. Those are a little more drastic in reduction, though. Usually when you are trying to match 8088, 286, or 386 speeds.

I'm gonna try that when i'll have time. I think (but not 100% sure) that i did try slowdown using latest registered version of BREMZE without any success, but i'm sure i didn't try FSB changing.

I found Windows exe that is able to change it live for my TUSL-2, but under Windows. I'm still looking for a DOS util that does the same.

Run time slow down programs usually do this by eating CPU cycles (not always.) This may not work for low level drivers. To work with those usually requires a lower level, BIOS or lower usually. That includes lowering the FSB, disabling the L1 and/or L2 cache, lowering the clock multiplier, or lowering the PCI or ISA buss speed. On my system, for some reason, all of the DOS methods of disabling the L1/L2 cache cause a system reboot, so I'm left without that option, and the CPU clock multiplier is locked, so that's out as well. Luckily, I can lower the FSB enough that my Voodoo cards all work correctly.

Could someone please let me know which glide2x.ovl they used when getting Descent 2 working under DOS? I've got an SLI setup and using the unofficial descent patch I still get a blank screen when running the game.

Update: I removed not important stuff from the post:
Just trying to make work Voodoo 3 on my modern X58 machine - if ~85% pure Dos games could work here too with sound and 90% without sound, 3dfx cards could work too, there is too much superstition about new fast hardware, i have Voodoo 2 in drawer too.

Some horrifying list of glide variables:
http://patrizio1.tripod.com/var.htm

Question, tested someone Vooodoo2 + modern PCI-E card like - ATI X800 or Geforce 6/7/Geforce 220? - all of these are working in pure Dos fine.. except glitches in very few games.

Ok i read whole thread, my Jay2cents..:

1. Where really need to V2/V3 compatibility table in one file, or link. I can glue it together in MsPaint, but it would be better if Vetz could use share text version in google docs / zoho.com sheets etc.. to make possible to copy result in plain text and make some text file for Dos.. Yes i can open picture in Pure dos, but because on 1 monitor, its cumbersome.. printed machine need some light, ugh..
2. Thread should be renamed to V2/V3 at least maybe even more add V1,V4,V5
3. Content of thread should be Pure DOS, but there are lots of Windows related stuff, its sometime hard of recognize that is Dos and Windows / Windows 9x Dosbox stuff..
4. Only Phil and few others did really very useful post with step by step hints and info about used driver version.
5. Few people wrote here / linked here some testing utils or public demos (Hexen 2 Dos demo, Red Guard demo, Tomb raider 3dfx demo), but link are dead, it would be nice to create some proven free public package to test machine + card, because on everyone have same game, same localization etc and we cant share them on binary level. Same with drivers.
6. Too fast CPUs - tthere was lots of info about it.. but nothing about software slowdowns, etc at the end few words about setmul and that is too slow.. When are lots of others - like Slowdos, MSRED, Throtlle etc.. which can do more that only disable some L1/L2 cache, did actually someone tested them? If there is pure FSB problem it will not work, but it looks as only V1 and maybe V2 problem. Setmul is on Core 2 Duo and other very very slow, on X58 is could simulate slow 486 what is enough for 3Dfx playing, but enough to test if problem is CPU speed related.
7. Did someone make Q2DOS work with Voodoo- i confused that it is working some .dxe files instead of ovl? Its running fine in software on X58 with all old and modern GPU which is tried, even with sound is working on Realtek HD integrated sound card (big achievement..). Added error message screen at to the post footer.
8. In compatibility sheet, should be also except game version, patch link and variables if there are needed also info, about in which mode its proven that game is working - EMS / NOEMS, realmode (Himem.only), or was used JEMM, QEMM etc.... because it making difference too, especially when lots of sound card drivers requiring EMS running, other fact is that is probably no dos games which needs more than 64MB of RAM, so HimeX+burnmem.sys +Himem.sys should be used to trigger unnecessary problems + info used hardware if reported as working..
   We need a bit removal of magic variables and unnecessary fiddling with some hard facts instead.. IMHO its too much such thing in this thread and that is what this site is about.
9. Blood+V3 - im getting Failed grSstQueryHardware what is mean, unrecognized HW or too fast machine, has anyone clue?

I made small testing package with all official V1/V2/V3 *.ovl files which i have found on Phils(thx) site, if there is some unofficial file which working better for pure Dos, tell me.

I also added compatibility matrixes as png files and few *.bat files with Glide variables which i found on net + txt with Glide variables from Vogons 3Dfx Viki. And there is keko ovl for testing which im using for Dosbox testing (im trying to test game in Dosbox first before migration to real machine), its from some old Gulikozas build, it could be outdated.

Also could help, that at least TES: Redguard (you have to install it from Windows, im using for it Win98 virtual machine and revert to snaphost, same im doing with Win9x drivers to muck the system.) + Tomb raider have 3DFX capable demo, if there more just tell me.

I could save some time for someone who will start with testing.
-----
My machines with X58 i wasnt lucky with V2/V3 cards game executables arent able to find the cards.. grSstQueryHardware error everytime in pure Dos, i tried some slowdos utils no luck, my O.E.M board has not Underclocking possibility.. so no way here. PCI-E GPU + Voodoo 2 is working at least for 2D picture passthrough..

Second machine Core 2+i865+Geforce 6 in AGP slot, with Voodoo 2 no luck, same error, underclock to 800MHz to enough, there so possibility to fiddle with FSB, only CPU speed parameter is available in the bios.
With V3 - i finally made some success - i made it as primary booting Videocard - bios has init frist PCI/AGP settings.. i made QDOS and Q2DOS working, i wasnt lucky with other games Blood,Carmageddon, Tomb raider 3DFX demo is starting only in software only.. but at last, i have tried Redguard demo and its working, so even GLide2x.ovl could work with my machine, Q*DOS is using own glide3.dxe drivers and some mesa openGL stuff.

I have question about Blood for V2 you need some magic variables V3 is reported as compatibile, is there any variables? What about resolution is something else than 640x480 working, is ok set resolution through setup?

Ok, i made Blood working too - i used real mode (Himem.sys only), laster V3 - ovl in my package, there were some problem with resolution.. I used batch for V2 and its working for 640x480, but never was successful with other resolutions.. i fiddle with setups resolutions and batch resolution, 640x480 its probably working, because i was V1 res.

Blood needs 53 MiB of RAM and always uses EMS if an EMS manager is active. The trouble is - EMM386 emulates 32 MiB EMS. Or less.
Run Blood with the XMS only setup (the NOEMS option for EMM386.EXE).

Gamecollector wrote:

Blood needs 53 MiB of RAM and always uses EMS if an EMS manager is active. The trouble is - EMM386 emulates 32 MiB EMS. Or less.
Run Blood with the XMS only setup (the NOEMS option for EMM386.EXE).

That's wrong information.

Blood is a DOS/4GW game, it runs in 32-bit protected mode using DOS extender. Such class of games/application do not deal with EMS/XMS shits. The memory is just memory. If you are familiar with the early history of 386 protected mode conflicts, then you would understand the story of 386 memory managers and DOS extenders competing for machine control for protected mode. VCPI and DPMI specification are the answers to address such conflicts and allow DOS extenders and 386 memory managers to co-exist peacefully.

DOS/4GW or any DOS protected mode games/application do not need HIMEM.SYS and EMM386.EXE, in fact they would run best without them. They are less sensitive to free memory in the 640KB DOS memory.

Gamecollector - I know, i know, your post helped me fix it years ago.

kjliew wrote:

That's wrong information. […]
Show full quote

Gamecollector wrote:

Blood needs 53 MiB of RAM and always uses EMS if an EMS manager is active. The trouble is - EMM386 emulates 32 MiB EMS. Or less.
Run Blood with the XMS only setup (the NOEMS option for EMM386.EXE).

That's wrong information.

Blood is a DOS/4GW game, it runs in 32-bit protected mode using DOS extender. Such class of games/application do not deal with EMS/XMS shits. The memory is just memory. If you are familiar with the early history of 386 protected mode conflicts, then you would understand the story of 386 memory managers and DOS extenders competing for machine control for protected mode. VCPI and DPMI specification are the answers to address such conflicts and allow DOS extenders and 386 memory managers to co-exist peacefully.

DOS/4GW or any DOS protected mode games/application do not need HIMEM.SYS and EMM386.EXE, in fact they would run best without them. They are less sensitive to free memory in the 640KB DOS memory.

The problem with that is that I had to either have no EMS or 53+ MB of EMS or Blood just would not run. Actually, I don't remember the specific amount, but it was over the 32 MB that DOS 6.22's EMM386 provides. I ended up having to go with another memory manager (to avoid multi-boot.) So, Blood may be DOS/4GW game, but they must have programmed it to check on EMS for some reason. Never tried just not loading HIMEM or EMM386, so don't know what Blood does then for sure. But, without NOEMS on the EMM386 line Blood wouldn't run. Replace memory manager with QEMM and set for 53+ MB EMS, Blood runs just fine.

FeedingDragon wrote:

The problem with that is that I had to either have no EMS or 53+ MB of EMS or Blood just would not run. Actually, I don't remember the specific amount, but it was over the 32 MB that DOS 6.22's EMM386 provides. I ended up having to go with another memory manager (to avoid multi-boot.) So, Blood may be DOS/4GW game, but they must have programmed it to check on EMS for some reason. Never tried just not loading HIMEM or EMM386, so don't know what Blood does then for sure. But, without NOEMS on the EMM386 line Blood wouldn't run. Replace memory manager with QEMM and set for 53+ MB EMS, Blood runs just fine.

Gosh, that does not mean that Blood uses EMS memory.

In the DOS era, I almost always used QEMM386. I can give you the true explanation of the issue you were experiencing back then. The short answer, MSDOS 6.22 EMM386 sucked. The long answer, early version of EMM386 did not provide unified EMS/XMS memory similar to the most popular 3rd-party 386 memory managers such as QEMM386 and 386MAX. However, EMM386 was the VCPI server when EMS was active and DOS extenders were required to talk to VCPI server to release machine control and provide available memory map for DOS extenders to enter protected mode. If EMM386 only managed EMS memory, then it could only provide the available memory map from the free EMS memory that it managed. It had no clue of how much XMS memory was in used as that was managed by HIMEM.SYS. On the other hand, QEMM386/386MAX did unifed XMS/EMS/VCPI memory management, hence they had full picture of the total free memory that can be released to DOS extenders, not just the free EMS memory.

Back in the DOS era, I never had to play with explicit allocation of EMS and XMS memory with QEMM386. I knew some people had to do that because they just used whatever came with MSDOS, or they had motherboard with chipsets based EMS support. I knew early 386 chipsets had built-in EMS support and the BIOS SETUP had memory configuration to partition "Extended" and "Expanded" memory - a legacy from the 286 era. So with QEMM, I am pretty sure that even if you restrict EMS memory to 16MB, Blood or any DOS/4GW games would still run happily.

Microsoft EMM386 improved over time, too. The version comes with Win98 does unified EMS/XMS memory even though it still requires HIMEM.SYS to load before it. So that basically closed the most critical gap between EMM386 and 3rd-party 386 memory managers.

kjliew wrote:

Gosh, that does not mean that Blood uses EMS memory.

I never said it did. I just said it tests it, if its there, for some reason. Trying to get my compatibility system back up and running, and if I succeed, I'll do more testing. But it definitely complained about not enough EMS when I had it enabled with EMM386. It was somewhere (on here I believe,) that someone said to just turn off EMS, and that temporarily fixed the problem. Until I had another game I wanted to install & play that required it 🙁 It was then that I discovered the 32 MB cap of DOS 6.22's EMM386 (or HIMEM.SYS) and started trying to get past it. What I ended up with:

QEMM386 for upper management with 64 MB of EMS & 64 MB XMS (383 MB not used - 512 MB total installed) and XMSDisk to eat up EMS and/or XMS RAM for the game that complains when there's too much (Privateer IIRC.)

Also, this is the 3DFx version of Blood, don't know about the normal version. It may not have this issue.