The Tape Ecosystem — Why the UK Was Different
In North America, most users had a 1541 disk drive as part of their package purchase. Britain was different. The C64 arrived into a market where the ZX Spectrum and Amstrad CPC had already made tape the normal delivery format for cheap software. A disk drive was an expensive optional extra, not something you assumed the buyer had. Publishers like Ocean, US Gold, Elite, and Mastertronic sold enormous volumes on cassette — and the tape they sold to the average kid for £2.99 was the product. The 1541 was not part of the picture. It was not uncommon for cracking groups to trade cassette tape originals with other sceners through the mail system, where several different groups released their own versions of the same cassette.
How Turbo Loaders Worked
The C64's built-in Kernal tape loading routine is extremely slow: roughly 300 baud. At that speed a 50KB game takes over 20 minutes to load, and the user gets nothing but a flickering border to watch. For commercial software, this was unacceptable.
Turbo loaders replaced the Kernal routine entirely. Instead of letting the Kernal interpret the tape's audio signal, the turbo loader installed its own interrupt-driven bit reader that ran at 5–10× the standard speed (typically 1500–3000 baud). This required recording the tape at the higher baud rate in the first place — which the publisher's duplication machinery handled — and a decoder small enough to fit in the C64's available RAM at load time.
TAP Format & Modern Preservation
The modern preservation format for C64 tape software is TAP — a file format that stores the raw magnetic flux timing from the cassette as a sequence of pulse-length values in microseconds. Unlike D64 (which stores logical disk sectors), TAP captures the actual electrical signal the Datasette would have produced, including all the timing nuances of turbo encodings, custom sync patterns, and protection-critical signal relationships.
Creating a TAP image requires hardware that can sample the tape's audio output at high resolution — either a purpose-built C64 tape interface (connected to the Datasette port) or a general-purpose audio ADC with the appropriate software. Tools like tapclean can then analyse, repair, and validate the resulting TAP file. GreaseWeazle, primarily known as a disk flux capture tool, also supports tape capture in TAP mode via an appropriate adapter.
Emulators including VICE support TAP playback directly — playing back the raw timing values through a virtual Datasette in exactly the timing sequence the original tape would have produced. A game protected by Novaload or Cyberload loads in VICE from TAP exactly as it would on original hardware, because the TAP contains the complete signal the original loader expects to see.
Novaload — The Stack Hijack
Novaload was perhaps the most widely deployed tape loader on the C64. At its peak it was licensed to scores of publishers including Ocean, US Gold, LucasFilm Games, and many Mastertronic titles.
The Standard Tape Problem
The C64's Datasette ran at roughly 300 baud — a large game could take 30 minutes to load, with no feedback except a flickering border. The Kernal's tape routine also had no auto-run: the user typed LOAD, waited, then manually typed RUN. Commercial turbo loaders addressed both problems: faster transfer rates (typically 5–10× the standard speed) and automatic execution. Protection was almost always bundled in — a tape that auto-ran via a custom loader couldn't be trivially copied to another tape with a standard tape-to-tape deck, since the turbo encoding was not reproduced by standard cassette duplication.
How Novaload Hijacked the Stack
The clever core of Novaload's protection was stack poisoning. The 6502/6510 CPU stack is permanently fixed in memory at page 1 ($0100–$01FF) and cannot be moved. Novaload's first data block was loaded directly into the stack area — overwriting the return addresses that the Kernal's tape loading routine had pushed there. When that routine finished and executed its RTS (return from subroutine), instead of returning to the normal BASIC LOAD handler, the CPU jumped to whatever address Novaload had written into the stack — straight into the loader's own code. The game launched without the user pressing anything, and without the code ever appearing as a conventional loadable BASIC or ML program.
Bit Timing and Why the Screen Can Stay On
One of Novaload's most notable features — the fact that the screen stays on and music plays throughout loading — comes down to a careful choice of bit timing. The standard Kernal tape routine turns off the screen during loading specifically because the VIC-II chip steals CPU cycles when it renders each scanline (these are called badlines). This cycle-stealing disrupts precise timing, so the Kernal plays it safe and blanks the display.
Novaload's designers worked around this.
The User-Facing Experience
Novaload created a rich loading experience: a custom loading screen with game artwork, a scrolling text message, a real-time counter showing elapsed minutes, seconds, and hundredths plus remaining block count, and SID music playing throughout. US Gold's Novaload variant used a specific arrangement of the American national anthem as its loading music — composed by Gary J. Sabin, who mastered cassette versions of US Gold titles. The source disks for these arrangements were recovered decades later by preservation researchers, along with Novaload's mastering tools.
The NovaBill Controversy and Freeload
The story behind why Ocean eventually stopped using Novaload is murky and somewhat disputed. Paul Woakes — the programmer behind Novagen Software and the creator of Novaload — believed that someone at Ocean had reverse-engineered and copied his loader to avoid paying the ongoing licensing fee. He was, by accounts from people who knew him, still genuinely upset about it years later. His response was to embed a character named "NovaBill" in the Mercenary series — a barely disguised reference to the person at Ocean he held responsible. The name made sense to anyone who knew the inside story.
The Ocean loader that replaced Novaload was called Freeload, written by programmer Paul Hughes. Hughes had joined Ocean and developed it independently. In his own words, he felt he knew Bill (the person Woakes had named) and couldn't picture him doing something so nefarious — the truth of what happened has never been officially confirmed. What is clear is that Freeload served the same purpose as Novaload and Ocean no longer needed to pay for a licence.
A footnote: Ocean later asked Hughes to write something similar for Spectrum and Amstrad to cut their third-party loader licensing costs on those platforms. He turned it down — he knew the C64 inside out but didn't know the Spectrum or Amstrad hardware well enough to build solid protection for them. Someone else took on the job; it went out once, the duplicating facility (Ablex) ran into problems with it, and it was quickly pulled.
Tape-to-Tape Defeat and Preservation
Novaload's protection prevented casual tape-to-tape copying because consumer cassette decks recorded and played back at standard speed and standard encoding. A copy of a Novaload tape made on a HiFi deck produced a normal-speed recording with the correct audio signal but which, when loaded on a C64, produced garbage — because the Kernal's standard tape decoder couldn't interpret the turbo encoding. Defeating it required either a C64 with a parallel tape interface that could record at turbo rate, or cracking the auto-run mechanism by patching the stack-overwrite code before execution. Preservation today uses flux-level TAP format capture tools (including GreaseWeazle used in tape mode) that record the raw magnetic signal and can reproduce the turbo encoding faithfully.
Cyberload
Cyberload was developed by John Twiddy. It was used by companies such as System 3 for their C64 catalogue from the mid-1980s. While not as widely licensed as Novaload, it's immediately recognisable from its visual signature: a sweeping effect running horizontally across the title text.
Like the other turbo systems of its era, Cyberload replaced the Kernal tape routine with a faster interrupt-driven decoder, ran at several times the standard baud rate, and provided auto-run. The loading screen often displayed the game's title in yellow, with a white animation bar.
Commodore used standard low-cost audio cassette transports in their computers. These don't have particularly good speed control, and can only respond in the normal frequency range of ferric audio cassettes. Duplicators such as Ablex used audio methods to duplicate tapes, too. So there can't be anything particularly magic about how C64 tapes are made. If the data format isn't self-clocking, it will fail at the slightest tape speed variation
In regards to Ocean, they didn't went straight from Novaload to Freeload - they had their own bespoke loader in-between. This loader - called the Ocean loader for lack of a better term - was used for their games between 1985 (first used in Hyper Sports) and 1987, and most games using this loader used a loading tune written by Martin Galway which is one of the best known SID tunes (of which there are two versions - simply dubbed Ocean Loader 1 and 2).
Freeload was first used by Hewson from what I recall, specifically on titles developed by Graftgold such as Uridium. The loader was soon cloned - two early games which used Freeload clones are A'n'F's Wibstars and Quicksilva/Binary Design's Glider Rider.