Coming back to this interesting benchmark, I'm curious to understand what games would especially benefit of Win 3.1 performance of the high-end cards?

Parni wrote on 2020-12-07, 07:52:

Coming back to this interesting benchmark, I'm curious to understand what games would especially benefit of Win 3.1 performance of the high-end cards?

Some native Win3.1 game. Not many of those... Civ II and Battle Isle 3 come to mind. Neither are real-time, so at best some cut-scene videos will be smoother, or the resizing of windows or such.

Yes. Some Windows 3.1 games used Windows GUI primitives. Like card games or simple arcade/puzzle games running in Windowed mode. These might get some acceleration and might get smoother, especially at high-resolution modes.

Then there is a handful of games that use WinG (Windows 3.1 API - predecessor of DirectX). These are unlikely to benefit from acceleration as they will suffer from the same CPU / host bus speed bottleneck just like in DOS. The purpose of WinG was to bypass GUI-centric Windows APIs and enable them to run. Especially if considering animated action games like WinG Doom.

Back in early 1990-05 nobody was buying more advanced graphics cards for games. Those were made for high-res GUI work and professional software.

OK, I'm a bit struggling as I'm setting up 486 setups intended for LAN partys, but started to think are there enough of good IPX games available from the 486-era, Doom, Duke and C&C are obvious ones, but started to hesitate should I go for Pentium builds to get more available games...

I think you'll have a much better Lan party with Pentium systems. The only reason I upgraded my beloved & elegant Am5x86 & mobo for an butt ugly 430FX with a grey market Pentium 133 was because I was going to a lan party. Oh Igor at at the local Microexperts strip mall store , where did you find those parts? The price was right and that's about it. Anyway, the 486 core could crunch through single player Duke & Decent at acceptable frame rates in the privacy of my own home, where noone saw the occasional frame rate drops, but multi player and peer scrutiny really demanded a Pentium. It was a great lan party, btw, but *sadness* I dropped my Multiscan 15sf trying to unlock my apartment door. The on-screen controls never worked again.

Disruptor wrote on 2020-09-25, 21:10:

reveals that Cirrus Logic cards access the VL bus with 16 bits only

Wait whaaaaaaaaaaaaaaaaat????
Is it all a big bluff than???

What about this???

Source:
http://www.elemar.pl/PDF/CL-GD5422.pdf

CL chips are very fast for 16 bit accesses, they just do 32 ones in two turns. At the time pretty much no software wrote to Video ram at 32bit. Doom for example was doing 8 bit writes! I think Duke 3D finally optimized to 32bit writes, most likely also Quake, but at that point you had Pentium with PCI.

rasz_pl wrote on 2023-09-29, 11:07:

CL chips are very fast for 16 bit accesses, they just do 32 ones in two turns. At the time pretty much no software wrote to Video ram at 32bit. Doom for example was doing 8 bit writes! I think Duke 3D finally optimized to 32bit writes, most likely also Quake, but at that point you had Pentium with PCI.

sorry, added more stuff while more replies coming, I'm editing this and re-writing it below.

aries-mu wrote on 2023-09-29, 10:56:

Wait whaaaaaaaaaaaaaaaaat????
Is it all a big bluff than???

What about this???

Please read page 3-3 and 3-4. You may also look at page 3-30 and 3-37 and 3-40.

Disruptor wrote on 2023-09-29, 11:10:

aries-mu wrote on 2023-09-29, 10:56:

Wait whaaaaaaaaaaaaaaaaat????
Is it all a big bluff than???

What about this???

Please read page 3-3 and 3-4.

oh ok lemme see, thanks...

rasz_pl wrote on 2023-09-29, 11:07:

CL chips are very fast for 16 bit accesses, they just do 32 ones in two turns. At the time pretty much no software wrote to Video ram at 32bit. Doom for example was doing 8 bit writes! I think Duke 3D finally optimized to 32bit writes, most likely also Quake, but at that point you had Pentium with PCI.

Wow! What a bluff they were!!!

Well, thanks!

