Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!mips!cs.uoregon.edu!ns.uoregon.edu!milton!sumax!polari!rwing!seaeast!shambala!kentkar
From: kentkar@shambala.uucp (Kent Karrer)
Newsgroups: comp.unix.sysv386
Subject: Re: Does ESIX still not support RLL?
Message-ID: <1991Apr25.144010.1108@shambala.uucp>
Date: 25 Apr 91 14:40:10 GMT
References: <1991Apr21.155642.1586@shambala.uucp> <1991Apr22.210543.27730@thyme.jpl.nasa.gov> <3080@cirrusl.UUCP> <513@pyrite.nj.pyramid.com> <3087@cirrusl.UUCP>
Reply-To: kentkar@shambala.UUCP (Kent Karrer)
Organization: The Conscious Interlude
Lines: 63

In article <3087@cirrusl.UUCP> Rahul Dhesi <dhesi@cirrus.COM> writes:
>
>I wrote:
>
>     How can ESIX even know whether the controller uses RLL?  How can
>     anybody find this out without ripping the disk apart and analyzing
>     the bit-patterns stored on the platter?
>
>Bill Pechter writes:
>
>     If there's more than the standard number of MFM sectors per track
>     -- you lose.  RLL does 25, ERLL (Perstor) does 31... So if the
>     driver expects 1-17 only...  you may not see your full disk sizes
>     (at best).
>
>Which sort of answers the question, but not really.  There is no such
>thing as "the standard number of MFM sectors per track."  Perhaps there
>is such a thing as "many disk drives use 17 sectors per track, and many
>more don't."
>
>The following is directed not towards Bill, but towards many Usenet
>users who assume that RLL is some sort of disk interface standard.
>It's not!  It's just a way of putting bit patterns on the disk
>surface.  And it wasn't invented by Adaptec either.  RLL means "run
>length limited" -- a way of recording bits such that you never have
>more than m consecutive raw ones or n consecutive raw zeroes.  Tape
>drives have used it for years (but they call it GCR or group code
>recording).  In the microcomputer world, the Apple II used it on floppy
>
>I still don't see how ESIX (or any other operating system) can find out
>whether the the controller uses RLL.  I can see that an operating
>system might not support a certain number of sectors per track, but
>that has only a very nebulous relationship to the recording format
>used, other than that formats denser than MFM yield more sectors per
>track.
>
>Perhaps Usenet posters ought to be saying "ESIX requires no more than
>17 sectors per track" (if that is true, which it probably is not,
>because the disk off which I run ESIX has more than 17 sectors per
>track) instead of blaming it on the recording format.
>
>Better, still, say something like "ESIX doesn't support my disk
>controller, and it happens to use RLL recording, but the recording
>format many or many not have something to do with it."
>--

Well, maybe. But about 18 months ago, I asked the people at ESIX to send
me some product brochures. Within the body of their brocures they specifically
mentioned that they DO NOT support RLL disk controllers. I also have
product brochures from other vendors of unix. They specifcally point out
that they do support RLL. Perhaps it is technically incorrect to refer to
RLL as a standard of some type however, experience with software seems to
indicate to me that someone somewhere within the microcomputer community
has accepted it as a "defacto" standard and therefore I must give it serious
consideration when choosing what software I purchase.


-- 
[~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~]
[ A GREAT DEAL OF CHAOS IN THE WORLD occurs because people don't appreciate ]
[                      themselves. -- Chogyam Trungpa                       ]
[               "SHAMBHALA - The Sacred Path of the Warrior"                ]
[___________________uunet!seaeast.wa.com!shambala!kentkar___________________]