Reply 20 of 24, by kool kitty89

User metadata
Rank Member

This is the card Apolloboy and I originally used in our 286-20 build (M205) that ended up with disappointing performance at the time.

I've since realized the VGA core portion of the card is relatively slow (lots of wait states?) both for mode 13h and unchained stuff (if wolfenstein 3D is any indication, at least) and doesn't seem to gain anything on 16-bit ISA over 8-bit (maybe on a slow early IBM AT there's a difference, but not on any of the machines I've tried; I could try using a slower oscillator plus de-turbo speed and see if that does anything).

The 8-bit bus shouldn't even be a limiting factor on texture mapping 3D or pseudo 3D games that do single pixel writes (or VGA register writes) in unchained mode, like Wolfenstein 3D or Doom, but wait states would certainly be an issue. (though Doom's low-detail mode should still help, since it uses VGA fills to draw 2 pixel chunks rather than writing 2 pixels)

I think some high-end S3 cards from that era (1990-91) are similar with slow, basic VGA functionality for compatibility along with an accelerator and/or SVGA core of some sort. So probably in the same ballpark as cheap Trident VGA cards of the time. (and like those, working in 8-bit XT slots)

So games and programs that stick natively to VGA won't make use of the accelerator and at best might make use of the added DRAM on the VGA side (Quake allows that, but it's horribly bottlenecked by that card). Games that explicitly use 640x480 SVGA graphics modes might be able to use the accelerator side of things, but I'm not sure about that either (if they're oriented to VGA features, just with added RAM, it's stuck with the VGA core, too).

OTOH, there's a jumper to set the accelerator's bus to 8-bit mode, too, so it might even be useable on Turbo XT boards (and 286 XT boards) and at least my 1991 dated example tolerates very high ISA bus clock speeds, higher than my CL 5420 or 5422. (it seemed to be OK at 20.8 MHz in an MTech Mustang S7 board: 83 MHz FSB, 41 MHz PCI, 1/2 PCI ISA divider) I assume the wait states have something to do with that.

So if anyone ever tries a Turbo XT V20 or V30 build overclocked beyond 16 MHz, this might be an interesting consideration. (though other slow, late gen 8-bit compatible VGA cards might tolerate things similarly)

I'm actually doing a pass of 3Dbench testing on another D60 286 motherboard (25 MHz) with this card right now for comparison, so I can post the results of that vs the CL5420 (512kB VRAM based).

Oh also, I'm pretty sure there's an error on Stason:

for the 8/16 bit jumper select, it says to use JU6, but there is no JU6 on the diagram or on any of the cards I've seen (mine or photos), but JU1 is clearly there with 3 pins and is listed on the diagram, but not anywhere in the configuration list, so I'm betting it's actually JU1 that configures the bus size. (I think that only impacts the coprocessor, but I could try that and see if it speeds anything up or impacts 8-bit slot compatibility for VGA)

Reply 21 of 24, by kool kitty89

User metadata
Rank Member

Well then, I was wrong it seems, at least for a 25 MHz 286 class system (should be a 12.5 MHz ISA bus).

Jumper 1 definitely switches to 8-bit mode when set to 2-3, but the card automatically switches when stuck in an 8-bit slot.
Both jumper settings give the same results in 8-bit slots and the same as 16-bit when set to 2-3, but a 16-bit ISA slot gives faster results when set to 1-2.

3DBench 1.0 =
6.7 (8-bit)
7.7 (16-bit)

7.7 (for CL5422)

I suppose unchained mode functionality (register writes, VGA fills, etc) might still differ between these cards, but for mode 13h it seems to be similar.

Unless I'm mistaken and 3DBench does use VGA acceleration for polygon fills and doesn't copy from a main memory framebuffer.

I also got 8.2 at 27 MHz, but the system wasn't stable long enough to try both cards. (seems like it was OK when started dead cold, but wouldn't run any of the benchmarks when warm or after a few minutes of sitting off; I'll have to get a 25 MHz 286 at some point to try ... or maybe another 20 MHz one will work, I've got an AMD 286-20 boxed away somewhere I haven't tried)

I also didn't perform the 25 MHz tests on that 'other' D60 board as it wasn't happy at that speed, so I set it back to 20. The original M205 Apolloboy and I got in 2011 does 25 MHz in real mode OK (and that 27 MHz test) but isn't happy with DOS loaded high. (chipset EMS works fine, but extended memory does not)

For reference, that other board (a Hedaka 988) briefly at 25 MHz did the same 3Dbench scores on the ATi card, and at 20 MHz did:

5.6 (8-bit)
6.2 (16-bit)

and the CL5420 did 6.3, so a hair faster and might have been closer than that if I ran the tests enough times and averaged them (at 25 MHz I was consistently getting 7.7, though)

I can try the CL5422 as well, which should be more fair to the ATi card since it's using DRAM and not VRAM, though it's also a newer card with 512kB 70ns DRAMs rather than 128kB 80 ns. (both CMOS, and neither card might actually need that speed, it just may have been what was available at the time of manufacture)


Nope, the 5422 does the same 7.7.

I'll have to try them in a faster machine (486 or S7) and see if there's a difference there or if they all bottleneck the same. (I've gotten weird slowness on ISA video cards tested on my S370 with 1.4 GHz PIIIs, a Shuttle Spacewalker AV18, so it's probably not a good example)

Reply 22 of 24, by rmay635703

User metadata
Rank Member
retro games 100 wrote on 2018-08-24, 16:36:

Would this card (in the original post) be a good choice for say a high end 386 (AMD DX-40 perhaps?), or an entry level 486 (say a DX-33) system? Pre "multimedia", and pre Doom era? Did anyone own this card back in the day? Generally speaking, was it considered a quality card? Thanks for any thoughts.

God no, pre doom era yes, good match to a dx40 no unless you specifically need the 8514a compatibility

Reply 23 of 24, by Anonymous Coward

User metadata
Rank l33t

I ran this card from 1992-1997 in a 486DX-33. I know people complain about how these are slow and don't have the best compatibility, but I really didn't experience many problems...I guess I just wasn't playing enough crappy CGA games or something. I played mainly VGA adventure games. I didn't really consider my system horribly slow until after 1995. I guess if you're building a system just to play DOOM on, you'd probably want VLB or PCI anyway, but I played it on my system back then regardless and felt it ran fine (despite not being 60fps). Windows accelerated graphics were pretty decent for ISA. In my opinion the real weakness of this card was that it didn't support 15,16 or 24-bit modes, which was a real problem in 1994 with Windows multimedia stuff, image editing and the internets.

Strangely, a friend of mine had a VGA Wonder XL24, and that card supported modes with more colours despite being cheaper and being sold around the same time. I believe those cards have a slightly newer VGA core as well, plus all 1MB is available to DOS (not that it really mattered much). I also remember it somehow being faster at Direct Draw than my card. However, my card was definitely better at 1024x768 (faster graphics and better refresh rate), not that you'd really want to run that on a 14" CRT anyway.

The point being, I think this card should be perfectly fine for a fast 386 or slow 486.

"Will the highways on the internets become more few?" -Gee Dubya
V'Ger XT|Upgraded AT|Ultimate 386|Super VL/EISA 486|SMP VL/EISA Pentium

Reply 24 of 24, by kool kitty89

User metadata
Rank Member
rmay635703 wrote on 2020-03-27, 01:17:
retro games 100 wrote on 2018-08-24, 16:36:

Would this card (in the original post) be a good choice for say a high end 386 (AMD DX-40 perhaps?), or an entry level 486 (say a DX-33) system? Pre "multimedia", and pre Doom era? Did anyone own this card back in the day? Generally speaking, was it considered a quality card? Thanks for any thoughts.

God no, pre doom era yes, good match to a dx40 no unless you specifically need the 8514a compatibility

I need to try this in my 386/486 Opti 495SX board. In that 286, up to 27 MHz (which is more stable with a 90 mm fan directly blowing across the board above and below the CPU), I'm getting within .1 FPS results with the Graphics Ultra (in 16-bit mode) and CL5422 and CL5420 ISA cards.

