Is this a good graphics card for a retro win95/DOS build?

[hunterjwizzard]

A little while back I bought an Intel AL440LX Slot 1 Pentiunm II AGP Motherboard for $1 on ebay(+17 shipping, urk). At the time I really couldn't justify grabbing a CPU for it(got a wedding and a honeymoon to pay for), but luckily for me I just found a pair of PIIs in a forgotten box in the back of my closet! I thought I threw these out ages ago but apparently not. I'm excited because one of them is the exact PII I had decided I wanted for a retro win95/DOS build. Now the motherboard also has an onboard Yamaha OPL Sound Card, which I understand is great for DOS.

Moving on.

I've had this ATI RAGE128 Pro in my parts bin for ages:

(I very, very stupidly threw out a voodoo5 but kept this piece of junk).

Anyway, I know its from 1999 and is not "period accurate", but I'm fine with using a somewhat newer card. Would this be a good choice for the build? This might be the oldest AGP card in my inventory, I think I kept it because I thought the dual fans made it somehow special.

 

[Plasma]

I think that's a Rage Fury MAXX. Should be fine for 90s games, but it only works with Windows 98. Also that keyboard looks like a biohazard...

 

[Timo W.]

The best card is whatever you have. And the MAXX is not bad (dual GPU!) It's actually a very sought-after card by collectors.

 

[GiGaBiTe]

Like others have said, what you have is a Rage Fury MAXX. It's basically two RAGE 128 PRO GPUs on one card, each with their own memory.

While it is an interesting historical video card, it is not a good gaming card. Due to the way that ATI wired up each GPU on the card to the AGP bus, it will only work under Windows 98SE, and potentially ME. If you use the card in DOS, only one of the GPUs will be utilized, and the other won't do anything. The same goes for Windows 2000 and XP, only one of the GPUs will be utilized because Microsoft doesn't support the way that ATI put two GPUs on the AGP bus.

The card is setup to do, and can only do AFR (alternate frame rendering). What that means is that each GPU takes turns rendering alternate frames of video data. This causes problems with stuttering, so if you're in a highly varied rendering load (basically any 3D game), the frame rendering times are always going to be different per GPU, so you'll notice stuttering or hitching in the rendering output.

Since the card relies entirely on the driver to do the AFR rendering, vs a hardware solution like 3dfx's SLI, you're not going to have a good experience. That card was only ever released in small numbers, and ATI abandoned support relatively quickly since it was at an evolutionary dead end. It was really them trying to make a stop-gap card that could compete with the Voodoo5 5500 and the Geforce 256, because their next generation "Rage 6" card (the original Radeon) was delayed.

 

[Timo W.]

If you use the card in DOS, only one of the GPUs will be utilized, and the other won't do anything.

Given that DOS games won't ever use *any* GPU features, I doubt that really matters. The fact he can not make full use of both GPUs doesn't mean it's a bad card. If anything, it will work just like a standard Rage 128 Pro.

 

[GiGaBiTe]

Given that DOS games won't ever use *any* GPU features, I doubt that really matters. The fact he can not make full use of both GPUs doesn't mean it's a bad card. If anything, it will work just like a standard Rage 128 Pro.

You'd be wrong there. DOS makes use of plenty of VDP/GPU features. VESA modes, blitter, DMA, misc draw call acceleration, etc. When a video card did hardware acceleration of those things, graphical software would run measurably and sometimes very noticeably faster. There were video chips that were no more than basically dumb frame buffers, and they were painfully slow.

Some later PCI/AGP video cards were known to have problems in DOS, one example being Matrox cards. They had extremely broken VESA support, and the G200 in particular had terrible problems with transparency effects, often resulting in system crashes.

You're also forgetting the early DOS Glide games. Blood being one example.

DOS Glide Games List \ VOGONS

www.vogons.org

 

[Eudimorphodon]

You'd be wrong there. DOS makes use of plenty of VDP/GPU features. VESA modes, blitter, DMA, misc draw call acceleration, etc.

Are you talking about VBE/AF? The number of games actually using that seems like it’s somewhere between zero and, well, very small, and when it exists at all it relies on a software layer; nobody put a full implementation in a card’s BIOS. The vast majority of dos games that relied on VESA only used dumb framebuffer support and the few 3d accelerated games that existed all relied on proprietary APIs. (Glide was the most successful, but most 90’s 3D accelerators at least had a little coverage. here’s an extensive list on Vogons showing which games had support for which cards.)

I think the TL;DR is if you actually want 3D acceleration in DOS with wide support you need a card from a very brief period in the 1990’s, and the best choice for that will be a Voodoo card because it has the most coverage. The ATI RAGE128 card would be “fine” for VESA games, in my experience ATI cards are solid, compatible, and performant under DOS, but it is just too late to have any DOS 3D games targeting it. (There were a few games that supported the Mach64 3D RAGE cards, but the emphasis is on “few”.) As for Windows, I’d normally also say a RAGE 128 should be “fine” for Windows 9x era games, the card was roughly comparable to a Voodoo3, but the quirks of the MAXX, which I’ve never personally touched, might put an asterisk on that. But, FWIW, if the drivers let you run it on just a single core it'll still be in the Voodoo3 ballpark for Windows OpenGL/DirectX games. (Except unlike a Voodoo3 it's actually accelerated in 32 bit mode, not just 16...)

 

[hunterjwizzard]

I think that's a Rage Fury MAXX. Should be fine for 90s games, but it only works with Windows 98.

Well that's really cool. I seem to recall my ex-brother in law(who gave me the card ages ago) telling me there was something special about it. Sure would be nice if ATI printed things like the actual model somewhere on the card. Here all this time I've thought I jus had an ordinary Rage128Pro.

I won't be using this card in the build for obvious reasons, but I definitely have to try it out on my win98 system sometime. Just for grins.

Also that keyboard looks like a biohazard...

Hmm. My fiancé said the exact same thing. Starting to think there might be a point here.

The best card is whatever you have. And the MAXX is not bad (dual GPU!) It's actually a very sought-after card by collectors.

I've got better cards than this. Probably. At least I'm sure I've got DOS/95 compatible cards

 

[hunterjwizzard]

I've got better cards than this. Probably. At least I'm sure I've got DOS/95 compatible cards

Well I was wrong. Just went through my parts bin, seems the only other AGP cards I have are either of a newer vintage, or that Matrox card already mentioned as being bad for DOS. I'm going to have to shelve this project for a bit while I hunt up something better.

 

[GiGaBiTe]

Are you talking about VBE/AF? The number of games actually using that seems like it’s somewhere between zero and, well, very small

Again, you'd be wrong. Draw call acceleration was used by virtually every DOS graphical program if available, because it was implemented in hardware on the video card. Before there was 3D acceleration, there was 2D acceleration, and video chip vendors started to implement accelerated draw calls in hardware. Some video chips were far faster than others, because they accelerated draw functions in hardware and provided DMA. This is in stark contrast to older dumb framebuffer cards where the CPU had to do all of the work.

2D and 2.5D games greatly benefited from the acceleration, and there was a measurable performance uplift. Even early 3D games like Quake would benefit from DMA transfers.

Phil's computer lab has a DOS benchmark pack, you can test several video cards if you want.

 

[Eudimorphodon]

Again, you'd be wrong. Draw call acceleration was used by virtually every DOS graphical program if available,

Citation needed, but let’s tackle this in two parts.

First off, yes, there was variation in DOS performance with VESA SVGA modes, but this was mostly about the hardware architecture of the cards in terms of optimizing access to video memory. (Some 2D accelerators were notorious for having slow access to VRAM; I have a vague memory that S3‘s early products fell into this category?) Show me where there are *any* acceleration APIs in the standard VESA 2.0 Core. (again, basically *nobody* implemented VBE/AF on their native BIOSes. And… are you confusing linear framebuffer access with “DMA”? Because, yes, cards that supported that are usually faster than ones that didn’t, but linear access is still a “dumb” framebuffer. And *any* PCI card should support linear framebuffers unless it’s a truely dumb/ancient chipset wedged on a PCI bridge.)

That said, there were some DOS games that used driver libraries that could do some limited acceleration with specific cards; for instance SciTech made a product game developers could link in that essentially provided VBE/AF, and sure, if you had a card supported by it it probably “helped”, but…

Phil's computer lab has a DOS benchmark pack, you can test several video cards if you want.

Have you actually done that and seen any significant difference? Because that is totally *not* born out by their huge Google sheet of results. Load it and look at the results for systems with the same CPU, and you’ll see that unless you’re throwing in a red herring like an ISA card amongst PCI/local bus models performance scales almost completely by CPU. There’s typically maybe 10-20% difference worst case, between video cards using the same bus, including on the Quake test… and it should be noted that, looking at the released source code, Quake at least *recognized* SVGA cards with acceleration as a device class (Via the SciTech library.) Doesn’t look like it did much with it, but, well, it’s there, and seems like it mattered hardly at all.

 

[Svenska]

Again, you'd be wrong. Draw call acceleration was used by virtually every DOS graphical program if available, because it was implemented in hardware on the video card.

You are thinking of the DOS program called "Windows". 2D acceleration was very important for windowed environments, such as Windows or XFree86. The Windows driver architecture could theoretically offload most of its work to the hardware, but nobody bothered beyond hardware cursors and blits, and sometimes lines and rectangles.

DOS games universally treated the video card as a large framebuffer, and that's about it. You want a fast bus speed, fast writes to VRAM, and a linear mapping. Nothing else matters.