Technically, this would be matter for reimbursement / returns requests, heck even class-action lawsuits. Because the real specs of the products did NOT match what was advertised and declared on the spec sheets.

If they declare "32 bit" on the bus, I don't care how fast their 16 bit turns are. They could be superluminal, relativity-breaking, time paradoxes-causing, universe-collapsing faster than light 16 bit signals. They're still dealing at 16 bit, while 32 bit is being claimed and advertised.

It reminds me of the much more recent (a few years ago) Dell-Alienware bus scam. A friend was about to purchase a top tower gaming Alienware PC, as I recommended him to make sure to buy a system with a 4th Gen. PCI Express mobo. Well, yes, indeed it did have 4th Gen. PCI Express bus. Only, if you digged deep enough through their manuals, you found that even the main PCI Express slot (the one for the video card) was only "MECHANICALLY" a x16 slot, but "logically" it was running only at x8, even if no other slots or extra M.2 slots were being used.

Basically, in the end, it was equivalent to a much older Gen3 PCI Express but with real x16 logics.

aries-mu wrote on 2023-09-29, 11:14:

Technically, this would be matter for reimbursement / returns requests, heck even class-action lawsuits. Because the real specs of the products did NOT match what was advertised and declared on the spec sheets.

You are looking at a graphics chip datasheet that is targeted to professional graphics card makers, not marketing material that is targeted to consumers. So I don't think any kind of consumer protection laws apply here, this data sheet is business-to-business stuff. Any professional electronics design engineer will immediately understand the level of "32-bit bus support" provided by the Cirrus chips immediately when looking at the chip pinout.

Furthermore, on the VL bus, you have no choice but you need to connect to 32 data lines. A single 16-bit bus interface will not work, as there is no address line A1. To connect a 16-bit chip to the VL bus, you need some logic to route the data to the upper or lower 16 data lines. In the case of the CL-GD5424, there is support in the chip to make the external logic as simple as possible (basically, you just need four 74F245 chips). This actually helps a card designer to build a 32-bit VL graphics cards based on the CL-GD5424. If you take a look at the ET4000AX as competitor for example, this chip also has a 16-bit bus interface, but it does not have any 32-bit bus transfer decoding logic. A VL card based on the ET4000AX usually requires one or more programmable logic chips to translate the 32-bit VL bus into a "pure" 16-bit bus matching the ET4000AX in addition to the four 74F245 chips. So there is a clear advantage of the CL-GD542x chip series over the Tseng series if you want to build a graphics card interfacing with a 32-bit host bus. The relevant pins that indicate the support of the CL-GD5424 (or later) being connected to a 32-bit bus (albeit not directly) is

• the presence of BE0# to BE3# (a 16-bit bus would only have two byte enable lines)
• the absence of an address line A1
• the presence of the OEH# and OEL# pins controlling the external routing logic

mkarcher wrote on 2023-09-29, 18:51:

You are looking at a graphics chip datasheet that is targeted to professional graphics card makers, not marketing material that […]
Show full quote

You are looking at a graphics chip datasheet that is targeted to professional graphics card makers, not marketing material that is targeted to consumers. So I don't think any kind of consumer protection laws apply here, this data sheet is business-to-business stuff. Any professional electronics design engineer will immediately understand the level of "32-bit bus support" provided by the Cirrus chips immediately when looking at the chip pinout.

Furthermore, on the VL bus, you have no choice but you need to connect to 32 data lines. A single 16-bit bus interface will not work, as there is no address line A1. To connect a 16-bit chip to the VL bus, you need some logic to route the data to the upper or lower 16 data lines. In the case of the CL-GD5424, there is support in the chip to make the external logic as simple as possible (basically, you just need four 74F245 chips). This actually helps a card designer to build a 32-bit VL graphics cards based on the CL-GD5424. If you take a look at the ET4000AX as competitor for example, this chip also has a 16-bit bus interface, but it does not have any 32-bit bus transfer decoding logic. A VL card based on the ET4000AX usually requires one or more programmable logic chips to translate the 32-bit VL bus into a "pure" 16-bit bus matching the ET4000AX in addition to the four 74F245 chips. So there is a clear advantage of the CL-GD542x chip series over the Tseng series if you want to build a graphics card interfacing with a 32-bit host bus. The relevant pins that indicate the support of the CL-GD5424 (or later) being connected to a 32-bit bus (albeit not directly) is

