On-disk copy protection on earlier Microprose releases.

Some people mistakenly think that earlier Microprose releases, such as F-15 Strike Eagle, have no on-disk copy protection; and that the only protection is codes from the manual. But this is not correct as we’ll explain in this article.

Why they think so? They do so because in many cases (described below), a copy made with a standard sector copier works flawlessly.

• If you make an ATR image of the original disk, the image will work ok under emulators.
• Furthermore, it will also work on real hardware when used with APE, SIO2PC or similar software.
• If you make a physical copy of the original disk (or write back an image) with an XF-551, the disk will still work.
• And even a copy made with an 810 or 1050 drive, it will again work as long as the disk is run from a Happy or similar enhanced drive in fast mode.

However, the normal procedure that the typical user at that time would use, doesn’t work. If you copy the disk (or write back an ATR image) with a sector copier on an 810 or 1050; and then you attempt to run the disk again in a stock drive, it will fail.

The Protection

The reason of this very strange behavior is the type of the copy protection used, and how it is tested. The protection is usually known as skew-align. It consists on measuring the radial distance of sectors across different tracks. This was a rather popular protection on some 8-bit computers like the Atari, because they used drives without an index-hole sensor.

These Microprose disks have the tracks almost perfectly (skew) aligned one with the other. This is easily done on drives that use the index-hole for formatting. Disks formatted on older stock Atari drives however, and because they cannot align with the index hole, always have a considerable skew misalignment across tracks.

There are at two basic ways for the protection to detect the skew alignment at run-time. The method employed here is to compare the time that takes to read corresponding sectors on different tracks. If the disk is skew aligned, the time will be more or less the same.

So let’s say that the software reads sector 1, then sector 19, then sector 37, then sector 55 (the first sector of tracks 0 to 3), etc. On the original disk, it will take about the same time between all these reading. If they differ above some threshold, it is assumed to be a copy and the program fails.

The reasons copies work

Now let’s see how a simple copy of the disk still run under all the cases mentioned above:

• Emulators have a (more or less) constant timing between reading any sector on an ATR image. There is no attempt to reproduce the timing effects of rotation or seeking across tracks. The result is that disregarding which sectors you read, it will always take the same time. And then the protection will pass.

• Exactly the same will happen when running the ATR image with a SIO2PC cable.

• If you copy or write back the disk with an XF-551 drive, you are actually recreating the protection. This is because unlike previous Atari drives, the XF-551 uses the index hole for formatting, and then tracks will be automatically aligned by default.

• Lastly, the skew alignment, or more precisely, the misalignment has no effect when using an enhanced buffered drive like the Happy. In this case the drive buffers the whole track before returning the first sector to the computer. And, because of the way this is performed, the time of this procedure is the same disregarding the skew alignment of the disk.