One of Wozniak's greatest inventions was the Apple II floppy disk controller, which allowed Apple to avoid going the Atari/Commodore route of making each disk drive a computer in its own right; instead, the hardware overhead per drive was very little beyond the drive mechanism itself. All this while achieving higher rather than lower performance.

It occurs to me to wonder about a possible downside: floppy disks were changing quite rapidly around that time, with several jumps in density, going from single to double sided, and a few years later, to 3.5". (There would also have been the transition from 8 to 5.25" which Apple just missed.)

Could the same controller card handle any of those transitions, or did a new model of drive need a new controller?

What about the associated firmware? Was the code that knew how to handle a particular kind of drive, located in ROM on the controller card?

  • 5
    I think it was more an interface board than a controller. The CPU did all the work.
    – user722
    Commented Jul 31, 2018 at 22:53

3 Answers 3


The Disk II controller in its original form is effectively limited to the Disk II because of the connections offered; in particular it expects direct control of a four-phase stepper motor whereas the standard Shugart bus exposes only step and direction signals.

It was also explicitly limited in terms of density, and effectively limited in terms of potential encoding unless you had a much faster processor.


The state machine which effects the drive's PLL is tuned to the GCR bit rate, which is the same as that of single density FM recording. So when reading you will not be able to detect flux transitions at a greater precision than that.

Similarly, the output rate is fixed. Not only is it fixed, but it's so fixed that the state machine and the CPU each take it as so implicit that the Disk II doesn't look for explicit signalling from the CPU for each new byte of output: it assumes it knows exactly when the CPU will produce them and just samples the data lines then, without inspection of the CPU's control lines. You'd better be in the prescribed-length loop with properly-placed STAs.


The limiting rule introduced by the Disk II (rather than occurring unavoidably as a result of analogue media) is that all 8-window blocks of flux transitions must begin with a transition at the top. The state machine is heavily oriented around that scheme: it'll take a brief pause every time a 1 reaches the top of its shift register, to make sure the CPU doesn't miss the event, and clear the thing afterwards.

That's still pretty broad, permitting both of Apple's GCR encodings and single density frequency modulation, but it's insufficient for double density MFM, even if the clock rate weren't wrong.

A much faster processor might be able to learn more from watching the shift register as it accumulates its result, but it wouldn't be able to fix the controller shift rate issue.


As noted above, Apple developed further iterations of disk controller to broaden their support; the original certainly wasn't a dead end. But it shouldn't be considered as generic as something like the Amiga. The need to keep in sync with a processor adds additional constraints.

  • 2
    That's a good explanation of the genius/crazyness of Wozniak. Writing my own disk monitor as a high-school kid , I tried to understand the disassembled DOS code and gave up. It was simply too weird.
    – Janka
    Commented Aug 6, 2018 at 0:00
  • 2
    If memory serves, the original controller state machine couldn't accommodate Apple's GCR encodings, but Woz figured out how he could manage to support pairs of consecutive zeroes while still fitting within the 16-state limit.
    – supercat
    Commented Aug 6, 2018 at 15:41
  • 1
    @supercat yes, that's right. In the drive, like in every other, there's analogue amplification of the signal before flux transitions are detected, with automatic gain. So that effects a maximum distance between transitions — too far apart and the gain will dial itself up so high that you get phantom noise. Woz was originally led to believe that any more than one window without a flux transition was liable to trigger random noise. He subsequently learnt that two windows was safe, but the first version of the state machine assumed the former.
    – Tommy
    Commented Aug 6, 2018 at 16:23
  • 1
    @supercat There were two sets of GCR encodings: the DOS 3.2 and earlier ROMs used 5-and-3 (storing 13 sectors per track) and the DOS 3.3 ROMs used 6-and-4 (storing 16 sectors per track). The sector address markers remained FM encoding in both cases.
    – cjs
    Commented May 5, 2020 at 6:10
  • 1
    @cjs: Yeah, I've since learned that despite the name "Muffin" (which I'd thought was a play on MFM) the 13-sector disks were another form of GCR. BTW, I just realized an interesting feature of the way Woz's cheaped out on write-protect reporting: if the Q7:Q6=01 state table were set up suitably, and software knew how to use it, the state machine could watch for changes to the state of write-protect when the drive is idle, thus letting software know if a disk swap may have occurred..
    – supercat
    Commented May 5, 2020 at 15:26


It's wasn't any more specific than any other controller. Apple did in fact make the switch to 3.5" (for the Mac) using the Apple II controller - just now as a single chip implementation called IWM - Integrated Woz Machine.

In general, it doesn't matter and any controller could be used for any drive (size) - given they use a compatible plug. Like any 3,5" 300 rpm drive with standard (Shugart) interface can be used with a S100 5.25" controller. No conversion needed - except maybe the plug that is.

Long Read

