mkarcher wrote on 2023-02-16, 18:10:

gonzo wrote on 2023-02-16, 08:40:

Can you upload the patched file for the 3DMARK2000 here, please?

Thank you, mkarcher.
Thank you once again for the lot of time you invested to adopt both 3DMARK99 and 3DMARK2000 for 486 😀

Sadly, my ZIDA-system wont't work with the patched 3DMARK2000.
First I had to install Dx7-drivers vor the Voodoo3 (Dx7-version 3.00 from 28 Oct 1999), then Dx7 itself.
After the "normal" installaton of 3DMARK2000, I patched your .exe and .dll to its main-directory overwriting the existing files.
For sure, I did a Win-restart.

But, on every 3DMARK2000-start, I got every time an error about "module E2_PENTIUMIII_CPU_MFC.DLL"...
After clicking this error away, the main menu appears, the tests etc. can be selected.
But, on the loading of test 1, 3DMARK crashes and I see the desktop again.

Of course, I use 64 MB of RAM.

gonzo wrote on 2023-02-17, 16:48:

Thank you, mkarcher. Thank you once again for the lot of time you invested to adopt both 3DMARK99 and 3DMARK2000 for 486 :-) […]
Show full quote

mkarcher wrote on 2023-02-16, 18:10:

gonzo wrote on 2023-02-16, 08:40:

Can you upload the patched file for the 3DMARK2000 here, please?

Thank you, mkarcher.
Thank you once again for the lot of time you invested to adopt both 3DMARK99 and 3DMARK2000 for 486 😀

Sadly, my ZIDA-system wont't work with the patched 3DMARK2000.
First I had to install Dx7-drivers vor the Voodoo3 (Dx7-version 3.00 from 28 Oct 1999), then Dx7 itself.
After the "normal" installaton of 3DMARK2000, I patched your .exe and .dll to its main-directory overwriting the existing files.
For sure, I did a Win-restart.

But, on every 3DMARK2000-start, I got every time an error about "module E2_PENTIUMIII_CPU_MFC.DLL"...
After clicking this error away, the main menu appears, the tests etc. can be selected.
But, on the loading of test 1, 3DMARK crashes and I see the desktop again.

Of course, I use 64 MB of RAM.

It's normal that E2_PENTIUMIII_CPU_MFC.DLL causes an invalid opcode exception, but you should only be able to see that exception as "first chance exception" when you run 3DMark2000 in a debugger. This exception is handled by the DLL itself, and that DLL is automatically unloaded again. As I don't think you are running 3DMark2000 in a debugger, you are likely experiencing a different issue. Possibly your Windows 2000 is older than the Windows 2000 installation I used. I am working with a fully updated Windows 2000, i.e. SP4 + rollup 1 + all patches distributed by Microsoft after the rollup (installed using "c't offline updater" by the german IT magazine publisher Heise). It's possible that some parts of 3DMark2000 are incompatible with older Windows 2000 variants.

mkarcher, I am using Win98SE (I forgot to tell you in my last post), maybe this is the reason for not starting 😉

Today testing:
Radeon 9250 PCI in a 486.
It already boots with an external 3.3 V supply.

gonzo wrote on 2023-02-18, 10:39:

mkarcher, I am using Win98SE (I forgot to tell you in my last post), maybe this is the reason for not starting 😉

According to the official documentation, 3DMark2000 is supposed to work with Windows 95, both the first and second edition of Windows 98 and Windows 2000. I might try Windows 98 later, but at the moment, I'm not focussed on Windows 98. There is only so much stuff I can do. Sorry for not being more helpful for now.

Disruptor wrote on 2023-02-18, 16:55:

Today testing:
Radeon 9250 PCI in a 486.
It already boots with an external 3.3 V supply.

3DMark 99 Max
486/133
285 3DMarks
354 CPU 3DMarks

Does not initialize with 40 MHz FSB = PCI. BIOS does graphics card beep.

Errors with 3DMark 2000.

In the last few days, another "little wonder" happens 😀

Testing another 486-board with a SiS496/497-chipset, there was possible to reach a stable system at 60-MHz-FSB, wich results in an AMD DX5-180 MHz, too 😀

It's good I have another CPU working stable at 180 MHz at 4,0 Volt (provided by the board) 😉

The board is a KM-S4-1 (Kaimai) Rev.1.1, but I found other names of it,too, like Azza 4SIG / Rectron RT-4s3 / Jetway J-446 / ATC-Unitron U6923.

BTW, my board is a very new/late one, as its chipsets are produced at about Christmas 1996! Few months later, the Pentium II was on the market 😉

As there is no information on the web about the 60-MHz-FSB, I played a little bit with the jumpers and finally this setting works:
On JP11, close pins 2-3 AND 4-5 . JP 12 must be closed to 2-3 (this sets PCI:FSB = 1:2).

Exactly like the Zida Tomato 4DPS (shown above) with the same chipset, this board works always with L2 dirty bit enabled, and it's only really stable at BIOS-settings "L2 Cache Policy = WT" and "L2 Cache Tag Bits = 8 bits".

So, all scores for 3DMARK99MAX under Win98Se are at 99 % equal (and equal to the ZIDA-board, too), regardless of using 32 or 64 MB of RAM, and regardless of using 256 or 512 KB L2 (so I finally choose the 256-KB-option, to spare my few ISSY-IS61C1024-modules).

Using the same V3-2000-VGA like with the ZIDA-board, a Sample-Point-setting of T2 in BIOS is possible. But, sadly, this does not have any effect of the 3DMARK-score...Not sure, but maybe this option does not work properly on this board, regardless of T2 or T3.

In GLQuake, the system reaches 11,9 FPS at 800x600 dpi.

Other results in DOS are:

-> Quake: 19,0 FPS
-> Doom: 68,14 (1096 realtics; no sound)
-> 3d bench 1.0c: 91,6
-> PCP-bench (vga-mode): 26,7

Also, this board supports EDO-RAM (I use for all tests). But, except of a higher RAM-bandwith in speedsys and Sandra 98, as well as a faster Windows-boot, all other test-scores are very close or equal to the ZIDA-board (it works only with FPM-RAM at some slower RAM-settings in BIOS).

As the board accepts a maximum size of 32 MB per RAM-slot, for 64 MB two modules must be used. This works perfectly at 60-MHz-FSB, and at very fast RAM-settings in the BIOS, too (two pieces of 50ns are used).

The manual for this board can be found here: https://theretroweb.com/motherboards/s/rectro … t-4s3#downloads.

In this manual, at least for my board-model, the jumper-settings for using of 256 KB L2 are wrong.
Using them, the system was very unstable, or it refuses to boot from any device, too.
Looking forward on the web, I found some pictures of the board using 256 KB L2, with other jumper-settings -> using them, the system works perfectly!
Here they are: JP7 -> 2-3 closed; JP8 -> 1-2 closed.

Exactly like the ZIDA-board, no COM-mouse can be used, even the COM-controller appears correctly in the device-manager (so the external CA9312-ISA-controller is used again).

Fortunately, my board has the (probably) newest BIOS for this model, so here is a copy of it 😀

more of them

more of them

and more

Disruptor wrote on 2023-02-18, 18:37:

3DMark 99 Max 486/133 285 3DMarks 354 CPU 3DMarks […]
Show full quote

Disruptor wrote on 2023-02-18, 16:55:

Today testing:
Radeon 9250 PCI in a 486.
It already boots with an external 3.3 V supply.

3DMark 99 Max
486/133
285 3DMarks
354 CPU 3DMarks

Does not initialize with 40 MHz FSB = PCI. BIOS does graphics card beep.

Errors with 3DMark 2000.

