I am curious how copy prevention was implemented for games or other programs loaded from cassette on the micro computers of the early 1980s, such as the ZX Spectrum 48k. If I recall correctly, some games even managed to defeat direct tape-to-tape copying. How was this achieved, and does this technique or set of techniques have any application for modern IT security?

I am mainly interested in the ZX Spectrum, but the scope of this question also includes other micro computers of the early 1980s that loaded programs from tape.

  • 2
    Heh, this is actually a really intriguing question. Time to dig out the old tapes!
    – Polynomial
    Dec 12 '12 at 12:47
  • As far as i remember from the C64 days, some programs just checked if a certain block on disk was formatted or not. Blank disks had to be formatted, so if you copied a program or disk with the usual tools then this block was always formatted on the copy. Not sure if the same principle could be applied to cassette tapes... Dec 12 '12 at 22:57
  • There is a series of great articles that show you how here: craigsretrocomputingpage.eu5.org/howtohack/index.html
    – user30202
    Aug 30 '13 at 18:23

If I recall correctly, some games even managed to defeat direct tape-to-tape copying.

In principle, this couldn't be possible, as the audio track on the tape contained all the information required. In practice, by using a custom loader which operated on data files encoded at a higher frequency than the standard Spectrum data files, low-quality consumer-grade tape-to-tape copying could be defeated - by making the format more sensitive to noise, you make it harder for noisy copiers to work.

Wikipedia has pointed me at this page with a surprisingly large amount of detail on custom loading schemes.

Applications to modern IT seem hard to come up with, because in-memory data is digital so 'copies' are either perfect or not actually copies at all. Although see the comments for how it's not necessarily that simple for all physical 'digital' media!

  • 1
    +1 for defeat of low-quality consumer-grade tape-to-tape copying, and for attempting to relate the technology to modern IT security. BTW That really is a fantastic website, and it is amazing to see that even 25 years later not all of the encoding schemes have been deduced.
    – D.H.
    Dec 12 '12 at 16:50
  • 1
    You can still get "close enough to fool the player" through digital means (eg. subtly misaligned tracks on custom manufactured CDs).
    – detly
    Dec 12 '12 at 22:00
  • I have accepted this answer as it provides the best response to the original question.
    – D.H.
    Dec 17 '12 at 14:53
  • 1
    @detly: I found the closest analogy here for Nintendo's Wii and Nintendo GameCube. each disc contains some deliberately placed defects. The exact positions of these defects, which differ for each produced disc, is encoded encrypted in the BCA of each disc. The BCA is readable on most standard DVD-ROM Drives, but consumer burners can reproduce neither the BCA nor the defects.
    – D.H.
    Dec 17 '12 at 14:57
  • 1
    Maybe it was CD-Cops which uses, apparently, the angle between the first and last sector of the disc as part of its protection. So a perfect digital copy doesn't necessarily include all the "data" required to run.
    – detly
    Dec 17 '12 at 23:57

Back then, tapes were just binary data on a magnetic film, with no "hidden" channels or out-of-band capabilities. Manufacturers that claimed to make tape-to-tape recording impossible often just made the tape look different, to deter would-be pirates. A regular tape recorder module was usually used to read them, so making "special" tapes couldn't really work.

The usual method was to ship a booklet (e.g. an instruction manual) with multiple pages, then ask the user to input a particular word from a particular line on a particular page. Code cards were also used, utilising embossed black text on dark paper to prevent easy photocopying.

Anyone could copy the tapes, but copying the booklet was more difficult at that time; nobody had scanners, and few people would go to the effort of photocopying a multi-page booklet at their local library. Even if they did try to copy the booklet, key words would often be darkened in the text to prevent them from being copied cleanly.

