Apple GCR

From: Eric Smith <eric_at_brouhaha.com>
Date: Wed Apr 7 21:14:12 1999

Chandra Bajpai writes:
> Can someone explain how the Apple II GCR worked? I tried deciphering this
> several years ago and I could figure it out (the only references I found
> were very vague). I believe the Apple Mac using the same GCR technique (at
> least on the 400K/800K drives). I'm interested in knowing how the data
> encoding scheme worked.

The first GCR scheme on the Apple ][ packed five user data bits into each
group of eight cells [*] on the disk, resulting in 13 sectors per track. This
encoding is 25% more efficient than FM (single density) recording. Because of
the way the disk controller works, the most significant bit of each 8-bit
group code (AKA nibble) is required to be a one, and there can't be two
consecutive zeros.

The newer scheme, introduced with Apple Pascal and Apple DOS 3.3, store
16 sectors per track by packing six user data bits per eight cells. This
is achieved by relaxing the constraint on zero bits so that there can be
two consecutive zeros, but not three. This required a change to the state
machine PROM in order to reliably retime the read data; the old PROM was
designated P6, and the new one is P6A. (The boot PROM also changed from
P5 to P5A, but is not involved in the disk controller data path.) This
encoding is now 50% more efficient than FM (single density).

However, MFM (double density) is 100% more efficent than FM, so Apple's
encoding scheme is still not as efficient as that used by most other
systems. On the other hand, it is quite elegant given the simplicity of
the controller.

The Apple ][ disk format use FM encoding for the contents of address fields;
on some of their later GCR systems, such as the Twiggy disks on the Lisa,
they switched over to GCR for address fields as well.

For a more detailed explanation, see the book _Beneath Apple DOS_.

Eric

[*] I'm using the term cell to refer to a position on the disk in which
there might be a flux transition, or the absence of a flux transition.
Loosely speaking, this is a bit, but it doesn't directly correspond to a
bit of user data.
Received on Wed Apr 07 1999 - 21:14:12 BST