Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-lcc!mordor!styx!ames!ucbcad!ucbvax!fizbin.DEC.COM!binder
From: binder@fizbin.DEC.COM (Sold - but we have others)
Newsgroups: comp.sys.apple
Subject: IBM/Apple disk interchange?
Message-ID: <8701062155.AA02531@decwrl.dec.com>
Date: Tue, 6-Jan-87 19:24:00 EST
Article-I.D.: decwrl.8701062155.AA02531
Posted: Tue Jan  6 19:24:00 1987
Date-Received: Wed, 7-Jan-87 05:49:52 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 79

We've had several people saying different things about whether IBM hardware 
can read/write Apple disks or Apple hardware read/write IBM disks.  From the
viewpoint of a hardware engineer who spent 15 years with disks and disk
controllers, I'd like to put in my two cents' worth.  Some of this stuff is
fairly heavy hardware terms!  Some or all of it may be hot air, if you've seen
something better.  If anyone out there has hard information to contradict
this, I'll be as happy as the next person to see it, but please don't shower
either me or the net with suppositions or rumors. 

The IBM 5-1/4" disk subsystem has at its heart the 765 disk controller chip.  
This chip is able to read or write only two disk recording schemes:

1.  FM (double frequency, also called single density), in which each bit is
    defined by a clock pulse at its beginning and by the next bit's clock
    pulse at its end.  Each ONE bit has a pulse between the two clocks. 
    Within the limits of disk speed tolerances, this recording scheme is
    self-clocking, in that every bit has its own clock pulse recorded on the
    disk.  IBM systems use FM for the first track of their double-density
    disks so that the system will be able to read the first track without
    knowing the density at which the remainder of the disk is recorded. 

2.  MFM (Miller Code, also called double density), in which each ONE bit is
    defined by a pulse, and there is a pulse between every two adjacent ZEROs
    to enable the phase-locked-loop data recovery system to keep tracking. 
    (This scheme is therefore not self-clocking.)  MFM is used because it
    allows twice as much data to be recorded on a disk by eliminating half
    of the magnetic pulses.

The 765 disk chip can be programmed for a very limited set of data formats, 
primarily the two used by IBM plus minor variations on those themes.  It
cannot be programmed to read the two GCR (Group Coded Recording) schemes used
by the Apple 5-1/4" disk system. 

The Apple 5-1/4" disk subsystem uses a state machine, implemented either with
a ROM and several MSI chips or as part of the Integrated Woz Machine(IWM)
superchip.  This state machine reads and writes Woz's own perverted form of 
GCR.  GCR encodes X bits of information in X+Y data bits, in which there are 
certain patterns that are defined as being illegal and other patterns that are
reserved for special meanings.  

Woz-style GCR, used by DOS 3.3 and ProDOS, uses a 4+4 GCR for the header (four
useful bits plus four more bits in each byte recorded on the disk) and a 6+2
code for the data sector - to record 256 data bytes, there are 342 actual
bytes on the disk.  (The older DOS 3.2 GCR was a 5+3 scheme.)  Among the
"illegal" patterns is the all ONEs pattern, or FF (hex). The actual pattern to
be recorded on the disk is constructed by 6502 software in a RAM buffer by
translating the desired data against a table before the state machine is
triggered.  When reading, the 342-byte pattern is translated in RAM back to
the desired data pattern. 

Among the oddities of this state machine is the way it writes and reads sector
preambles, which consist of five self- synchronization bytes (10 ONEs in a row
instead of 8). When reading, the state machine can find this 40-ONEs-in-a-row
pattern, and it is so designed that it will shift its expected byte boundaries
to be in proper synchronism at the end of the pattern even if it started
reading somewhere other than at the beginning.  The state machine would
interpret the IBM all-zeroes preamble as an all-ONEs synchronization field and
begin looking for a sector header, which also contains a series of reserved
GCR patterns.  If this series of patterns isn't found, the state machine
restarts.  It cannot be made to read FM or MFM. 

Now then, there are some tools out there that claim to be able to read
anything.  The ones I have seen are combinations of software and hardware -
the hardware is implemented in a nonstandard way, and it is designed to gobble
everything off the disk without regard to what it is.  Then the software goes
in and tries to decode it, much the same as do the common tools for copying
protected disks.  A tool like this can read either Apple or IBM, or virtually
anything else for that matter.  But it can't usually write all those different 
formats.

Okay, troops, if I'm wrong, let me know.  If I'm right, this should put an end 
to the question.

Cheers,
Dick Binder   (The Stainless Steel Rat)

DEC Enet:	ASD::BINDER
UUCP:		{ decvax, allegra, ucbvax... }!decwrl!asd.dec.com!binder
ARPA:		binder%asd.DEC@decwrl.ARPA