[comp.os.minix] IDE, ESDI, SCSI, MFM, RLL

kjh@pollux.usc.edu (Kenneth J. Hendrickson) (01/10/91)

I know Minix supports MFM drives, and I think it supports RLL drives if
a couple of constants in the hard disk device driver are changed.  I
have also seen people post SCSI device drivers.

Question: Just what are IDE and ESDI drives, and does Minix support
them (yet)?  Is any official support planned?

It seems that MFM and RLL drives may go the way of the dinosaur.

-- 
favourite oxymorons:   student athlete, military justice, mercy killing
Ken Hendrickson N8DGN/6       kjh@usc.edu      ...!uunet!usc!pollux!kjh

adrie@philica.ica.philips.nl (Adrie Koolen) (01/11/91)

In article <29233@usc> kjh@pollux.usc.edu (Kenneth J. Hendrickson) writes:
>I know Minix supports MFM drives, and I think it supports RLL drives if
>a couple of constants in the hard disk device driver are changed.  I
>have also seen people post SCSI device drivers.
>
>Question: Just what are IDE and ESDI drives, and does Minix support
>them (yet)?  Is any official support planned?

First, let's describe the path the data takes from the magnetic medium to
the main memory. The drive is connected via an interface to a controller,
which is normally plugged into the computer. The interface between the drive
and the controller can be ST506/412, used in the old IBM PC's, ESDI, IDE or
SCSI. With the ST506/412 interface, data passes through one serial line from
the drive to the controller. Even clock signals are superimposed on these
line. The `old' MFM data encoding (mixing of data and clock signals) is
somewhat less efficient than RLL encoding. Of course, you need a special
controller to decode RLL encoded data instead of MFM encoded data!

ESDI is a variant of the ST506/412 interface. There are separate lines on
the ESDI bus for clock and data, so that the controller in the computer can
be somewhat simpler. Because data encoding/decoding is local to the drive,
it can decide to use MFM or RLL without the PC controller ever knowing this!

With IDE, not only the data separator, but the whole controller is moved to
the drive. Now, what's left on the PC mainboard is not much more than a
connector to the drive.

There are many ways to design a hard disk controller for a special bus. The
registers and functionality of the controllers, used on the PC, are defined
bij Western Digital. Their WD1003 is the model of many clones (the PC used
another controller, although they used the same ST506/412 interface between
the controller and the drive). The software doesn't need to know what kind
of interface the controller uses to talk to the drive, so there exist
ST506/412, ESDI and IDE (even SCSI) controllers, who implement the correct
registers and functionality of the WD1003.

Alas, IBM chose to design a new controller for their ESDI equiped PS/2
computers. It's not compatible with the WD1003, but then again, even their
PS/2 ST506/412 controller is not compatible with the WD1003!

With SCSI, all decoding is done on the drive. The controller can transfer
command blocks over the SCSI bus to the drive requesting to read a block.
The drive will read it, pack it into a data block, which is transferred to
the controller on the PC. There are 8 data lines on the SCSI bus so transfers
can be very fast.

>It seems that MFM and RLL drives may go the way of the dinosaur.

I hope that it will be clear know that on the magnetic medium, always a kind
of data encoding will be necessary. Otherwise, how can you guarantee that
when writing 100 bits 0, you won't read 101 bits 0? You'll have to add clock
information or code data in another way (with limited run lengths, e.g.).
Almost all SCSI, ESDI, ST506/412 and IDE drives use MFM or RLL (2,7). There
used to be an M2FM, but its timing characteristics were that bad that nobody
uses it anymore. Also, ordinary FM data encoding isn't used anymore. RLL
encoding uses also bad timing but it gives you 50% more data storage with the
same basic timing as MFM. An RLL drive should therefore allow longer runs than
MFM drives. They should be certified for that.

Adrie Koolen (adrie@ica.philips.nl)
Philips Innovation Centre Aachen