Does ESIX still not support RLL?

[Rahul Dhesi]

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
disks way back when.

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."
--
Rahul Dhesi <dhesi at cirrus.COM>
UUCP:  oliveb!cirrusl!dhesi