Why are you using such a new driver version? The answer to your question is in the original post. I listed specific driver versions for a reason - no other versions worked.

Also, my experience with the HOT-433 is such that the board is flakey like PC Chips. So if you install the correct driver version and it still doesn't work, try another motherboard.

PNY GeForce2 MX400 64MB Win95c NVIDIA Detonator v12.41 for Am5x86, however I was unable to get Direct3D working (e.g. Outlaws, M […]
Show full quote

PNY GeForce2 MX400 64MB
Win95c
NVIDIA Detonator v12.41 for Am5x86, however I was unable to get Direct3D working (e.g. Outlaws, MDK). OpenGL works with the Am5x86 with v12.41, however Direct3D games will require a POD. NVIDIA Detonator v77.72 for POD.

AMD Am5x86-160 - GLQuake (nosound, 640x480x16) = 26.7 fps [with sound at 1280x1024x32 = 24.4 fps]
AMD Am5x86-160 - QuakeII (nosound, 640x480x16) = 15.5 fps

Thank you, feipoa, now I really see this 😉
I will check the Nvidia Detonator driver versions 6.31 and 8.05.

BTW, the Direct-3D-test from the DirectX-panel (the rotating cube) works perfectly with the 44.03...

I already know your experience with the HOT-433 posted here on VOGONS...
Another board I have is a ZIDA Tomato 4DPS, but I am a little bit scarry to use it due to your experience posted here, again 😉
I also have a Voodoo 3 here - it doesn't post with the HOT-433, as reported earlier in many threads here.

Maybe, if the HOT-problems persists, I will re-think my position about the ZIDA-board...

No luck, even with NV-drivers 6.31 and 8.05. Exactly the same problems like above. Any other tests exept of GLQuake work perfectly.
In my eyes, for GLQuake it seems to be a problem of the combination mainboard<->Geforce-VGA, or UMC-chipset<->Geforce-driver.
I could take another VIA-board from somebody (it's a FIC 486-PIO-2), must check if it works good with the DX5-133 or not (I already found the latest BIOS-versions for it).
The VIA-486-chipset is known for it's average/weak RAM-performance, but for now I remain optimistic...

You need to try version 12.41. In many cases, only one driver version would work when trying to use these more modern cards on a 486.

to make it short, has anyone ever got both d3d and opengl games running on amd486dx5+gf2mx so far? whatever mainboard it is.
i had success on riva128 but havn't tried gf2mx yet.

i had also tried rendition1000 before but i think windows just froze at loading desktop, only windows bundled driver(which had no 3d support) worked. maybe someone else can give it a try.

Adding 3.3v to pci adapter(Released)

This may be of some help for bringing more cards to the table.

But many of these 486 chipsets is seems have pci specs that are too far out of date for some of the cards even with 3.3v

Sorry for asking the same questions again, and sorry for the long explanations.

Something is still going wrong about playing GLQuake 1 on all my 486-configurations,
so I start to think that eighter my install-procedera or the files I am using is/are wrong...

Meanwhile, I choose to work with the ZIDA Tomato 4DPS (Ver. 1.0), BIOS-Ver. 500A,
with 32 MB RAM and 256 KB L2.
The CPU is an AMD DX5-133 with absolutely no overclocking at this time.
The VGA is still the original 3dfx Voodoo 3 2000 16 MB PCI I used in another topic with a PC-Chips 486-board.
The soundcard is a Creative Soundblaster AWE64, CT4520, ISA.

What I did, and what works pretty fine:
1. Clear new install of Win 98SE
2. Install of the V3 Driver kit: 1.01.02
3. Install of the AWE64-soundcard with the onboard-98SE-drivers
4. Test successfully the hardware with the DirectX-6.1a-tool (onboard in 98SE), including all 3D-tests for the V3 (the rotating cube etc.)
5. Install of Quake 1.06 as shareware (I still do not found the full version anywhere...).
6. Install and test successfully of WinQuake in the Quake-directory in C: (of course, the DOS-version works fine, too).
Winquake remains in the quake-directory before installing glquake (is this so correct?).

Now the problems start here:

7. Tests of two different versions of GLQuake (glq1114.exe and glq1022.exe) are both not successfull 🙁
I choose the installing of the Voodoo-gl-drivers included in glquake.
The desktop-color in Windows (2D) is set to 16 bit (@ 1280x1024 dpi).
I have add to the desktop-shortcut of glquake the string "-width 640 -heigh 480 -nosound -nocdaudio -nonet -nojoy +timedemo demo2".

In all cases starting glquake I see the blue runing bar during the color-adjustments, then the resolution changes (as expected), finally I see the
fullscreen-animation of the 3dfx-logo and...NOTHING HAPPENS ANYMORE (= empty black screen).

A really very frustrating problem...

By the way, I got exactly the same problem some months ago testing a Geforce 2 MX on some other 486-boards using 95/98SE/ME (then deleting the opengl32.dll from
the quake-directory because of not using a Voodoo-VGA).

So, in fact, the same problem occurs using different VGAs on different mainboards and in different Windows-Versions...Very strange...

Can somebody help, please? Thanks alot.

SUCCESS!!!

The only missing additional step to run GLQuake under Win95/98/ME is to add the option "-window" to the shortcut-string on the desktop.

Unfortunately, this information is missing in all threads I have checked until know (please correct me, if I am wrong), so maybe this should be very important for some users of 486-systems,
because no one of my test-systems does start without this "-window" addition.

So, the correct string seems to be:

glquake.exe -window -width 640 -heigh 480 -nosound -nocdaudio -nonet -nojoy +timedemo demo1 (or "demo2" if desired).

At normal non-OCed-conditions, my system shown above (Tomato ZIDA 4DPS; AMD 486-DX5-133 WB; 32 MB FPM; 256 KB L2 WB; Voodoo 3 2000 16 MB) has a score in GLQuake demo1 of 17,7 FPS (54,8 sec).
A nice result, I think 😀

I hope, I can do an OC-test soon, too.

I run GLQuake1 in full screen mode.

Btw, i find Zida motherboard very flaky. Maybe that's why you are having a problem ?
At the same time you indicate "multiple test systems", so can this be a driver(s) issue ?

Breaking News:
Now benching 1st time with a bugfixed 3D Mark 99 Max
Prior to this test 3D Mark 99 Max raised wrong values on a system without RDTSC command (486, 5x86).
Re: 3dmark99 MegaThread

pshipkov wrote on 2023-02-06, 19:27:

I run GLQuake1 in full screen mode.

Btw, i find Zida motherboard very flaky. Maybe that's why you are having a problem ?
At the same time you indicate "multiple test systems", so can this be a driver(s) issue ?

I tested in the last months some combinations of 486-PCI-mainboards (Zida 4DPS Rev. 1.0, HOT-433 Rev. 1 and Rev. 4; ECS UM8810-PAIO Rev. 1.1 and 2.1) and PCI-VGAs (Voodoo 2, Voodoo Banshee, Voodoo 3 2000; Geforce 2 MX 400 from Gigabyte).
Also, I used many different appropriate old driver-versions for the VGAs (in accordance to the experience of feipoia and other users here).
Every single test was done by a clear new system-installation.

Any time I got exactly the same troubles, regardless of any BIOS-settings and VGA-driver-settings.
The "-window" add-on is the only possibility for me to start qlquake...

What is interesting to see at the start of glquake, is, that even in window-mode, the display-resolution changes to 640x480 in generally.
That means, at higher desktop-resolutions glquake does not appear/start into a smaller window (with the rest of the desktop visible around it).
On the other hand, the frame of the 640x480-window is sometimes visible (it is sometimes a full-screen window-mode). Really strange...

Just to prove it, I will test this soon with a HOT-433 and a Geforce 2 MX 400, too.

On my ZIDA 4DPS, I was able to get an AMD DX5-133 working stable at 180 MHz (5,0 Volt; FSB 60 MHz x 3.0).

As known, they are some few DX5-models able to work at this high voltage.

Sadly, my CPU was not stable at 200 MHz/FSB 50 MHz (it's only POST-ing).

Maybe because of the 1.0-board-revision, no one of some DX5-CPUs tested work stable using the 3,6V-settings shown on stason -> fully unstable even in DOS and under non-OC-conditions.

Fortunately, the ZIDA works great at FSB 60 MHz (FSB:PCI = 1:2) even with 512 KB L2, BUT only with one piece of 32 MB FPM-RAM (fully stable in DOS and Windows until now). Using some different single modules of 64 MB FPM (even with Samsung chips) goes always wrong (= very unstable system, no stable DOS-/Windows-boot).

The BIOS-settings are the best possible ones.

Finally, I did some tests in Win98SE 😉

Sadly, speedsys in DOS sucks at the ATAPI-test (speedsys /sp does not help), so it must be started in Windows as a "fast test". The CPU-score is 66,04.

The only thing I wonder, is the score of 26,6 FPS in demo 1 / GLQuake.
This is very close to feipoia's result of his combo DX5-160/FSB 40/Geforce 2 onto an UMC881F-board (26,8 FPS), and far away from a Cx586-133/FSB 66/Voodoo 3 (28,2). So, in fact, the higher FSB and a "plus" of 20 MHz for the CPU here are not really an advantage...I assume, this is caused by the low RAM-throughput of the ZIDA.

EDIT: all of my glquake-test here are at 640x480 dpi, so they can not be compared to feipoia's results (made in 800x600 dpi). Sorry, but I noticed that some days later...

Some more pics.

More of them.

By the way, my ZIDA-board does not recognize any COM-mouse, too (as this problem is already known from other users here).
So, I had to use an ISA I/O-controller ( it's a CA9312, also shown on stason), with all options disabled except of the COM-and LPT-ports.

gonzo wrote on 2023-02-08, 18:24:

Some more pics.

May I ask, why do you use L2 cache tag bits 8bits? 7bits is a lot faster, because the 8th works then as dirty tag ram.
And your 512kB are enough to still cache all 32MB with 7 bits.

Or was it crashing with 7bits?

EDIT: typo fixed

CoffeeOne wrote on 2023-02-08, 19:22:

May I ask, why do you use L2 cache tag bits 8bits? 7bits is a lot faster, because the 8th works then as dirty tag ram. And your […]
Show full quote

gonzo wrote on 2023-02-08, 18:24:

Some more pics.

May I ask, why do you use L2 cache tag bits 8bits? 7bits is a lot faster, because the 8th works then as dirty tag ram.
And your 512kB are enough to still cache all 32MB with 7 bits.

Or was it crashing with 7bits?

EDIT: typo fixed

At 7 bits, there is no booting of Windows possible (crash after few seconds).
A DOS-boot is possible, the Speedsys-problem still remains like discribed above.

There is another 4DPS-thread here on vogons (My first 5x86 build (also motherboard component level repair)), maybe I should try an older BIOS-version to reach some more speed, so I will try this soon.

gonzo wrote on 2023-02-09, 09:00:

CoffeeOne wrote on 2023-02-08, 19:22:

May I ask, why do you use L2 cache tag bits 8bits? 7bits is a lot faster, because the 8th works then as dirty tag ram. And your […]
Show full quote

gonzo wrote on 2023-02-08, 18:24:

Some more pics.

May I ask, why do you use L2 cache tag bits 8bits? 7bits is a lot faster, because the 8th works then as dirty tag ram.
And your 512kB are enough to still cache all 32MB with 7 bits.

Or was it crashing with 7bits?

EDIT: typo fixed

At 7 bits, there is no booting of Windows possible (crash after few seconds).
A DOS-boot is possible, the Speedsys-problem still remains like discribed above.

Well, WB without dirty is always dirty and works almost like write-through.
So you'll definitively lose some percent of performance.

And on 486, SpeedSys won't show difference in L2 write cache performance because during the write test the L2 is cold (not pre-initialized).

Today I spend a little more time with the 4DPS 😀

For CPU at 180 MHz (FSB 60 MHz):

- using of BIOS 400A has the same benchmark-results like 500A.

- using of 256 KB L2 instead of 512 KB L2 (BIOS 500A) results in a glquake-score of about 25,3 FPS (about -1,3 FPS)

- using of BIOS 1.72F (no CPU burst write) and 512 KB L2 results in 26,2 FPS (about - 0,4 FPS)

Decreasing the FSB to 40 MHz (FSB:PCI = 1:1) and CPU at 160 MHz allows to have better RAM- and cache-timings, as well a better RAM-throughput in SiSoft Sandra 98, but results in only 24,1 FPS in glquake.

So, finally, the higher CPU-frequency of 180 MHz "wins the run" - maybe it could be even better by using faster L2-chips (12;10 ns -> chips I don't have) to reach better BIOS-timings...

Just for fun, I oc-ed the Voodoo 3 2000 to a Voodoo 3 3000 using Powerstrip (GPU/RAM at 166 MHz, because the RAM-chips are ones with 6 ns).
But, the qlquake-score doesn't change (as this can be expected, too).

Fascinating

Have you tried 40 MHz with LBD# Sampling point of T2 too?