Re: Apple2 disk controller questions

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

Supertimer <supertimer@aol.com> wrote:

> "Fabrice Frances" <frances@ensica.NOSPAM.fr> wrote:
> 
> >there's still something confusing me...
> >It seems 343 GCR-encoded bytes are transfered through the
> >disk controller for a single 256-bytes sector... I would say
> >GCR efficiency lies between FM (512) and MFM (256),
> >am I wrong ?
> 
> Come to think about it, you are right.  It must be the variable
> spin drives that give Apple 3.5" disks the extra 80k, but GCR
> is probably a little less efficient.

Allow me to step up on the soapbox for a few minutes.

First: rotation speed and capacity issues.

The 800K 3.5" disks get extra capacity due to varying rotation speed.
It isn't actually "constant linear velocity", but gets reasonably close
to it.  There are five speed bands, each of which contains 16 tracks.
Each speed band has one more sector per track (per side).  The inner
tracks have 8 sectors and the outer tracks have 12.  All sectors are 512
bytes, plus a small header area which isn't used on the Apple II.

Apple II 5.25" drives have a constant rotation speed, so the bits are
physically longer on the outer tracks, and all tracks have the same
number of sectors (ignoring copy protection schemes and older formats):
16 sectors, each of which holds 256 bytes.

The raw data transfer rate for the 3.5" drive is 500 kilobits per second
(2 microseconds per bit).  The 5.25" drive is half this: 250 kilobits
per second (4 microseconds per bit).

I'll ignore the 3.5" drive for most of the rest of this message.

The 5.25" drive has a nominal rotation speed of 300 rpm, which is 5
revolutions per second.  At 4 microseconds per bit, this works out to
about 50000 raw data bits per track.


Second: data encoding (FM vs MFS vs GCR)

FM uses a simple clock/data scheme, where data bits may be written as
either 0 or 1, but must be interleaved with clock bits (always 1,
ignoring synchronization issues).  All bits are regularly spaced.

Given the Apple II 5.25" drive characteristics, a totally packed track
recorded in FM would be able to fit 25000 bits, which is 3125 bytes.
This drops considerably if sectoring is used.  I have a page from an
Intel disk controller data sheet here, which shows the standards as
either 18 or 16 128 byte sectors per track (2.5KB at best, for a full 35
track disk capacity of 87.5KB per side).

There is no FM standard format with 256 bytes per sector quoted here,
but the ones with 512 bytes, 1KB, 2KB or 4KB per sector are able to fit
4KB onto the track.  I suspect these are actually for an 8 inch disk, or
possibly a 5.25" disk rotating slower (perhaps with double density
media).


MFM varies the recording format in two ways:

1. Clock bits can be omitted with certain combinations of data bits,
e.g. two adjacent 1 bits.

2. The bit cell timing is adjusted to allow bits to be recorded in twice
as many potential positions (i.e. 2 microsecond resolution for bit cell
positioning), but adjacent cells cannot contain 1 bits.  This means that
the 1 bits are always at least 4 microseconds apart on the disk, which
is sufficient for single density media.

In combination, these changes allow MFM to record exactly twice as many
bits per track as FM on the same media.  "Double density" media may
allow more reliable operation, but isn't essential.

The standard MFM format on a 5.25" disk has 9 sectors of 512 bytes per
track, which is 4.5KB.  (The theoretical limit without sectoring would
be 7250 bytes.)


Now lets look at GCR, as implemented in the Apple II.  Bits are written
in regularly spaced 4 microsecond cells, like FM.  GCR doesn't use clock
bits, but instead relies on using a limited subset of the 8-bit values
which can be reliably written to a disk, based on bit patterns.

For the Apple II 16 sector format, the rules used to pick the valid disk
bytes are:

1. Every byte must have bit 7 set.  (This is actually a limitation of
the Apple II disk controller, not the GCR format.  If this limitation
was removed, a few more byte values might be made available, but it
would complicate things considerably.)

2. The byte must not contain more than two adjacent zero bits.

3. There can be at most one pair of adjacent zero bits in each byte.
(This is not actually necessary, but reduces the number of valid bytes
to a convenient power of two plus a couple of spares.)

The end result is 64 valid disk bytes values plus one (0xD5 = 11010101)
which is reserved for use in address and data marks.

The Apple II uses a 6-and-2 encoding scheme, in which each data byte is
broken up into 6-bit and 2-bit fields.  The 6-bit value is used as an
index into the lookup table to get the corresponding valid disk byte.
The 2-bit leftover is combined over three bytes to get another 6-bit
number which is used similarly.  (The data corresponding to the leftover
bits is written at the end of the sector.)

When reading, the process is reversed.  A valid disk byte is used to
look up another table (which has unusued positions corresponding to
illegal disk bytes) to produce a 6-bit value.  This is combined with the
2-bit residue from the decoded data at the end of the sector to form an
8-bit data byte.

