Legacy Peripheral Interfaces

Chapter 1.1 made a claim without yet showing you the evidence: that peripheral fragmentation was never really about connector shapes, and that it ran through signalling, communication models, configuration, software and the whole lifecycle of attaching a device. That chapter argued the shape of the problem. This one puts the actual interfaces on the table and lets you compare them.

The temptation with a chapter like this is to write a museum tour — a paragraph each on ports you will never wire up, ending in the comfortable conclusion that old things were worse than new things. That would teach you nothing. These interfaces were, for the most part, competent answers to the problems their designers were given. What they were not was a system, and the only way to see that clearly is to compare them along the dimensions an architect would actually care about.

So this chapter is organised by engineering dimension rather than by chronology. By the end you should be able to look at any two peripheral interfaces and say not "this one is older" but "these two make different assumptions about who knows what, and when" — which is the skill Chapters 1.3 to 1.5 will exercise on individual interfaces in detail.

1. The Unit of Comparison — an Attachment Stack

Fix the instrument before using it. When we say a computer "had a serial port", we are naming only the visible end of something much deeper. What the machine actually carried was an attachment stack: a vertical column of commitments, every one of which had to exist before a peripheral could do useful work.

A stack includes a connector and cable; an electrical convention on the wire; a communication model that says what the exchanged signals mean; host-side controller hardware that implements that model; a story about how the host learns what is attached and configures it; an expectation about when a device may be connected or removed; an arrangement for powering the device; and the software that knows all of the above.

The critical property — the one this whole chapter exists to establish — is that these stacks were vertical and independent. Work done at any layer of one stack was worth nothing at the same layer of another. Two interfaces might both be described as "serial" and still share no electrical convention, no framing, no configuration model and no driver code. A computer with five peripheral interfaces was not a computer with five cables. It was a computer maintaining five parallel columns of unrelated engineering.

2. Four Columns, One Machine

Figure 1 puts four representative stacks side by side. Read it vertically first — each column is one complete path from a connector down to the software that drives it — and then notice what is missing horizontally.

There are no horizontal edges in Figure 1, and their absence is the whole diagram. Four columns of roughly equal depth, no layer shared, no reuse available at any level. A fifth device class arriving in the market would have drawn a fifth column of the same depth rather than attaching to anything already present.

A note on scope before the comparison begins. These four are representative, not exhaustive, and no single machine necessarily carried all of them — SCSI in particular was common on some platforms and an add-in purchase on others. A game port, frequently doubling as an attachment for MIDI instruments, is a fifth stack worth knowing about precisely because it shows how narrow a column could be: an interface serving essentially two device families, carrying its own connector and its own host-side logic like all the others.

3. Dedicated Purpose Against General-Purpose Pipe

The first real dimension separates interfaces built around a device from interfaces built around a job.

At one end sits the dedicated input port. A keyboard port existed to have a keyboard on it. The interface could assume what was attached, which is an enormously simplifying assumption: no identification is needed when the answer is known in advance, and the host-side controller can be built for one kind of traffic.

At the other end sits the serial port, which is closest to a general-purpose pipe. It moved characters, and it was deliberately vague about what those characters meant — which is why it hosted modems, terminals, measurement instruments, and on some systems pointing devices too. That generality is a genuine strength, and it is worth resisting the reflex to read this chapter as a list of failings.

But generality at the transport layer bought less than it appears to, because the interface stopped there. It would carry any characters you liked and had nothing to say about which characters a given device expected. The agreement about meaning lived entirely in the two endpoints, which in practice meant it lived in the operator and in device-specific software.

The parallel printer port sits in between, and it is the more interesting case: an interface whose control lines were named and shaped for the mechanics of printing. Other devices were later attached through it — storage and scanners among them — but doing so meant working within, or around, a design that had a particular device class in mind. An interface shaped for one job can usually be pressed into another, but the fit is something the device and its software have to pay for.

4. Serial Against Parallel Is Not the Dividing Line

This section exists to prevent a specific wrong conclusion, because the wrong conclusion is seductive and extremely common.

The tempting story is: legacy ports were parallel, parallel is bad, USB is serial, therefore USB won. Every step of that is confused, and the confusion will actively damage your understanding of the chapters ahead.

Start with the technical half. Presenting several bits at once on separate lines is a real design with real constraints: the receiving end must sample the lines within one common window, so the lines must stay adequately aligned with each other — and keeping them aligned gets harder as cables get longer and rates get higher. Sending bits one after another along a single path does not face that particular problem, which is one reason so many later interfaces are serial. That much is true.

Now the architectural half, which is what matters here. Not one of the costs Chapter 1.1 identified — a host interface per device class, devices that cannot identify themselves, configuration done by hand, undefined attachment behaviour, capacity fixed at manufacture — is caused by sending bits in parallel. A serial port fragmented the landscape exactly as thoroughly as a parallel one. Two interfaces can both be serial and share nothing else: not voltages, not framing, not the meaning of what is framed, not a way to discover what is on the other end.

