Woz’s five-chip Apple II floppy controller made software do the expensive hardware’s work

Woz’s Apple II floppy controller handed the software a deadline every 32 microseconds. Moving jobs out of hardware made the controller cheaper, but the work had to happen somewhere. In this arrangement, the processor got the chores and a very small window in which to finish them.

Andy Hertzfeld’s first-person account calls the design a “five chip disk controller.” It shifted encoding, decoding and head movement into software, reducing the amount of circuitry required. The impressive part is the exchange: inexpensive hardware becomes useful because code arrives at exactly the right time, rather than because a feature disappeared from the requirement list.

Hertzfeld encountered the design while helping Burrell Smith and Brian Howard test a Macintosh prototype. They had wired up a Woz-style controller and needed working routines to exercise it. A small test loop and a logic analyzer were the starting tools, which is considerably more tangible than waving away every hardware question with the word software.

The timing problem was not completely settled in a manual. Hertzfeld describes asking Smith how long the prototype took to execute its instructions. Smith did not have the measurements yet, so the team watched the instructions on the analyzer and adjusted the routines. A predictable machine still needs its actual behavior measured (the stopwatch gets a vote).

There is an important correction below the story. In a comment attributed to SteveWoz, Woz says the explanation of one-to-one interleaving is wrong. His account distinguishes continuously reading or writing sectors from the extra time needed to move buffered data into its eventual RAM locations. Skipping that comment would turn an enjoyable reminiscence into misleading instruction.

The practical issue is where data waits between the disk and the program using it. If moving a sector takes too long, the next wanted sector can pass before the software is ready. Spacing sectors gives the processor breathing room; eliminating the extra copy can change that trade. The source’s disagreement is a reason to keep the mechanism specific, rather than repeat a simple claim that the Apple II could not write quickly enough.

For people working on constrained systems, the useful inheritance is the discipline around the boundary. A component count alone cannot tell you whether a design is simple to use. Some of that complexity may have moved into timing-sensitive routines, where every extra operation has to fit before the next byte demands attention.

Hertzfeld eventually used the prototype to display Apple II slideshow images after the others had gone to dinner. That is a better payoff than an abstract performance claim: the controller work produced something the team could actually see. The account still leaves readers a technical discussion underneath it, with the designer correcting the part nostalgia might otherwise smooth away.

Dinner could wait. The disk couldn’t.