• the presence of BE0# to BE3# (a 16-bit bus would only have two byte enable lines)
• the absence of an address line A1
• the presence of the OEH# and OEL# pins controlling the external routing logic

Wow, this is above me, but thanks.

I have benchmarked my VLB cards (36 pieces):
https://gona.mactar.hu/VLB_benchmarks/

Gona wrote on 2026-01-26, 21:10:

I have benchmarked my VLB cards (36 pieces):
https://gona.mactar.hu/VLB_benchmarks/

WOOOOOOOOOOOOOOOOOOOW MAAN!!!!! What a fantastic job you did!!!! 😳 Thanks for sharing!

aries-mu wrote on 2026-01-27, 09:53:

Gona wrote on 2026-01-26, 21:10:

I have benchmarked my VLB cards (36 pieces):
https://gona.mactar.hu/VLB_benchmarks/

WOOOOOOOOOOOOOOOOOOOW MAAN!!!!! What a fantastic job you did!!!! 😳 Thanks for sharing!

Thanks and you are welcome! 😀

Gona wrote on 2026-01-26, 21:10:

I have benchmarked my VLB cards (36 pieces):
https://gona.mactar.hu/VLB_benchmarks/

Thanks for posting that. Very interesting stuff. I rarely get to see Matrox VLB benchmarks outside of old Byte magazines. I've never knew the different S3 805 chips performed so differently in DOS.

Did you notice any variability in a single chip if it was implemented differently? For example, in DOS, does a DRAM based EXM229 Mach32 card perform faster than VRAM EXM195 version ? Does the unbuffered EXM224 Mach32 card perform better than all of the buffered versions?

I know it's a hard card to find but ... no Mach64? You break my heart!

douglar wrote on 2026-01-27, 13:05:

Thanks for posting that. Very interesting stuff. I rarely get to see Matrox VLB benchmarks outside of old Byte magazines. I've never knew the different S3 805 chips performed so differently in DOS.

Yes, I also found only Matrox VLB benchmarks in old Byte magazines, and I want to test it. I also want to test the SXCI 2D/3D API/library (on the software developer side: the RenderWare 3D API) on a VLB Impression Lite (few games on MGA 3D-SuperPack CD) and works.

douglar wrote on 2026-01-27, 13:05:

Did you notice any variability in a single chip if it was implemented differently? For example, in DOS, does a DRAM based EXM229 Mach32 card perform faster than VRAM EXM195 version ? Does the unbuffered EXM224 Mach32 card perform better than all of the buffered versions?

I know it's a hard card to find but ... no Mach64? You break my heart!

I have only one Mach32. I have planned Mach64 but too expensive and according to other tests not outstanding so finally I have dropped. I'm interested in rare ones, and top performers. As I see in other tests DRAM and VRAM Mach64 have same results.

Gona wrote on 2026-01-27, 14:00:

I have only one Mach32. I have planned Mach64 but too expensive and according to other tests not outstanding so finally I have dropped. I'm interested in rare ones, and top performers. As I see in other tests DRAM and VRAM Mach64 have same results.

My experience was that the DRAM Mach32 did ~6% better in DOOM. I suspect that the unbuffered card is a few percentage points better than the buffered card. Starts to get close to the "margin of error" though. The VRAM Mach32 is ~20% faster in Windows compared to the DRAM version, and you can contrive much larger differences if you push the RAMDAC bandwidth consumption by setting high res, hi color, hi refresh rates.

True, I suspect that the mach64 is about the same as Mach32 in DOS, and a DRAM Mach64 would have a hard time separating itself from a VRAM Mach32 in most Win3.1 tests. Would have been nice to see it in numbers though, right? The VRAM mach64 could start to noticeably pull ahead of any Mach32 if you test in Win95, but those VRAM Mach64 cards are pretty rare. I've only seen those in pictures.