Hold this firmly, because USB is itself serial and the resemblance is a trap. If "serial" were the answer, the serial port would already have been the answer. What separates a universal peripheral architecture from a legacy port is not the number of wires carrying data. It is everything the interface promises above the wire: identity, configuration, topology and lifecycle.

5. One Device, or Several?

Interfaces also differed in how many peripherals they could serve, and this is where the "all legacy interfaces were alike" reflex breaks down most usefully.

The dedicated input ports were the simple case: one port, one device, no ambiguity about who is speaking, and no mechanism needed to resolve it. The parallel printer port was much the same in ordinary use. The serial port served one device per port, with machines commonly offering a small fixed number of ports.

SCSI is the instructive exception, and it is the reason this chapter includes it. SCSI was a genuine bus: several devices shared one physical path and were distinguished by an address, so a host adapter could direct a command at one device among many. That is a materially more sophisticated attachment model than the ports around it — closer in spirit to what came later than to its contemporaries.

Which makes the way it fell short the more valuable lesson. Those addresses were not worked out by the system; each device had to be given a unique address by whoever installed it, and the electrical arrangement of the bus imposed its own installation requirements about how the chain was terminated. The mechanism for having many devices existed. The mechanism for making that effortless did not, so expansion remained an operation performed by someone who understood the rules.

So the honest summary of this dimension is not "legacy interfaces could not expand." It is that expansion, where available at all, was a task delegated to a knowledgeable human rather than a property of the architecture.

6. How Much the Host Had to Know in Advance

Now the dimension that separates these interfaces most sharply from anything modern, and the one Chapter 1.1 identified as the expensive one.

Ask of each stack: at the moment of connection, how much does the system already have to know for the connection to be useful?

For a dedicated input port, a great deal is known and none of it needs discovering — the port's purpose is its answer. For the printer port, little had to be decided for the device it was designed around. For a serial port, the interface answered nothing at all: the framing details and the meaning of the traffic both had to be agreed in advance, which in practice meant an operator selecting settings and installing software that matched the device on the other end. For SCSI, the host adapter could scan the bus and find devices at their addresses — but only because a person had already assigned those addresses and cabled the bus correctly.

Two observations, and the second one matters more.

First, these interfaces genuinely differed here, and a chapter that flattened them into "none of them had discovery" would be teaching something false. SCSI's scan is real discovery of a kind. A dedicated port's assumption is a legitimate design answer to the question, not an absence of one.

Second, and decisively: no two of them answered the question the same way. Even where discovery existed it was specific to its own stack, so the host needed a separate discovery and configuration path per interface — and the knowledge that tied a physical device to the software that could drive it still, overwhelmingly, originated with a human.

7. Attachment and Power Were Separate Questions

Two lifecycle properties, both of which reward care.

Connecting while the system runs. These interfaces were, in general, not designed around a peripheral that arrives after start-up. Dedicated input ports and SCSI chains were typically expected to be populated when the machine came up and scanned. In practice, behaviour on live connection varied by interface, by implementation and by era — some arrangements tolerated it, others were explicitly not intended to, and hot-swap capability did exist in particular environments. The dependable statement is not that hot attachment was impossible; it is that it was not a defined, architecturally supported event with guaranteed electrical and software behaviour, so a user could not rely on a rule that the architecture had never written down.

Powering the device. This one is routinely overstated, so be precise: some interfaces did supply power to the peripheral they were designed for. A dedicated keyboard or mouse port powered its device; the game port likewise supplied a rail for the controller attached to it. What did not exist was a general power contract across the attachment surface — a defined budget that any peripheral could request against. So whether a device needed a second cable to a wall socket depended on which stack it happened to attach through, and the answer was a property of that stack rather than of the system.

8. The Comparison, Side by Side

With the dimensions established, the landscape fits in one table. Read it by row — each row is a question you can ask of any peripheral interface, including the ones that came after.

The table's value is not the individual cells. It is that no column can be derived from another. Learn one row for one interface and you have learned nothing about the neighbouring column — which is the same statement Figure 1 made visually, now with the detail filled in.

9. Fragmentation Propagates Inward

Everything so far has been described at the connector panel. The consequence that matters to a hardware engineer is what those differences do once they are inside the machine.

A distinct attachment stack generally implies distinct silicon: controller logic implementing that interface's communication model, and the electrical interface circuitry that drives and receives its particular signalling. It implies a distinct software-visible surface — its own registers, its own notion of what an event on the interface means, its own path by which the processor is told something has happened. It implies a distinct configuration procedure, a distinct driver, and distinct firmware knowledge wherever the peripheral has a controller of its own.

Follow that chain and the shape of the cost becomes clear:

a separate attachment stack
        ↓
separate controller logic and interface circuitry
        ↓
separate registers, events and software paths
        ↓
separate configuration, driver and firmware knowledge
        ↓
another integration and verification surface to own

That last line is the one worth keeping. Each interface is not merely a block to design; it is a block to verify, to integrate, to bring up on real silicon, and to support in software for as long as the product lives. And because the stacks share no layer, none of that effort is transferable: correctness established for one interface says nothing about the next.

This is the inward-facing form of the scaling problem Chapter 1.1 identified from outside. The same argument had already been settled inside a chip, where connecting every block to a processor with private signals gives way to fixing one interface and reusing it — the reasoning developed in CPU-to-Peripheral Communication. Peripheral fragmentation is not confined to the back panel. It propagates inward, and it is paid for in hardware, firmware, software and verification.

10. What Would Have to Become Common

Now use the comparison rather than recalling it. Look back along the rows of §8 and ask the question this chapter has been building toward:

What would have to become common before one interface could serve every one of these device classes?

Not the connector alone — §3 and §4 have already disposed of that. Row by row, the table names its own answer. A shared electrical and framing agreement, so that the physical layer stops being a per-device negotiation. A shared communication model above it, so that device classes differ in what they say rather than in how saying works. A defined way for a device to supply its own identity, so that the knowledge binding hardware to software stops originating with a person. A common configuration procedure that follows from that identity. A defined notion of attachment and removal, so the lifecycle is part of the architecture instead of a gap in it. An expansion mechanism that does not require an installer who knows the rules. A power arrangement general enough to serve devices of differing appetite. And a software-visible abstraction shared across device classes, so the host's complexity stops scaling with the market's variety.

That list is not a description of USB. It is what falls out of the table in §8 when you ask what the columns would need to share. Chapter 1.6 takes up the question of what was actually built and why, and the modules after it work through the mechanisms one at a time. What this chapter can already tell you is the standard those mechanisms have to meet — and that a proposal satisfying only the first item on the list would not have been worth the effort.

11. Common Misconceptions

12. Reason It Through

Work through this before reading the answer.

A machine replaces its serial, parallel, keyboard, mouse and game connectors with a single connector shape, so any peripheral plugs into any port. Behind the connector, each device class keeps its own electrical mode, its own discovery mechanism, its own configuration procedure and its own driver interface. Has this created a universal peripheral architecture?

Which row of §8 changed? Only the physical one, and only partially. The other five rows — communication character, discovery and configuration, attachment expectation, power relationship, expansion — are untouched by construction.

What happens inside the machine? Nothing improves. §9's chain begins at a separate attachment stack, not at a separate connector, so the controller logic, registers, software paths, drivers and verification surfaces all remain exactly as many as before. The host's complexity still scales with device variety.

What has become worse? A failure mode has been manufactured. Previously the connector was a physical type-check: a plug that fitted was a plug that belonged. Now every port accepts every plug while only some combinations function, so a user can make a connection that is visibly correct and silently wrong — and the mechanism that used to prevent that mistake has been deliberately removed.

What is the principle? Physical consolidation is not architectural standardization. The connector is one layer of a stack that is many layers deep; unifying it while the layers beneath stay unlike changes what a mistake looks like rather than whether mistakes are possible. A real solution standardises the rows that generate the cost, and a common connector is then a consequence of having done so.

13. Understanding Check

14. Summary

The pre-USB landscape is best understood not as a collection of connectors but as a collection of attachment stacks — vertical columns running from a connector down through electrical convention, communication model, host controller, discovery and configuration, attachment expectation, power arrangement and driver software. Figure 1's missing horizontal edges are the chapter's central fact: the columns shared no layer, so nothing done for one was worth anything to another.

Comparing those stacks along engineering dimensions rather than by age shows real and instructive differences. Some interfaces were built around a known device and some around a general job; some served one peripheral and SCSI served several by address; discovery ranged from a bus the adapter could scan, through a port whose purpose was its own answer, to an interface that answered nothing; power was supplied by some stacks and defined by none in general. Serial against parallel is not the dividing line — the serial port was serial and fragmented the landscape thoroughly, and USB is serial too, so the distinction must be sought in what an interface promises above the wire.

Those differences did not stay at the back panel. Each stack propagated inward into its own controller logic, registers, event semantics, configuration path, driver and firmware, and therefore into its own integration and verification surface — none of it transferable.

The conclusion to carry forward is a judgement about where the defect lived. Individual legacy interfaces were, in the main, competent answers to the problems they were given; what the machine lacked was any common peripheral architecture above them. USB's value must therefore be assessed as architectural standardization — of attachment, identification, configuration, expansion, lifecycle and software abstraction — and not as the replacement of several connectors by one.

15. What Comes Next

The comparison is built; now the curriculum fills in the columns. Chapter 1.3 takes RS-232 first, and it is the right place to start for two reasons. It is the most general-purpose of the four — a pipe that would carry anything and guarantee nothing about meaning — so it shows most clearly what an interface leaves undone when it declines to define anything above the wire. And it is the one whose assumptions are most often misread as USB's ancestry simply because both move bits along a single path, which makes it the sharpest test of §4's distinction. Chapters 1.4 and 1.5 then take the parallel port and the dedicated input ports, before Chapter 1.6 returns to the question of why USB was created at all.

Browse the full path on the USB tutorials index.