The Radeon 9250 driver emits a blue screen during texture loading. It's a memory copy operation that slightly overreads the source pages. You can skip the overread in a kernel debugger (repeatedly), and the resulting images do not obviously look wrong. I don't understand the driver well enough yet to know the root cause of the problem. Again, I am operating stuff out of spec, as the Radeon 9250 drivers are meant to be used with DirectX 8 or newer, but DirectX 8 refuses to install on a 486-class computer, so I am using the driver with DirectX 7. Possibly DirectX 7 handles mipmaps slightly differently than DirectX 8 or something like that. EDIT: It actually is a mipmap issue. When copying mipmapped textures into the graphics RAM, the ATI driver expects the 2x2 image to be padded from 4 byte per line to 8 bytes per line, but the texture in memory actually is not padded to 8 bytes per line. The heap allocator used in that driver often allocates that 8 byte range (2 rows * 2 columns * 2 bytes per pixel) at the end of a page. When the code expects padding that isn't present, it tries to locate the last scan line (or multiple scanlines for rectangular textures) past the end of the allocated memory range.

Result is in, though: R9250 / 5x86 @ 33x4 (133MHz) -> 228 3D marks (3DMark 2000). This result has been obtained on a machine with the a kernel debugger attached to skip over all the blue screens I would have otherwise gotten, so handle with care. As the blue screens happen during load time, and not during execution time of the benchmarks and as the results look plausible, I am confident the numbers still are valid.

mkarcher
Nice work, congratulations!

Will there be a fix for Final Reality?

Preliminary information:
mkarcher is enjoying his Cyrix 5x86 / 100 and plays with the chip settings these days. With enabled branch prediction it shows some surprises. Stay tuned!

Takedasun wrote on 2023-02-21, 00:36:

mkarcher
Nice work, congratulations!

Will there be a fix for Final Reality?

I did not look into Final Reality yet, but that might be possible, too. I don't even know yet what kinds of issues Final Reality might have, but if it behaves similar to 3DMark 99, similar fixes are possible, too.

Disruptor wrote on 2023-02-21, 12:37:

Preliminary information:
mkarcher is enjoying his Cyrix 5x86 / 100 and plays with the chip settings these days. With enabled branch prediction it shows some surprises. Stay tuned!

The processor I am testing with is a Cyrix branded 5x86 with a teal heatsink, which is clearly more blue than the standard green heatsink on my Cx486DX (both heatsinks are the original Cyrix colorful anodized aluminum heatsinks). It reports Stepping 1, Revision 3, and has a nominal clock speed of 100MHz, the available multipliers are x2 and x3 (and of course x1, software selectable).

Well, no real surprises for people that know the Cyrix 5x86 performance characteristics well. In "default configuration" (L1WB correctly enabled by the BIOS, but most other settings in the default configuration), it's approximately on par with a AMD 5x86 at the same clock speed. Compared to a nominal 133 MHz AMD 5x86, there is no performance reason to use the Cyrix 5x86 at nominal 100MHz.

I am happy to report, though, that this processor in the HOT-433 board (UMC8881, early revision) works fine in DOS (speedsys) and Windows 2000 (3DMark 99, 3DMark 2000) with branch prediction enabled (PCR0 = 02). Branch prediction works miracles on that processor! Compared to the default configuration (DTE caching already enabled by the BIOS), I disabled LSSER, enable BTB and enable FPFAST, which caused the 3DMark scores to jump up by about 30%. This makes a clock-trippled Cx5x86 get quite close to a clock-quadrupled AMD 5x86 in 3DMark 99, and nearly reach it in 3DMark 2000. Even more exciting: The processor even works at 120MHz (3*40MHz), if you add a fan, at least at 3.6V. I didn't try 3.45 yet. Even branch prediction works in the use cases listed before (mainly 3DMark) at 120MHz, so it gets close to the AMD 5x86 at 160. Getting 30% more IPC on the Cyrix 5x86 compared to the AMD 5x86 is an impressive feat by Cyrix, even more so as I had to add a memory read waitstate to get the 5x86 to work correctly at all. I don't need that extra waitstate with an AMD 5x86 at FSB40 or a Cyrix 486DX4 at FSB33, but the 5x86 needs the waitstate even at FSB33. Nevertheless, as finding an AMD 5x86 that works at 160MHz is way easier than finding a Cyrix 5x86 that works at 120MHz, there still is no point in going Cyrix except for brand loyality.

