FM, MFM, and GCR channel codes (was Re: stepping machanism of Apple Disk ][ drive)

From: CLASSICCMP_at_trailing-edge.COM <(CLASSICCMP_at_trailing-edge.COM)>
Date: Fri Apr 9 19:14:50 1999

>Dick wrote:
>> One interesting thing about the Apple GCR modulation format is that it
>> essentially was a "double-density" technique.

>Tim wrote:
>> Eric said the same thing, and I disagree with you both. To me (and all

>I said no such thing. I said that Apple used FM for the address fields,
>and that the GCR they used for data fields was more efficient than FM, and
>less efficient than MFM.

I think you're confused as to what I was disagreeing with, and
that's probably my fault for not explaining myself more clearly. I was
disagreeing with what I believe to be your assertion, Eric, that
you can take any FM data channel, pump about 50% more data through it with
GCR, and pump twice as much data through it with MFM.

There are twice as many places in a MFM
data stream where a transition *may* take place, as compared to a FM data
stream at the same data rate. The maximum number of transitions per time
remains the same.

At first glance, this might lead you to believe that the bandwidth
needed for a FM encoding that gives you a data rate of 250kHz
will also support a MFM encoding at 500kHz. It isn't this simple;
if you do a Fourier transform of the MFM stream you'll see that you
do indeed more bandwidth for MFM.

On the other hand, a GCR data stream over the same circuit will
give you a data rate of 375 kHz or so (depending on the details
of the GCR) without requiring more bandwidth than the 250kHz FM channel.
(Admittedly the GCR distribution of energy in that bandwidth will be
more even than the FM distribution of energy - but that's precisely
why you're able to pump more data through.)

-- 
 Tim Shoppa                        Email: shoppa_at_trailing-edge.com
 Trailing Edge Technology          WWW:   http://www.trailing-edge.com/
 7328 Bradley Blvd		   Voice: 301-767-5917
 Bethesda, MD, USA 20817           Fax:   301-767-5927
Received on Fri Apr 09 1999 - 19:14:50 BST

This archive was generated by hypermail 2.3.0 : Fri Oct 10 2014 - 23:31:41 BST