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.