PCIe · Module 1

ISA — The First PC Expansion Bus

How the ISA bus worked, why it was tied to the CPU's own bus, and the bandwidth, addressing, and manual-configuration limits that made it the first expansion bus the PC had to outgrow.

Chapter 1.1 laid out the arc from shared parallel buses to a switched serial fabric. This chapter takes the first stop on that map seriously. ISA is the bus that made the PC expandable, and it is a clean case study in how an interconnect's limits follow from its architecture rather than from any single weak component. ISA exposed a system-bus-like interface at the expansion slots: a card sees address lines, a data path, and bus control signals, and takes part in the same transaction model the processor side uses. Most of what constrained ISA follows from that choice.

1. What ISA Actually Was

ISA — Industry Standard Architecture — is the expansion bus of the IBM PC family. The name is retrospective: IBM shipped the PC bus and later the AT bus, and the industry applied "ISA" to the family afterwards, once clone vendors had made it a de-facto standard no single vendor owned.

Two generations sit under that one name, and the distinction matters for every number in this chapter:

The 8-bit PC/XT bus (1981–83). An 8-bit data path and 20 address lines — matching the 8088's 1 MB reach — brought to a single card-edge connector.
The 16-bit AT bus (1984). A second, shorter connector was added in line with the first, widening the data path to 16 bits and extending addressing to 24 lines (16 MB). An 8-bit card still worked: it used the first connector and ignored the second. That backward compatibility is a large part of why ISA lasted as long as it did.

Unless stated otherwise, the limits discussed below are those of the mature 16-bit AT-class ISA environment — the configuration that dominated the installed base and the one PCI was built to replace. The 8-bit PC/XT bus was narrower and more limited still.

The defining property is not the width. It is the participation model: an ISA card decodes address ranges it has been configured for and responds to bus control signals, rather than communicating through a discoverable, packetized, negotiated link. What reaches the slot is a buffered, latched extension of the system bus — real systems place bus-controller, transceiver, and latch logic between the processor and the connectors — but architecturally the card is a participant in a shared bus transaction, not an endpoint on a managed link.

2. How a Transfer Worked

The mechanism is deliberately simple. When the CPU reads or writes an address, that address appears on the bus along with a strobe indicating memory or I/O, read or write. Every card decodes the address lines. The one card configured to own that range drives the data lines (on a read) or latches them (on a write), and the cycle ends.

Two details do most of the work in explaining ISA's ceiling:

The bus clock was originally the CPU clock. In the first PCs the expansion bus ran at the processor's frequency — about 4.77 MHz on the original machine. That was convenient and cheap, and it was also a trap: as CPUs got faster, cards designed for the slow bus could not follow. The industry's fix was to decouple the expansion bus and settle it at a fixed, low frequency — commonly around 8 MHz — regardless of how fast the CPU ran. ISA's speed was frozen so that existing cards would keep working.

A transfer takes several bus clocks, not one. A standard ISA cycle spans multiple bus-clock periods, and a slow card can extend its own cycle further by asserting the wait-state signal. Cycle timing is therefore part of the throughput equation, not an afterthought to it — and how many clocks a transfer actually costs depends on the transaction type, the card, and the chipset implementation. There is no single ISA transfer rate to quote: sustained bandwidth is a property of a particular configuration, not a fixed architectural constant.

Figure 1 — ISA exposes the system bus at the expansion slots. Address, data, interrupt request, and DMA lines run the length of the bus, and the dashed connections mark every card tapping all of them. A card responds when it sees an address inside the range a human assigned it by jumper: it participates in the shared transaction rather than being discovered and configured by the host.

3. The Limits That Ended It

ISA did not fail at one thing. Four constraints arrived together — two on what the bus could move and reach, two on how devices could be fitted into a system at all.

Bandwidth was frozen by design. Decoupling the bus from the CPU clock is what preserved compatibility, and it is also what guaranteed the gap would widen. Processors kept getting faster; the expansion bus deliberately did not. By the early 1990s a hard disk controller or a graphics card wanted far more than ISA could deliver, and the bus could not be sped up without breaking every card already sold.

Addressing topped out at 16 MB. Twenty-four address lines reach 16 MB, which was generous in 1984 and a real constraint once PCs carried more memory than that. It bit hardest on bus-mastering and DMA cards, which have to generate addresses themselves: such a card could not reach memory above the 16 MB line, so systems needed awkward workarounds — copying through a buffer placed low in memory — to move data to or from regions an ISA card could not address.

Configuration was manual, and collisions were the user's problem. An ISA card needs an I/O port range, usually an interrupt line, and often a DMA channel. Nothing assigned these. A human read the manual and set jumpers or DIP switches, and if two cards were set to the same IRQ or the same port range, the result was a machine that misbehaved in ways with no clear error message. Plug and Play ISA arrived later to automate this, but it was a retrofit onto a bus never designed for discovery, and it never fully removed the problem.