Gona wrote on 2026-01-26, 21:10:

I have benchmarked my VLB cards (36 pieces):
https://gona.mactar.hu/VLB_benchmarks/

This is an incredible effort and really deserves a topic all of its own.
Loving the work you've done here.

Amazingly you also managed to find time to compare a bunch of CPUs on a Sis 85C471 chipset board (and a NexGen setup) and those results are interesting in their own right.
As you observed, only the Cyrix 5x86-120 with LSSER bit and Linear Burst was capable of hitting the DOOM cap at 35.53 FPS, with all other CPUs ending up below 35 fps.

What I find interesting is that I've recently been testing Doom on the Spring Circle SF586 Pentium VLB board, using a Pentium 100 and an S3-Trio32 card - so a 33Mhz VLB bus - and managed to clock 35.48 FPS once I upped the L2 cache to 1MB. And I haven't even tuned memory or cache settings yet. That's a board with a Forex chipset rather than the more common Opti Pentium VLB boards. Based on your results it looks to me like the VLB implementation isn't half bad.
Conventional wisdom seems to hold that VLB only really works well plugged directly into the native CPU bus of a 486-derivative but it looks like chipset-based mezzanine VLB connections can perform with the best of them. At least as far as Doom is concerned, which would be more about latency than transferring significant amount of data. I intend to test an Opti Cobra board soon to see how well that does.

douglar wrote on 2026-01-27, 15:00:

My experience was that the DRAM Mach32 did ~6% better in DOOM. I suspect that the unbuffered card [...]

I have dropped Win95 tests because the tested cards are slower on Win95 than Win 3.1 with 486DX/4-100, and many chips have no drivers for Win9x.
As I have seen in other tests, in DOS, Mach64 cards have the same results. My Mach32 unfortunately does not work on Windows at all.
What I really appreciate about Mach32 is that it was the first VLB card, so it beat everything else in its time.

Beerfloat wrote on 2026-01-28, 17:35:

This is an incredible effort and really deserves a topic all of its own. Loving the work you've done here. […]
Show full quote

This is an incredible effort and really deserves a topic all of its own.
Loving the work you've done here.

Amazingly you also managed to find time to compare a bunch of CPUs on a Sis 85C471 chipset board (and a NexGen setup) and those results are interesting in their own right.
As you observed, only the Cyrix 5x86-120 with LSSER bit and Linear Burst was capable of hitting the DOOM cap at 35.53 FPS, with all other CPUs ending up below 35 fps.

What I find interesting is that I've recently been testing Doom on the Spring Circle SF586 Pentium VLB board, using a Pentium 100 and an S3-Trio32 card - so a 33Mhz VLB bus - and managed to clock 35.48 FPS once I upped the L2 cache to 1MB. And I haven't even tuned memory or cache settings yet. That's a board with a Forex chipset rather than the more common Opti Pentium VLB boards. Based on your results it looks to me like the VLB implementation isn't half bad.
Conventional wisdom seems to hold that VLB only really works well plugged directly into the native CPU bus of a 486-derivative but it looks like chipset-based mezzanine VLB connections can perform with the best of them. At least as far as Doom is concerned, which would be more about latency than transferring significant amount of data. I intend to test an Opti Cobra board soon to see how well that does.

Thank you!
Wow! I didn’t think that 35 FPS would be possible on a Socket 5 VLB Pentium 100 system.
FOREX chipsets are overprinted. For me the FOREX really looks like OPTi Pyton or OPTi Premium. These are better with VLB than PCI (but not reach a native PCI chipset with PCI card on P100). The only one I have seen (and tested) which is not OPTi, the DFI G586VPA with VIA VT82C535MV/531MV/505/406MV.
I was tempted to do a speed benchmark using a Powerleap PL-Pro/MMX 6.0 with a Tillamook 266, but these boards are not compatible with many cards.