Right.  That's the guts of how the data in each sector is encoded.  With
a 6-and-2 split, there are (256 + roundup(256 / 3)) = 342 data bytes
written for each sector.

So, for a 256 byte sector:

FM needs to write 512*8 = 4096 bits

GCR needs to write 342*8 = 2736 bits

MFM needs to write 512*8 = 4096 potential bits, but in half the space,
so it only counts as 2048 bits.


The data header and trailer on the Apple II is seven disk bytes (D5 AA
AD at the beginning, checksum and three trailer bytes at the end, with
the third being a "slip" byte).

The address marks are actually recorded in FM to speed up processing, so
they need two disk bytes for each 8-bit data value.  They require
fourteen disk bytes in total (D5 AA 96, two bytes for volume, two bytes
for track, two bytes for sector, two bytes for checksum, DE AA EB).

There are also gaps between the address and data marks.  These are made
up of self-sync bytes, which are 10 bits instead of 8.  GAP1 (before
first sector) is typically 40 to 128 sync bytes.  GAP2 (between address
and data marks) is typically 5 to 10 sync bytes. GAP3 (between sectors)
is typically 14 to 24 sync bytes.

So, adding everything up, we could theoretically have:

128 * 10 + 16 * ((10 + 24) * 10 + (14 + 342 + 7) * 8) =
1280 + 16 * (340 + 2904) =
53184 bits per track

Dividing by 8 gives 6648 raw disk bytes per track.

In another posting in this thread, Fabrice Frances wrote:

> It seems the .nib format used for Apple II disks holds 6656 bytes per track,
> or 70 phases every 3328 bytes... Either one of these 300 rpm, 250 kbps,
> 6656 bytes/track cannot be exact... so ?

I imagine the 6656 is to allow for a little safety margin.  A real disk
on a drive which is running slow might be able to fit more bytes per
track, but a normal speed drive can't anywhere near fit this many.

Getting back to SuperTimer's article:

> What I don't understand is the high density 3.5" Apple II
> format.  Like the Mac, high density 3.5" Apple II disks are
> 1.44MB MFM.

The 3.5" disk effectively has twice the density of a corresponding 5.25"
disk, and bit cells are twice as fast: 2 microseconds for single/double
density instead of 4 microseconds.  MFM on a double density 3.5" disk
(720KB format) is able to use 1 microsecond positional resolution for
its bits, but must keep a gap of at least 2 microseconds between bits.

GCR sticks to 2 microseconds per bit cell, and Apple squeezes more data
on by varying the rotation speed (as mentioned earlier).  If they didn't
do this, and the disk rotated at the same speed as in a PC, I suspect it
would only hold 640KB (8 sectors per track), since MFM can squeeze more
data onto the track than GCR.

This assumes that the innermost (fastest) band is the same rotation
speed as the PC 3.5" drive.  I don't have the rotational specifications
for the PC 3.5" drive, so I can't check this detail.  According to its
manual, the Apple 3.5" Drive rotates at 394 to 490 rpm.

A high density 3.5" disk doubles the bit cell density again.  MFM uses 1
microsecond cells with 0.5 microsecond positional resolution.

(An aside: the high density 5.25" drive doubles the track density as
well as almost doubling the number of bits that can be recorded per
track.  The high density 3.5" drive has the same track density as the
double density drive, probably to allow better compatibility with double
density media than you typically get with 5.25" drives.)

Apple didn't bother to use GCR on high density 3.5" disks, however...

> However, there is a special 1.6MB GCR format that is used by AE's driver
> for the IIGS.  I'm not sure how the AE driver squishes those extra few
> kilobytes into the disk.

Now I'm going into speculation territory.

Given that the high density disk holds twice as many bits per track as
the double density one, and the drive mechanism supports 1 microsecond
bit cells for MFM, all that AE needed to do was to be able to transfer
data twice as fast and use the same GCR encoding and variations in
rotation speed.

The problem is that the IWM controller chip in the IIgs only supports 2
or 4 microseconds per bit cell (and the main CPU can't possibly keep up
with reading or writing a byte every 8 microseconds anyway - assuming no
accelerator).

To get around this, I expect the AE 1.6MB drive has internal RAM to
buffer data, in a similar manner to the UniDisk 3.5.  It probably uses a
proprietary transfer protocol to take advantage of the 2 microsecond
mode in the IWM.  (It could use the SmartPort protocol, but this slows
the transfer down to 4 microseconds per bit cell.)

This means that you can fit twice as much data on an AE 1.6MB HD disk,
but the transfer rate will be approximately the same as an 800KB disk.

On the other hand, a 1.44MB HD disk with a SuperDrive card is able to
transfer data twice as fast as a 720KB DD disk (the SuperDrive card has
a SWIM chip and a faster CPU).  If the SuperDrive card supported the
1.6MB format, then it would also get double the data throughput compared
to an 800KB disk.

Here endeth the lesson.
-- 
David Empson
dempson@actrix.gen.nz
Snail mail: P.O. Box 27-103, Wellington, New Zealand