SPS Technical Overview

Much of the information contained on the site is rather technical in nature, since it is a complex subject. So lets attempt to start at the beginning, when the games were originally produced...

As you probably know, disks for different systems stored their data in different ways, this is called the “disk format“. This was taken to another level on systems like the Commodore Amiga, where the flexible nature of the hardware (actually just a cheap move by Commodore to supply minimal hardware and shifting as much work as possible into “cheap” software - the operating system) meant that it was not restricted in reading and writing any particular disk format. What you get is quite unlike other systems (like your common x86 PC) where the disk format is defined in the hardware that controls the drive (the “Floppy Disk Controller or FDC). The result of this is that on the Amiga, developers could implement far more diverse and inventive ways to prevent a disk being copied.

The disks themselves were basically all written on commercial mastering machines (duplicators), like the ones from a company called Trace Products. They did very accurate and high quality disk mastering. The duplicators started up by loading a disk image into RAM which was written to every disk in the disk feeder or “hopper” - used to load 50, 100 or more disks depending on the model. The mastering machines were controlled by a Unix workstation, equipped with some specialised software that implemented a disk structure description language called Freeform. This basically allowed the duplicator company to describe pretty much any disk format, implement custom ones, and even accept Freeform scripts from Copy Protection companies like Rob Northen Computing. Rob Northen would have written a Freeform script for his Copylock protection, and supplied it to the duplicator in order to write the Copylock “key” disks. Even AmigaDOS has a Freeform script. You can look at the AmigaDOS format description in our own language in the July 1002 WIP update.

So why was all this needed?

Well, basically, you need to know how to write a disk in order to write whatever data you want to write reliably - this is heavy Magnetic Recording Theory stuff, and is quite complicated. Freeform provides this “description” of how to write the disks. It can also be used to check that what has been written to a disk is correct, this is because the script also describes where and how integrity information is stored. The duplication machine uses this to verify disks on a second pass.

As an aside, we should say that on the Commodore Amiga, there are actually not as many of these formats as people might think. The secret is that they were just used in slightly different ways, and this is something which both freeform and our language handle automatically. We believe that apart from a couple of exceptions, we now know pretty much all of the generic disk formats used on the Amiga. So it may be that the only other ones left are ones specific to certain games. It may also be interesting to note that we have only added formats so far that we can verify are 100% correct, as we check both the integrity information used by the game and by the duplicator, the duplicator integrity information is something the games did not use in most cases.

Nothing has changed from then and now. This is still how you have to write disks with copy protection and custom formats. So part of what we have done is something similar, except instead of writing the disk, we hold all the information in an IPF (Interchangeable Preservation Format) file. The IPF files are basically a combination of both the disk data and how this data is stored. This can be used both to master the disk images back as well as in emulation now.

So basically, we have developed dumping tools that can read a disk at a very “low level”. In fact, we pretty much pick the bits off the disk surface. This is not usually possible because what you read through the FDC (even an Amiga) is not what is actually stored on the disk surface.

This disk image containing the raw signal information is then loading into our analyser where known disk formats are automatically detected. The analyser checks it is unmodified since it was originally mastered, and checks all integrity info is correct against the format description. The “final” disk image (if it proves to be from a good disk) is then created which contains the disk data, how it is stored (and hence how to write it back) and also a few other things needed to store copy protection (like how dense the data is at any part of each track.

The final disk images are sent back to the original contributors, and then archived for preservation.