Speedlock and Co.

20 February 2004

Disk Formats / Copy Protection Support


  • Alien Breed protection support
  • AmigaDOS track on Pinball Mania, see Pinball Mania section for more info.
  • CHW (alternate), on Conqueror
  • Cosmic Bouncer: Alternate data tracks
  • Death Trap
  • Demonware protection on Ooops Up and The Power
  • Electronic Arts: Support for the protection on the early games, see Electronic Arts section for more info.
  • Elite Systems: Another format on the Encore version of Beyond the Ice Palace
  • Cyberblast protection tracks. They work almost exactly the same as the very unique protection on the Garrison games. The author of both games is the same and it seems they are actually pretty much the same game - just different graphics and sound.
  • Hacker protection support. This game is very rare, it was previously thought not to exist by many.
  • Knightforce: Save/highscore format
  • Lankhor protection track: Found on G.Nius & Maupiti Island so far. It is basically a slight variant of the Infogrames protection track.
  • The Moochies
  • Power Drift and Super Hang-On: Support for the retail versions using flakey bit protection and encryption.
  • Pinball Wizard track/ protection.
  • Protec: New protection track variant on Silent Service
  • Protec: Alternate format on Tennis Cup
  • Protec: Protection track variants on some old US games
  • Prison: Flakey bit protection
  • Rubicon: Flakey bit protection
  • Rainbow Arts protection variant on Mission Elevator
  • Rob Northen: An old format on Flip-it and Magnose, Black Lamp, Badlands Pete, Star Goose possibly other games too.
  • Rob Northen protection on TV Sports Football
  • Speedlock: Alternate track used on P47 Thunderbolt
  • Speedlock: Alternate data tracks on ATFII
  • Surf Ninjas
  • Ubi Soft on Jupiter’s Masterdrive and Celtic Legends, possibly others
  • Visionary Design format on the retail version of Datastorm, Dragon’s Lair data and Vortex
  • Zarathrusta: Unfortunately this format does not hold much integrity information, though the marks at the end of each track assure that the stream size has not changed.
  • Another Zeppelin format on Sink or Swim
  • Zyconix


  • Anco protection to use gap distance instead of block number.
  • Prince of Persia renamed to Broderbund as it is used on the US version of Typhoon Thompson.
  • Back to the Future 3 renamed to JIM, as it was found on another game, the budget version of Viz.
  • Daley Thompson’s Olympic Challenge: Support added to the old protection format.
  • Renamed SWIV to RPW variant as it really is and used by St Dragon as well.
  • Renamed Pro Tennis Tour to Ubi Soft 2 as they share the same format.


  • Dragon’s Lair (see Visionary Design above)

There are also many formats added and changed due to new MFM (Modified Frequency Modulation) integrity testing that you read more about in the integrity testing section below.

Notes on Formats/Protections

Pinball Mania

AmigaDOS track with “NCQ” signature in the area, followed by a value that is possibly a serial number. Found on the retail version of Pinball Mania. It may be just be a duplicator identifier, but obviously it will be present just in case the game ever takes a peek.

Electronic Arts

Full support for the Copy Protection data used on the very first games by Electronic Arts. Funnily these games are much better protected than later ones, and it was quite a challenge understanding what they do since they are all unoptimised C code passing around all the parameters on the stack as well as variables, and weak/flakey bits are just added to the protection data resulting in the games only working randomly. All restored now to their original glory of 1986, working perfectly.

Luckily some games share common encryption keys.

Supported titles include: Archon, Arctic Fox, Skyfox, One on One, Seven Cities of Gold. Later titles use HLS protection and at least Skyfox has a revised edition dumped where the protection is changed to the much more reliable HLS one.

This bit of work took a lot longer than for most games. Two days, writing notes on stack frames, guessing what variables do and so on. The protection uses two techniques. The first is 20 or 30 (depending on game) 32-bit encryption keys (all are used), and the second is the distance of two marks on the track from each other in bits, rounded.

The tracks have weak/flakey bits to prevent proper copying, rendering many of the games unreadable nearly twenty years on, as the mark distance read becomes altered. Luckily pairs of games use the very same key, which was useful in determining what the distance was meant to be.

User Library Changes

Flakey bit generator changed to make Prison happy. It did not work if the combined bits from two rotations were algorithmically generated with matching bits on decoded data. The reason for this is that all other flakey bit games use the raw bits to check changes, but Prison tries to decode them as an AmigaDOS block, then checks the results. The algorithm has been replaced with a true pseudo random one.

Analyser Changes

Explicit Gap Values

Now in the analyser, gap values can be set to each block individually through scripting, to override the default setting. This is particularly useful for protections where the whole track is set to the same value and is expected to be readable regardless of the track size, i.e. tracks fully written with gaps of certain values.

Track Size Calculation

Optional track size calculation for release images where the source image results in conflicting sizes, normally associated with incomplete track writing - leaving the gap area unformatted, thus promoting widely variant track sizes. While random track content is desirable as protection, this function is to take care of mastering problems that are unintentional.

It was needed for Capcom Platinum and a few others as the analyser would not let bad files (i.e. nonsense track sizes) be saved.


Added script to repair certain AmigaDOS problems associated with bad MFM encoding for the mastering problems on Utopia.

Automatic detection of irregular gap sizes, a semi-uncommon mastering problem.

Fix function for the new Copylock Amiga version (see last WIP for more details about the fix functionality).

Games of Interest

Alternate Reality

The first Amiga game found that has a GCR encoded track.

Little Computer People

This game is quite unique. To read about our investigations into why, we have a dedicated article available.

Push Over

We had been having some trouble finding good disks of this game, but a recently submitted dump is perfect. The funny thing is that the game is different from all the bad ones. Luckily disk two is the same on both versions (see Comparison Technology below), and since this is where the mastering errors occurred, we are able to release both versions!

According to file dates the good version is older by two weeks, so it is likely to be very rare, having changed it a few days after production started.

Ultima 4

The US version of this game has now been dumped, and is protected with a system called Xelok. The interesting things about this is that it is very similar to Protec. It seems either Protec was originally called Xelok or somebody ripped it off.

Comparison Technology

We had always planned to create some kind of comparison tool so we could easily see the differences between IPF files and for another reasons we will come back to later. However, we had put it off since (a) it was not really needed yet, and (b) it is really not a trivial task to find differences between files where data is meant to vary anyway, let alone the fact that we want to compare disks of many different formats.

A tool that we have not mentioned until now is CTT (CAPS Transfer Tester). Its job was basically to ensure that there are no network transfer errors in a RAW or IPF file. It does this by checking the checksum information we calculate when creating the files. This functionality is being expanded to highlight differences between IPF files.

Some recent work is a first step, it allows us to get any part of any block without MFM Encoding and independent from variables that would otherwise render a comparison unusable. This is things like track size, gap values, flakey bits, etc. Basically pure unencoded data content with all the things that change ignored.

This is possible because IPF files identify and otherwise describe data elements. Therefore we are able to separate real data from changing/irrelevant data. It works because the user library is the “mastering device” and variable data (such as gaps) is generated at runtime from the info collected about track geometry. Encoding (just MFM at this point) is generated as well, it is not stored that way.

CTT does not actually show what is different within a particular track yet, just that it is different and is good enough for the moment.

One question that may come up is for similar sets of game disks. Are we going to release just one disk from alternate version of a game if only that one is different? Well the answer is no, since it was not sold that way. We will only release complete disk sets.

Sync Differences

Some games only vary by their sync values. Since it is very useful to see differences with and without the syncs involved, checking is made optional. A game effected by this is Dragon’s Lair.

An Issue, Resolved

Formats that contain a generated gap distance value and fed from a different master are reported as different, while once decoded they yield the same decoded data. Obviously the only thing different here is the fact that the gap distance variable is set to different values. So while currently reporting it as different is technically very correct, logically it is not.

Since both of these things can be detected automatically by the data, it is possible to check for this condition and activate a deeper comparison that is aware of this issue. This is actually needed anyway for reporting the differences in detail.

There are two formats are affected by this: AmigaDOS and SFX.

Image Merge

Functionality added to CTT to allow merging of RAW disk images. Selected tracks replace existing or add new tracks to the destination image. This is very useful when several bad images of the same version of a game are available.

One practical example is the dumps we have of the game ATF II. When played, this game modifies its disk. We do have one copy which is infected with a virus and so doesn’t boot. The nice thing about this is that, since it cannot be booted, it is otherwise unmodfied. It probably happened soon after its purchase. Merging a good boot track into this image gives us a fully working version. The comparison functionality is also helpful here so we can ensure it is exactly the same version.

