Image Map Image Map
Results 1 to 9 of 9

Thread: Sectors / track on an MFM hard drive

  1. #1

    Default Sectors / track on an MFM hard drive

    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
    Retro enthousiast. Love everything < 486. Learning and sharing on my little channel

  2. #2
    Join Date
    Jun 2015
    Location
    Sioux Falls SD
    Posts
    277

    Default

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

  3. #3
    Join Date
    Jan 2013
    Location
    Marietta, GA
    Posts
    3,235

    Default

    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.

  4. #4

    Default

    Quote Originally Posted by SomeGuy View Post
    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?
    PM me if you're looking for 3" or 5" floppy disks. EMail For everything else, Take Another Step

  5. #5
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    31,981
    Blog Entries
    18

    Default

    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.

  6. #6

    Default

    Quote Originally Posted by SomeGuy View Post
    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 ?)
    Retro enthousiast. Love everything < 486. Learning and sharing on my little channel

  7. #7

    Default

    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.

  8. #8
    Join Date
    Jan 2013
    Location
    Marietta, GA
    Posts
    3,235

    Default

    Quote Originally Posted by RetroSpector78 View Post
    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.

  9. #9
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    31,981
    Blog Entries
    18

    Default

    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.

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •