Path: utzoo!attcan!uunet!zephyr.ens.tek.com!gvgpsa!gold!grege
From: grege@gold.GVG.TEK.COM (Greg Ebert)
Newsgroups: comp.sys.ibm.pc.hardware
Subject: Re: What (exactly) are MFM and RLL Modulation Techniques?
Message-ID: <1453@gold.GVG.TEK.COM>
Date: 13 Sep 90 17:40:47 GMT
References: <4304@trantor.harris-atd.com>
Distribution: na
Organization: Grass Valley Group, Grass Valley, CA
Lines: 77



Let's backtrack a bit. FM encoding defines a 'bit cell' which is bounded by
clock bits. On the media, a flux reversal occurs each time a bit is written.
When a '0' is written, there are no flux-reversals inside the bit cell;a
'1' is written if there IS a transition in the bit cell. Now you might ask
"How do I synchronize ?" Easy. A preamble with one or more 0's, and a
missing clock bit will indicate that the next bit is definitely a clock
bit. The nominal time duration of the bit cell is called the data window.
The window is usually 'narrowed' somewhat so that the clock bits can jitter
somewhat without wreaking havoc. 

Seem wasteful ? Indeed. The clock bits contribute NOTHING to the data
storage capability. MFM mashes data and clock bits together subject to
the following rules:

1) If it's a '1', do a flux-reversal in the middle of the bit cell

2) If it's a '0', do nothing, BUT..

3) If the current bit is a '0', and the next bit is a '0', write a
   flux reversal at the EDGE of the bit cell.

If you write N bits/second in MFM, the time between bits is:

		1.0/N - for adjacent 1's
		1.5/N - for a 1-0-0
		2.0/N - for a 1-0-1

The smallest increment of time is 0.5/N, thus MFM data has an embedded
clock running at TWICE the data rate. Note, though, that the maximum
number of flux-reversals/time equals the data rate; this is the case
for adjacent 1's.

You need a timer to tell you how much time elapsed between bits. Seem fine
and dandy ? Well, it aint that easy. When flux reversals get squeezed 
together, they fight with eachother (wouldn't you ?). If you write them
at the exact intervals listed above, you won't see them at the same
intervals when they get read back. This is called bit shift. Someone
figured out that bit shift is predictable. You guessed it! They slightly
altered the intervals at which bits are written, depending upon the
pattern and the density. [Remember that bit density increases as you
move toward the inner tracks]. This is called write-precompensation.
When the bits are read-back, they pop-up when they are expected to do so.


Like MFM, RLL is self-clocking, and the clock rate is twice the data rate.
But, by using a different encoding scheme, it is possible to put 50% more
data onto the media WITH THE SAME number of flux-transitions per unit
length. There are two 2,7 RLL schemes I know of: IBM and XEROX. 

XEROX encoding extracts 1,2, or 3 bit packets, and encodes them into 2,4, or 6
bit streams with an embedded clock. The packet size chosen depends upon what
the data bits are. The resulting RLL encoded data has the property such
that there are at least 2 consecutive zeros between a 1, and at most 4
zeros. This is necessary to maintain synchronization with the data stream
via a phase-locked loop (PLL). I should have mentioned that MFM requires a
PLL as well.

The IBM technique is similar, except the packet size is 2,3, or 4 bits at
the input (4,6, or 8 encoded), and the minimum number of consecutive zeros
is 2; the maximum is 6.

Noting that the MINIMUM spacing between adjacent 1's is at least 2 zeros, and
that the encoded data stream is twice the rate of the incoming data, it
follows that the frequency (ie, flux-transitions/unit length) is actually
LESS than the data rate; 2/3 in this case. Remember that MFM had a worst-case
flux-transitions/time (or length) equal to the data rate. Since the flux-change
rate for RLL is LOWER than the data rate, we can get MORE data stored for the
same flux-transitions/length.
-------------------------------------------------------------------------
                                                               #####
{uunet!tektronix!gold!grege}    "Register to vote, then      ##  |  ##
grege@gold.gvg.tek.com           vote responsibly"          #    |    #
							    #   /|\   #
"Support the First Amendment, not those who attack it"       #/  |  \#
							      #######