Path: utzoo!utgpu!water!watmath!221.162.fido!Geoffrey_Welsh
From: 221.162.fido!Geoffrey_Welsh@watmath.waterloo.edu
Newsgroups: comp.sys.ibm.pc
Subject: Re: RLL on a ST-225
Message-ID: <17138@watmath.waterloo.edu>
Date: 26 Feb 88 18:16:29 GMT
Sender: ugate@watmath.waterloo.edu
Lines: 31


 > From: davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr)
 > Message-ID: <9692@steinmetz.steinmetz.UUCP>
 > Date: 25 Feb 88 21:13:30 GMT
 > BTW: MFM is just a term used for one type of RLL compression, I believe
 > RLL-0,2 but please don't quote me. Back in about 1978 floppies made the
 > change from "single density" to "double density" using this newfangled
 > thing "MFM recording. There is another RLL being tested which gives 100%
 
   I'm no expert, especially on RLL, but I think you've explained it 
well. The 'single-density' floppies used "FM" formats, which included a
clock bit and a data bit to make sure that the controller wouldn't lose sync.
 MFM is "self-clocking", so it packs more data without actually increasing
the number of flux changes per unit distance. Some manufacturers decided to
use GCR (group code record) in stead of MFM. This reduced overhead from FM's
50% clock bits to 20% (using 5/4 GCR encoding). I don't have the slightest
clue what MFM overhead is, nor what RLL overhead is.
 
   The "new RLL" is called ERLL (extended RLL? enhanced RLL?), and 
promises to double the capacity of some drives.
 
   What I do not understand is how RLL can damage a drive; I have heard 
from many sources that using an RLL controller on a drive than can't handle
it will leave you with a pile of junk. If indeed the problem is simply one
of the timing being off and causing read errors in the controller, one ought
to be able to reformat with a standard controller...
 
   Geoff ( watmath!fido!221/171!izot )

--- ConfMail V3.31
 * Origin: The Waterloo Window: WOC's out there? (1:221/171)