On a typical floppy-based system, the act of reading a sector consists of the following steps:

  1. Moving the head to the appropriate track.

  2. Waiting until a certain "start of sector header" pattern of wiggles is observed passing under the drive head.

  3. Reading a few bytes' worth of wiggles to see if they match the expected track and sector number, looping back to steps 1 or 2 if not (subject to some retry-count limits).

  4. Waiting a little while until a "start of data" pattern of wiggles is observed, looping back to step 2 if it isn't.

  5. Reading a sector's worth of wiggles.

Different systems used different patterns of wiggles for their "start of sector header" indication, and any portion of a disk which didn't contain the "start of sector header" pattern of wiggles expected by a drive would be effectively ignored.

Of particular note, if a disk format would contain 16 sectors per track, an attempt to read e.g. track 18 sector 1 would be processed in a manner oblivious to whether track 18 contained 16 sectors in a recognizable format, or contained a "sector 1" in the expected format and a bunch of other wiggles that did not include a "start of sector" header. It would thus be possible for a track to contain sectors formatted in multiple different ways, without the systems that are reading the track having to know or care about the various formats.

By my understanding, there were some programs released in Apple DOS 3.2 13-sector format whose first track contained a single sector written in 16-sector format, which in turn contained code to read a sector in 13-sector format, which in turn contained code to load everything else in 13-sector format. There are also many games that e.g. have a Commodore 64 version of the code on one side of a disk and an Apple II version on the reverse side. Are there any games or other programs which combine software for multiple independent machines using different disk formats, all on the same side of a disk, beyond the DOS 3.2 hack noted above?

  • 5
    I don't have good sources, but I seem to recall that certain PC/MSDOS games distributed on floppies had copy protection mechanisms that relied on non-standard physical format of certain data on certain tracks, which would not be copied by any tool that only expects the standard disk format, and then there were advanced copying tools which attempted to perfectly copy whatever was there on the physical layer, not what was decoded with certain assumptions about the format, error correction, etc.
    – Peteris
    Feb 9 at 5:39
  • 1
    You might want to extend your question that you ask for different numbers of sectors of potentially different sizes. Most answers are one layer above, targetting the file system. This is not the same. Feb 9 at 8:21
  • 1
    To my knowledge, some later Commodore 64 freezer cartridges had a fast save/fast load function that would save the image with a special track format so the raw track data was sent directly to the Commodore 64 and only decoded there. That may be worth investigating, as it could be combined with regular tracks on the same disk side.
    – Janka
    Feb 9 at 10:57
  • 1
    Some combinations might, some others might not work. Some file systems require information (like a boot sector or directory) on specific locations (like a specific track or sector) on the disk. If these overlap, what you're asking for would not be possible.
    – tofro
    Feb 9 at 12:26
  • 1
    Some Electronic Arts games on C64 did something for copy protection similar to what @Peteris describes on PC. They took forever to load.
    – Theodore
    Feb 9 at 17:33

7 Answers 7


Yes - the magazine ST Amiga Format (predecessor to the long-running Amiga Format magazine) had coverdisks that were dual-format - it contained both a FAT filesystem that the ST could read, and an Amiga filesystem.

I had an Amiga, and I remember using some of these disks. They were not always reliably detected by the Amiga - sometimes when inserting the disk the Amiga could not recognise a filesystem. Removing it and reinserting was usually enough to get it recognised. My guess is that the first track was divided in half, one for Amiga and one for ST, and both halves started with the same MFM sync mark. Therefore which one you'd get would depend on the disks rotation and which one landed under the drive head first.

There's surprisingly little information on this on the Internet. I do remember reading a description of this, and I recall that the dual format disk was created by Rob Northen Computing (famed for disk copy protection systems), but I haven't found references for this on the Internet. Possibly this was in a contemporary print magazine.


It's older than the Apple II

It might be worth to remember that joining two completely different forms of recording is older than the Apple II or most micros. When Double Density recording (MFM) became available, some OS (*1) tend to still format track 0 on side 0 of a disk in FM. This allowed the boot ROM to only work using FM setup, relegating all switch to MFM to the first boot stage.

Additionally, if that track also held a (root) directory, machines could identify and catalogue disks in either format. Even more, systems only capable of doing FM, could still successful identify disks they otherwise can't read.

All a great enhancement for cross platform compatibility.

Systems supporting that as late as the 1990s were, for example, the Siemens PC-X/MX series using SINIX.

Now for the Apple:

I spent quite some time in 1983 writing ROM/driver code for a company designing an Apple II card combining serial, parallel and clock functions. The goal was to get it as compatible as possible to existing (Apple Inc.) cards while not copying the SSC ROM (*2).

For the driver disk I wanted to get all 4 supported OS onto one disk, as there were

  • Apple DOS 3.3
  • CP/M 2.2
  • UCSD OS (Pascal)
  • ProDOS 1.0

Luckily, all four use the same 16 sector format, although with different skew and optional blocking. Even better, except for ProDOS and UCSD, they all use different places to store their directory:

  • Apple DOS 3.3
    • Track 11 Sector 0 contains the VTOC which in turn points to the directory.
  • CP/M 2.2
    • The directory is located after 3 reserved tracks, covering all 16 sectors (although some can be excluded).
    • Block 2-7 of Track 0 contain the directory
  • ProDOS 1.0
    • As with UCSD OS, but with a different structure

Too bad that UCSD OS and ProDOS use different directory structures, so they can not exist on the same disk. But either of them can be made into a single (read only) Disk with DOS and CP/M. So three OS Disks aren't an issue - once one owns a sector editor.

The different skews used aren't a big issue, as they will only result in some formats reading a tad slower than expected. Nothing to worry for software distribution.

