Interesting, are you able to test the Cyrix 5x86 @120mhz? Would like to see how that compares to the 133mhz version.

Are you able to tell which CPU gives a better gaming experience between the AMD/Cyrix as benchmarks don't always paint the full picture.

In terms of gaming experience, I will need to run a 15 min. test of each system first. However, from my recollection of running the timedemos, the Voodoo2 is more blury compared to the Voodoo3 and the image is not as uniform. The Quake image of the Voodoo3 is overall the best, however if the image on the GF2 could be lighten up a bit, I'd say that the GF2 would look the best. Unfortunately, I do not see any OpenGL overlay options with version 12.41 of the Nvidia drivers. Is there some add-on tweak for Nvidia v12.41 drivers to lighten up the OpenGL playback in Quake?

It would be possible to run these alternate configurations,

Biostar / UMC / Cyrix 5x86-120 / 40 MHz / 256K / 64 MB / Voodoo2
DTK / SiS / Cyrix 5x86-120 / 40 MHz / 256K / 64 MB / Voodoo3

however I don't think I am up to disassbmlying my systems at this time. The 1024k mod is partially soldered to my Biostar board and removing it would require pulling the motherboard out of the case. Leaving the 1024K in place would mean that I could not use as fast of L2 timing compared to 256K, so the results would not be representative of an optimised system. I could use a spare Biostar board, but I'd still need to pull out all the hardware and setup a test bed.

For the DTK board, I would need to drop the cache down to 256K, or possibly 512K-double banked, for the fastest L2 settings to run reliably. It would take time to establish stable settings at 40 MHz. The last time I dug into that system, something on the HDD got corrupted and I had to restore it from a ghost copy.

In short, I'll need to feel more adventerous before trying out the Cyrix 5x86 at 120 MHz. These systems are so sensitive to work with and take such a long time to properly configure that the risk of ruining the system is too great. I'm sure someone else on the forum has a Voodoo2, Cyrix 5x86, and an MB-8433UUD. If I were to speculate, I'd say the results with a Cyrix 5x86-120 are probably onpar, or marginally less, to that of the 5x86-133 system because of the faster graphics, L2, and memory FSB. The drawback would be the less cache and memory size required to make the fastest L2 timings possible. However, most people consider 256K and 64 MB more than sufficient on a 486.

No worries Feiopa Don't take your systems apart its not worth the heartache.

The question about the gaming experience was more to do with the framerates/slowdowns, was their any noticeable difference between the AMD/Cyrix? In the timedemo tests when it goes into the wide open room with that flying monster shooting with the Nail gun the slowdowns are big, just wondering if either CPU handles that scene better than the other.

it's more about fighting the bus. Texture uploads and swapping will be magnitudes nastier on a 486 so you want that reduced as much as possible. It's the kind of overhead Q3's engine was designed to avoid (although there are other major factors that make that game unplayable on the 486, such as the QVM system, the shader system (particularly deformVertex/tcMod functions) and the sound system even)

leileilol wrote:

it's more about fighting the bus. Texture uploads and swapping will be magnitudes nastier on a 486 so you want that reduced as much as possible.

That's not true as the tests show the difference between 33/66mhz is almost non-existent between the cyrix chips.

Indeed - the 66 MHz was a bit of a disapointment, however it is there for convenience. It allows you to run your PCI bus at 33 MHz and your IBM 5x86c chips at 133 MHz. I'll post the Speedsys and Cachechk results of these systems. I've put them all up on the KVM, so I can test the gameplay. Here's a shot of the 3.

The Matrox case badge on the middle case is from times past. I have been meaning to create an AMD 5x86 case badge for that centre case as this system does not even contain a Matrox card. The IBM 5x86c-133 is in the larger left-most case as this case can accomdate improved air flow. One day I should use retrobrite on those two cases on the right.

IBM / Voodoo2

Cyrix / Voodoo3

AMD / GeForce2

feipoa wrote:

In terms of gaming experience, I will need to run a 15 min. test of each system first. However, from my recollection of running the timedemos, the Voodoo2 is more blury compared to the Voodoo3 and the image is not as uniform. The Quake image of the Voodoo3 is overall the best, however if the image on the GF2 could be lighten up a bit, I'd say that the GF2 would look the best. Unfortunately, I do not see any OpenGL overlay options with version 12.41 of the Nvidia drivers. Is there some add-on tweak for Nvidia v12.41 drivers to lighten up the OpenGL playback in Quake?

to tune the brightness of quake2, you have two variables to adjust:
vid_gamma affects the gamma of whole world, the lower the brighter, usually between 0.5 and 1.
gl_modulate affects the brightness and range of lights, the higher the brighter, default is 1, i prefer 2 or 3 and some people may go higher.

after changing any of them you need to type vid_restart to take effect.

Alteration of brightness is more important in GLQuake because it has more playable frame rates compared to Quake II. Does anyone know how to change the brightness in GLQuake?

feipoa wrote:

Upon looking at the Quake II results, what stands out the most is the incredible jump in performance of the AMD/GF2 system compared to the Voodoo2 and Voodoo3 systems. What technology does the GF2 card have which enabled such a performance hike in only Quake II and not GLQuake?

I suppose the hardware T&L just has a bigger effect in Q2 than in glQuake. I think I mentioned previously that hardware T&L already could work in OpenGL before DirectX 7 came out, and games would have to be written for DX7 to use HW T&L.

For the brightness I think there is IdGamma.

That is a good study!

Is your AMD system stable at 50MHz FSB? I think that AMD 5x86 at 3x50MHz would show slightly better results since it is considered generally faster than 4*40MHz.

I would not consider the AMD 5x86 at 3x50 to be faster than the 4x40. From my experience, anything above 40 MHz will require the L2 cache slowed down via wait states (sometimes on the slowest settings) for the system to be stable. A 50 MHz PCI bus is also not considered stable. Most motherboards have a 1/2 PCI divisor, which will drop the PCI bus down to 25 MHz - SLOW. There is one such motherboard which as a 2/3 divisor, the MB-8433UUD, which allows for a 33 MHz PCI bus, however I can guarantee that the 50 MHz memory bus needs to be slowed down with wait states for it to be stable.

50Mhz would not likely work on PCI.

Here are the memory throughput results. Bear in mind that on an equal FSB-to-FSB basis, the SiS 496 chipset is usually around 1-2 MB/s faster in RAM read. I think the UMC8881 is about 1-2 MB/s faster in L2 read though. This is why the memory read throughput on the Cyrix / Voodoo3 is approximately the same as on the IBM / Voodoo2 system. 2 wait states needed to be added to the IBM / Voodoo2 system for the RAM to be fully stable. You can get away with 1 wait state if you don't mind pseudo-stable. What I find most impressive is how the AMD / GeForce2 system can compete against the Cyrix/IBM/Voodoo systems with such poor, comparitavely, memory throughput.

IBM / Voodoo2

Cachechk
L1: 272.2 MB/s
L2: 101.6 MB/s
RAM: 55.6 MB/s
L1/L2/RAM Write: 92.4 MB/s

Cyrix / Voodoo3

Cachechk
L1: 272.9 MB/s
L2: 93.1 MB/s
RAM: 55.5 MB/s
L1/L2/RAM Write: 69.3 MB/s

AMD / GeForce2

Cachechk
L1: 164.9 MB/s
L2: 74.5 MB/s
RAM: 47.8 MB/s
L1/L2/RAM Write: 83.3 MB/s

Does anyone have the results for a socket 5 P75, P90, or P100 with GLQuake using any accelerated 3D card? It would be interesting to see how these systems compare.

The POD100 (MB-8433UUD) results for GLQuake at 640x480x16 using the fastest available driver were:
GeForce2: 36.1 fps
RIVA TNT: 29.5 fps
Rage 128VR: 27.4 fps
Matrox G200: 23.4 fps

DOS Quake at 320x200: 24.4 fps.

Keep in mind that driver version 77.72 was required to get the GF2/POD score up so high. For direct comparison with the driver version used with the AMD / GeForce2 (which was v12.41), the POD scored only 29.2 fps, compared to the AMD / GeForce2's result of 28.3 fps. So essentially, you can achieve Pentium level performance out of your 486 rig with the right combination of graphics card and driver version.

idspispopd wrote:

I suppose the hardware T&L just has a bigger effect in Q2 than in glQuake.

That could be because they made the BSPs more 'leafy' in Quake II.
T&L is only efficient when you send larger batches to the hardware. Perhaps Q1 just sends triangles to OGL one at a time, as they come out of the BSP, where Q2 may batch them up a bit, so the GPU can process a batch of them at once.

idspispopd wrote:

I think I mentioned previously that hardware T&L already could work in OpenGL before DirectX 7 came out, and games would have to be written for DX7 to use HW T&L.

Indeed.
Legacy OpenGL was very high-level, so the details of where vertices were stored, or how matrix operations were performed, were hidden below the API surface.
In Direct3D you would manipulate matrices and vertex data directly. Which meant they were in system memory, out of reach for the GPU. In DX7 it became possible to store vertex buffers directly in video memory, which was required for efficient T&L.
I don't think drivers even made any effort to try and use T&L on DX < 7, even though in theory they could have copied the data to video memory themselves, and batch things up before processing.
This is how OpenGL generally works, because the classic mode of the OpenGL API is to send vertices one at a time anyway (glBegin()/glEnd()). The only way to make that remotely efficient is to batch things up at the driver side, which you might as well do in video memory, so you can run T&L on it.

dirkmirk wrote:

Are you able to tell which CPU gives a better gaming experience between the AMD/Cyrix as benchmarks don't always paint the full picture.

idspispopd wrote:

For the brightness I think there is IdGamma.

Before performing a test for best gaming experience, I downloaded Idgamma and tried my best to get it installed, however I have failed. After loading Idgamma.exe, I select one of the default configurations, e.g. for the RIVA TNT, and select "Go", which is supposed to save the configuration. Upon hitting "Go", I receive the following error,

1Disk not ready in module IDGAMMA at address 1AFC:283A
2Hit any key to return to system

Hoping that the configurated got saved anyway, I launched GLQuake, but I did not see any gamma changes. According to the [very poorly written] documentation which came with idgamma, it need to type map restart once inside the Quake console. When I type this, I receive the following error,

1Couldn't spawn server maps/restart.bsp

Any idea what I am doing wrong? I tried Idgamma in, both, Win95c and NT4 without success. The reference to "Disk" in the "Disk not ready in module..." error makes me think that this program will not work with SCSI fixed disk controllers. Or perhaps some files are write protected, or it idgamma does not agree with my Quake version.