What were the differences in floppy disk formats between Amiga and IBM/PC compatible computers?

Question

The capacity in Amiga Old File System format (OFS, OS version 1.x) was 840KB, with the Fast File System ("FFS" (!)) introduced for OS 2.x onwards able to store 880KB. The PC format stored 720KB on the same density disks.

Amigas had the same 3.5" disks and disk drives as PCs with Dual Density (DD) disk drives (or at least the same capability with respect to physical data density; see this post and this link for more details).

I think the capacity increase from OFS to FFS came from taking 24 bytes per 512 byte sector into use for data storage instead of redundancy/CRC/future use. I am guessing the difference between PC and Amiga formats is similarly down to differing amounts of disk space for housekeeping/error redundancy.

(For example, PC drives were notably faster at listing directories, except when compared to the Directory Cache mode introduced for the Amiga (D)OS 3.x, which gave comparable listing speed at some storage cost.)

Does anyone know in more detail what the differences are?

Answer 1

The Amiga disk format stores 512 bytes per sector, 11 sectors per track (a track is one side of a cylinder), double sided (i. e. 2 tracks per cylinder) with 80 cylinders per disk, which makes 80 * 2 * 11 * 512 = 901120 bytes = 901.12 kB = 880 KiB raw block data.

The IBM-PC format also stores 512 bytes per sector, but only 9 sectors per track (on a Double Density (DD) disk, as opposed to a High Density (HD) disk), also double sided, also 80 cylinders per disk, which yields 80 * 2 * 9 * 512 = 737280 bytes = 737.28 kB = 720 KiB raw block data.

Neither of those formats is able to achieve that nominal amount when you sum the sizes of the files stored on disk. The more obvious reason is that you always need to store metadata such as filenames, dates, subdirectories, etc. as well. The other reason is that on those filesystems file data always occupies a multiple of some unit (a block on Amiga OFS/FFS and a cluster - consisting of multiple blocks - on MS-DOS FAT12) and if the file size doesn't exactly equal that multiple, some bytes of the last block or cluster are wasted where no useful data is stored.

You are right that the Amiga OFS format also stores housekeeping information on each data block (a block that is used for the contents of the file, as opposed to a block that is used for the file metadata or directory data), so only 488 bytes of each 512 byte block can be used for actual file data, while the Amiga FFS (Fast Filesystem) format uses all 512 bytes of a data block for file data and doesn't store redundant housekeeping information there, that's why you can in general put some more data onto FFS disks than on OFS disks (unless no file on the disk is larger than 488 bytes or your disk content consists only of directories and subdirectories, in which case you can store the same amount).

The speed difference when reading a directory likely comes from the vastly different way each filesystem (Amiga OFS/FFS vs. MS-DOS FAT12) stores directory information on the disk:

MS-DOS FAT12 groups several file metadata structures (that include filename, protection bits, change date, first cluster, etc.) into one block while Amiga OFS/FFS has one file metadata block per file (OFS/FFS directory blocks just store a pointer to the first file metadata block and a hash table for quickly finding a file/subdirectory if you access it directly by filename). That means to list a directory and the names of its contained items, you have to load fewer blocks from a FAT12 formatted disk than from an OFS/FFS disk.

Answer 2

A little more background on the formats...

When IBM is involved, it's all about history.

IBM's first PC floppy disk format was single sided, 5-1/4", 160K on a single-sided drive. (40 tracks, 8 sectors per track, 512 byte sectors). This started as "double density" but was otherwise a conservative design, typical for IBM. Double-sided floppies were 320K, of course. They very quickly made a "bump" to 180K/360K as they found they could easily squeeze on a ninth sector.

IBM's implementation of 3-1/2" drives was made to be as backward-compatible as possible, so they simply wheeled over the same formats, except with 80 tracks, so 360/720k.

You can see with IBM's conservative tack of "dragging their old designs forward", there was lots of room for an aggressive competitor to best them.

