Got it fixed with QEMM386.SYS. HIMEMX.EXE & JEMM386.EXE broke many of my other games. My problem with QEMM386.SYS was that I was also using HIMEM.SYS. Removed that and everything is working again. It limits total DOS RAM to 64 Mb, but that isn't really a problem, haven't found anything DOS that needs more than that anyways. "XMSDSK.EXE /t" started working again, though I had to change the size from 496M to 48M for Privateer, but it works fine now too. I wouldn't mind having DOS show the full 511M of extended memory, but I'm not going to argue over it, as long as everything works. Now I just have to find QEMM386.SYS somewhere other than the zip file I have (want an official package, not sure where this came from.)

Newer versions of QEMM support more than 64 MB if I recall correctly, you could give that a try

alexanrs wrote:

Newer versions of QEMM support more than 64 MB if I recall correctly, you could give that a try

I found that out. I was using QEMM 8, and upgraded it to 8.03. Memory jumped up to 256 MB, but it totally broke everything 🙁 So I dialed it back to v8. Not sure if I want to try 9 ('97) the last version or not, or just stick with what works.

I`d give it a go (it`s not like you`re risking anything). Besides, you could also tinker with the command line parameters. QEMM has A LOT of features to increase available conventional/upper memory (some of which are enabled by default, AFAIK), and those might break compatibility with a lot of stuff.

Ok, have tested this s23dfx.exe, it IS statically linked. As all others similar .exes - no glide2x string and have "Glide(tm) Version 2.xxx" string inside.

Statically linked DOS glide games:
Battle Arena Toshinden - tsd.exe, 1177 kiB, Glide Version 2.03h2.
Descent 2 - d2voodoo.exe, 1667, Glide(tm) Version 2.2.
EF 2000 2.0 - _ef2000.exe, 2509, Glide(tm) Version 2.1; diagnost.exe, 946, Glide(tm) version 2.1.
Screamer 2 - s23dfx.exe, 1272, Glide(tm) Version 2.1.1.
Starfighter 3000 - star3000.exe, 1225, Glide Version 2.03h3.
Tomb Raider (Rush patch) - tomb.exe, 1114, Glide(tm) Version 2.1.1.
UEFA Champions League - uefa3dfx.exe, 2547, Glide Version 2.03h3; install.exe, 1878, Glide Version 2.03h3.
VR Soccer '96: Semifinals (OEM) - soccer.exe, 1646, Glide Version 2.03h2.
Whiplash - whip3dfx.exe, 1352, Glide Version 2.03h2.
XCar: Experimental Racing (unpatched) - xcarfx.exe, 1095, Glide(tm) Version 2.1.1.

Actua Soccer: Semifinals (OEM) and Fatal Racing (OEM) - don't have these games, can't test.

It looks like the only way is the code analysis. To find the exact way these games detect and initialize a 3dfx card. And to find why a Voodoo2 isn't always detected...

P.S. "Voodoo Graphics (Rush?) only" games:
Carmageddon/Carmageddon: Splat pack (carmav.exe, carmavg.exe).
Dreams to Reality.
Prost Grand Prix.
Screamer 2 (s2_3dfx.exe).
Screamer Rally (strt3fx.exe).
Tie Break Tennis.

Archimedean Dynasty and Battlecruiser 3000 A.D. - not sure.

alexanrs wrote:

I`d give it a go (it`s not like you`re risking anything). Besides, you could also tinker with the command line parameters. QEMM has A LOT of features to increase available conventional/upper memory (some of which are enabled by default, AFAIK), and those might break compatibility with a lot of stuff.

Well, I've tried all the parameters, and I can force it up to 256MB (QEMM 8.0,) but forcing any amount breaks XMDSK /t completely (it crashes, reports XMS errors etc..) The same thing that QEMM 8.03 & QEMM '97 do without forcing anything. Tried forcing both QEMM 8.03 & '97 to use less than 64Mb and it totally ignores the command (still sets up 256Mb of EMS.) Finally, I tried loading HIMEM.SYS with SETXMSTO.EXE (to set total RAM to 512Mb) and QEMM 8.0, 8.03, & '97 all complain that having HIMEM.SYS is a waste, then reset everything to what "they" want. Still breaks XMSDSK /t. I'm not looking at other alternatives.

One page stated that loading Window 98's HIMEM.SYS will detect up to 512Mb of XMS (which it doesn't,) then DR-DOS 7.03's EMM386.EXE will use up to 1G for EMS. Only, first Windows 98's HIMEM.SYS doesn't, and DR-DOS's EMM386.EXE is even less functional than DOS 6.2's. It also complains that HIMEM.SYS isn't needed. Regardless of how much XMS is available DR-DOS's EMM386 will "only" set aside 32Mb of EMS (up to the max XMS you have.) You can not even lower it manually like you can with DOS 6.2. Reading another page, I tried the /KB=???? command, but it was removed, and I can't find a version that still has it.