There were a few high-profile DOS applications (not games!) with actual hardware driver support, but those are not relevant for this discussion. Unless, again, you are talking about Windows.

 

[hunterjwizzard]

I found a shocking number of windows 95-only games last night. I'm somewhat annoyed at being stalled on this build.

 

[Eudimorphodon]

There were a few high-profile DOS applications (not games!) with actual hardware driver support, but those are not relevant for this discussion.

Yeah. Going back into the 80’s there *were* definitely a few DOS programs that supported specific 2d accelerators, like the TIGA cards using the TMS340x0 series or the IBM8514/A API (which ATI cards up to the Mach64 had a wrapper to emulate), but any examples I can think of were things like CAD programs. I mean, after digging around and finding out that things like SciTech’s UniVBE+VBE/AF library *existed* I can’t say that *no* DOS games might have used some nugget of 2D acceleration, but I have found *zero* concrete examples. The standard and the matching library didn’t even come out until after Windows 95 was a thing, so that’s a tiny window where it even would have made any sense to use it.

(* Edit: actually, I have a vague memory of there at least being demos of game-like software like flight simulators for TIGA, so I suppose if you really want to stretch definitions then, sure, accelerated DOS game. But if you find any of that, yeah, you’re going to need a *very* specific card to run it that probably predates VESA and ain’t going to be a very good general purpose gaming card…)

 

[Svenska]

Some video chips were far faster than others, because they accelerated draw functions in hardware and provided DMA.

Actually, you got me curious about the DMA part. How does it work?
Do you have some generic code making this available to DOS applications?

 

[GiGaBiTe]

Have you actually done that and seen any significant difference? Because that is totally *not* born out by their huge Google sheet of results. Load it and look at the results for systems with the same CPU, and you’ll see that unless you’re throwing in a red herring like an ISA card amongst PCI/local bus models performance scales almost completely by CPU. There’s typically maybe 10-20% difference worst case, between video cards using the same bus, including on the Quake test… and it should be noted that, looking at the released source code, Quake at least *recognized* SVGA cards with acceleration as a device class (Via the SciTech library.) Doesn’t look like it did much with it, but, well, it’s there, and seems like it mattered hardly at all.

Don't need to do the testing, it's already been done by someone else.

Chart at 7:25 on the second video.

On the ISA cards alone, going from the slowest chip to the fastest chip, you have Wolfenstein 3D with 142% performance uplift, Quake at 134% more performance and Doom at 93% more performance. And you can't say that VLB is always beneficial, because an ISA Diamond Speedstar 24x (WD90C31) is faster than the VLB Diamond Viper P9000 (OTI087X), even though the latter has considerably more bus bandwidth available. Cirrus Logic destroys the competition with their VLB cards.

Now, what's this nonsense you're on about "no more than 10-20%"? That wide of a performance gap cannot be accounted without having some form of hardware acceleration of draw calls and DMA. I'm not going to go digging out 30 year old datasheets to prove it to you, because the data speaks for itself. I remember reading them long ago, and this data shows it, some video chips were far better than others due to hardware acceleration. And no, the application doesn't have to explicitly support it to work, hardware can be faster than other hardware, irregardless of CPU speed. All of these tests were done with a 486 DX 33.

 

[Plasma]

You seem to be unfamiliar with wait states. What DMA channel is my ISA video card using?

 

[GiGaBiTe]

You seem to be unfamiliar with wait states. What DMA channel is my ISA video card using?

You seem to be unfamiliar with the concept of DMA. Video cards don't need to access host resources to do DMA transfers. The example I'm referring to is Blitter, which can do complex block copies of pixel data in memory, without intervention of the host CPU. The ET4000/W32i has a hardware blitter engine and some hardware sprite support, which makes it a very fast ISA video card.

 

[hunterjwizzard]

So after a little digging around on the 'net I'm toying with getting an nVidia RIVA 128 for this build(when I eventually have money to finish it). I know their graphics support was terrible, but this is supposed to be one of the first AGP cards.

If someone can recommend a better card that can be had for $20-30 I'm all ears. Performance does not have to be top dog, compatibility is slightly more important. But mainly I am looking for that mid-90s timeframe. Once you hit 1998+ I have a better system on hand.

 

[Plasma]

You seem to be unfamiliar with the concept of DMA. Video cards don't need to access host resources to do DMA transfers. The example I'm referring to is Blitter, which can do complex block copies of pixel data in memory, without intervention of the host CPU. The ET4000/W32i has a hardware blitter engine and some hardware sprite support, which makes it a very fast ISA video card.

The speed discrepancy between video cards in DOS programs is primarily due to wait states inserted by the card during video memory writes. And possibly banked vs linear memory access for SVGA modes. It has nothing to do with "hardware blitting", "draw call acceleration", or whatever you are calling DMA.