Windows 2000 fails with LOOP+RSTK (without BTB). Windows 2000 also fails with write bursts (might be due to mainboard incompatibility), although Quake and Doom in SPEEDSYS/DOS work with LOOP+RSTK+WBRST. The early revision of the 8881 north bridge doesn't support linear bursts (I tried manually setting the bit in PCI configuration space, only to find out that this bit is stuck at zero), so I skipped testing anything with linear burst. Possibly the extra read waitstate on the RAM is needed to properly support the 1+4 burst pattern of the Cyrix 5x86. I definitely should get the MB-8433UUD from storage (it has a late 8881) and compare performance.

mkarcher wrote on 2023-02-21, 21:34:

Disruptor wrote on 2023-02-21, 12:37:

Preliminary information:
The early revision of the 8881 north bridge doesn't support linear bursts.

Good work, mkarcher.
Would you please tell us, which board-revision of the HOT-433 exactly do you use/mean?

mkarcher, as far as I can recall, you should be able to use the Cyrix 5x86 at 120 MHz using fastest timings (2-1-1-1 sram, 0ws/0ws dram) on the MB-8433UUD provided you use 256K double-banked cache. If you are testing in Windows, I assume you are using a Stepping 1, Revision 3 CPU rated at 100 MHz. Sometimes when overclocking the Cx5x86, some of the fancy features, like BTB, FP_FAST, DTE, LSSER, etc may not be fully stable at 120 MHz. I've noticed some early 3D games don't like some of the Cyrix features. Off the top of my head, I don't think Turok or Quake II liked FP_FAST, at least not in glide mode. I didn't test in software mode. More details here: Voodoo 1 vs. Voodoo 2 on a 486

gonzo wrote on 2023-02-22, 09:42:

Would you please tell us, which board-revision of the HOT-433 exactly do you use/mean?

You can see a photo of the board here: download/file.php?id=73291&mode=view
My 486 UMC8886/8881 Project (Version 2.0)

On the system shown above (KM-S4-1; AMD DX5-180; 64 MB EDO; 256 KB L2) I tested a Voodoo Banshee, too.
Interestingly, this VGA has in DOS a slightly better performance than the Voodoo 3:

Quake: 19,2 FPS
3DBench 1.0c: 97,7
PCPBench (vgamode): 27,1
Doom: 70,46 FPS (1060 realtics)

In Win98SE, they are:
GLQuake: 26,0 FPS
Quake II: 11,7 FPS
3DMARK99MAX: 425 3DMARKS; 479 CPUMARKS

Like using the Voodoo 3, there is no performance-difference of having T2 or T3 in BIOS (both options work).

This Voodoo Banshee is from Creative (a 3D Blaster Banshee PCI, CT6760).
It was only possible to use it in 3D installing the original drivers from Creative.
To run Quake II in full screen mode, the additional driver 3dfx-minigl-1.49 must be installed (I did not test older versions of minigl).

I also tried other VGAs from Nvidia: Geforce 2 MX/400, Elsa Erazor II (Riva TNT) and a Riva TNT 2 M64 with this board.
For all VGAs, I used appropriate drivers like Detonator 6.31, 8.05, and some older/newer ones.
In 2D, there are no problems. Sadly, no one 3D-software works (even starting the Dx6-box and trying to see the VGA-properties crashes).

and the most important pic: