First post, by kdr
I've been investigating a pair of ancient Sigma Designs EGA cards that I got a while back from a pile of untested ISA boards.
One of the cards (the SPEGASYNC) works nicely in my Turbo XT at 4.77Mhz, but utterly fails in turbo mode at 10Mhz. Both the RAM (120ns) and ROM (?) appear to be too slow. The other card (the ERGO480) fails to POST and even manages to lock the system up. But I have high hopes for it, because the RAM is faster (100ns). Thus begins the investigation...
The BIOS strings claim these are UNISYS cards. (Didn't know UNISYS made ISA graphics cards!)
The SPEGASYNC is a pretty standard early EGA card from 1986. 256KB of RAM and using the CS8240 chipset from CHIPS. Plus a Sigma Designs gate array, the L1A2334, to hold all the 'glue' logic to connect the EGA chips to the ISA bus. BIOS string says "UNISYS ENHANCED GRAPHICS CONTROLLER VERSION 1.30". It works nicely at 4.77Mhz and does all the typical EGA stuff.
On the subject of "does every EGA card have 256KB?" -- the August 1986 issue of PC Magazine, immediately after the first EGA clones came on the market, reviews 12 different EGA cards (IBM's plus 11 clones). All of the cards offer a 256KB memory option, but even more interesting is that only three of the cards (the IBM plus two clones) are available in a 64KB configuration.
But I want an EGA card that works in my Turbo XT at 10Mhz! So let's try the ERGO480.... it has two oscillators onboard, a 28.500Mhz and a 32.000Mhz; hmm, very close to 2x of the standard 14.318Mhz OSC signal and the 16.257Mhz oscillator that one expects an EGA card to use. No matter what I do, can't find the right switch settings to get this thing to POST and output a proper 15.7khz or 21.8khz sync. As a bonus, it usually also freezes the system, preventing it from even booting!
Progress is made once I pull the ROM off the card. This reveals a curious PAL16L8 hidden underneath the ROM socket, which is a bank switcher -- do an I/O write to port 03CBh and bit D0 switches between the two 16KB banks. The card maps the ROM at C000-C3FF. (Why Sigma bothered with this bank switching scheme instead of just mapping the whole 32KB to C000-C7FF is a real mystery.) I stuck the ROM into an Ethernet card's boot ROM socket and dumped the whole 32KB.
With the ERGO480 card now ROMless, I can install it alongside an MDA card and my machine is able to boot.
I can poke the standard EGA registers and bring the card up. Programming the sequencer and CRTC according to the values from IBM's EGA Technical Reference is enough to get an 80x25 text mode display up and running -- at 31.5khz hsync! Hmmm, better not plug in the CRT just yet. [If only I had an early NEC Multisync with TTL digital inputs.] The video RAM at B800 is accessible and works fine, even in 10Mhz turbo mode. I change the I/O base address jumper on the card (moving it from the standard 3C0-3CF ports to the alternate 2C0-2CF ports) so that I can both with the video BIOS ROM installed, because the ROM doesn't support (and can't detect) the card if it's at the alternate address. And I was able to confirm that the ROM is also fast enough to work reliably in turbo mode at 10Mhz.
Yes, this means it is possible to have *three* video cards installed in an XT! One MDA or CGA adapter, plus one EGA adapter at the standard 03Cx and 03Bx/03Dx ports, plus a *second* EGA adapter at the alternate 02Cx/02Bx/02Dx ports. But there's zero BIOS or DOS support for that EGA at the alternate address. Did any software or operating system ever take advantage of this ability?
Now it's time to debug the video BIOS! I tried just jumping to the initialization code at C000:0003, but it kept getting confused into thinking it was in monochrome mode and started reprogramming the CRTC in my MDA adapter, whoops! So instead I rigged up a way to load the video BIOS dump into RAM and execute it from there. Required patching up the bank-switching trampolines to modify the CS register instead, and also had to patch up a couple of hard-coded references to the C000 segment, but... it worked! I was able to single-step through the BIOS in Turbo Debugger, skipping over any questionable bits as needed. As a bonus, TD seems to have its own MDA support that doesn't rely on any BIOS routines, and is very aggressive about reprogramming the MDA to known-good values every time it hits a breakpoint.
Finally I can figure out why this card goes off the rails! And also maybe figure out what the switch settings are!
As it turns out, a couple of the DIP switches were faulty. No wonder I couldn't figure out the settings. Liberal application of IPA resolved the issue. Many of the switch settings are "standard", same as on the IBM EGA. Once I found a setting that worked (SW1..4=OFF:ON:ON:ON for colour 80-columns on a 200-line monitor) the BIOS was able to POST and write its version string to the primary display (the MDA). But then it failed its self-test, beeped out the familiar long-short-short-short code, and promptly froze the system.
By single-stepping my way through the self-test, the issue was easily identified: a bad DRAM chip on bits D0-D3 of plane #3. The memory test activates the A000 mapping for the video RAM and then tests each plane, one by one. When the test fails, it beeps out the code but then continues executing the rest of the video BIOS initialization instead of bailing out.
So it bravely carries on to the next step, which is calling its own INT 10h handler with AX=CE01h, which is some sort of proprietary Sigma extension to the standard INT 10h interface. Most likely to handle the CGA emulation. And that's what is in the second bank of the ROM: a copy of the SIGMAEGA.COM emulation utility! It even has a bunch of help text describing the various commandline options available. How weird. Anyway, the AH=CEh handler has to set up some kind of 'sane' environment before it can execute the emulation code, and it does so in the A000 segment -- which was oh-so-conveniently left enabled by the RAM self-test code.
Too bad that plane #3, which is the one left enabled, is the one with bad RAM in it. Chaos ensues and things quickly go off the rails, and the system appears to freeze because the CPU is off in never-never-land executing total garbage.
Guess it's time to order some new RAM.....
Anyway, this L1A2334 chip appears to contain a bunch of CGA emulation hardware in addition to the expected bus interface glue logic. What I've found so far:
03CB: write-only register for ROM bank switchingbit D0 controls the bank, 0=low 16KB, 1=high 16KB03CD: read/write register holding emulation mode status (?)bit D0 seems to be some kind of reset - clear this bit and the EGA I/O ports 'disappear'bits D3 and D7 appear to control the emulation mode03x9: read/write register (this is the CGA and Hercules mode control register)not clear if anything happens on writes to this register, or if it's there to remember whatever value the CGA program has written
The data bus from the ISA slot is routed (via an LS245) to the card's internal data bus. The L1A2334 sits on this bus, along with the ROM, the PAL16L8 bank switcher, a PAL16L8 that acts as a CLKSEL multiplexer, and the 82C43x chips. What's weird is that D3 and D7 from the ISA slot only go to the L1A2334, and D3 and D7 on the card's internal data bus are only connected to the L1A2334. So it has some sort of ability to intercept or modify these bits as they move between the ISA slot and the 82C43x chips. Very interesting.
