How specific was the Apple II floppy disk controller?

Question

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?

Answer 1

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.

Density

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.

Encodings

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.

Addendum

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.

Answer 2

TL;DR

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.

Answer 3

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.