Xref: utzoo comp.sys.ibm.pc:15511 comp.sys.misc:1414
Path: utzoo!utgpu!water!watmath!clyde!att!ihnp4!amdcad!phil
From: phil@amdcad.AMD.COM (Phil Ngai)
Newsgroups: comp.sys.ibm.pc,comp.sys.misc
Subject: Re: RLL- why it is hard on drives (was Re: Disk Controller Question ?)
Message-ID: <21605@amdcad.AMD.COM>
Date: 14 May 88 02:09:45 GMT
References: <1255@kodak.UUCP> <638@mccc.UUCP> <216@octopus.UUCP> <650@mccc.UUCP>
Reply-To: phil@amdcad.UUCP (Phil Ngai)
Organization: Advanced Micro Devices
Lines: 53

In article <650@mccc.UUCP> pjh@mccc.UUCP (Pete Holsberg) writes:
>...MFM formatting is *actually* a form of RLL. What we call 'RLL' is just a
>...different encoding scheme. It increases the amount of data stored on the
>...disk by placing the flux changes on the platter in a more accurate pattern
>...than that used by MFM. The DENSITY of flux changes is not any different.
>
>Pardon my simplistic look, but if a drive rotates at a constant speed
>regardless of its formatting and produces data (RLL formatting) at 1.5
>times the rate of MFM data transfer, then it seems that there are -- at
>least effectively if not physically -- more bits per inch.  How the

On magnetic medium, a 1 is represented by a change in flux and a 0 by
no change in flux. Of course, if you get too many successive 0s, the
time when you are looking for a flux change, sometimes referred to as
a bit cell, will drift with respect to when the flux change really
occurs. MFM, the low density alternative to RLL, throws in a flux
change between two successive 0s, in the middle of the bit cell for
the second 0. 

One limit on the media is how many flux changes you can get per inch. 

The literature on RLL says that it encodes data into a form where
there are a minimum of two zeros between each one, compared to the
minimum of one zero between each one in MFM. This means that after
encoding into RLL, you can write onto the disk three times as fast as
you can with MFM. Because the process of encoding into RLL gives two
bits for every bit in, RLL delivers user bits at the rate of 150% of MFM. 

There is a table of how RLL encoding is done. 10 becomes 1000, 11
becomes 0100, and so on. I am not enough mathematician to explain how
it is derived. The way I look at it, intuitively, is that with MFM you
have to throw in that flux change in the middle of the 0 bit cell,
right next to the flux change from a possible previous 1, so that sets
your timing. But successive 1s are a whole bit cell apart. In effect,
MFM is wasteful because it makes the media "hurry up and wait". It has
to put some flux changes close together and others wastefully apart.
RLL uses the media more evenly and thus more efficiently. 

We have a few app notes on this subject. You can call up our literature
department at 800 538 8450 or 408 732 2400, and ask for PID #09010A,
_PLDs implement encoder/decoder for disk drives_, and PID #09014A,
_Constant-density recording comes alive with new chips_.

I hope you find this useful. I do not speak for the company, nor do I
work on disk drives so I take no responsibility for the accuracy of
what has been presented here.  I merely thought my contribution might
be of value. (if you are curious, I work on processors)

-- 
Make Japan the 51st state!

I speak for myself, not the company.
Phil Ngai, {ucbvax,decwrl,allegra}!amdcad!phil or phil@amd.com