Re: GCR specification - where?

[nparker@cie-2.uoregon.edu (Neil Parker)]

In article <5dtns1$ajp@staff.cs.su.oz.au> ftww@cs.su.oz.au (Fred the Wonder
Worm) writes:
>
>I've recently unearthed my Apple ][+ and was somewhat surprised to find
>that everything was in working order (I did clear the spiders out of the
>case first, though).  Anyway, I want to find out precisely how the data
>is laid out on the disk; much searching through FAQs and various other
>places has revealed little more than that GCR (group code recording) is
>used.
>
>So now what I want is a description of how data is organized on the disk
>under GCR, and how this is translated into bytes to move into memory.
>Obviously I could look at RWTS, but it's likely I would misunderstand
>something, and in any case the timing considerations would not be spelt
>out.  So does anyone have such a specification handy?

As others have pointed out, the best source for this information in _Beneath_
_Apple_DOS_, by Don Worth and Pieter Lechner.  I believe Byteworks still
has it for sale--check out their catalog at
http://www.hypermall.com/byteworks/.

The full details are a bit too long to repeat here, but maybe the following
will be useful:

A disk drive controller contains an internal clock which typically runs at
0.25 MHz, one tick every four microseconds (except for 3.5-inch and
high-density controllers, where the clock runs faster).  If a change in the
magnetic polarity of the disk surface occurs between two clock ticks, the
controller reads a "1" bit.  If there is no polarity change between two
clock ticks, the controller reads a "0" bit.

But this convention has one major problem:  a "0" bit is defined as
"nothing happened between the last two clock ticks."  If nothing keeps
happening for too long, the clock can get out of sync with the spinning
disk, and incorrect data will be read.  Apple disk drives can only handle
two consecutive 0 bits before the clock starts to drift out of sync.

So some means must be found to guarantee that data stream never contains
three consecutive 0 bits without an intervening 1 bit.  There are several
different ways of solving this problem.

The earliest solution was to simply insert an extra 1 bit after every data
bit when the data is written.  When the data is read back, the controller
uses these extra 1 bits to resynchronize the clock, but strips them out
before handing them back to the user.  This scheme is called "frequency
modulation," or "FM."

Later somebody realized that FM encoding is serious overkill...it inserts
an extra 1 bit after *every* bit, when all we really need is to insert an
extra 1 bit between two consecutive 0 bits.  In order to make this extra 1
bit distinguishable from the real data bits, it's written during the
"wrong" part of the controller's clock cycle.  This scheme is called
"modified frequency modulation," or "MFM," and it packs the data much more
efficiently than FM (which, of course, doubles the length of the data
stream).  MFM is the scheme used in current PC disk controllers, and on
1.44-Meg 3.5-inch floppies.

The scheme used in Apple II disk controllers is an entirely different
approach.  It never inserts any extra bits at all--instead, it relies on
the software to encode the data into a form that meets the
only-two-consecutive-zero-bits requirement before presenting it to the
controller for writing.  

For various technical reasons, the Apple II controller imposes additional
requirements--it deals with raw data bits in groups of eight, and it expect
the high bit of every eight-bit group to be set.  Between this restriction
and the only-two-consecutive-zero-bits restriction, there are about 70
different eight-bit groups that the controller can read reliably.

Apple DOS uses 64 of these ~70 groups.  It takes the data to be written,
breaks it down into groups of six bits, and replaces each six-bit sequence
by one of the 64 valid disk groups by looking it up in a table.

This scheme is called "group code recording," or "GCR," because it encodes
each six-bit group of data bits by an eight-bit group of disk bits.  It
expands the data stream by about 33%...much more efficient than FM, but not
quite as good as MFM.


The breaking down of the original data into six-bit groups is somewhat
complicated, and I'm not going to try to describe it here.  There's an
excellent picture of the process on page 3-20 of _Beneath_Apple_DOS_.

>PS: While I'm here, I'd also like descriptions of what happens with the
>    stepper motors in the drive.  I have a document by Neil Parker which
>    mentions the four phases, but doesn't say what happens if more than
>    one phase is on at once, or how long programs should wait before
>    assuming the head is where they want it to be.

With 5.25-inch drives, turning on more than one phase at the same time
isn't useful.  I don't know exactly what it does, but I suspect it would
try to move the head to whichever of the two phases happens to be nearest
to its current position.

It's a different story for 3.5-inch drives.  The Unidisk 3.5 recognizes
phases 0 and 2 turned on at the same time as the Smartport bus reset
signal, and phases 1 and 3 turned on at the same time as the signal to
begin a Smartport bus transaction.  These combinations were chosen
specifically because they're useless on a 5.25-inch drive.  And the Apple
3.5 Drive recognizes phases 0 through 2 as internal register-select
signals, and phase 3 as a "perform the selected action" signal.


If the document you've been reading is what I think it is, then the timing
information for the stepper motor can be extracted from the TRKMOVE routine
at the end of the document.  The delay is generated by these instructions:

     LDA #$56
     JSR WAIT

The WAIT subroutine delays (5*A^2 + 27*A + 26)/2 microseconds, so the
total delay here is about 20 milliseconds.  This is exactly the same delay
used by the disk controller boot ROM.  DOS 3.3 and ProDOS use a more
sophisticated delay routine, where the delay gets shorter as the head picks
up momentum.

               - Neil Parker
-- 
Neil Parker, nparker@{cie-2,cie}.uoregon.edu, http://cie-2.uoregon.edu/~nparker
     "Evolution is vastly overrated."  -- Ambassador Delenn, _Babylon_5_

Unsolicited commercial e-mail to my address will be discarded unread.