The ATi card might benefit more from ISA bus overclocking, too, and does seem to be the most stable overclocked. (it's the only one of the 3 that works at all at 20.8 MHz ISA clock on a Socket 7 board: 83 MHz FSB, 41 MHz PCI, 1/2 PCI ISA divider, though I haven't actually used it for games or benchmarks above 13.5 MHz, and that's on the D60 286 board) Hmm, I could try it at 40/5 and compare to 40/3 if the IDE interface remains stable at 13.3 MHz and see what the difference is.

Oh, and I do have a late gen 8-bit VGA card I could compare it with, too. (fake 16-bit connector on that one with no traces going to any of the pins)

Hmm, for that matter, I need the wolfenstein 3D benchmark for comparison, too. (and that'd be more VGA-bound and less processor bound than Doom, though would also be 286-compatible)

I've tested the CL cards, a Trident VLB card, and Avance Logic VLB card on the 486 board (with 40 MHz FSB, 10 MHz ISA, 120 MHz ST/Cyrix 486 DX4) and that Trident card gave the worst results, but only slightly less than the ISA cards) in 3DBench, PC Player, Doom, and Quake. I didn't make note of Chris's 3D Bench scores and need to run through these again, but difference was pretty marginal at 320x200 and only moderately moreso for PC Player at 640x480.

The ISA CL cards did 50 to 51 in 3D Bench, the Trident card 49, and Avance card 55.1 to 55.5. (I remember those off the top of my head, but need to look up the others).

I haven't messed with the VESA jumper settings on that board yet (though there's 386/486 settings and <33 MHz and >33 MHz, and I assume that mostly configures waitstates). I don't think this OPTi chipset is particularly fast anyway (and even later OPTi 486 chipsets aren't known for speed) so it might turn out to not have very good VESA performance in general.

I haven't messed with jumpers on the VLB cards, and if there's wait state configuration on that end and/or a jumper to select ISA bus compatibility mode, that could make a big difference. (on the wait state end, things might end up better even if I have to drop to 33 MHz for zero wait states)

Also, I wouldn't think Doom would benefit as much from VESA as VGA games that rely on copying from a framebuffer in main RAM (actually using the 32-bit bus) as Doom draws directly to VGA memory one 8-bit pixel at a time in unchained mode (or writes to VGA registers for 2-pixel line fill commands when in low-detail mode) so low wait state access to VGA RAM and registers would be more important than bus width.

Games running in MCGA/13h mode would benefit from fast local bus copying and ones that use unchained mode for hardware scrolling, but still do block reads/writes for 2D rendering with nonlinear VGA pixel organization. (you can still blit 4 8-bit pixels at a time, but they're not packed, but spaced 4 pixels apart, so most code would probably work at doing blits and copies along 16 pixel boundaries, since you effectively get 16 packed pixels in 4 adjacent unchained/planar VGA address writes)

It's weird and byte-planar, not bit-planar (unlike EGA and 4-bitplane VGA modes), and for single-pixel texture mappers (like Doom) it doesn't matter much other than using non-linear address increments (and only when starting a new column, or drawing spans), and for Quake rendering in VGA mode (not sure if it supports linear SVGA or 8514 compatible framebuffer modes), but Quake's use of 16-pixel span line segments seems to fit well in the VGA planar organization as well. (though you can also just render to a linear back-buffer in main RAM and translate 16 pixel blocks to VGA memory as part of the copy routine)

And further afield of the Graphics Ultra (and VGA Wonder architectures), but on the topic of VGA game oddities/quirks/dependencies and performance:

Games that support 320x200 and jump straight to 640x480 as the alternate mode probably often support linear framebuffers exclusively (13H and linear 640x480 modes), possibly with a double-buffering option in 640x480. (I'm not sure if you can do that in 13h with cards 512kB or larger, since chain4 maps the 64kB linear buffer into 256kB space redundantly, it seems like it'd work via switching 256kB banks)
I assume Tie Fighter CD and Wing Commander III and IV use that technique.

There also might not be much point in double-buffering mode 13h other than maybe reducing main RAM requirements for multiple back buffers. (to avoid screen tearing in 13h, you just need a fast enough VGA card and a properly timed copy routine that polls the v-synch status register, I think) And even real-mode games could fairly easily resort to moving the back buffers to EMS memory and swapping out 64kB chunks, or potentially using the 64kB HMA block available in real-mode and modifying the protected-mode extended address registers for simple 64kB page style bank switching, or the same thing using a dedicated 64kB page in the UMA. (either using the LoadALL exploit or switching to protected mode via a reset: I think on AT class machines, that's done with a special routine assisted by the keyboard controller MCU along with A20 handling)

Most games seem to just resort to requiring EMS memory or making direct use of VGA memory for additional buffering, though.

Use of VGA memory might be one of the reasons Wolfenstein 3D didn't need to resort to EMS memory requirements. (Wing Commander 1 and 2, and X-Wing either have optional features available through EMS, or require EMS for general functionality) I'm not sure if the Wing Commander games have special options for using portions of UMA or HMA, but given Ultima VII makes use of real-mode LoadAll addressing exploits, Origin might have done that elsewhere.