Some early video games included merchandise, code wheels, text on CD cases (e.g. Meryl's codec number in Metal Gear Solid), or other physical goods that were required to play the game (e.g. to solve certain puzzles), and these were reasonably effective deterrents. Other games simply shipped posters and action figures to make the original copies more valuable than a copy could be.

As a (slightly off-topic) side note, VHS tapes did have the ability to contain data that couldn't be copied by normal players. Essentially a VHS player works by running the digital signals from the tape into a digital-to-analog converter (DAC), which then sends that signal to the monitor along with an appropriate synchronisation signal. This analog signal is interpreted as a set of colours, but some subtle peaks were also used to send commands to the player (e.g. blank screen, reset vertical sync, etc.).

Macrovision (a copy-protect mechanism) encoded high voltages into the tapes, such that the player's protection circuitry would compensate. On the original tapes, the value would be interpreted as a glitch and be ignored by the player. On a copy, the recorder would reduce the signal level to that of the rest of the video. Once that part of the signal was reduced to a normal level, the player would interpret it as a blanking signal, causing the video to be entirely blank (usually blue). Other mechanisms relied on the same trick, but instead used signals that caused the video to be hue-shifted, or that caused most players' tracking mechanisms to malfunction.

  • 1
    +1 for an informative response, especially for the interesting description of the Macrovision mechanism. However, I can't help feeling that game developers did do something more hi-tech. I seem to recall "accelerated" loaders, not native to the Spectrum ROM, that seemed to defeat copying attempts; though maybe their primary objective was just to speed up the loading.
    – D.H.
    Dec 12 '12 at 16:08
  • @D.H. It may just have been that the code was obfuscated, to prevent people disassembling the game and stripping out the license checking stuff.
    – Polynomial
    Dec 12 '12 at 16:09
  • Ah, this brings up fond memories of my first professional Matrox capture card that had the ability to strip Macrovision so that I could actually digitize my VHS library back in the good old days when gigabytes were still big. Dec 12 '12 at 16:33
  • @AJHenderson As a kid, my dad and I actually built a custom bit of hardware to strip Macrovision from video signals. Essentially it was a comparator, ADC, sample buffer, DAC and notch filter. The signal would go through the ADC, sit in a sample buffer for ~250µs, go back through an DAC, and finally though the notch filter. When comparator spotted the Macrovision peaks, it would enable the notch filter and cut off everything but the tracking. After a fair amount of tweaking (and a lot of maths that I didn't understand back then) we got it to record a pay-per-view movie onto VHS :)
    – Polynomial
    Dec 12 '12 at 17:01
  • Wow, the bit about VHS tapes is INCREDIBLY wrong! For starters there isn't any digital data as part of standard VHS. The picture and sound are stored as analogue waveforms. Later uses could put some digital data onto VHS for custom purposes but standard consumer VHS is all analogue. You're a bit off on Macrovision too, it's to do with non-standard sync-pulses but you're in the right neighbourhood.
    – Greenaum
    Jun 25 '20 at 17:18

Those good old days. When I was young I copied some Spectrum games and had to work my way around copy preventions schemes.

Tape-to-tape copying is described in other answers. I was interested in digital copies for the best results.

Data on the tape in standard format was essentially just a series of bytes. With a few standard statements (LOAD, SAVE) you could load that data into memory, switch tapes and write it back to another tape.
The copied game would load from disk but to my surprise it did not work.

After some experimenting I discovered that after the main game-data three extra datablocks came on the tape that should be copied as well. Slightly more complex but doable.

Still, no success.

After still more experimenting I discovered that the first one of the small extra datablocks was loaded into a special Spectrum memory location (FRAMES) that was (interrupt driven) incremented 50 times a second by the ROM. After the last small block was loaded, the (FRAMES) value was verified by the code to see if would lie within a certain range. If the small datablocks on the tape were not exactly on the correct distance the game would refuse to load.
This was very hard to get right if you would manually copy each of the blocks individual.

As expected, after some years copy-helper-programs could be found that would help you copying these datablocks and remembering the distance of the blocks.

Another trick gamebuilder would use against this was to make the game extremely large so it would fill up almost every byte of the memory. That way there would be no room for any copy-helper-program.
To work around that new copy-helper-program emerged that would even use the video memory for storage of the datablocks loaded from the tapes. Your screen would be a mess but the game got copied.


There were other (non tape-related) types of copy-protection as well. I remember one game in particular called ACE that had the Lenslok copy-protection: https://en.wikipedia.org/wiki/Lenslok

From Wikipedia: "The Lenslok device was essentially a row of prisms arranged vertically in a plastic holder. Before the game started, a two-letter code was displayed on the screen, but it was corrupted by being split into vertical bands which were then rearranged on screen. By viewing these bands through the Lenslok they were restored to their correct order and the code could be read and entered allowing access to the game. The device was small enough when folded flat to fit next to an audio cassette in a standard case."

As I recall, it was very tedious to use and you would often get the code wrong, having to reload the program all over again.


it was due to the tape deck and an "averaging" volume leveller that home decks , that pro-mastering machines didn't use. if you google "paul hughes freeload" you'll learn about it. he wrote oceans c64 loaders. certain loaders had self modifying code also. the built in rom routines for tape and 8 bit are really slow. sadly the 8 bit atari was dreadful.. the kernal loader on a c64 tape deck was pretty poor also. there were a few tricks also like the padlock card and lenslok which stopped a lot of such things as well.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.