Just goes to show that even virus infected disks can still be helpful!

Integrity for the Integrity-less

Although we find integrity on many games that were previously widely thought not to have any (usually since it is not used by the loader), there are some games that really have no integrity information, so knowing if we have a good one or not is much more difficult. Notable examples of games without integrity info are Shadow of the Beast I and II. No surprises these are from Psygnosis whose dubious duplication quality seems to come up again and again as an issue.

So, to verify these games are good, we have done two things.

  1. The comparison technology as described above. It can be used to do a comparison between as many dumps of these types of games as possible. This is something that was planned as a last resort for a long time, we just have not needed to do it yet since we had plenty of games to work with that did have integrity information. The functionality was not needed yet, now it is.
  2. A technique that uses an MFM Encoding integrity test as an EDC process (see a previous WIP for details of the analysation pipeline). This is used for those games where there really is no checksum on the data tracks.

The data area that is specified for the operation is read as a raw bitstream and must match how the decoded data would be encoded to raw form, it must not contain any marks and the flow of encoding must be continuous between each data part. Due to the way MFM is encoded, these restrictions act together as a weak parity check and ensure that the data is read back as it was written., i.e. not bit shifted data, as bitshifting would normally cause one or more of the conditions to fail.

Unfortunately this is not as good as a real parity check for the simple reason that you do not have a checksum of what had been read by the mastering device and that what was duplicated was correct in the first place. So, the master disk or the reading of the master disk could still be faulty.

However, this combined with the comparison functionality gives us a very powerful method of weeding out bad games that have no proper integrity information. The games effected by this functionality are listed below.

New Formats

New formats supported that do not have a real EDC recorded on the disk, but are now supported using the MFM integrity tests.

  • Atomix
  • Baal
  • Disposable Hero
  • Gazza II: Boot data
  • Hammerfist
  • Maupiti Island: Boot data
  • Robotnic
  • Shadow of the Beast, two versions
  • Shadow of the Beast 2
  • Typhoon
  • Yogi’s Great Escape: A Gary Antcliffe format without a checksum.

Modified Formats

MFM integrity tests added to existing formats that benefit from this feature.

  • Dragon’s Lair boot tracks
  • Moochies
  • SmartDOS: Added to the last 10 bytes that is not covered by the checksum
  • Zarathrusta

Also changed Botics to Vectordean as the format seems to be originating from them. The last block has no checksum for whatever reason, so it is now checked against MFM integrity.


Shadow of the Beast

Interestingly, these techniques have already brought to light a few things about this game in particular. Many disks from this game have been dumped, but almost all are bad. This was highlighted using the comparison tool, and quantified by the MFM integrity tests, which also helped us to find one that was good.

You may remember that we take multiple revolutions (or “reads”) of each track. It is interesting to note the kinds of things the analyser does to help. In this instance, just before the tracks got really bad (where only some reads were failing) the analyser noticed and selected better ones without manual intervention.

There are actually two versions of this game:

  1. A common, probably later version with the protection on long tracks. From retail to budget each version is of this kind, i.e. no differences - apart from tons of bad tracks on (very nearly) all of them.
  2. Three dumps of a version with a different track layout. Two bad, but the other (only very recently dumped) version is good.

Note: Writing long tracks without verifying using a checksum is a really bad idea. We would have hated to work in Psygnosis’ returns department!

With the new Analyser enhancements and the IPF comparator, it was possible to filter out a good copy of the common version.

Shadow of the Beast II

Of the huge number of dumps of this game, it seems we have two versions of this one too:

  1. Each and every version (except one) dumped including all copies bundled in A500 packs, retail copies, etc.
  2. A different version dumped only by the founder of CAPS. Unfortunately disk two is the same with all the other versions, but it shouldn’t be. Therefore somebody mismatched the packaging so we only have the first disk of that one. The disk looks different though, the first disk is a white one with the real in-game logo. (Update: We eventually found a complete set.)


As we expected, both of these games have an incredibly high bad disk rate.

Games mastered without verifying. Not using checksums for mastering is one thing (and stupid), but writing on long tracks where it is much more likely writing will fail... Really... What did they expect...?