It occurs to me to wonder about a possible downside: floppy disks were changing quite rapidly around that time, with several jumps in density, going from single to double sided, and a few years later, to 3.5".

That's the same downturn for any other format - or none at all.

To look at this one might want to separate four things here:

  1. The Drive
  2. The Material
  3. The Controller
  4. The Driver/OS

Drive capabilities are basically invariant to the recording scheme. Their technology doesn't differ much since big old (audio) tape machines. It's a head and a magnetic media. While these components set upper (and lower) limits for signal recording in speed (as length of media per time - usually in cm/s).

Basically 8", 5.25" or 3" drive don't differ at all. They are just motors spinning disks at a certain (sometimes variable) rate and a head to read or write from the media.

The disk material does define the density possible, they have no further say in recording format or how fast or slow recording will happen (within physical limits). Most important here density as fluxes per length, which, together with the rotation speed, defines the maximum transfer speed it can handle.

A controller again can work with any drive - given that they got the same interface - and any material. As long as the material in conjunction with the rotation speed can handle the transfer speed. The controller defines how recording is done. Wozniak's choice of GCR or 'standard' FM/MFM encoding for example. Usually a controller is defined for a certain transfer speed like 250 kbps (FM) or 500 kbps (MFM).

These parts can interact in many ways but are in general interchangeable.

Last part is the Driver/OS as it might need some knowledge about the disk. Most likely rotation speed so it can accommodate track length as intended. Second might be maximum density per track, as it also does influence the amount of data that can be stored.

Could the same controller card handle any of those transitions, or did a new model of drive need a new controller?

It depends on how the new combination of above four factors is build. The switch from 5.25" disks to 3.5" is a great case study about how it can be done.

When the Shugart standard world of 300 rpm FM/MFM drives changed from 5.25" to 3.5" (*1), they had to wait until material with almost triple the density was developed. With that successfuly developed, controllers as well as OS and drivers could use these drives without any change.

Apple, in contrast, did switch with the Mac as one of the first (major) users toward 3,5". Years ahead of the 'standard' users. At that point disk material wasn't as developed, thus they used variable speed recording. A disk was partitioned into 5 zones with 8 sectors on the innermost tracks and 12 on the outermost, effectively now able to put 800 KiB on a smaller (3,4") disk with unimproved media much like the one used for 5.25".

Apple also kept the same GCR controller Woz developed for the Apple II. Just now moved into a single chip and called IWM - Integrated Woz Machine and motor speed control (via PWM) added (*2). Except for motor control, the device interface was kept the same.

So both strategies did work out well without (or rather minor) changes.

Similar changing form 360 rpm 8" disks to 300 rpm 5.25" could be done by just adapting OS/drivers.

So there are endless possibilities to switch over. All depending what the tools are, the ability to wait, or what is to be achieved.

What about the associated firmware? Was the code that knew how to handle a particular kind of drive, located in ROM on the controller card?

Depends much on the machine you're asking for. Anything possible here.

*1 - This is always about capacity per track. Adding more tracks do not really need changes except for the number of tracks incorporated on OS level.

*2 - Well, there where other changes to simplify driver writing, like a bitstream buffer, relaxing the timing constrains for the CPU quite a bit. After all, years have passed, and the standard what consists minimal investment have shifted.


The IWM chip, used in the prototype Mac with double sided "Twiggy" drives, and later in the original production Mac 128k with Sony 3.5" diskette drives, is basically Woz's original disk controller design (converted by Wendell Sander and Bob Bailey to NMOS), with the addition of buffer registers to allow the processor to run a bit more asynchronously. But, except for not having to run (* almost) synchronous with the disk data rate, the 68k CPU did all the raw data decoding (GCR nibbles to bytes, etc.) and head stepping in software, very similar to the 6502 code in the Apple II (DOS) RWTS.

(* the 6502 in the Apple II did not actually run purely clock synchronous with an absolutely periodic disk data rate, but jittered a half clock every scan line to maintain pseudo-NTSC color timing, worsening the timing error budget by a fraction of a nibble time).

The Amiga 1000 also did most of its disk data decoding and head stepping in software on the main CPU, but had the addition of DMA, and enough built-in timing to do MFM as well as GCR encoding/decoding.

  • 2
    IIRC. I helped design these custom ASIC chips many decades ago.
    – hotpaw2
    Commented Aug 4, 2018 at 17:56
  • 1
    The IWM? Or the Amiga chipset? In either case worth a story, don't you think so?
    – Raffzahn
    Commented Aug 4, 2018 at 19:50
  • Note the signatures on the cases.
    – hotpaw2
    Commented Aug 5, 2018 at 12:43
  • I can't see how things could work if the floppy controller's clock didn't remain synchronous at 2x the rate of the 6502 clock, with the same half-chroma delays as the CPU.
    – supercat
    Commented Aug 6, 2018 at 15:39

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .