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) except when you first boot Disk I (only used for the intro).

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

Historical Aspects

It is our understanding that floppy-disk-based copy protections in Japan were, by and large, produced by the companies involved in disk manufacturing and duplication. Publishers would purchase a specific protection scheme to be applied to their disks during duplication. More complex schemes could cost more, as would customizing the patterns to be unique for a specific game. (In a few cases it was possible to bypass copy protections by swapping in a disk with an identical protection.)

The software developers would receive source code of the routines used to validate the protection, which they could tweak if desired. Encryption and obfuscation routines were also available directly from the companies producing the protection. It is not clear whether any of the anti-tampering routines were provided by said companies.

We have come across a few schemes that so far appear to be exclusive to individual publishers. Whether they were bespoke or developed in-house is unknown.

In every case we've seen so far, the copy-protected software is not intermingled with the protection scheme, meaning that removing the protection from the disk will not affect the correct operation of the software. Naturally, the software will typically refuse to run if its protection checks fail, but we've never seen a case, in Japan, where the protection concealed some sort of program data or other critical component of the software being protected.

Copy protections were themselves sometimes protected, by patents and perhaps trade-secret laws. However, it seems unlikely that the patterns themselves would qualify for copyright protection, being largely trivial and only of secondary importance in most schemes. (In some cases the patterns are not even checked - only their presence.) If they were found to be subject to copyright, the original rights holder would be the company that created the scheme, which was not normally the software developer / publisher, as noted above.

Preservation Home