For instance Apple opened at 400k/800k, accomplished by changing drive rotation speed for different tracks, moving closer to CLV rather than CAV (CLV was more famously used by the Laserdisc format, and it was something the 3.5" format designers had never imagined when they designed for a 1MB raw-data-stream capacity. Hence, Apple's approach pried more raw capacity out of the drive than even the designers intended, and then used that fairly conservatively). That was typical of Steve Wozniak, coming up with masterstrokes of parts-efficient design rather than pushing the performance envelope.

Answer 3

There is single key difference.

Amiga FDC controller writes or reads the track as a whole -- there is no option to write or read single sector. As a result, smaller inter-sector gaps and more sectors per track are possible.

PC FDC controller is able to write each sector individually and the consequence is the need for bigger inter-sector gaps to compensate for different rotation speeds of different drives and other misalignments.

There are other small differences, for example amiga FDC controller does NOT do MFM-en/decoding in hardware and just reads or writes raw data, without being aware there is some encoding (with the exception of optional "0x4489" track beginning mark). The sector header format is therefore optimized for an easier CPU decoding and is non-standard. The consequence is that no pc FDC controller is able to read disks in native amiga format (while the opposite is false -- amiga easily reads just about ANY disk with comparable bitrate).

Some info on amiga disk format: http://lclevy.free.fr/adflib/adf_info.html

Answer 4

FFS was only really meant for hard disks. Or more to the point media that had some form of hardware error correction before it hit the OS. Plus it made DMA easier I imagine too. OFS really was well thought out for the single track writes of Amiga floppies. The Amiga folks thought it all through when adding a zero cost floppy interface using the hardware at hand. They needed to have extra resilience in the filesystem when using every bit of the magnetic surface. The cut the data size down from 512 bytes in a logical sector for forward and backward links. This made it possible to recover files without reference to a home directory block. Enterprising hacker used this to link folders and files back on themselves to make them of infinite length. Ooopps.

Answer 5

Others here have mentioned the inter-sector gaps, but I thought it might be enlightening to describe just how much space these really take; it's probably more than you might think.

Today I happened to be working out code to format disks on my Fujitsu FM-7, which uses 5.25" double-sided, double-density floppies, just like the IBM PC, with the same low-level (index marker, etc.) disk formatting. But the FM-7 uses 16 × 256 byte sectors per track, for 320 KiB of user data storage per disk, whereas the PC uses 9 × 512 byte sectors per track, for 360 KiB of user data storage. (These numbers are the total number of data bytes that can be written in all the sectors, i.e., what's available to the OS before filesystem overhead or anything like that.)

Here (with a few minor approximations) are the raw bytes that actually get written to disk.

The track starts (after the index mark) with "post-index" information, that exists only once at the start track:

80× $4E     post-index gap
12× $00     sync
 3× $C2     index address mark
    $FC     index address mark
50× $4E     gap

Then the following is written for each sector:

12× $00     sync
 3× $A1     ID address mark
    $FE     ID address mark
    $__     Track number
    $__     Side number
    $__     Sector number
    $__     Sector length (1 for FM-7 256 bytes/sec, 2 for PC 512 bytes/sec)
 2× CRC     CRC bytes for the ID data
22× $4E     gap
12× $00     sync
 3× $A1     data address marker
    $FB     data address marker
SS× $__     sector data; SS = sector size (256 or 512)
 2× CRC     CRC bytes for the sector data
NN× $4E     gap; NN = 54 for 256 byte sectors, 84 for 512 byte sectors

There will be a varying amount of extra $4E filler at the end, after all the sectors, depending on the sector size, variance in the speed of the disk, and so on.

So the overhead here, after the user data itself, is 116 bytes for a 256 byte sector and 146 bytes for a 512 byte sector. This means that: - The FM-7s 16 × 256-byte sectors, storing 4096 bytes of user data, use at least 6098 bytes of raw data on a track. - The PC's 9 × 512-byte sectors, storing 4608 bytes of user data, need only 5922 bytes of raw data on a track.

Storing 12% more user data on the disk by increasing sector size actually stores 3% less actual raw data on the disk. There's no advanced technology involved here; in fact if we were pushing the limits of the disk it would be the lower-capacity format that would fail first, as it ran out of track space to store all the extra empty gaps it's putting on the track.