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

From: Eric Smith <eric_at_brouhaha.com>
Date: Sat Apr 10 05:16:51 1999

Tim wrote:
> 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.

I don't think I ever asserted that.

> 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.

I thought about this for a few minutes. Ignoring rise and fall times,
for 250 kHz FM, I expect to see spectral peaks at 250 kHz and 500 kHz.

For 500 kHz MFM, I expect to see peaks at 250 kHz, 375 kHz, and 500 kHz.

Therefore, it seems to me that a channel with reasonably flat response from
250 kHz to 500 kHz should be able to handle either 250 kHz FM or 500 kHz
MFM.

However, since you've got me curious as to whether there's some hole in this
reasoning, I've just put together a C program to simulate FM, MFM, and Apple GCR
coding, for all-zeros, all-ones, random, and "6db6" data, with adjustable
resolution and edge rates. (What shape should the edges be, and what are
reasonable edge rates for this analysis?)

Now I just need to find suitable FFT and plotting programs for Linux.
Ptolemy? GNUplot? I'm tired now, so I'll look at it tomorrow.

> 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.

Your last sentence was the point I was actually making, though I didn't explain
it very clearly.
Received on Sat Apr 10 1999 - 05:16:51 BST