7

The original IBM PC used a 5.25" floppy disk format of two sides, 40 tracks, 9 sectors per track, 512 bytes per sector, for 360K per disk.

As I understand it, a significant amount of disk space went to spacing between sectors, and I'm wondering why that half-kilobyte sector size stayed so consistent between disk formats and operating systems; a reasonable optimization would seem to be to use fewer, larger sectors, thereby reducing the overhead. But then, there was some onboard intelligence in most floppy disk controllers. (The Apple II controller was famous for not having such.)

So for a specific question:

On the original IBM PC floppy disk controller, was the sector size under software control? Could an operating system choose to use e.g. 5 kilobytes per sector, in the hope of squeezing 5K instead of 4.5K into one track?

  • 1
    From this page it looks like the original IBM PC FDC used sector sizes that were powers of two starting at 128 (shifted left by an 8-bit value). A lot of the 8-bit microcomputers used 256-byte sectors before the world settled on 512 byte sectors for a while. I wonder which if any systems used 128-byte sectors? – hippietrail Jun 26 at 4:24
  • 4
    @hippietrail CP/M used 128-byte sectors. – dirkt Jun 26 at 5:38
  • Do you understand the role of the floppy disk controller in this? – Thorbjørn Ravn Andersen Jun 26 at 13:34
  • 3
    @dirkt CP/M 2.2 did and the BIOS writers had to handle the mapping to 512 byte sectors on non-single density drives. (Disassembled one). CP/M-3 contained logic to handle this, but that was not the version emulated by QDOS which became MS-DOS. – Thorbjørn Ravn Andersen Jun 26 at 13:35
10

Yes, the sector size is software-controlled, to a certain extent. Every FDC command involving sectors or tracks takes the sector size as a parameter. The size is specified as a bit shift applied to 128, so sector sizes are of the form 128 × 2n (usable values go from 128 to 4096 on the original PC; there isn’t enough time to fit an 8KiB sector in a track using the IBM PC’s single-density 5.25” drives). Sector sizes are assumed to be the same throughout a track.

As Tim Paterson explains, the IBM PC can write at most 6250 bytes per track in total (including gaps, which don’t store data). The headers and gaps result in an overhead of 114 bytes per sector, so a track can store 9 512-byte sectors, but not quite 10 — at least not safely. (Since the tracks are circular, having gaps between the logical sectors isn’t sufficient, so counting 10 sectors and 9 gaps doesn’t work — a gap is also needed between the last and first sectors.) However it would technically be possible to store 5 1024-byte sectors, for a total capacity of 200KiB per side, 400KiB per disk. So while this addresses your question, it doesn’t explain why 512-byte sectors were chosen. 1024-byte sectors were used on other computers, and on IBM’s own 8” disks.

Later disk formats such as XDF and 2M used varying sector sizes to increase storage capacity, but they are more CPU-intensive and not appropriate for a 4.77MHz 8088. Some copy-protection techniques also relied on non-standard sector sizes.

See also What is between the sectors of floppy disks? for details of floppy disk layouts (in particular, their capacity needs to be considered in terms of reversals per unit of time, not bytes or anything like that).

(Using larger sectors increases the memory requirements when reading from or writing to disks; DOS used two buffers by default on the PC, which would have meant going from 1KiB for buffers, to 2KiB. Larger sectors also reduces the data manipulation granularity, and 1KiB was a significant amount of data back then — two 512-byte buffers would have been more useful than one 1024-byte buffer.)

| improve this answer | |
  • 3
    10 512-byte sectors don’t quite fit on the original PC drive (see Tim Paterson’s blog post on floppy disk formats for details), but you’re right, 5 1024-byte sectors would fit. I suspect another factor here is the amount of data being read into memory; 1024 bytes is a lot in a 64KiB system... – Stephen Kitt Jun 26 at 12:18
  • 2
    @StephenKitt: Using larger sectors would necessitate the use of larger buffers. In a 48K system, three buffers [which I think was the minimum for usable operation] would take 1.5K with a sector size of 512, but would take 3K with a sector size of 1024. – supercat Jun 26 at 15:08
  • 3
    @StephenKitt: I forgot that floppies used FAT12, which would allow the FAT for a 160-cluster disk to fit on one sector, making single-file operations workable with two buffers (one for the FAT and one for the data). Still, for any purpose involving simultaneous reading from one drive and writing to another, having at least four buffers would be much better (one for source FAT and data; one for destination FAT and data). – supercat Jun 26 at 15:36
  • 2
    @StephenKitt: Actually, until now, I'd sorta wondered why DOS used FAT12, since the storage savings didn't seem terribly significant, but the difference between having a FAT take 480 bytes of data versus 640 is really a difference between having it take 512 versus 1024. – supercat Jun 26 at 15:58
  • 2
    @supercat indeed; I used to stop optimising programs when I crossed a cluster boundary, but I hadn’t made the FAT12 connection either... – Stephen Kitt Jun 26 at 16:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.