Four on one disk would be harder, except standard Apple disks are single sided. So with the help of the good old write unprotect switch, (*3) one could put two of them on one side, flip the disk and add the other two. Similar for distribution (*4).

So in the end I created a 3 OS Version (DOS, ProDOS and CP/M) and a two sided 2+2 OS one (DOS + ProDOS and CP/M + UCSD OS) (*4).

*1 - Quite often found with Unix/Xenix systems.

*2 - Later when we showed it to Apple Germany in Munich, they said they wouldn't have cared anyway. ...might have been a different company back then.

*3 - The usual hack of adding a 3-way switch to each drive to set the write protect line to Unprotected / Disk / Protected. Saved not only cutting second holes into disks, but also allows to write protect when needed :))

*4 - In the end the company decided to pack two single-sided disks with each card instead of using one two-sided, as it saved them production time.


Yes, and I have one. The first issue of Zero magazine had a covermount disk containing Recoil for the Atari ST and Merv the Merciless for the Amiga. The ST uses an ordinary PC-compatible sector format with a FAT-ish filesystem resulting in a 720kiB disc (or 360kiB if you had an early model with a single-sided drive), whereas the Amiga… doesn't, and squeezes 880kiB with its bespoke format. However, the bootsectors don't clash and it's possible to format a disc half-and-half which is bootable on both.

Similarly, in the early days the BBC Micro usually had 40 track (48tpi) single-sided drives which stored 100kiB, but after a while double-sided 80 track (96tpi) drives were became cheap enough that nobody would buy a 40 track drive what with 200kiB per side to make 400kiB total being compelling. This presented a problem for software vendors. Typically software was sold in whichever format was the most popular at that point in the machine's lifecycle, and many 80 track drives had a switch to enable double-stepping so they could read old 48tpi discs, but it was certainly possible to format a disk which was readable on both:

Track 0 was the same location on both types of drive and contained all the filesystem metadata, one could contrive a filesystem where the data was on tracks 20–39 and duplicated in both track densities: tracks 20–39 at 48tpi correspond to tracks 40–79 at 96tpi, and conversely tracks 20–39 at 96tpi correspond to tracks 10-19 at 48tpi. This wasted most the capacity of the disk, but 50kiB is still plenty for a game for a 32kiB machine.

Different drive types for the same machine isn't quite the same thing as formats for different machines, but it shows how the same general trick was well-known and used. Fast-forward a few decades and optical media can be mastered such that they are bootable on multiple platforms: El Torito for BIOS-based PCs, EFI partitions for newer PCs, and BIOS boot sectors so the image can just be copied to a USB stick rather than burnt to CD. ISO-9660 images can even be hacked to present a completely different file hierarchy on big-endian versus little-endian machines, which is how some CD-ROM software provided separate MS-DOS and MacOS versions on the same disc.


I haven't proven this, but I have read that the Amax emulator for Amiga allowed you to format a floppy disk that was capable of being used by both your Mac and Amiga. The capacity was much smaller because it used a proprietary format in a region of the disk that could be accessed by both drive mechanisms. The idea was 1 mac disk could be spread out across 3 'custom' disks and transferred to the Amiga.

So it's not strictly 'multiple formats on one disk', but it is an interesting example of creating a filesystem that works on two dissimilar systems to share data back and forth.


I don't know if you'd consider this to be 'combining disk formats' (since the underlying sector structure was the same) but boot floppies for the BBC Master 512 contained a small ADFS filesystem holding the bootloader, followed by a FAT12 filesystem holding DOS Plus itself.

When I implemented CP/M on the PcW16, I created a similar situation, with a "boot/root" floppy format containing a FAT12 filesystem readable by the PcW16's native operating system (with the boot program), followed by a CP/M filesystem containing CP/M. In that case, a dummy file in the FAT12 filesystem covered the area of the disc containing the CP/M filesystem.

In both of those examples, the data areas used by the two filesystems are disjoint. Another utility I wrote, DualDOS, creates a disk readable under both MSDOS and Amstrad CP/M, where there are two separate directories (one in FAT12 format, one in CP/M format) both referencing the same files. However the combined boot sector does not meet all the criteria to be a valid FAT12 boot sector and so the resulting disk may not be readable on less forgiving systems than MSDOS.


Game titles from Advantage combined C64 and IBM formats not only on the same disk, but they shared directory structures on the same side of the disk. C64 table of contents resides on a track that DOS normally reserves for data, so the DOS format can mark those tracks as "bad" and store data around them. The C64 drives were single-sided, so DOS can store the PC data on the second side.

I wrote about this in more detail here: The diskette that blew Trixter’s mind


To expand upon a comment made by @Peteris on the question, I remember looking at the copy protection mechanism on a 5¼-inch floppy used by a game (think it was M1 Tank Platoon) running on an Amstrad PC1512.

There were one (or more?) sectors on the game floppy which couldn't be copied by the standard MS-DOS utilities. As a learning exercise investigated the copy protection mechanism and found:

  1. The game code was reading the non-standard sectors using INT 13H.
  2. When the game code successfully read the non-standard sectors from the originally floppy provided with the game, managed to intercept the INT 13H call and capture the contents of the non-standard sector read by the copy protection mechanism.
  3. Rather than making a complete copy of the game floppy with the non-standard sector, by intercepting INT 13H that game code made to check the non-standard sector was able to return the contents the game code was expecting.

I realise this answer is missing detail on the format of the non-standard sectors, and if would have been possible to use a standard floppy drive to create an exact copy. I'm answering from a memory of something I did around 35 years ago.

You must log in to answer this question.

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