Sectors / track on an MFM hard drive

[RetroSpector78]

I have a MICROSCIENCE: HH-725 20MB MFM hard drive and according to the docs it has 32 sectors / track.

Going by the following assumptions (hoping they are correct)

• Not the hard drive itself but rather the hard drive controller will dictate the number of sectors / track used (17 in case of MFM, 26 in case of RLL).
• The number of sectors / track will dictate how much space will become available (total disk space = cylinders * heads * sectors * 512 bytes). RLL encoding on an MFM drive results in 50% more disk space as the advertised MFM space.
• Some RLL controllers allow you to specify the number of sectors / track, allowing you to operate RLL drives on 17 sectors / track instead of 26. This would reduce their disk space by 50% but still use the higher bit rate RLL encoding.
• The higher bitrate of RLL encoding will make them faster than MFM encoded hard drives (?)

So 2 questions :

1. The HH-725 hard drive mentioned above supports 32 sectors / track. Does this automatically make it eligible for RLL encoding ? If not, what is the point of having 32 sectors / track on this drive if it will only use 17 in case of MFM.
2. And a side-question : Why would somebody opt to only use 17 sectors / track on an RLL hard drive (some RLL controllers allow you to configure this). I guess this would result in 50% less disk space as advertised.

Thx

 

[lafos]

Note the spec sheet you linked used 256-byte sectors. I don't think the HH-725 is compatible with RLL encoding.

 

[SomeGuy]

Some RLL controllers allow you to specify the number of sectors / track, allowing you to operate RLL drives on 17 sectors / track instead of 26. This would reduce their disk space by 50% but still use the higher bit rate RLL encoding.

Controllers that let you specify number of sectors per track usually do so to support 3000RPM drives, which fit more data per track. However this appears to be a standard 3600RPM drive. It should have 17 sectors of 512 bytes.

Note that some controllers have BIOSes that support "sector translation". This is mainly used on RLL controllers that have to pretend they have 17-sectors per track because some disk tools, OSes, and motherboards BIOSes were hard coded to assume all drives would forever have only 17 sectors per track.

I'd assume this drive will only work with MFM.

If you wanted to experiment and try RLL, after formatting run Spinrite with thorough pattern testing. If it finds piles of "bad" sectors starting at about halfway in, then it is not compatible.

 

[Stone]

Controllers that let you specify number of sectors per track usually do so to support 3000RPM drives, which fit more data per track. However this appears to be a standard 3600RPM drive. It should have 17 sectors of 512 bytes.

So why do the specs list it at 32 sectors of 256 bytes?

 

[Chuck(G)]

Sectoring on a ST506-type hard drive is up to the controller. You could have any number of sectors, or none at all (some hard drives were use for video frame memory). It's like a floppy disk--the personality of the format rests in the controller firmware.

It was not uncommon for pre-PC drives to state formatted capacity in 256 byte sectors.

 

[RetroSpector78]

Controllers that let you specify number of sectors per track usually do so to support 3000RPM drives, which fit more data per track. However this appears to be a standard 3600RPM drive. It should have 17 sectors of 512 bytes.

Note that some controllers have BIOSes that support "sector translation". This is mainly used on RLL controllers that have to pretend they have 17-sectors per track because some disk tools, OSes, and motherboards BIOSes were hard coded to assume all drives would forever have only 17 sectors per track.

I'd assume this drive will only work with MFM.

If you wanted to experiment and try RLL, after formatting run Spinrite with thorough pattern testing. If it finds piles of "bad" sectors starting at about halfway in, then it is not compatible.

So if I understand correctly there's really not much point in setting up an RLL controller to use 17 sectors / track ? (only for some software compatibility reasons ?)

 

[mbbrutman]

There have been a few threads here in the past about this particular model of hard drive.

The 256 byte sector is kind of goofy for DOS, so it probably wasn't being sold as a hard drive strictly for PCs. DOS can handle it but DOS internally expects 512 bytes per sector, so it just means that if it really was formatted as 256 bytes per sector that DOS would probably need a device driver to talk to it. (There is no way to tell DOS that it's dealing with an oddball sector size otherwise.)

For use on a DOS machine it makes more sense to format it as a normal MFM drive which has 17 512 byte sectors per track. Which magically works out to be near the 32 256 bytes per track the drive is advertising. (With less slack space and headers between the sectors it probably works out. No matter, the controller is going to force it either way.)

RLL is just a different encoding. Many RLL drives are just sorted MFM drives that worked with the RLL signalling.

So short story - if this is going on a PC, go with the standard 17 sectors per track. If you want to push it you can try RLL encoding, which will increase the sectors per track by about 50%. But you need an RLL controller, and it might not work unless the drive is certified for it.

 

[SomeGuy]

So if I understand correctly there's really not much point in setting up an RLL controller to use 17 sectors / track ? (only for some software compatibility reasons ?)

Correct. Usually you want to avoid sector translation unless you are up against a known compatibility issue. And if you aren't using sector translation, then specifying less than 26 sectors (of 512 bytes) on an RLL controller simply leaves part of each track blank, which is wasteful.

 

[Chuck(G)]

The shoe was on the other foot not long after SCSI, IDE and ESDI drives came onto the scene. There, the problem was that even with 26 sectors per track, the 1,024 BIOS cylinder limitation didn't allow for "native" geometries. So, the number of heads was bumped up to 255 or so; when that was insufficient, the number of sectors per track went to 63; eventually, BIOS extensions had to be formulated to allow for larger drives. SCSI didn't have too much of a problem faking geometries, as it's natively LBA.

But by the time larger 3.5" drives came onto the scene, any notion of knowing what the real geometry was went out the window. Not only were run-length-limited codes being used, but also "zoned" recording, where more sectors are placed on the outer tracks of the disk.

So, it seems that SCSI had the right idea all along.