Still searching......

Another trouble with the P4 + Voodoo2 + MS-DOS 7.1 combo.
Have tested old glide2x.ovl versions (with glide2x SDK test00.exe).
All glide2x.ovl (and glide2x.dll) except 3.02.00 and 3.03.00 can't detect my Voodoo2.
"Expected Voodoo, none detected". Why Voodoo? It must be Voodoo^2, dammit...

Why spend so much time on getting a game that crashes on the second level working?

Also Screamer 2, Phil got it working as well earlier in this thread. I tested all the games on two different systems using Creative 12mb ct6670 in Sli and Diamond 8mb.

vetz wrote:

Why spend so much time on getting a game that crashes on the second level working?

But on the Voodoo 3, it doesn't crash on the second level. At least it hasn't for me. Also, if push comes to shove, I'll put my Voodoo 1 back in the system. I just don't want to use a switch box (Voodoo 1's pass-through doesn't play nice with the Voodoo 2's pass-through.) Right now, I'm playing Blood on the Voodoo 3, and all my other DOS games on the Voodoo 2 SLI.

vetz wrote:

Why spend so much time on getting a game that crashes on the second level working?

Blood "not starting" trouble was fixed (by XMS-only config or 3rd party EMS managers).
Current trouble is statically linked glide games.

Also Screamer 2, Phil got it working as well earlier in this thread. I tested all the games on two different systems using Creative 12mb ct6670 in Sli and Diamond 8mb.

I know this.
You have missed the main point - there are troubles with fast CPU/FSB/something.
The main reason of my posts - I need someone to test Voodoo2 with same/faster CPUs. To confirm/unconfirm this trouble.
The next step is - find someone with coding skills. To analyze the troubled API function (grSstInit or grSstQueryHardware) and to find the exact cause of the problem.
The last step - fix this damn bug completedly.

Feedinhdragon: That makes sense. Should work fine on the Voodoo3 😀

Gamecollector: Thanks for clearing that up. I missed the point, yes 😀

Gamecollector wrote:

You have missed the main point - there are troubles with fast CPU/FSB/something.
The main reason of my posts - I need someone to test Voodoo2 with same/faster CPUs. To confirm/unconfirm this trouble.

I had the V2's working with Tomb Raider's static version (not the Rush,) on 800 Mhz CPU 100 Mhz FSB just fine. I now have a 1.4 Ghz CPU with 100 Mhz FSB, and it won't run at 100 Mhz FSB. Lower it to 83.3 Mhz (the next lowest level I can put it,) and it starts running again. I'm afraid that's the only game I have available right now that is statically linked. I use Tomb Raider static file because, for some reason I don't know, it switches to/from the videos faster, gives Laura her shadow back, and just seems to play smoother to me. Could be my imagination, that last bit, though. I'm sure there's a perfectly logical reason for why it works better, I just haven't really cared enough to look it up 😀

But from the numbers, 100 Mhz FSB should be OK, but CPU over 1166 Mhz is iffy. But my machine, for some reason, has been extremely picky on system speeds 🙁. Other people (with the same chipset, even the same board,) haven't have the speed issues I've had. My Voodoo 2's do the same thing (refuse to work right at 100 Mhz FSB 1.4 Ghz CPU,) with the OVL files too (all the OVL's.) At 83.3 Mhz FSB or less, it works but only with the following 5 OVL files:

• v2.10 July 14, 1998
  v1.02.51 April 23, 1998
  v1.03.00 June 18, 1998
  v3.01.00 October 11, 1998 &
  v3.01.01 January 22, 1999

All the others fail regardless of what I set my FSB to. Also, before someone comments, I did play musical PCI slots with the Voodoo 2 cards.

