16-Bit Accesses to 8-Bit Adapters
There are two fundamental classes of adapters that may be plugged into the AT bus: 8-bit adapt […]
Show full quote
16-Bit Accesses to 8-Bit Adapters
There are two fundamental classes of adapters that may be plugged into the AT bus: 8-bit adapters and 16-bit adapters. The two are distinguished by the extra bus connector that appears only on 16-bit adapters; in addition, 16-bit adapters must announce to the bus that they are indeed capable of handling 16-bit accesses, by raising a particular bus line on the 16-bit connector early on during each access.
What happens if an adapter doesn't have the 16-bit connector, or if it doesn't announce that it's a 16-bit device? Why, then the AT's bus does two things. First, the bus splits each word-sized access to that adapter into 2-byte-sized accesses, sending the adapter first 1-byte and then the other. That's not all the bus does, though: During each of those byte-sized accesses to an 8-bit adapter, the AT bus inserts three extra wait states (in addition to the one-wait state that's routinely inserted), effectively doubling the access time per byte of such adapters to six cycles, as shown in Figure 2. These extra wait states, which I'll refer to as 8-bit-device wait states, form a pivotal and little-understood element of 16-bit VGA. Together with the splitting of word-sized accesses into 2-byte-sized accesses, 8-bit-device wait states can quadruple the access time per word of 8-bit adapters; instead of accessing one word every three cycles, as is possible with 16-bit adapters, the AT can access only 1-byte every six cycles when working with 8-bit adapters.
Three extra wait states are inserted on accesses to 8-bit adapters because the first 8-bit adapters were designed for the PC's 4.77-MHz bus, not the AT's 8-MHz bus. In order to ensure that PC adapters worked reliably in ATs, the designers of the AT decided to slow accesses to 8-bit adapters to PC speeds by inserting wait states to double the access time. Modern adapters, such as the VGA, can easily be designed to run at AT speeds or faster, whether they're 8- or 16-bit devices -- but the AT bus has no way of knowing this, and insists on slowing them down -- just in case. It should be obvious that true 16-bit operation, where an adapter responds as a 16-bit device and handles a word at a time, is most desirable. Not at all obvious is that it's also desirable, that an adapter respond as a 16-bit device even if it can internally handle only a byte at a time. In this mode, an inherently 8-bit adapter announces to the bus that it's a 16-bit device; on writes, it accepts a word from the bus and then performs two 8-bit writes internally, and on reads, it performs two 8-bit reads internally and then sends a word to the bus. From the perspective of the bus, each word-sized operation seems to be a 16-bit operation to a true 16-bit adapter, but in truth two accesses are performed, so the operation takes twice as long as if the adapter were a 16-bit device internally.
Why bother? The advantage of having an 8-bit adapter respond as if it were a 16-bit adapter is this: The bus is fooled into thinking the adapter is a 16-bit device, so it doesn't assume that the adapter must run at PC speeds and doesn't insert three extra wait states per byte. From now on, I'll use the word "emulated" to describe the mode of operation in which an adapter that's internally an 8-bit device responds as a 16-bit adapter; this mode contrasts with the true 16-bit operation offered by adapters that not only respond as 16-bit devices but are 16-bit devices internally. AT plug-in memory adapters, for example, are true 16-bit adapters. 16-bit VGAs, on the other hand, may be either true or emulated 16-bit adapters; in fact, as we'll see, a single VGA may operate as either one, depending on the mode it's in.
Emulated 16-bit operation is at heart nothing more than a means of announcing to the AT bus that an inherently 8-bit adapter can run at AT speeds thereby making the three 8-bit-device wait states vanish. While emulated 16-bit adapters can run up to twice as slowly as true 16-bit adapters (word-sized accesses must still be performed a byte at a time), emulated 16-bit operations can double the performance of an inherently 8-bit adapter that is otherwise capable of responding instantly, by cutting access time from six to three cycles.