Interrupt and DMA lines were scarce. The bus offers a small, fixed set of interrupt request lines and DMA channels — the AT expanded both over the original PC by cascading a second controller, but the total stayed small. Two cards that each needed a dedicated IRQ, in a machine where most lines were already claimed by the standard peripherals, simply could not both be installed. Scarcity of these lines, not bandwidth, is what blocked many real configurations.

Compatibility became a scaling constraint

Holding the bus clock steady so existing cards keep working is a defensible engineering decision — and on a shared bus it is also the decision that caps the whole system. Because every attached device operates against the same medium at the same rate, the configuration has to remain workable for the slowest card anyone might install. Compatibility and capability are therefore coupled: raising one risks the other.

The structural lesson is that this coupling is not inevitable — it is a consequence of the shared-bus model. Later interconnect architectures decouple the two, so a device's capabilities need not constrain what every other device in the system can do. How PCIe achieves that is the subject of later modules; what matters here is recognising the constraint ISA could not escape.

4. What Came Next, and Why It Was Not Enough

Two extensions tried to buy ISA more time before PCI displaced it.

EISA (1988) widened the bus to 32 bits while keeping the ISA connector compatible, so old cards still fitted. It was technically sound and commercially marginal — expensive, and mostly confined to servers.
VESA Local Bus (early 1990s) went the other direction: rather than improve the expansion bus, it wired high-bandwidth cards — graphics, chiefly — closer to the processor's local bus to escape ISA's speed. It worked, and it inherited the coupling problem in a sharper form, since a bus tied tightly to one generation of processor does not survive that processor being replaced.

Note the shape of both attempts, because it repeats. EISA widened the bus; VLB moved the hungriest device onto a faster, more private path. Chapter 1.4 will show AGP making exactly the same move for graphics a decade later. Widening and privileging one device are the two obvious responses when a shared bus runs out — and Chapter 1.1 already told you where that road ends.

5. Common Misconceptions

Myths to unlearn

"ISA was slow because 8 MHz was the fastest clock available." It was not. The bus was deliberately held at a low fixed frequency after being decoupled from a CPU clock that kept rising, specifically so existing cards would keep working. The constraint was compatibility, not the state of the art.
"ISA's problem was bandwidth." Bandwidth was one of four. Address reach, IRQ and DMA scarcity, and manual configuration each blocked real systems independently — and for many users, a resource conflict was the more visible failure.
"Plug and Play fixed ISA." PnP ISA did add a real mechanism — an isolation protocol that let the system identify participating cards and program their resource assignments instead of relying on jumpers. But it was a retrofit layered onto a bus with no native concept of configuration: it added no interrupt or DMA lines and no address reach, and any non-PnP card in the machine still had to be accommodated by hand, so conflicts persisted in mixed systems.
"Configuration on ISA was always manual." Also too strong, for the same reason — PnP-capable cards could be configured by software. The durable point is narrower and architectural: self-description was not part of the bus model. It arrived late, as an option, alongside a large installed base that predated it, which is why it could reduce the problem but never remove it. Contrast a bus where configuration is defined from the outset and every device must support it — the approach Chapter 1.3 takes up.

6. Understanding Check

7. Summary

ISA is the PC family's expansion bus, exposing the system bus at the slots: an 8-bit, 20-address PC/XT bus from 1981, extended by the 1984 AT to a 16-bit data path and 24 address lines, with backward compatibility preserved by a second in-line connector. Cards decode the address ranges they were configured for and respond to bus control signals; self-description was not part of the bus model as defined, and the configuration mechanism that arrived later was an option layered on top. The constraints below describe the mature 16-bit AT-class environment.

They follow from the architecture. Bandwidth was frozen deliberately — the bus was decoupled from a rising CPU clock and held at a low fixed frequency so existing cards would keep working — and because a transfer costs several bus clocks, with wait states on top, sustained throughput is set by cycle timing rather than by width × frequency. Addressing stopped at 16 MB, which constrained DMA and bus-mastering cards in particular. Configuration was manual, so IRQ, DMA, and port conflicts were routine and diagnosed by hand. And interrupt and DMA lines were scarce enough to block configurations outright. EISA and VESA Local Bus tried widening and privileging respectively; neither changed the model.

Hold one takeaway: on a shared bus, compatibility and capability are coupled. Operating parameters belong to the medium, so the system stays hostage to the least capable device that might be attached.

8. What Comes Next

Chapter 1.3 — PCI is the real successor: a bus that keeps the shared parallel model but adds the things ISA never had — a defined protocol rather than extended CPU signals, configuration space and automatic resource assignment instead of jumpers, and a substantially higher clock. Understanding what PCI fixed about ISA is the setup for Chapter 1.5, which examines the limits PCI could not fix.

For the whole arc in one view, revisit Evolution of System Interconnects. Browse the full path on the PCIe tutorials index.