@Feeding Dragon: can you please download this, boot in DOS, then try glide2x\dos\test00.exe with different .ovls?
To be precise - I need to confirm the error message - "glide2x.dll expected Voodoo, none detected". No Voodoo^2 reference. And to confirm the same glide2x.ovl can work/fail because of FSB.
Tnx.

Not a problem, after presents in the morning though... About to pass out (meds finally kicking in.)

Good news:
Have tested problem glide2x.ovls with the downclocked P4 3.2E. FSB 100 MHz, CPU 1.6 GHz. All glide2x.ovls work w/o troubles.
Up to 106 MHz FSB - no glitches.
107-113 MHz FSB - runs once then don't react to keyboard.
114 MHz FSB- "_GlideInitEnvironment: glide2x.dll expected Voodoo, none detected".
I have another P4 CPU (2.6C), so I will try to test with it later. Theoretically glide support will break with the same FSB frequency or with the same CPU frequency... Or something else.
P.S. All problem ovls shows 3dfx logo. Can someone try to hexedit the file (disable the logo)? Maybe this will fix speed trouble?
P.S.S. Well, I can use test16.exe. If it breaks non-downclocked P4 3.2 GHz and glide2x.ovl 2.56.0.459...
P.S.S.S. Failed.
Bad news:
This hasn't fixed statically linked games. *Censored*.

Well, I have tested P4 2.6C (Northwood, 13x) with glide2x.ovl 2.50.
Freezes and bugs start around FSB 155 MHz. Strange...

Gamecollector:

Sorry it took so long. I've tested all the OVL's I can extract from those available from FalconFly Central. Those are:

• 1. Creative 3D Blaster V2.16rc1 (15 Feb 1998)
  2. 3DFX Voodoo2 RC2 (13 Mar 1998)
  3. 3DFX Voodoo2 V1.02.50 (06 Apr 1998)
  4. 3DFX Voodoo2 V1.02.51 (23 Apr 1998)
  5. 3DFX Voodoo2 V1.03.00 (18 Jun 1998)
  6. 3DFX Voodoo2 V2.10 (14 Jul 1998)
  7. 3DFX Voodoo2 V3.01.00 (11 Oct 1998)
  8. 3DFX Voodoo2 V3.01.01 (22 Jan 1999)
  9. 3DFX Voodoo2 V3.03.00 (18 Jun 1999)
  0. 3DFX Voodoo2 V3.02.02 (27 Jan 2000)

Of those, V3.03.00 worked at all speed up to 100 Mhz. Didn't test over that. V3.02.02 never worked at any speed. All the others worked at speed of 83 Mhz or slower (50, 66, 75, & 83.) The multiplier is fixed at 14, so those speeds are: 700, 933, 1050, 1166, & 1400 Mhz. I've attached a ZIP file with text files of all the test00 runs at 100 Mhz. They are labeled 100-#.TXT where # corasponds to the number in the list (the names of the driver version is also contained in the test file. the V3.02.02 driver locked up my computer so there is no echoed output. But no error message was given when I ran it without the redirect.

I also made one startling discovery. V3.03.00 works fine in Shadow Warrior at full speed. I must have accidently skipped that one when I was testing 🙁 Or QEMM changed things up for me. As does the Voodoo Rush version of Tomb Raider's 3DFX patch. I still prefer playing Tomb Raider in Voodoo 1 mode though 😀 Shadows and much faster video switching.

Well, except the 3.02.02 version - results are same (I not tested 1, 2 and 6, will test them later). Something is wrong within grSstQueryHardware code...
P.S. Have tested 2.50rc1, 2.50rc2. And 2.53 from 2.10 drivers. Results are same as yours. Rc1 and rc2 can't find Voodoo^2.

I should note, that some of the ones on FalconFly I didn't test because they were identical (the OVL file that is,) to other versions. For example, the V3.03.00 OVL file is identical to the V3.03.00b OVL file. The other files may not be identical, but they aren't used in a DOS environment, so I didn't check those. 2 of the drivers available (3DFX Voodoo2 v2.11 & Creative 3D Blaster v2.18,) are in proprietary or encrypted install packages. I couldn't find a way to extract the OVL file without installing the entire package in a Windows environment first (which I didn't really want to do.) Also, I put the wrong date for the 3DFX Voodoo2 v2.10 driver (I've corrected it now.)

Wondering if there are any outcomes from Voodoo 3 AGP DOS compatibility testing? What is the success rate?

See page 2 in this thread