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?

  • It is not clear what the question is about. Are you interested in the difference of format at the hardware level? Or by the differences between the file formats of PC and Amiga? These are topics which each deserve their own question and it is not clear which one you are interested by. Commented Jul 3, 2016 at 1:59
  • Worth noting is that the nominal unformatted capacity of a DD floppy is exactly 1000000 bytes.
    – pipe
    Commented Jul 6, 2016 at 1:20
  • 7
    The main difference seems to be that the Amiga reads and writes complete tracks at once - That lets it get rid of the intersector gaps that other formats use and squeeze 11 sectors onto a track instead of nine.
    – tofro
    Commented Jan 25, 2017 at 19:30
  • 1
    some custom Amiga formats (Rob Norten PDOS) are able to squeeze 12 sectors onto a track. And it's not the record of the bigger track size. Commented Jan 27, 2020 at 21:03

5 Answers 5


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.

  • 9
    As for the reason why Amiga disks can hold 11 sectors per track instead of 9, its due to the way tracks are written by the drive. On the Amiga the entire track is written at once unlike PC floppies which write data one sector at a time. This allows the inter-sector gaps (used to detect the end of a sector) to be eliminated, increasing usable space on the disk.
    – mnem
    Commented May 6, 2016 at 8:10
  • 4
    @tofro at least in the Amiga's case, varying drive speeds is not an issue as they are all exactly the same. In fact, when they introduced high density drives for the Amiga 3000, they had to hack it to run at half rpm for HD disks so that the data rate was kept constant because the floppy controller is completely custom and reads and writes raw bit sequences directly via DMA. Doubling the data rate along with the density would have required an updated custom chip.
    – mnem
    Commented Feb 6, 2017 at 4:21
  • 4
    @supercat The performance penalty isn't necessarily as bad as you might expect on another computer. Since the AmigaOS is preemptively multitasking, and the floppy controller is part of the Paula custom chip which has direct DMA access to the CHIP RAM area, a slower file copy, for example, will not prevent the user from doing other things. This is a completely different experience from a standard PC where the whole computer is tied up while reading / writing from the floppy and all you can do is wait.
    – mnem
    Commented Feb 6, 2017 at 18:21
  • 2
    @supercat The AmigaOS also employs a lot of tricks to reduce disk access when no HDD is present. Many often-used system libraries are held in ROM (256KB ROM in earlier versions, 512KB ROM in later ones) instead of read off the disk, and a large number of CLI commands are made resident at startup so that after the first time they are used they are held in memory and don't need to be read from the disk again. This minimizes the kinds of small reads that would take the biggest performance hit from having to deal with entire tracks at once.
    – mnem
    Commented Feb 6, 2017 at 18:40
  • 3
    The Amiga format DOES have sector headers etc, just no sector gaps. So reading a track can start at any sector. Writing also doesn't wait for the index pulse. Therefore, reading or writing a whole track at once isn't as slow as it seems, given that reading a single random sector would otherwise take half a revolution of the disk (on average). For 2 sectors it is already a win to read the whole track (on avg). More info: see wiki.amigaos.net/wiki/Trackdisk_Device Note that I wrote a device driver to read PC floppies on the Amiga: aminet.net/package/disk/misc/MSH-1.58 Commented Jan 16, 2018 at 11:20

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.

  • Isn't it exactly the other way around? CAV = constant angular velocity - same RPM all the time, which was the ordinary IBM way of "spin the same speed all the time". Constant Linear Velocity changes the RPM depending on how far out you are on the disc. So the speed of the head over the media is the same. Commented Jan 23, 2019 at 16:08
  • @Prof.Falken quite right. Good save. Commented Jan 23, 2019 at 16:54

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


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.


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.

  • Smaller sector size wastes more space between sectors, but an average file leaves half of the last sector empty so larger sectors waste more space per file. 16 small files on the FM-7 could fit on one track, but in IBM format would take up nearly 80% of the next track as well. Commented Jan 28, 2020 at 23:10
  • @BruceAbbott Well, you're right to a point, but it also depends on the allocation size used by the filesystem; it's not unusual for filesystems to allocate only clusters of several sectors. I don't have information about the FM-7 DOS, but the NEC PC-8001 also uses 16 × 256 byte sectors per track, but the minimum allocation unit for a file is 8 sectors, or 2048 bytes. So actually only two files could fit on a PC-8001 track, whereas four files could fit on a PC 360K floppy track because it used only 1K clusters.
    – cjs
    Commented Jan 29, 2020 at 4:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .