Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 beta 3/9/83; site cwruecmp.UUCP
Path: utzoo!linus!philabs!cmcl2!floyd!harpo!decvax!cwruecmp!cmf
From: cmf@cwruecmp.UUCP (Carl Fongheiser)
Newsgroups: net.micro.apple,net.micro,net.rumor
Subject: Re: Apple drives may have more storage?
Message-ID: <1174@cwruecmp.UUCP>
Date: Mon, 4-Jun-84 01:28:45 EDT
Article-I.D.: cwruecmp.1174
Posted: Mon Jun  4 01:28:45 1984
Date-Received: Wed, 6-Jun-84 00:48:58 EDT
References: <1497@sdccs6.UUCP>
Organization: CWRU Computer Engr. Cleveland, Ohio
Lines: 60

There seems to be some confusion (this may be an understatement) about
exactly what an Apple disk drive is and what it will do.  This may be a
bit technical, but here goes...

The mechanics (i.e. head, motors, chassis, etc.) of the Apple drives are
equivalent to those of a Shugart SA400.  Shugarts were used for a while,
but reliability problems started cropping up, and they switched to ALPS
drives.  In any case, these are your standard, run-of-the-mill, 48 TPI
floppy drives.  Only 35 out of the 40 available tracks are used,
probably because 35 track drives are cheaper, being older.  The
recording method used is FM.  However, they pack 4K on a track, which is
the same density as most MFM disks.  In fact, if the Apple drive used 40
tracks and both sides (like some of the Rana and other drives), it would
have 320K per disk, just like an IBM PC.  Now, you may ask, how does the
Apple get MFM data density with FM data rates and encoding?  The answer
is a very clever recording method called MGCR (stands for Modified Group
Code Recording).  Thanks to some wizardry (no lesser adjective is
appropriate) on the part of Steve Wozniak, this is done with a handful
of cheap chips (look closely at the Apple controller sometime).

The basic idea involved in FM is to have a stream of clock bits with a
stream of data bits interleaved.  MFM takes this and fudges with the
clock bits (sorry for the lack of technical accuracy, folks), sometimes
dropping them altogether in order to fit in the data.  On the average,
there are more flux changes per unit length, and thus a higher bit
density.  MGCR takes the data bit stream and breaks it up into 6-bit
groups.  It maps these groups to 8-bit groups (hence the name "group
code recording")  which represent flux changes on the disk.  No clock
bits are used.  Instead, each 8-bit group conforms to a simple set of
restrictions regarding number of consecutive 0 bits and others
(including the high bit being high (no pun intended)).  These
restrictions allow the nifto Woz state machine on the controller to keep
track of everything and stay synced up.  This technique is used for
high-density tape drives and on the MAC.  In short, it gives you
double-density with single-density physical bit density (flux changes
per unit length), and hence, greater reliabilty.

It's too bad everyone else uses flakey old MFM.  Oh, well.

On the issue of 96 TPI drives, etc.:

The stepper for the head on Apple-compatible drives is controlled
directly by the 6502.  The existing code in DOS will step at 96 TPI even
with a 48 TPI mechanism.  Several copy-protection schemes rely on this
so-called "half-tracking" ability.  In fact, with appropriate
incantations, you can step the head at 192 TPI.  There's only one small
catch:  a 48 TPI head is twice as wide as the one on a 96 TPI mechanism.
Therefore,  a standard Apple drive will not quite handle 96 TPI.  A 96
TPI mechanism will.  This is the trick by which the Rana and other 96
TPI drives will boot and run 48 TPI (standard) disks without
complaining.  They look like normal drives, but can handle the higher
track density.  One wonders why Apple doesn't bring out 80 track, double
sided drives.  Again, Oh well.

				--Clayton Elwell
				...!cbosgd!osu-dbs!elwell
				despite the address on the header of
				this message.

P.S. Flames are welcome, but do not send to cwruecmp!cmf...