Floppy Copy Protection Methods

Copy Protection Methods

Many different protection methods were developed over the years in a cat-and-mouse game with those that wanted to make a copy of their own (or a friend's) disk. The methods steadily increased in complexity, but whether or not the protection was easily duplicated or not, a way was always found to make a working backup. Descriptions of the drive hardware itself, as well as many of the methods that different companies employed to keep the disks from being copied are found here.

Protection Methods

Intentional Disk Errors

  • This protection consists of a disk error purposefully placed on a sector or an entire track, then its existence is checked for in the program. If the error isn't found, it assumes this is a copy and not an original disk. In the beginning, there were no copy programs except Jim Butterfield's "COPY/ALL" that came on the 1541 test/demo disk. This program could not reproduce these errors (and even if it could, it took *FOREVER* to copy even regular disks). Like most protection, though, it only foiled casual copiers. Early, clever crackers figured out how to scan an original disk for these and the methods for recreating the errors were not difficult. Soon after, programs like "Copy II/64" came out that could effortlessly detect and reproduce these errors which marked the end of this era. Most publishers of disk software used this method before late 1984.

Track Skew

  • This protection involves placing a track on the disk that is a specific skew offset from the one before it. The protection is checked by the program by stepping the heads between the tracks and checking that the exact timing is what is expected between them. If the timings are wrong, it knows this is a copy.

Fat Tracks

  • Fat tracks are a special case of track skew protection where two copies of a track are stored on sequential tracks of a disk with no skew, so they appear as one "fat" track. Electronic Arts used this protection from about 1984-1985, and Activision used it and called it "XEMAG" for many years. These protections stand out from most other early methods because they could *not* be copied 100% reliably even with *any* nibbler. As mentioned earlier, the 1541 has no way to know where it is on a track. Therefore, it has no way to know where it is in comparison to any other tracks on the disk. For this reason, it is impossible to reliably write these tracks out perfectly aligned with a 1541 drive. This was an idea that was greatly expanded on in future protections, but it still stands the test of time and still can't be duplicated reliably without using the index hole sensor. It is of note that it *is* possible to "unreliably" copy these, as you can just try over and over again copying just these two tracks until you happen upon "close enough" alignment for it to work. NOTE: Slowing your disk drive motor down to 298.5rpm or less seems to allow EA and XEMAG skew-protected disks to pass the protection checks.

Half Tracks

  • Along the same vein as fat-tracks, it was of course possible to read and write to the usually skipped "half-tracks" instead of the normal tracks, if you weren't worried about storing any data on the normal tracks. This foiled many copiers because they didn't search for and copy these half-tracks by default, so they instead got garbled, invalid mixes of the "real" data when trying to read the tracks as if they were normal. Copiers later came out that could scan for and detect these and copy them properly. There are very few titles which require half-tracks to work, but there are a couple.

Extra Tracks

  • This protection simply relies on using disk tracks beyond 35. Normally, copy programs default to copying only tracks 1-35, so these are missed. I am not sure why the programmers didn't extend this by default, except maybe some would lock up reading unformatted tracks, which these tracks usually are. Sometimes these tracks contained actual DOS-formatted data, but usually they were just "key" tracks. They could sometimes be nibbled, other times they could not, because they were combined with other protections.

Changed Bitrates

  • As mentioned above, the bitrate is normally higher on the outer tracks and lower on the inner tracks. Some disks were protected by using a non-standard bitrate on different tracks. Copiers later came out that would scan for the correct density and these disks could be copied that way.

"Signatures" in the Header, Sector, or Tail gaps

  • As mentioned above, when a disk is copied with either a fast copier or a nibbler, the gap data is not copied directly. Copiers would commonly just fill this space with 0x55 bytes. Gaps are "inert" bytes, meaning they aren't normally used as data, but just a space filler that is ignored by DOS. There are some protections that check for specific bytes here, or even the length of the gaps, and know they're a copy if it's different. This protection can be copied with hardware solutions that either extend the RAM in the drive to 8k or add a parallel port so it can read and write the entire track in one pass.

Long Sectors

  • As mentioned above, the drive has only 2k and can't fit an entire track in RAM, so it must be broken down into 4 parts and stitched together on the destination disk. If you make a sector longer than will fit in RAM, it can't be copied with a normal 1541. This can be copied with hardware solutions that either extend the RAM in the drive to 8k or add a parallel port so it can read and write the entire track in one pass.

Custom Formats

  • These usually depend on the long sectors trick above to be successful, but they also entail changing the way that GCR is interpreted in a custom DOS. If you write your own DOS, you can use your own disk format entirely, ignoring common sync, gap, header, and data conventions altogether and use whatever you want. You only have to adhere to the GCR limitations of sync and no more than two '0' bits in a row, but even that didn't stop later innovations.

Long Tracks

  • Normal drives spin at ~300rpm and can "write" data at the highest density up to about 7700 bytes per disk track. However, the drive can "read" more than that, within some margin of error depending on motor speed. Some protection took advantage of this and put more data on the track than could be written back out at the normal speed, making it difficult to copy. Some copiers would "trim" the data in as non-destructive way as possible (reducing sync length and gaps) and it was also possible to slow down the disk drive to foil this, but usually these disk relied on a combination of other protections as well. A good example of this is the later Epyx Vorpal protection/loader.

Sync Counting

  • A sync mark must be at least ten '1' bits long to signal the drive hardware that we're about to see GCR data. However, sync marks are usually much longer than this (40 bits) and have no limit to their length. When copying a disk with a software nibbler, sync has to be reproduced rather than copied, since it is more like a "signal" than actual data stored on the disk exactly. For this reason, the length of a sync is also somewhat dependent on drive speed and will vary a little. Some protections count on this and measure the lengths of the sync, or the occurrences of sync on a track, to see if they match, and know they're a copy if they don't. Microprose used this method on some disks, and in fact "trimming" the sync will fail the protection checks.

Track Synchronization

  • We mentioned above that the drive doesn't use the index hole, so lining up the tracks on the disk is nearly impossible on the 1541. Since disks weren't usually mastered with a 1541, but rather with machines that could do track sync based on the index hole, protections took advantage of this in different ways. They would move to a halftrack or the next track in the middle of reading to see if the data that should be there exists. If it doesn't, it knows that it's a copy.

Bad GCR/Unformatted/"Weak Bits"

  • We mentioned before that if the drive sees 3 or more '0' bits in a row, it clocks in a random '1' bit occasionally. Single occurrences of this sequence won't always make it lose framing, it will return a "random" byte, but more than a couple in a row will result in the drive losing framing and reading these "random" bytes until it sees the next real '1' bit. Most nibblers can't duplicate this, so protections checked a byte purposefully on the disk somewhere and if it reads the same thing over and over, it knows it's a copy. Later copy programs did try to reproduce this-- Burst Nibbler detects and writes a 0x01 byte in their place, which is enough to fool most software into working. It is also worth noting that this is the same thing as unformatted tracks, so you'll see this a lot when imaging in new disks. Since the disks aren't usually duplicated on a 1541, and the tracks aren't always as long as they could be, the machine leaves unformatted data on the end of all the tracks, causing a lot of software to appear to have these on every track, and making it difficult to verify the tracks from disk to disk, since the bytes will be different from sample to sample. I have several disks from Synapse that have unformatted parts on all the tracks, and none of the tracks above 25 are formatted at all! I've seen this used in Rapidlok (all titles), later Microprose disks, and Datasoft (Bruce Lee, The Goonies, Mr. Do!)

Signature (Key) Tracks

  • This protection is seen from time to time and revolves around a track being mastered in a non-standard way. It can be all sync '1' bits (which we call a 'sync-killer' track), unformatted (or all '0' bits), filled completely with some other byte, or filled a special byte sequence like EA's PirateSlayer, or a combination of all of them. These tracks generally foil most all copy programs because they either cannot handle all or long sequences of '1' or all '0' bits, or they are just read incorrectly/out of framing. We can remaster most all of these with our development version of 'nibtools'.

No SYNC

  • One of the meaner protections that came about used tracks on the disk that had *no* sync marks. Most copiers cannot read these tracks and just detect them as empty. The later Epyx Vorpal loader uses this technique.

"SpiraDisc"

  • This protection name hails from the Apple ][ and isn't exactly the same, but similar. It is found on one commercial disk that we've seen- "Bounty Bob Strikes Back". The data on the first 14 tracks or so are written half on the regular track, and half on the next half-track, all aligned perfectly. The game loads by stepping out to track 1, beginning the load, then stepping a half track at a time all the way in until the game is loaded. If any deviation in time from where it expects the data to be and when is found, it fails. I've never been able to make a working copy. Jim Drew of UU developed a custom copier for the SuperCard+ board that is able to copy this protection, but it's really more of a custom "remastering" program

Documentation provided by Peter Rittwage and corrected, formatted by Xiny6581!