Re: 6 & 2 / 5 & 3 Encoding

[dempson@atlantis.actrix.gen.nz (David Empson)]

In article <3gsniu$ok9@gap.cco.caltech.edu>,
Nathan Mates <nathan@cco.caltech.edu> wrote:
> In article <3gop7c$ma8@usenet.ins.cwru.edu>,
> Michael A. Balfour <mab22@po.CWRU.Edu> wrote:
> >I've been busy writing an emulator, and I'm on disk access currently.
> >Unfortunately, I don't have access to any useful texts like Beneath
> >Apple DOS, so I was wondering if somebody could *please* explain to me
> >how 6 & 2 and 5 & 3 encoding works (and for that matter, why it's
> >necessary).  E-mail would be greatly appreciated.
> 
>    Unless you're planning to make this a 1:1 emulator down to the
> hardware, you might want to skip this step. Basically, it comes from
> the fact that early Disk II controllers could not reliably read more
> than 1 0 bit. Two or more zeros in a row wouls start producing false
> 1's, and other stuff you'd rather not deal with.

It is a general characteristic of ALL disk drives that they cannot
reliably read a continuous sequence of zero bits, because of timing
differences between the drive used to read and write the disk, and
speed variations.

A one bit is recorded as a reversal in the magnetic flux.  A zero bit
is no change in the flux.  The receive circuitry can cope with
variations in speed as long as the one bits are close enough together.

Older disk drives (pre Apple II) used a technique called FM (frequency
modulation) in which the data bits were written to the disk with
interleaved "clock bits" (one).  The Apple II uses this method for the
address field of each sector (4 and 4 encoding).

The Apple II gets quite a lot more storage out of a single density
disk by eliminating the clock bits and allowing zero bits to be
written more often.  (The technique used by the Apple is called "GCR"
- Group Code Recording.)

The PC uses a technique called MFM (modified frequency modulation)
which allows most of the clock bits to be eliminated.  MFM is about as
efficient as GCR for disk usage.  The PC also uses higher density
(less time per bit) and also uses both sides and more tracks to get
more data onto the disk.

Getting back to the Apple II:

With the original DOS 3.0 through 3.2.1, data was recorded in "5 and
3" format.  With 5-and-3, each data byte is split into a group of five
bits and a group of three bits.  The five bit code is used to look up
a table of bytes which can be written to the disk and reliably read
back again.  The three bits are combined with leftover bits from
another byte to make up another five-bit number.

The valid disk bytes for 5-and-3 encoding must obey the following rules:

- Bit 7 must be set (this is a requirement of the Disk ][ controller);
- There cannot be any adjacent zero bits.

The first valid disk byte with this scheme is $AA (10101010).  There
are 34 valid disk bytes from $AA to $FF.  Only 32 bytes are required
for a 5-bit code, so two were removed from the list ($D5 and $AA) and
reserved for use as mark bytes.

Under this scheme, 410 disk bytes are required to store 256 data bytes
(256 times 1.6), and there are 13 sectors per track.

With DOS 3.3 and Apple Pascal, Apple improved the encoding system
(requiring a change in the disk controller's logic state sequencer and
boot ROM, but no change in the drive itself), allowing the use of
6-and-2 encoding.

Under this scheme, 6 bits from each data byte are used to look up a
table of 64 valid disk bytes.  The remaining two bits are combines
with two bits from another two bytes to form another 6-bit code.

The rules for valid disk bytes under 6-and-2 encoding are:

- Bit 7 must be set.
- There must be no more than two adjacent zero bits, and only one pair
of adjacent zero bits within the byte.
- There must be at least one pair of adjacent one bits.  (This is an
artificial requirement, used to reduce the number of available bytes.)

The valid disk bytes start at $96 (10010110).  There are 66 valid disk
bytes, and $D5 and $AA are again removed for use as unique signature
bytes, leaving 64 coded disk bytes, exactly the number needed to
encode a 6-bit number.

>    The solution was to pad a series of 5 bits with 3 one bits such
> that there was never any 2 0's in a row

Nope.  The "5-and-3" name comes from the splitting of data bytes into
a five bit and three bit group.


Michael - I've hardly scratched the surface.  To provide enough detail
for you to implement this an emulator would require retyping much of
the early part of Beneath Apple DOS.

I suggest you buy your own copy of the book.  It is available from
Byte Works for US$12.95.

Byte Works, Inc.
8000 Wagon Mound Drive N.W.
Albuquerque, NM 87120
U.S.A.

Phone   (505)898-8183
E-Mail  MikeW50@aol.com
-- 
David Empson
dempson@actrix.gen.nz
Snail mail: P.O. Box 27-103, Wellington, New Zealand