New formats, Copylock Amiga & Copylock ST

28 October 2002

Disk Formats

New

  • AmigaDOS, trk/sec mod: yet another ADOS variant where both the track and the sector numbers are modified. Found on Carthage.
  • Anarchy
  • BAT
  • Battle Squadron: US version
  • Bloodhouse: a different format on Stardust.
  • Botics: Unfortunately the last block of data on each track is not covered by the EDC - probably by mistake.
  • Copylock Amiga: the protection format used by tons of Amiga games with varying cell density (read more about this later). This includes:
    • “Normal” Amiga Copylock
    • Old, MFM illegal version of Copylock Amiga. Found on Populous (early?) European version, and Incredible Shrinking Sphere.
    • Clone (?) newer, different density Copylock Amiga version. Found on Odyssey and World Class Rugby’95.
  • Copylock ST: Automatic density detection for the Atari ST version of Copylock. Found on the ST/STE versions of Back to the Future 2, Nightbreed the Interactive Movie, Operation Wolf, Stunt Car Racer, Time Scanner. The density identification was later enhanced, possibly eliminating all artifacts where certain density graphs were sometimes falsely identified as Copylock ST.
  • Crosscheck
  • Elfmania
  • ESD dual-boot: Eclipse Software Design dual-boot support on Atari/Amiga, found on Stone Age and Monster Business.
  • Executioner
  • Flipit and Magnose
  • Gremlin: Slightly different format on Deflektor
  • Gremlin: Another format on Plan 9 from Outer Space
  • Hackmat: By Jeff Spangenberg, found on the US versions of After Burner and Thunder Blade.
  • MH, Marc Hawlitzeck: Krymini including highscore format
  • Monkey DOS: On Games - Summer Edition
  • MT variant found on BC Kid
  • Night Hunter
  • Plague
  • Puffy’s Saga
  • Rome AD92 including save games
  • Shadow Warriors
  • Startrash: Game loader does not use the EDC, but of course we can.
  • SWIV
  • Teenage Mutant Hero Turtles (Konami), from the author of BTTF3
  • TL variant on Death or Glory

Changed

  • Firebird: Added authenticy area (right before marks) as mandatory data so the analyser cannot remove it.
  • Software Projects: Support for the mastering errors.

Removed

  • Stone Age dual-boot, it’s ESD

Density Detection

When a track is selected in the analyser, the density for it is detected and named in the graph as shown in Fig 1.

Fig 1: Density graph for a normal Amiga track

New

  • Automatic density detection for the newer, different density Copylock Amiga.
  • Automatic density detection for Copylock ST (that is, the Atari ST version). Found on the ST/STE versions of Back to the Future 2, Nightbreed the Interactive Movie, Operation Wolf, Stunt Car Racer, Time Scanner.

Changed

  • Renamed all references from “CopyLock” to “Copylock Amiga”, since that is the name being used on the disks themselves. Besides the Atari ST version is called Copylock ST (but only density detection is supported so far).

Copylock, Official Analyser Support

Copylock has been a protection scheme that has been one of the most concentrated on since CAPS began. Partly due to the fact that it is probably the most unique copy protection on the Amiga, and it is certainly technically brilliant. As discussed in previous WIPs, its major failure really was caused by it being used as an “after thought” and not integrated during development. However, this was something that Rob Northen really pressed upon companies licensing it, it is just a shame that most didn’t listen.

Renewed Interest

So what spurred the research into how Copylock really worked. Finding out has always been on the agenda, because what we are concerned about is how we can check that data read is 100% true to the original and would pass the key reader routine (from when the game loads) no matter what parts of the track are being used (so we don’t have to take a look at each game using it; well over 500 titles). But we re-started the research again particularly now because we got some information from quite an unlikely source. We had a contribution of Atari ST games from Jaquita and have and only just got around to dumping them and we noticed a semi-familiar density graph in a semi-familiar place...

Fig 2: Density graph for a Atari ST Copylock track

As opposed to the now familiar Amiga Copylock in Fig 3 & 4.

