Re: GCR Encoding

[Eric Smith <eric-no-spam-for-me@brouhaha.com>]

"Bryan Parkoff" <bryan.nospam.parkoff@nospam.com> writes:
>     I will be willing to pay you the fee for more information about MFM
> encoding and MFM hardware.

To understand any of these data formats, it is necessary to understand
the concept of a channel code, and the distinction between data bits and
channel bits.

Raw data cannot normally be written directly to a medium, or transmitted
across a communication channel, because there has to be some means at the
reading/receiving end to determine where each bit begins and ends.  One
of the most common ways of dealing with this is to transform the data
into a self-clocking format using a channel code.  Channel codes may
or may not be binary.  For instance, modems (including those used for
DSL) generally pack multiple bits per transmitted symbol.  However,
for our purposes we will only consider binary channel codes.

To convert binary data into a binary self-clocking channel code, extra
bits must be added.  Data bits are the user-level data.  For instance,
on an Apple II a logical sector consists of 256 bytes of eight bits
each.  But at the hardware level, the disk controller deals with groups
of eight channel bits that have special limitations on the allowable
combinations.  Each group of eight channel bits encodes only six data
bits (or five data bits in 13-sector format.

In general, GCR formats allow any string of channel bits that meet the
requirement of not too many consecutive zeros.  The channel bits are
used in groups, and typically there is a "code book" to map combinations
of user data bits into groups and vice versa, hence the term "group code".

Sometimes some other constraints are added; for instance, Apple GCR adds
the requirement that the most significant bit must be a one.

Apple calls groups "nibbles".

Note that in GCR there is not a one-to-one mapping of data bits into
channel bits.  You can't isolate bit 4 of the group, for instance, and
say that it corresponds to bit 6 of the data byte.

In simpler channel codes, there is a more direct relationship between
data bits and channel bits.  For instance, in FM coding every other
channel bit must be a one, and is called a clock bit.  The data bits are
passed through unmodified, so each data bit maps to exactly one
corresponding channel bit.  (Inside Apple DOS erroneously claims that
Apple GCR has clock bits.)  FM coding basically identical to the "4+4"
format used for the volume, track, and sector bytes of the address field
in Apple format.  But on an FM disk, all data is encoded that way.

You can see that FM is less efficient than Apple GCR.  There are
only 16 legal combinations of eight channel bits, versus 32 for Apple
13-sector format, and 64 for Apple 16-sector format.  (FM uses a few
otherwise "illegal" codes with a missing clock bit as the index mark,
address mark, and data mark.)

For the same channel bit rate, FM is 4/5 as efficient as Apple 13-sector
format (5+3 encoding) and 2/3 as efficient as Apple 16-sector format.

For typical 5.25-inch FM formats, the nominal channel bit cell time is 4
us, thus the interpulse time is 4 us or 8 us.  For each actual data byte
recorded, eight clock bits are inserted, so a byte of data requires 16
channel bits (64 us).

MFM packs data with twice the density by eliminating most clock bits.
Clock bits are only introduced when two consecutive data bits are both
zeros.  The channel bit rate is doubled, so the nominal interpulse times
are 4 us (between two consecutive one data bits), 8 us (between two one
data bits separated by a single zero data bit), or 6 us (between two one
bits separated by two zero data bits).  Thus twice as much data can be
stored on a disk using the same bandwidth, requiring only that the
read channel be more precisely able to discriminate the pulse timing.

>  Maybe FM encoding will be included.  I do have
> enough information about GCR encoding since I already have Beneath to DOS
> 3.3 and ProDOS.  I don't need more information for GCR encoding, but I need
> to understand how Disk II hardware work.  I do have Understanding Apple II+
> & //e book that explains Disk II hardware.

Based on the questions you asked in the original message, it would appear
that you should spend more time studying those books.

>     Do you have any book that can explain FM / MFM encoding and hardware?

No.  However, the data sheets for the NEC uPD765, Intel 8271 and 8272, and
Western Digital 1771 and 1791 have a lot of useful information about it.  The
data on the Western Digital parts may be found in their 1983 data book:
    http://www.bitsavers.org/pdf/westernDigital/_dataBooks/