A few days ago I finally swatted a VGA emulation bug that I had known about for several years, but couldn’t identify until recently. The problem affected only Windows 3.1 running in Standard mode. It did not occur in Windows 3.1 running in 386 Enhanced mode, and it did not occur in Windows 3.0 Standard or 386 Enhanced mode.
The failure mode was rather interesting. Start Windows 3.1 in Standard mode, then start a DOS box. No problem there. Use Alt-Tab to switch to the Windows desktop, no problem. Use Alt-Tab to switch back to the DOS box—still no problem. Use Alt-Tab again to go to the Windows desktop (no problem) and then again to the DOS box: Blank screen!
Running ‘MODE CO80’ in the blank DOS box would restore visibility but a few Alt-Tab round-trips would result in a blank screen again.
After a little bit of poking around it was clear that the screen was blank because bit 5 in the VGA attribute controller index register (at I/O port 3C0h) was not set… but why? I had a strong suspicion that the problem had something to do with the attribute controller flip-flop, but couldn’t figure out what exactly.
The VGA Attribute Controller
Like many VGA features, the attribute controller is an extension of the EGA hardware. And like many other EGA registers, the attribute controller was write-only. That is, the EGA hardware registers would be written, but not read. Needless to say, this “feature” of the EGA hardware caused endless headaches for programmers… but that’s a different story.
The relevant bit is that like most other EGA function groups (CRT controller, graphics controller, sequencer), the attribute controller used an index register and a data register. But unlike the other groups, the attribute controller mapped the index and data registers at the same I/O address (3C0h)!
That sounds crazy, but it was not completely crazy. There was an internal flip-flop which controlled whether the next write to I/O port 3C0h would be directed to the index register or to a data register. Each write to port 3C0h toggled the flip-flop.
The flip-flop was reset (i.e. would point at the index register) by reading the EGA miscellaneous status register at port 3DAh (EGA in color mode) or 3BAh (EGA in mono mode).
Now, modifying the attribute controller state without visual glitches was only safe in the retrace interval on the EGA. Each write to the attribute controller registers in the EGA BIOS was therefore preceded by a loop reading the status register and waiting for the retrace.
The flip-flop was thus reset “for free” as a side effect of the necessary status register read.
The attribute controller flip-flop mechanism lent itself to using the REP OUTSB instruction directed to port 3C0h to quickly write a set of index/data pairs.
The VGA by necessity adopted the EGA behavior, but made the attribute controller registers readable. However, reading the attribute controller registers is cumbersome because reads do not toggle the flip-flop. I can only guess that this was done for backwards compatibility with the EGA, where reads from port 3C0h didn’t affect the flip-flop either (although it’s unclear why anyone would be attempting to read from a write-only register, at least intentionally).
Whatever the reason was, on the VGA reading port 3C0h returns the current attribute controller index register, while port 3C1h reads the currently selected data register. To read multiple attribute controller registers, one must reset the flip-flop, write the index register, read the data register, and repeat the cycle starting with the flip-flop reset–because otherwise a data register would be written instead of the index.
Documentation, or the Achilles’ Heel of VGA
The VGA attribute controller behavior is somewhat idiosyncratic, but it is not outrageously complicated. Except… except… everything depends on whose documentation one reads!
The description in the paragraphs above is based on IBM’s VGA documentation. It is to the best of my knowledge accurate. The trouble is that other vendors documented the attribute controller differently.
For example the 1996 Cirrus Logic CL-GD5446 Technical Reference Manual, usually a reliable source of information, documents the attribute controller registers as follows.
Port 3C0h is documented as ‘Attribute Controller Index/Data (Write)’ and port 3C1h as ‘Attribute Controller Index/Data (Read)’. That is at best misleading—port 3C1h only reads the data registers, while the index register is read at port 3C0h. The explanation in text is no better, and does not make it at all clear how attribute controller reads work.
The 1999 3Dfx Voodoo 3 datasheet is even worse. Here is an excerpt: The Attribute Index Register has an internal flip-flop, rather than an input bit, which controls the selection of the Address and Data Registers. Reading the Input Status Register 1 (port = 0x3BA/0x3DA) clears the flip flop and selects the Address Register, which is read through address 0x3C1 and written at address 0x3C0. Once the Address Register has been loaded with an index, the next write operation to 0x3C0 will load the Data Register. The flip-flop toggles between the Address and the Data Registers after every write to address hex 0x3C0, but does not toggle for reads to address 0x3C1.
The text plainly states that the address (index) register is read at 3C1h, but that’s not true–it’s read at 3C0h. The reader is also left to wonder whether reads from 3C0h toggle the flip-flop or not.
I don’t know what documentation the original author(s) of the VGA emulation in question read, but given the two above samples, it is not too surprising that they got it wrong.
Back to Windows 3.1
When running in 386 Enhanced mode, Windows 3.x traps writes to the VGA device, and therefore can keep track of the VGA state. In Standard mode, that is not possible, and the 286 VGA grabber is tasked with saving and restoring the VGA state as best it can.
In Windows 3.0, the grabber saves and restores the attribute controller data registers, but does not restore the state of the attribute index register. That quite possibly caused problems in some uncommon situations, but avoided the problem with broken VGA emulation.
The grabber in Windows 3.1 was improved to save and restore the index register as well, but it does not attempt to restore the flip-flop state, which is significant. The problem with the VGA emulation was that it erroneously applied the flip-flop state to reads from port 3C0h, and Windows 3.1 would save the wrong index register value… but only the second time through, because the flip-flop state was different at that point. That is to say, the Windows 3.1 standard mode grabber read from port 3C0h to query the attribute controller index register state, but the emulation returned the currently selected data register contents instead.
And then, when restoring the attribute controller index register the next time around, the register would be restored to the wrong value which didn’t have bit 5 set, causing the screen to go blank.
The VGA emulation fix was trivial, making reads from 3C0h always return the current index register value, regardless of the flip-flop state. Years to find, seconds to fix.
As an aside, there are semi-undocumented registers in the VGA CRT controller register range which allow reading the current attribute controller flip-flop state. Register CR24 reads the flip-flop state, and register CR26 reads the attribute controller index state. The latter seems at first glance redundant.
Windows 3.1 makes no attempt to use these registers. Without a wider survey it is unclear how widely implemented those registers were. It is also quite unclear why IBM didn’t document the registers, since they filled a real need—together with register CR22, which reads the current value of the graphics controller latches, register CR24 makes it possible to read otherwise hidden internal VGA state, which is required to fully save and restore the state of the VGA. Mysteries of PC hardware.
In what emulator did you make that fix?
I guess the fix would need to be to Windows itself?
Nah, the 286 grabber does what it can. It could be possibly improved by using the undocumented CRTC register to read the current flip-flop state, but either Microsoft didn’t know about it or they found that it wasn’t supported everywhere.
The EGA is a nightmare to virtualise, which is interesting since it was designed about when the PC/AT was supposed to offer next generation multitasking environments. Some minor design decisions would have made it much easier to deal with.
I wonder if the idea was that in a multitasking environment, only the OS would be accessing the EGA hardware. And since the OS driver knows what it wrote to the hardware, it doesn’t need to ask the hardware what its state is. Of course it didn’t work out that way.
But that’s basically what the EGA.SYS driver did. Have one central place that writes the EGA registers, remembers what it wrote, and can be asked what the hardware state is.
I wonder if it is also to save a few transistors in the chips that the original IBM EGA cards used.
A weird thing is that IBM had ASICs on their original EGA card. That means that write-only registers/flags isn’t as reasonable as if it was built using discrete logic chips. Sure, as Yuhong Bao suggest it would save some transistors, but not that many.
As a time scale reference, in the mid 1970’s generic I/O chips (like the 6821, 6522 and whatnot) allowed read back of written information. A year after EGA came to market the Amiga came out using about as many chips for it’s graphics hardware as an EGA card does.
Did IBM on purpose use older technology when designing their ASICs to ensure reliability? Or wasn’t IBM able to have the actual chip manufacturers use the latest capabilities?
Remember we are talking about in 1983 here as well.
(for comparison the original 8088 had 29000 transistors)