Fig 3: Density graph for a Amiga Copylock track Fig 4: Density graph for the newer Amiga Copylock track

Integrity!

However, even though we discovered we could master this protection even before we had finished the dumping tool, we didn’t know how to check the integrity of a Copylock track.

The main reason a Copylock descriptor was held back (apart from getting bored with it last year ;) is that we have not added any formats where we do not know how to check their integrity. If you didn’t already realise, every single format so far supported in the analyser also describes how integrity information is stored in it, and this is checked when a dump is processed. That of course means all formats added can be properly checked, even many of which have no EDC check in the game loader. In these cases the method was recovered from the unused track data that was almost certainly only used by the duplicator service to verify the data was written correctly.

We knew there must be a way to check Copylock integrity, but if you take a look at the track data it is not obvious at all and there is no unused data either. So we thought maybe the only way is to have the trace script, but that seemed a bit too tedious.

So we let it rest for quite some time, until the Atari ST games were dumped and we saw the density graphs on some looked like a “half” Copylock track. The data stored on the Atari version was easier to figure out. One thing became obvious: it is generated data. So we looked at the Amiga version again... and again... and finally - it “clicked” and we knew the relationship between the data bytes, therefore the integrity test was added using the now 100% known Copylock algorithm.

The algorithm creating the Copylock Amiga blocks is fully implemented, thus the integrity of a Copylock track can be 100% checked. The “Key” value in the analyser shows the number of iterations required to have the first byte of the track (in other word: seed value) from the code generator. So now if we needed to, we can generate a 100% complete CLA track from its seed value. Bit by bit... The integrity test for copylock is quite strict: data read is compared with data generated and is a very accurate verifying procedure.

As an interesting aside, we would like to mention that bad tracks are less likely to be found towards the outer rim of a disk since data is less dense (and hence more clearly defined). It was a good choice to put Copylock there.

Compression

So for a Copylock track, the only thing that you need to store is the generator seed value. The whole “junk” that fills the track can be created from the seed. 12500 bytes to 3 bytes is a fairly good compression ratio. However we decided (partly for purist reasons, and partly because of legal ones) that we would store the whole track data as it was read, but obviously only if the data is 100% correct. This also avoids the need for emulators to implement the Copylock generator algorithm.

PROTEC

There is another really popular protection format, certainly the most popular after Copylock and it is called PROTEC. It consists of a track format and the Copylock style “key track”. However, the track format(s) were rarely used.

Two variants of the track format have been added to the analyser, but the protection track is not yet supported.

Analyser Changes

PDOS

Control blocks not generating output were reported missing in data node. This affected e.g. PDOS, where the automatic key finder algo generated a missing block.

Data element list for analysed tracks

Once a format scores above 0% (i.e. it is not completely rejected or an unknown format) it is possible to list all the used elements of the track geometry as it was interpreted during that actual analysation. This could vary greatly, due to the fact that many descriptors use advanced search features, such as adapting values and their frequency used on the track. E.g. Finding mark values automagically.

Fig 5: Data Element List

Descriptors may contain informative or even dummy entries that are meaningless for the output stream (to CAPS release files) since they effect the input stream. The entries like area definitions, mark constraints etc., are removed from the list, to provide clean/human readable geometry output.

Saving Support

Various support logic is being implemented that is required for saving. This is much more complex than it seems, due to the way the analyser reconstructs data from possibly millions of data combinations.

Saving requires the original ordering of the data elements and their exact bitposition, so it is traced and derived to the positions of an imaginary perfect track.

Saving requires gap sizes bit-exact, so they are recalculated. Gap info is displayed in the track geometry.

Misc

  • Control blocks are no longer displayed in track geometry, if they don’t contain real data.
  • An additonal “<>” info section may precede format info. It may contain:

>’*’, if the track originally was not synced with index during mastering.
‘?’, if the track possibly contains more data, than what is mapped according to descriptors (not working yet).

  • Format scores are only displayed (similarly to track geometry) if they are not 100% (default). This provides cleaner output.