Preservation Home


Problems with Disk Images of Unknown Provenance

There are many problems with images found in public distribution. This section attempts to catalog the most commonly seen reasons that a disk image might not be pristine. Note that you often see multiple categories at the same time.

This will hopefully illustrate why it is so important to go back to the original source material.

Modifications by the software

For example, to save the game or high scores.

Modifications by the user

Users occasionally customize their disks by modifying configuration files, for example.

Modifications by the OS

Some operating systems (i.e. graphical versions of Human68k) will write to disks on every boot. Please make sure your original disks are write protected!

Modifications by hackers

Extremely common. Mainly done to bypass copy protections. Different hackers often produce different implementations.

Discarded unused tracks

This is mainly an X68000 problem due to the DIM optimization that is commonly used on that platform. Although the tracks were (probably) unused from a functional standpoint, they often contain interesting data such as source code for the software on the disk.

Junk in unused areas

Often occurs when a disk is reused to make a copy.

Rebuilt images

This is typically due to copying files instead of duplicating sectors.

Bad dumps

One or more disks in the chain of copies had read errors.

Improper dumps

Occasionally happens when the copier did not cope properly with a particular protection scheme. Different copiers sometimes produce different (improper) results.

Missing legitimate variants

Disk-based software was often released in multiple forms, for example to fix programming errors. It is shockingly common for us to find variants of X68000 games that never made it into circulation and were therefore lost.

Inconsistent source material

Some disks do not have a canonical form; variations can and do occur between dumps, sometimes even dumps of the same physical disk. Eliminating or at least segregating these inconsistencies is one of our goals.

Ever wondered why there were so many "alternates" in that collection you downloaded? Now you know.

Floppy Disk Copy Protection

Most disk-based software falls under one of the following categories.


There are no impediments to copying the disk.

Be aware that even though a disk may be unprotected, it could still contain software that checks the protection on a different disk in a set. Many unprotected disks in circulation have been "fixed" for this reason.


The disk contains copy protection features but they are not utilized and do not interfere with duplication. This is believed to most commonly be an oversight or misunderstanding on the part of the programmers (i.e. incorrectly assuming that the protection was passive, as defined below).


The disk has features intended to stymie disk duplication but the software makes no attempt to determine if the disk is a copy or not. Unauthorized copies typically remove or replace the troublesome parts of the disk so that it can be replicated without special software.


The software checks the disk to determine if it is a copy or an original. Note that the software need not be on the protected disk itself, as mentioned above.

In the majority of cases, unlike the previous category, such disks can be copied by standard software without incident, but they will be identified as copies and refuse to run.

Non-disk-based protections, such as challenge-based schemes (codewheels, manual look-up, etc.), could also be considered "active", even though the media itself is normally unprotected.

Floppy Disk Designations

This section describes how to interpret the codes assigned to floppy disks, the most well-known being 2HD and 2DD. A common misconception is that "HD" stands for "high density" which isn't quite accurate.

The first character is the number of sides (for disks) or heads (for drives): 1 or 2.

The second character indicates the cell density: 'S' for single-density (FM), 'D' for double-density (MFM), or 'H' for high-density.

The third character, if present, is a 'D' standing for "Double Track" (i.e. 96 TPI). If omitted, assume 48 tracks per inch (TPI). Although you will see it used for 3.5" disks, this designation is only really meaningful for the 5.25" form; the other disk sizes only ever used one track density.

Using the above should make it obvious how to characterize the more obscure designations such as 2S (double-side, single-density) or 1D (single-sided, double density).

You may also see a fourth character, which differentiates between various sector formats. These are probably unofficial. On X68000 there are two: 2HDA and 2HDE. There is no physical difference compared to disks with other sector formats.

There are many non-standard designations that don't quite fit the rules, such as 2HS or 2HQ. There isn't a standard way to interpret these; however, they are likely to be double-sided and double-tracked with some sort of exotic sector format.

Another attribute that isn't encoded in the three-character designation is the recording drive's rotational frequency: 300 or 360 RPM. Disks written with a given speed can only be (correctly) read by a drive spinning at the same rate. Like sector formatting, this is not a physical property of the disk; the medium itself can be (re)formatted at either speed.


Some software will reject a disk if it is in an unexpected write-protection state, meaning that it is writable when it shouldn't be or it is read-only when it should be writable.

As for why such checks are performed, checking for unexpected writability could be an easily subverted form of copy protection, and that probably is the intent in at least some cases, but in our experience it seems more likely to just be an easy way to reject an obviously incorrect disk. For example, some games will reject a disk for being read-only even if there is no intention to write to it at the time it is being inserted.

On the X68000 at least, polling for an inserted disk produces several other status bits, one of which is the write-protection state. So it is easy enough to check for writability along with waiting for a disk to be inserted.

An example where it doesn't seem intended for copy protection is Mid-Garts, which doesn't care about the write-protection state of Disk II (main program) unless you boot Disk I (only used for the intro).

A more sophisticated copy protection method involving unexpectedly writable disks would entail actually writing to the disk, such that the damage is not noticed until later.

Preservation Home