Protection Methods, Explained
Here's every major protection category used on C64 software, roughly in order of how hard they were to beat — from simple tricks used in 1982 to fiendishly complex multi-layered systems that defeated practically everything through the early 1990s.
The oldest trick in the book. During manufacturing, specific sectors were deliberately left corrupt — missing sync marks, bad checksums, missing data blocks, or wrong track/sector IDs in the header. The game's loader attempted to read these sectors and expected specific error codes from the DOS. If a copy program had correctly reproduced those sectors (fixing the errors), the check would fail and the game would refuse to run.
You could implement this with a simple BASIC loop: OPEN 15,8,15 : OPEN 5,8,5,"#" : PRINT#15,"U1:";5;0;33;5 : INPUT#15,S : IF S<>23 THEN GOTO ... — open a buffer, read sector 5 of track 33, and check that the status code is 23 (data block checksum error). If the copy fixer wrote valid data there, S would be 0 instead.
CBM DOS Read Error Codes — The Complete Reference
These are the standard error numbers returned on the 1541's command channel. Protection schemes verified that specific error codes appeared at specific tracks/sectors — not just that any error was present.
#20 – Block header not found (sync found, but no matching T/S header)
#21 – No sync character (head spins, no sync marks at all)
#22 – Data block not found (header found, but data block marker missing)
#23 – Checksum error in data block (data read, but CRC doesn't match)
#24 – Byte decoding error (invalid GCR — cannot decode to valid byte)
#27 – Checksum error in header (header CRC mismatch)
#29 – Disk ID mismatch (sector header ID ≠ BAM disk ID)
#30 – General syntax error
The most common errors used in protection were #20 (no sync — the "bad track" type that pounds the head), #21 (sync-less track), #23 (deliberate checksum corruption), and #27 (header checksum). Protection schemes sometimes verified that errors appeared in a specific sequence or count — checking for three error-23 sectors plus one error-20 sector, for instance, rather than just "any error present."
A more sophisticated variant of the bad-sector check involved a specific technique Jim Drew (author of Burst Nibbler and Super Parameters / Kracker Pak) documented: early checks used the OPEN / INPUT#15 method above, which caused the drive to visibly rattle its head during the error-sector reads. Publishers noticed users could identify the protection check by listening for the head rattle. The counter-move: use the 1541's job queue (the low-level drive command interface at $0600–$06FF in drive RAM) to read an error sector without the full head-hunt retry loop. The job queue approach reads the data once, returns the error code without retrying, and does so silently. Crucially, once copiers discovered this technique, they used the same job queue method to extract the actual data from a checksum-error sector — error #23 only means the stored checksum is wrong; the data bytes themselves can still be perfectly valid and readable.
These were broken almost immediately by nibblers that preserved error codes. Within a year the method was considered trivial. It remained in use through the mid-1980s as a secondary layer combined with stronger methods.
The 1541's drive mechanism has an 80-track range, but uses a single-density (narrow) read/write head. Normally each track is written once, at the precise center of a track position. A fat track writes the same (or related) data across multiple adjacent track positions simultaneously, using an extra-wide write head at the mastering facility.
The protection check works like this: step to track 35, read a specific signature. Step to track 35.5 (half-track), read the same signature. Step to track 36, read again. On an original, the same data appears at all three positions because the write head was wide enough to cover all of them. On a copy made by a standard 1541 (which writes narrow tracks), only position 35 was written — the half-track and track 36 positions are unformatted and return garbage or errors.
Markus Brenner confirmed this technique in a 1999 presentation: the extra-wide write head records two adjacent track positions simultaneously, and the check reads from all positions to verify the original. EA used fat track heavily throughout the Pirate Slayer era.
Jim Drew — author of Burst Nibbler and Super Parameters / Kracker Pak — offered a precise copier-side account of what the term means and how the bypass worked: the phrase "fat track" was coined by Mike (J. Henry), not by the copy scene at large. From the copier's perspective, the EA scheme was simple enough that it didn't require reproducing the fat track at all — a copier could just write standard narrow tracks 34 and 35 back in perfect alignment, and EA's check was loose enough to pass. The reason this worked was that EA's early implementation read both track 34 and the 34.5 half-track but didn't require the data at 34.5 to match exactly; it only needed it to be readable. A narrow write to track 34 naturally bled slightly into the 34.5 space on a well-aligned drive, passing the borderline check. Later and stricter fat-track implementations were less forgiving.
Critically, Drew noted that the 1541 cannot write a true half-track in normal operation — the drive electronics include a guard band (erase head) that erases a strip slightly wider than the write head on each side of the track being written. This prevents adjacent-track interference on reads. Writing a half-track requires disabling or narrowing this erase band, which requires either modified drive hardware or a mastering facility's professional equipment. Consumer copiers that wanted to write genuine half-track data had to either modify the 1541's erase circuitry or find a way to write at an offset that approximated the half-track position while keeping the guard band, accepting imperfect results.
Because each physical track position requires two stepper motor steps in the 1541's drive mechanism, a single step moves the head halfway between two nominal track positions. These "half tracks" at positions like 17.5, 18.5, 35.5 are physically writable and readable — they just don't correspond to any position in the standard disk format.
A protection scheme places authentic data at a half-track position. When copying, standard disk copiers step in fixed full-track increments and never land on a .5 position, so they completely miss this data. The game's custom loader explicitly tells the drive to step only once (rather than twice) to reach the half-track, reads its key data, and uses it to decrypt or authorize the rest of the load.
Writing genuine half-track data was the exclusive province of professional mastering equipment. As Jim Drew documented, the 1541 cannot write true half-tracks in normal use: the drive's guard band / erase head wipes a zone slightly wider than the write track on each side to prevent adjacent-track bleed. Writing a half-track means writing data that must survive exactly between two full tracks — but the guard band of the full tracks on either side overlaps those intermediate positions, threatening to erase them. Professional mastering rigs used narrower erase heads and precise head positioning to thread data into these half-track gaps without erasure. Consumer copiers sometimes approximated this by commanding only a single stepper-motor step (Drew's trick used on the Bounty Bob Strikes Back! copier), relying on the motor stopping 180 degrees out of its normal detent phase to land close enough to the half-track position to read existing data — though this was mechanically imprecise and drive-dependent.
The 1541's standard DOS firmware only uses tracks 1–35 for safety — moving beyond track 35 risks the head grinding against the inner track stop if not careful. But the physical mechanism supports up to 40 tracks (and sometimes beyond, though with increasing risk of head damage). The ROM firmware simply refuses to go there.
A custom loader bypasses the firmware and directly controls the stepper motor, positioning the head on tracks 36, 37, 38, 39, or 40. Key data is stored here. Standard disk copiers that respect the firmware's 35-track limit will never copy this data. Since standard disk images (D64 format) are also defined as 35-track, most emulated backups from the pre-preservation era are silently missing this content.
The 1541 has four speed zones, each with a specific bit rate set by the VIA timer registers. Zone 3 (tracks 1–17, outermost) runs at the highest rate of 307 kbps; Zone 0 (tracks 31–35, innermost) runs at the lowest, 250 kbps. A protection scheme writes a track at the wrong bit rate: for example, writing track 30 (which should be Zone 1 at 267 kbps) using Zone 3's 307 kbps rate. The track is physically there, but a standard reader tuned to 267 kbps will misread it. Only a reader specifically configured for the correct (wrong) rate can decode it.
Even more devious: bit rate can change within a single track. The middle of track 22 might switch from Zone 1 to Zone 3 mid-sector. No standard drive controller expects this, so the read electronics lose sync at exactly that point. The protection scheme's custom loader knows exactly when to switch the VIA registers to decode the data correctly. Antitrack noted from cracking experience that in-track density switching was known but seldom used — because nibblers of the era almost never checked for it, a protection using it had an effective free pass against most tools.
Jim Drew's observation from the field captures how far this evolution went by the late 1980s: in the final years of the commercial C64 era, publishers were building game disks where only track 18 — the directory track — remained in standard CBM DOS format. Every other track used either a custom loader format, non-standard bit rates, or other protection-derived encoding. Standard disk tools couldn't read these disks at all; only the game's own boot loader, and the handful of nibbler tools that had been updated to handle these formats, could interact with them meaningfully.
A standard 1541 running at 300 RPM can write approximately 7,820 GCR bytes per revolution on the outermost tracks (Zone 3, tracks 1–17). A long track writes more bytes than one full revolution — effectively squeezing data in so tightly that it overlaps the start of the track, or by slowing the drive motor during recording so more bytes fit before the disk returns to its starting position.
When copying, a standard nibbler tries to read all data in one revolution at the drive's normal speed. If more data was recorded than can fit in one revolution at normal speed, the beginning of the data gets overwritten before it's been read. The entire track appears truncated or corrupt to standard tools.
Markus Brenner documented the clever V-MAX! long-track GCR decoding trick, where the custom on-the-fly decoder used this formula:
byte = (GCR_byte_1 AND $AA) OR (GCR_byte_2 AND $55)This takes the even bits from one GCR byte and the odd bits from the next, interleaving them to reconstruct the original byte. The result is a highly compact encoding that doesn't need the drive to buffer the entire track — it decodes as it reads, making the approach both a fast loader and a protection mechanism simultaneously. Normal copy programs choke on this because the track doesn't fit in the drive's 2 KB buffer.
The GCR spec says no valid data byte can have more than eight consecutive 1-bits. This means any sequence of ten or more 1-bits is either a sync mark or corruption. Clever schemes exploit the gray area between "sync" and "data" in several ways:
- Killer Track (All-Sync): The entire track is filled with $FF bytes (all 1-bits). Every standard disk reader enters an infinite loop looking for the sync to end and data to begin. Many nibblers simply hang permanently when they hit this track. If a copy program skips it (which some do), the protection detects that the all-sync track wasn't reproduced correctly.
- Sync Count: The protection counts the exact number of sync marks on a given track, or measures the byte length of each sync mark. On original disks, this is fixed. On a copy, the nibbler may write sync marks of slightly different lengths, or the count may differ. The check measures this with the VIA timer.
- Missing Sync (No-Sync Track): A track with zero sync marks. The drive head finds no data start points and spins indefinitely. Used in Vorpal, where entire sections of the disk use a custom no-sync format with all data read by raw bit timing instead.
- Bit Framing Drift: A very long run of 0-bits (which GCR limits to two) causes the read electronics to lose their byte-boundary framing. A protection scheme may deliberately include a region that looks valid to the hardware but causes framing corruption at a specific bit offset that only their custom decoder knows to compensate for.
Between sectors on a track, there's a gap region filled with $55 or $4A bytes by default during formatting. This gap is normally discarded by disk copiers — they only care about the header and data blocks. Protection schemes write specific key bytes into the tail gap of particular sectors — bytes that the game's custom loader reads with precise timing.
One real-world implementation: a key scheme on track 36 was EOR'd with 5 specific bytes in the tail gap of each sector. These gap bytes were used to decrypt the main data stream as it was loaded, in 256-byte blocks, stored backwards on the disk. Neither the tail gap bytes nor the backwards storage nor the XOR key are preserved by standard copiers, making this a triple-layered barrier. Even if a nibbler preserved the raw GCR, the copier had to also know to read the gap.
However, Jim Drew noted that gap-based protections became progressively less used once hardware copiers became common. Hardware parallel-cable nibblers like Burst Nibbler transferred raw GCR flux data — which included the gap bytes — directly. A software copier that worked sector-by-sector discarded gaps; a hardware nibbler that worked track-by-track preserved them automatically. This shifted the gap protection's value from "invisible to copiers" to "visible but only to hardware nibblers" — reducing it to one layer among several rather than a standalone protection.
A section of the disk is deliberately left with no magnetic transitions — either by never formatting that area, or by erasing it precisely. Because there are no transitions for the read electronics to phase-lock onto, every time you read this region you get different, essentially random data.
The protection checks this by reading the "weak bit" zone multiple times and confirming that the bytes differ between reads. On a copy, the nibbler wrote whatever garbage it read on the first pass — so now those bytes are fixed and consistent. Reading twice gives the same bytes, which fails the check.
Jim Drew documented a crucial hardware difference that affected how weak-bit protections were detected and copied: the original 1541 (and 1541-C) uses an analog data separator that genuinely "floats" invalid GCR bits — with no valid magnetic transitions to lock onto, the read output is indeterminate and truly random. The 1541-II and 1571, however, use a different data separator design that does not float: when these drives encounter invalid GCR regions, they stabilise the output to a fixed pattern rather than generating random values. This means a weak-bit protection that produces random data on a 1541 will produce consistent, fixed data on a 1541-II or 1571 — which appears to the protection routine as a copy rather than an original. Some users were baffled when their original, legally purchased disk would play fine on a 1541 but fail the protection check on a 1541-II; this was the cause. It also meant that copiers using a 1541-II as the source drive could more easily identify and correctly target weak-bit regions, since the fixed output made them visible and unambiguous.
Every sector on a CBM DOS disk has a header that identifies it: a track number and a sector number. Normally these are unique — track 18, sector 4 appears exactly once. But the 1541 hardware reads sector headers sequentially as they spin past the head, and the firmware simply looks for the first sector whose header matches the requested track/sector number. Nothing in the hardware prevents a disk from having the same track/sector combination appear more than once per revolution.
A protection scheme exploited this by writing two or more sectors with identical track/sector header IDs on the same physical track. From the perspective of a standard DOS LOAD or sector copier, only the first instance encountered as the disk spins was ever read — the second was invisible. The protection's custom loader, however, would read the track in raw mode (bypassing the standard sector-match logic) and explicitly seek the second instance, often by counting sync marks or measuring inter-sector timing. The second instance held the actual key data or decryption bytes.
Some schemes extended this across multiple tracks — placing a sector with the same ID at the same logical position on two different physical tracks. The standard loader picked up one copy; only the custom loader that knew to seek a specific angular offset on the second track would find the other. Jim Drew noted this was not uncommon in early protections, particularly 1983–1985, before the community fully understood the technique and began building copy tools to detect and handle it.
Defeating duplicate sector ID protection required a nibbler that copied all raw GCR data per track without any sector-matching logic — which meant reproducing every sector regardless of whether its ID was unique. Standard sector copiers were blind to the duplicate because they matched-by-ID and stopped at the first hit; only a raw track copier would reproduce both instances faithfully.
RapidLok, developed for Accolade, was one of the most technically demanding protections of the era — and one of the most speed-sensitive. Understanding it requires knowing how it worked from the inside.
The core concept: the protected tracks use a custom GCR encoding that discards every third bit from the standard GCR stream (essentially implementing a proprietary 10-to-something encoding). The resulting byte stream is not valid standard GCR — a normal disk reader gets garbage. Only RapidLok's custom drive-side decoder, running in the 1541's RAM, knows the correct decoding table.
A typical RapidLok disk had track 18 in standard CBM DOS format (so the directory was readable and the loader itself could boot normally). The loader then downloaded its custom routine into drive RAM. This routine stepped the head to track 36 — an extra track beyond the standard range — where the key was stored. The key's position on track 36 was read using precise VIA timer cycles.
The killer detail: reading the key correctly depended on the exact position of specific sectors as the disk rotated. This timing was so tight that if your 1541's motor speed was even slightly off from exactly 300 RPM, the head would step to the correct angular position but read the wrong byte. As one user described from 1999:
GUNSHIP would not load on three different 1541s until I sat there with a small screwdriver and kept adjusting the drive speed a little at a time. As a matter of fact, it was a good method of setting my drive speed!
— Francis Yarra, comp.sys.cbm, October 1999After authenticating the key, RapidLok read the protected data tracks using its custom decoder, decrypted the data using the key bytes, and transferred the result to the C64. Some tracks on the disk were standard CBM DOS; others were RapidLok format. Track 18 was always standard.
Copying RapidLok required tools like Kracker Jax's Super Shotgun II that specifically implemented RapidLok's decoding routine. Generic nibblers that copied raw GCR flux would step past track 36, get nothing or hit the head stop, and the copy would appear to work but refuse to load protected data — or crash during load.
V-MAX! was created by Harald Seeley and went through at least seven versions over roughly eight years. It began as a fast loader in 1985 (the copyright line "V-MAX! © 1985 by Harald Seeley" appeared on Diskmaker v3.3b), and only gradually became the infamous copy protection it's remembered as.
Version 1 (1985): Essentially a fast loader. Used on Star Rank Boxing and a few early Thunder Mountain titles. A track (typically track 20) was formatted with data in a special streaming EOR format. The drive-side code read two raw GCR bytes and EOR'd them together to produce one decoded byte, on the fly, without buffering the full track. This was fast but not hard to copy once you understood the encoding. Pete Rittwage noted that Star Rank Boxing specifically was far more complex than typical V-MAX! v1: the entire game was converted to p-code (a virtual machine layer) with embedded track-to-track alignment checks that fired randomly during gameplay — meaning a cracker who removed only the initial boot protection would still encounter checks mid-game that crashed or corrupted the running program.
Take Down Wrestling — the most extreme V-MAX! v1 variant. Among the hardest V-MAX! titles to crack was Take Down Wrestling (Thunder Mountain). It used a V-MAX! v1 custom configuration combined with the "nastiest timer-encrypted code" Rittwage had encountered. The protection ran simultaneous decryption loops on both the C64 and the 1541 drive simultaneously, swapping data back and forth over the serial bus to decode each other's routines on the fly. This mutual decryption phase lasted approximately 30 real-time seconds — meaning the disk spent nearly half a minute doing nothing but running a dual-machine cryptographic handshake before any game code was ever loaded. Removing this required reverse-engineering both the C64-side and drive-side routines in parallel, as neither made sense without the other.
Versions 2–3 (1986–1987): Added non-standard bit rates on the higher-numbered tracks. Defender of the Crown, Bop N Rumble, and Howard the Duck used this era. Still copyable by Epyx FastLoad-era tools, but harder. Most V-MAX games of this period would refuse to load with a FastLoad cartridge inserted because the protection interfered with anything already resident in drive RAM.
Versions 3+ (1988 onward): The version people remember and fear. Now required extra RAM in the 1541 to copy. The standard 1541 has 2 KB of RAM. V-MAX! v3+ used a custom encoding that required the full decode buffer to exceed 2 KB — meaning a standard drive could read the data and execute it, but couldn't buffer it for copying. To copy this version, you needed a RAMBoard or Supercard expansion that added 8 KB of RAM to the drive (starting at $8000 in the drive's address space). Games: Three Stooges, Arkanoid 2, Alien Syndrome, Thunderblade, Rastan, Times of Lore, Rocket Ranger.
Harald Seeley himself appeared in the comp.sys.cbm newsgroup in November 1999 to comment on the discussion of his protection:
Did I actually make 7 versions of V-MAX!? I forget... Anyway, I really only remember the fine details of the last one, but feel free to ask if you need help understanding how it works. I honestly don't know of anything that could copy it with a 1541/71 (even getting it professionally duplicated was a real problem). If it's keeping you from making archival copies of your legitimately purchased C64 software 12 years later, I guess it's outlived its usefulness. ;-)
— Harald Seeley, comp.sys.cbm, November 1, 1999Even professional disk duplicators struggled with V-MAX!. Commercial houses that mass-produced game disks sometimes couldn't use their standard GCR duplicators and had to use specialty equipment. Markus Brenner noted that the slowed-motor variant was particularly difficult — the disk was recorded with the motor intentionally running slow, packing more bytes per revolution than physically reproducible at standard 300 RPM.
Vorpal was Epyx's in-house loading and protection system, widely used across their catalog. Like RapidLok and V-MAX!, Vorpal was advertised primarily as a fast loader — and it was genuinely fast. Unlike most systems, Vorpal took its innovation a step further by using tracks with no sync marks at all.
Without sync marks, the drive's standard ROM can't find data blocks. Vorpal's custom decoder read data by raw bit timing instead of looking for sync marks — counting bit transitions and reconstructing byte boundaries from the timing of magnetic flux changes alone. This is an extremely tight implementation because the decoder must maintain its bit-level sync with the spinning disk entirely through timing.
Early Vorpal also used gap protection — key bytes in the inter-sector gaps that were XOR'd with the main data blocks. Later versions added bit-rate mixing. The combination made Vorpal one of the more respected protection systems; it took good nibbler tools to copy accurately.
TIMEX was created by Ivo Herzeg (scene handle: Mr. Cursor), a German freelance programmer who also designed the disk magazine interfaces and loader systems for Magic Disk 64, Game On, and Golden Disk 64. It stands apart from virtually every other C64 protection because its primary mechanism is not disk-level format trickery — it is a runtime memory decryption system driven by the VIC-II raster interrupt.
The core principle: game code is stored on disk in an encrypted form. TIMEX's loader installs a small IRQ handler that hooks the VIC-II's raster interrupt. As the game's code is loaded into RAM, this handler fires repeatedly and decrypts memory in-place, XOR-ing bytes against values derived from precise raster timing. The game runs from the decrypted data in RAM — the CPU never executes the encrypted bytes directly.
This creates an attack surface completely different from disk-level protections. A cracker cannot simply nibble the disk and get a working copy — the disk copy is byte-accurate but the loaded code remains encrypted without the IRQ decryption running. The standard cracking approach of freezing the computer with a cartridge, examining memory, and patching the protection check is also defeated: the decryption is ongoing, not a one-time check, so freezing at an arbitrary moment catches the code in a partially-decrypted state.
Snacky (Sigi, Genesis*Project) — voted cracker of the year 1990 on C64 — gave the definitive first-hand account of the TIMEX experience in a 2006 interview:
The TIMEX system was a copy protection on C64 that used the raster timer together with the IRQ (Interrupt) to decode the memory during operation. Remarkably, Ivo Herzeg also known as Mr. Cursor was truly one of the masters of C64 development with this masterpiece. I cracked Timex first in Tiebreak. [...] In general, as soon as the protection was found and removed, it was pretty easy to remove it the next time if it was used again. And this was the key point with the TIMEX protection. Once cracked, it was easy to remove it again.
The first crack — on the tennis game Tiebreak — took Snacky nearly a full week: finding the IRQ handler, tracing the decryption logic, identifying which memory regions were being decoded in which order, and then either reconstructing the decrypted code or patching the game to survive without the live decryptor. Once that template was understood, subsequent TIMEX titles fell much more quickly.
Versions
TIMEX went through at least three versions. The earliest variant appeared in issues of Magic Disk 64 and Game On commercial disk magazines — protecting the magazine software itself. These used a simpler form of the raster-IRQ technique. TIMEX v3 was the most sophisticated. Radwar released the TIMEX v3 source code publicly in October 2002, with Mr. Cursor credited as original author.
The Track Offset Disk Component
Some TIMEX versions also used a disk-level component: a track offset across the entire disk. Rather than storing track N's data at physical position N, data is shifted so track N's content is at position N+k. A standard disk reader or emulator that maps physical positions to expected track numbers reads garbage from every track. NIBTools specifically documents and supports TIMEX v1 track offset handling in its d64→g64 conversion path.
Rubicon — TIMEX at Its Most Extreme
The most heavily TIMEX-protected game was written not by Ivo Herzeg but by Snacky himself — who, having cracked TIMEX, was contracted to protect Rubicon (Datasoft / 20th Century Software, 1991) using it. He improved v3 to close every attack point he'd found as a cracker:
I also added not only countless checks for the protection at the start and in the game; just the "Ending" of Rubicon alone was protected by more than 20 different routines that verified each other. Changing or removing one routine would end up in a crash later on. The beginning of Rubicon was protected by the TIMEX v3 system. But I improved the Timex v3 system slightly to close the "attack points" that I found when cracking this type of protection.
The Rubicon tape edition added a further layer: Snacky developed a custom turbo tape loader capable of loading 256-block files from cassette in under 30 seconds — a speed he described as unprecedented on the C64. The publisher's own industrial tape duplication machine (20th Century Software, London) could not reproduce his custom write format and contacted him directly for assistance.
Pete Rittwage added a physical disk-level detail from the preservation side: Rubicon's disk protection changed the rotational speed of the floppy during the protection read and de-adjusted the binary reading of the floppy header. The combination made it impossible for Burst Nibbler to reproduce. The manual re-sync check used a three-byte signature: "SKY" — an abbreviation for Snacky's name — embedded at a specific point in the header, which was then verified as part of the authentication. This was Rubicon's specific magnetic fingerprint: the only game that signs its own disk with its creator's initials as the unlock key.
This technique exploits a fundamental difference between factory-mastered original disks and copies made on a 1541. The drive has no index hole sensor, so when writing a track, the first byte is placed at whatever angular position the head happens to be at when writing begins. This position is random — and different every time.
Factory mastering equipment does use the index hole to precisely control the angular starting position of every track. This means on a genuine original disk, the angular offset between the starting position of track N and track N+1 is fixed and constant — every original copy of a given game has the same ratio.
The protection works like this: step to track N, wait for a specific GCR marker byte to pass under the head, start the VIA timer. Immediately step to track N+1. Count how many timer cycles elapse before a specific marker on track N+1 passes the head. On an original disk, this number is always the same. On a copy written on a 1541, both tracks started at random positions, so the timing is random.
64er magazine (Germany) documented a particularly robust three-track version: measure the timer ratio between markers on tracks N, N+1, and N+2. The ratio of these three timers must match a specific constant on the original. Even if a sophisticated cracker could fake one timer value, getting all three right simultaneously — without index hole hardware — is essentially impossible on a standard 1541. Antitrack (a scene cracker who annotated Pete Rittwage's Recollection #2 article) described the same method independently: "You can measure the angular difference between three tracks. You search for a special GCR mark on the track, you move one track ahead, also check for a special GCR mark, read the timer, and repeat three times. Thus you have three timer values. Their quotient must always be the same — if it isn't, you know that the angle between the GCR marks is incorrect and thus it's a copy."
A "signature" or "key track" is a track formatted in a non-standard way designed to trip up copy programs:
- All-SYNC track: The entire track is continuous $FF bytes — all 1-bits. Most copy programs enter an infinite loop waiting for the sync to end.
- All-zero / unformatted track: The track was never written, or was magnetically erased. No transitions, no sync marks, nothing. Copy programs either skip it entirely or lock up trying to read it.
- Specific byte sequence: An entire track contains one repeated specific byte or a known key sequence. EA's Pirate Slayer used a track filled with a particular pattern followed by a fixed authentication byte that keyed the next stage of the loader.
- Keydos (Activision): Simultaneously used all-sync, all-zero, and specific-byte signature tracks on different tracks of the same disk, creating multiple failure points for copy programs.
Para-Protect (used by GMA/SecuriSpeed and several System 3 titles) was notable for using completely standard Commodore DOS formatting for all data — not a single custom GCR byte in sight — while hiding the key on a non-standard track position. Last Ninja 3 (System 3) even listed "PARA-PROTECT" in its disk directory.
The protection checked a single track (or possibly a half-track) that existed outside the standard 35-track range, or at a half-track position. Because everything else was standard DOS, fast-copy programs that ignored protection would reproduce the disk perfectly — except for that one track. The game loaded fine from the copy, then failed the Para-Protect check at runtime and either froze, corrupted, or triggered an anti-piracy screen.
The deceptive simplicity of Para-Protect made it surprisingly effective. Several crackers spent considerable time on Para-Protect titles because the main data was so obviously and completely standard that the protection had to be elsewhere — but where? Track 40, as it turned out, using a signature track technique.
XEMAG (the company was also written "X-EMAG") grew directly out of Formaster, the pioneer disk duplicator manufacturer. Allen Cronce — whose brother Scott would later manage technology at Disclone — worked at Formaster before moving to XEMAG under Greg Galloway. XEMAG became the largest copy protection duplicator of the era, eventually being acquired by Dysan (a disk manufacturer), which then merged with Xidex Magnetics. The technological lineage is traceable: everyone who could write PDG disks came from Formaster in some fashion.
XEMAG 2.0 used a fat-track scheme almost identical to EA's early protection, but placed the overlapping tracks at positions 35/36 rather than 34/35. Interestingly, at least one XEMAG title — F-15 Strike Eagle — has the fat track on tracks 6/7 instead, showing flexibility in the method. A key difference from EA fat tracks: XEMAG disks are typically aligned about one-eighth of a rotation off the index mark, so they require SPLICE mode rather than INDEX mode when copying with modern hardware.
Like EA fat tracks, XEMAG disks exploit the fact that the 1541 has no way to track angular position relative to other tracks. Slowing the drive motor to 298.5 RPM or below has been found to allow both EA and XEMAG skew-protected disks to pass their protection checks — suggesting the check relies on a specific timing window that a slower drive widens sufficiently to make ambiguous reads consistently succeed.
Early Vorpal (sometimes called "Epyx Vorpal" after its principal user) is classified by preservation researchers as "sync counting/anomalies" — a fundamentally different approach from most protections. Rather than using non-standard data, it uses the number of sync marks on a track as a key. The standard 1541 controller ignores extra sync marks entirely, treating them as separators between sectors. Vorpal exploited this blind spot: it could write a track with a very specific count of sync marks, then verify that count by custom drive-side code that the standard ROM never executes.
This made early Vorpal particularly resistant to nibblers that faithfully reproduced all flux transitions: a nibbler would copy the sync marks correctly, but the drive motor speed variations from disk to disk would cause sync marks to merge or split on write, changing the count. Only a duplicate written at exactly the right speed on a calibrated drive could pass the check.
Later Vorpal escalated significantly. It combined three previously independent threats: a slowed drive motor (similar to V-MAX!), no-sync tracks (similar to Mindscape), and a track mastered to the index hole. The latter is the critical new element: by mastering to the factory index hole sensor, the angular position of every track relative to every other track is fixed at manufacturing time. Because a standard 1541 has no index hole sensor (it was removed to save money), there is no way to replicate this angular relationship when writing to a blank disk.
This meant that even a perfect bit-for-bit copy of every track — if written to a blank disk — would have subtly wrong inter-track timing because each track would start at a random angular position. Later Vorpal's protection check measured these inter-track timing relationships directly. Copying later Vorpal to a real disk requires writing in INDEX mode with a special XE1541 or XA1541 cable, and even then success rates are imperfect. It is one of the few protections that truly required specialized hardware to archive.
Rainbow Arts was a prolific German C64 publisher responsible for titles like Katakis, X-Out, and Z-Out. Their protection, often called RADWAR after a signature string found in the drive code, relied heavily on precisely calibrated motor timing — even more so than V-MAX!. Two distinct generations existed, sharing an approach but differing in implementation details enough that tools built for v1 often failed on v2.
The name "RADWAR" carries an important and often-missed detail: RADWAR was also the name of a prominent C64 demo and cracking group, and the protection was named after it — or by its members. Pete Rittwage noted in the C64 Preservation Project's Recollection #2 article that the protection is often referred to as "RADWAR/BETASKIP" and that "the RADWAR cracking group created a copy protection. Which is better known as TIMEX." This puts TIMEX and RADWAR protection in the same creative lineage — the people who became expert at breaking protections designed their own, drawing directly on that knowledge. This explains why TIMEX, which uses IRQ-timed runtime decryption, is so technically sophisticated: it was designed by people who had spent years reverse-engineering everything else.
RADWAR V1 is among the most timing-sensitive protections ever documented. Even VICE — generally considered the gold standard of C64 emulation — had confirmed problems with RADWAR V1 timing in versions 2.4 and beyond, causing games like Katakis to fail. The protection used track mastering aligned to the index hole combined with specific bit-rate adjustments, creating a check that was simultaneously sensitive to angular position and bit density. Magic Bytes (a sister/related label) used the same scheme.
Archiving RADWAR correctly requires using the -pm flag in NIBTOOLS to apply a special handler that adjusts how track 36 is remastered on output. Without it, the protection track is written back at slightly wrong timing parameters that look correct in the raw image but fail on real hardware.
Origins — PirateBusters Inc. The protection most commonly known as PirateSlayer on EA titles began life as PirateBusters, a separate commercial protection product developed by Kevin P. Pickell and Brian R. Niessen, with Kris Hatlelid joining the team after he and Brian theorised about an approach at a Toronto trade show. All three were former copy-program authors — "known breakers who thought there was a better way." Their understanding of the 1541 came from first principles: Brian organised a weekend at the University of Victoria in 1983 where a group of hackers disassembled the entire 1541 ROM set, while Kevin had obtained the source printout for the older 4040 drive through a contact at Commodore and worked backward from there (the 1541 firmware is closely related).
The first confirmed PirateBusters title is Beach Head II (Access Software), which identifies itself as PirateBusters 1.0FL on screen and names Pickell and Niessen directly. EA and Access Software were the primary licensees; Sydney Development also used it. The protection Kris Hatlelid developed for EA was internally called PirateSlayer — EA's branding for the same family of techniques applied at production scale.
How the no-sync track check works — the VIA timer mechanism. The core technique: a specific track is written with no sync marks at all. Without sync marks, the 1541's ROM firmware cannot find byte boundaries — it cannot read the track at all using standard methods. PirateBusters' custom drive-side code, loaded into the 1541's RAM, reads that track using the 6522 VIA Timer 2 — the timer that the standard DOS firmware does not normally use. The code loads T2 with a specific countdown value and opens a timed read window of exactly that many timer ticks. During that window, it reads raw bits directly from the disk head, bypassing the standard sync-detection logic entirely, and checks for a known byte pattern that was written to the track at mastering time. On the original disk, the pattern always falls within the timer window because the disk was mastered at a specific bit density. On a copy made by a serial nibbler — which never reads the no-sync track at all, because it has no sync marks to trigger reading — the window contains nothing and the check fails. On a copy made by a hardware nibbler that did reproduce the raw track, drive speed variance shifts the pattern's position within the window, causing intermittent failures. This is why PirateBusters/PirateSlayer copies were notoriously finicky: a copy might work on one drive and fail on another, depending on motor calibration.
EA's PirateSlayer expansion. Electronic Arts' later protection built significantly on this foundation. Rather than relying on a single physical anomaly, PirateSlayer combined multiple independent techniques: the no-sync track, signature tracks verified by custom drive code, and critically, some disks were mastered to the index hole while others were not. This inconsistency was itself a trap for copiers: tools configured for index-hole mastering would corrupt the non-indexed titles, and vice versa. The 22-block boot-loader — noted by Antitrack as "really a little bit nasty, for he's overloading himself several times" — used p-code (a virtual machine layer) and runtime-modified indirect jumps that made static disassembly nearly useless. Even after the disk-level protection was defeated, the cracker still faced a loader that rewrote its own jump tables while running.
PRODOS — the earlier EA system. Before PirateSlayer, EA used a related but distinct loader called PRODOS. Listed by Pete Rittwage alongside PirateSlayer as among the hardest loaders on the platform, PRODOS used a key signature track combined with complex self-overloading code and timer-based encryption. Games including Legacy of the Ancients, Arctic Fox, and Bard's Tale used PRODOS. PRODOS and PirateSlayer share the same conceptual approach but differ enough in implementation that parameters written for one do not work on the other.
A well-known example of the index-hole inconsistency: Skate or Die! is a PirateSlayer title that is not mastered to the index hole, making it copyable in SPLICE mode. Other PirateSlayer titles require INDEX mode. Because both exist under the same protection name, archivists adopted a "use SPLICE when in doubt" rule for the scheme.
Before PirateSlayer, Electronic Arts used a protection system typically called PRODOS in the scene. Pete Rittwage listed it alongside PirateSlayer as one of the hardest loaders on the platform. Where PirateSlayer (described above) used no-sync tracks and complex runtime self-modification, PRODOS was built around a key signature track combined with a heavily obfuscated multi-stage boot loader.
The PRODOS loader was known for "self-overloading" — its stages loaded each other into overlapping memory regions in a sequence that made static disassembly nearly useless. If you froze the machine after stage 1, stage 2 hadn't been placed in memory yet. If you froze after stage 2, stage 1's code had been overwritten. Following the execution path required tracing through five or more loading phases in sequence, each one decrypting the next. The drive-side component loaded into 1541 RAM and ran alongside the C64-side code; neither side made sense without the other in context.
PRODOS and PirateSlayer share the same conceptual EA design philosophy — both use a signature track verified by custom drive code — but differ enough in implementation that parameters written for one do not work on the other. PRODOS is generally considered slightly less complex than later PirateSlayer, but was still formidable for its era.
The 1541 normally steps the drive head in full-track increments, landing cleanly on tracks 1 through 35. But the stepper motor hardware is fully capable of stopping at intermediate positions — "half-tracks" between normal tracks — if the drive code commands it. Big Five Software (creators of Bounty Bob Strikes Back) and System 3 used these half-track positions to store key data or protection checks.
The mechanic is elegant: when a copier reads tracks 1–35 normally, half-track data is not retrieved at all — the head simply never positions over it. And the data it does read from adjacent full tracks is a blended signal: the head picks up interference from the half-track, producing garbage that looks like errors rather than hidden data. Early nibblers were completely blind to half-tracks because they never issued a half-step command.
Bounty Bob Strikes Back is the canonical example. Tracks 1–11 use half-tracks for protection data and must be copied with half-tracks enabled in the imaging tool. Tracks 12–35 are standard format. Track 12 additionally contains a byte-count protection check: the number of raw bytes per revolution is verified, and because this count depends on drive speed, a copy written from a drive spinning at a different RPM than the one it was read from will fail the check. This is why Bounty Bob copies were notoriously finicky — they might show the title screen but hang on the "Player 1" screen, which confused players into thinking the game worked.
Mindscape and Datasoft used an approach based on extremely long tracks — longer than what fits in a single standard GCR revolution — plus custom encoding that exploits the hardware behavior of the 1541's read electronics when there are no flux changes for an extended period. Recall that GCR encoding forbids more than two consecutive zero bits; if the drive reads a region with no transitions (a "blank" zone), the hardware will eventually lose sync and begin outputting a stream of zero bits. Mindscape's protection used this property as a key: it verified that a specific region would produce a specific number of zero-bit transitions in a row, a number that only occurs if the disk was written with the exact right blank-zone length.
These long tracks are also indexed-hole mastered at the factory, so they additionally benefit from fixed angular positioning between tracks. NIBTOOLS supports Mindscape via the -pm parameter for older Rainbow Arts/Magic Bytes variants (which share similar techniques) and via the long-track read handler for standard Mindscape disks.
DSI's protection on Pocket Writer 64/128 and Pocket Planner 64/128 has a strong claim to being the most stubbornly uncopyable protection ever implemented for the Commodore 64. From a 1999 comp.sys.cbm discussion, veterans of the C64 copying scene described it as follows:
You wanna try your skills on the most difficult protection ever created on CBM software? If so give the DSI programs Pocket Writer 64&128 / Pocket Planner 64&128. To my knowledge nobody ever had succeeded on these. Elite V3 did it but only to the extent that a full disk fast copier could duplicate them easily to another disk, but a type of non-standard tracking and sectoring remained which prohibits their use on CMD devices — Ramlink, hard drives, FD2000 or 4000 series.
— Joseph Fenn (aka Kilroy), comp.sys.cbm, October 10, 1999The DSI protection used non-standard track and sector geometry — the underlying physical disk layout deviated from the CBM DOS specification in ways that Burst Nibbler (even v1.9 PAL) could copy but not fully normalize. A copy that ran successfully on a standard 1541 still refused to work on CMD hard drives, RAMLink, or FD drives because those devices expected fully standard sector vectors.
Elite v3 (Kracker Jax) was the only tool that could reduce the protection enough for a fast-copy program to duplicate the disk, but even this left residual non-standard geometry. Maurice Randall (CMD) reportedly worked extensively on the DSI protection without fully resolving it. It is considered by veterans of the scene to be the final unsolved problem of C64 disk protection.
The C64 tape ecosystem — dominant in the British market — had its own parallel arms race completely separate from the disk protection scene. Turbo loaders loaded games at 5–10× the Kernal speed and wove copy protection directly into their encoding. The two dominant systems were Novaload (used by US Gold, LucasFilm Games, and Mastertronic across dozens of titles) and Speedlock (Ocean Software's standard tape format from the mid-1980s onward).
These have been moved to their own dedicated volume with full technical detail: the 6502 stack-poisoning trick that made Novaload auto-run without RUN ever being typed, the header-hiding technique that smuggled bootstrap code into metadata fields, Speedlock's two-tone square-wave encoding and why copying it on a standard deck distorted the timing, and how both systems are preserved today using TAP format flux capture.
Keydos was Activision's in-house disk protection system, documented by Pete Rittwage and named after a signature string found in the drive code. It is notable for a specific design choice: rather than using a single signature track technique, Keydos used all three main signature track varieties simultaneously on different tracks of the same disk. A typical Keydos-protected title had:
- One track formatted as all-sync ($FF filled — the "killer track" that causes copy programs to hang looking for data)
- One track that was completely unformatted (magnetically blank — no transitions, no sectors, nothing)
- One track containing a specific byte sequence used as an authentication key
The three-layer approach meant that a copy program had to handle all three correctly to produce a working backup. A nibbler that hung on the all-sync track never made a complete copy. A nibbler that skipped unformatted tracks missed one signature. A nibbler that copied the key-sequence track but reproduced it with slightly different timing failed the authentication step. Defeating Keydos required understanding all three techniques and applying different handling to each.
Activision also used the XEMAG fat-track service for some titles (documented under Fat Tracks / Wide Tracks above), and some titles combined Keydos signature tracks with XEMAG fat-track mastering — creating a dual-layer system where even correct signature track handling wouldn't produce a working copy without also addressing the fat-track component.
Further Named Schemes — From the preservation64.de Catalogue
The following protections are documented in the preservation64.de named protection catalogue. Entries with only a list of games and no technical mechanism description have been omitted; only protections with documented technical characteristics are included here.
CYAN Engineering's loader/protection system appeared in four documented variants (V1, V2, A, B) that evolved over roughly five years. The common thread across all variants is a custom sector layout combined with non-standard bit rates on specific tracks. CYAN's scheme pre-calculated a hash of the track header IDs in a particular order and verified that hash at load time; any nibbler that reproduced the sectors in a different sequence (because nibblers don't guarantee angular ordering) would produce a different hash and fail.
The name "CYAN" has a specific origin in the cracking community: it refers to the colour the C64's screen turns when the protection check fails. When a CYAN-protected title detected a bad copy, the machine crashed in a distinctive way that left the border and/or background in cyan — not the usual random crash garbage, but the same cyan, consistently, on every failed boot. This made it immediately identifiable to scene members who had encountered it before. Pete Rittwage confirmed this etymology directly in the C64 Preservation Project's Recollection #2 article. It is one of the few protection schemes named entirely from a physical observation of its failure mode rather than from its creator or a technical feature.
CYAN V2 and the lettered variants (A/B) added a gap-based component: key bytes were written into the inter-sector gap in a specific position relative to the sector header, and the loader verified both the byte value and the gap length (measured in VIA timer cycles). Standard copiers ignore gap data entirely, producing a clean but unprotected gap that fails the length check. CYAN's protection was notable for being used on titles across multiple publishers rather than being a single-publisher in-house scheme.
Ocean Software — one of the most prolific C64 publishers — used a tiered protection approach across their catalog that changed in sophistication over time. Early Ocean titles used simple bad-sector checks: sectors with deliberate CRC errors were written to track 35 or beyond, and the boot loader verified the error code returned by the 1541 DOS. Standard copiers that either skipped errors or normalised them produced disks that loaded but hung at the protection check.
Later Ocean releases moved to a more sophisticated scheme involving non-standard sector interleaving. The standard 1541 interleave for Zone 0 tracks is a specific skip value optimised for load speed; Ocean's protection disks used an unexpected interleave on the key track that — when copied by a sector copier using the standard interleave — reproduced all data correctly but at the wrong angular positions relative to each other. The loader timed the gap between consecutive sector reads using the VIA timer; a copy where the interleave was normalised produced a gap time outside the expected window and triggered the protection.
Rainbow Arts (Germany) developed three generations of their own in-house protection, distinct from — though related to — the RADWAR mastering service documented elsewhere in this document. All three versions shared the same basic architecture: a custom turbo loader that also doubled as the protection mechanism, so that the speed-loading code and the authentication code were intertwined and could not be easily separated.
Rainbow Arts V1 used a straightforward non-standard bit rate on the key track — the boot loader switched to Zone 3 timing on a track physically in Zone 0, making the raw GCR data unreadable to anything using standard zone-speed lookup. V2 extended this with a no-sync section on the same track: data was written without sync marks and read by raw bit timing, the count of clock transitions serving as an additional key. V3, the most sophisticated, added a drive RAM residency check — the loader verified that the 1541's zero page had not been disturbed by any pre-existing fast-loader or cartridge, which would abort the load with no error message, making diagnosis difficult.
GMA was a disk mastering and duplication service that issued a new protection variant each year, named by the year suffix (GMA85 through GMA92, with GMA91 apparently absent from the catalogue). The yearly update cadence was a deliberate anti-cracking strategy: by the time the cracking scene had fully analysed GMA85 and published parameters for common nibbler tools, GMA86 was already in the field, requiring a fresh analysis.
All GMA variants shared a family of techniques: half-track positioning (the key data was at a half-track offset), a custom sector format where the sector header used a non-standard gap length before the data block, and a drive-side verification routine downloaded into the 1541's RAM. The routine measured the physical rotation time from one sector to the next using the VIA timer and compared it against a hard-coded constant derived from the year-specific scheme. Each GMA year varied the half-track position, gap length, and timing constant, meaning parameters for GMA85 were useless for GMA87. GMA's SecuriSpeed branding appeared on some of these disks. The scheme is also related to Para-Protect (see above).
Kingsoft, the German publisher responsible for titles like Giana Sisters (early), Katakis, and numerous budget releases, used an in-house protection whose primary distinguishing characteristic was a checksum applied to the disk's BAM (Block Availability Map) on Track 18. The BAM is normally the first thing any copy tool reads; Kingsoft's loader read it too, but also verified that the checksum of specific BAM bytes matched a hard-coded value embedded in the loader code. A disk copied by a sector copier would reproduce the BAM data correctly, but the sector copier also normalised the BAM's allocation bits for the copy's own directory structure — altering exactly the bytes Kingsoft's checksum covered.
Some Kingsoft releases combined the BAM checksum with a bad-sector check on track 35, providing a two-layer system: the bad sector was checked first (failing obvious track-copying attempts), and the BAM checksum was checked second (failing more sophisticated sector-level copies). The protection was moderate in difficulty — the bad-sector component was trivially bypassed, while the BAM checksum required understanding which bytes were being checksummed and reproducing them in the copy.
Melbourne House (Australia / UK) developed a protection distinct from the Speedlock tape loader they are better known for on the Spectrum. For C64 disk releases, their scheme centred on a combination of extra tracks (beyond track 35) and a non-standard sector count on the key track. The standard 1541 Zone 0 (tracks 31–35) supports 17 sectors per track; Melbourne House's protection track was written with 18 or 19 sectors — the Zone 1 sector count used at a Zone 0 physical position. Because the drive's ROM uses the track number to select the sector count for reads, it would attempt to read 17 sectors and either time out or read partial data. The protection loader, running from drive RAM, used a hard-coded 18- or 19-sector count and retrieved valid data.
Preservation64 notes that Melbourne House's protection was particularly resistant to parameter-based nibblers because the protection parameter (sector count) was not exposed in the standard copy-program parameter interface — the nibbler copied the raw GCR correctly but then re-formatted the copy with the standard sector count, destroying the key.
Microprose's disk-level protection on C64 used a multi-layer approach that evolved across their catalog. The base layer was a bad-sector scheme with a twist: rather than a single unreadable sector, Microprose wrote multiple sectors with specific, different error codes on a dedicated protection track. The loader verified not just that errors were present, but that errors 20, 27, and 29 (in CBM DOS terminology: sync not found, checksum error, and write protect error) appeared in a specific sequence. A generic bad-sector copier that reproduced errors but normalised their types would fail.
Later Microprose titles (F-19 Stealth Fighter, Gunship, Silent Service) combined the disk check with the code-wheel physical protection documented in the code wheels section below. The disk component prevented casual copying; the code wheel prevented the cracker from simply patching the disk check, because removing it still left the in-game knowledge checks that the wheel answered. Both layers had to be addressed simultaneously to produce a playable crack — a significantly higher barrier than either alone.
The STP (Starbyte Protection) scheme V1.0 was used exclusively by Starbyte Software, a German publisher, and represents an interesting middle-ground approach. Rather than exotic non-standard formats, STP relied on a densely layered boot sequence. The disk contained a standard CBM DOS directory, but the first loader block loaded a custom secondary loader into the C64's RAM using a non-standard sector ordering. The secondary loader then downloaded a verification routine into the 1541's drive RAM. This drive-side routine checked for a specific number of sectors on a designated track — one more than the standard maximum for that zone — and verified that the extra sector contained a specific signature byte.
TIMEX's author Ivo Herzeg (Mr. Cursor) is associated with some Starbyte releases, which may explain a runtime decryption component found in some STP-protected titles that resembles early TIMEX — suggesting a technical exchange between the two systems. The STP scheme was not widely broken by generic nibbler parameters; it required specific analysis.
Teque Software (UK) developed and published numerous budget and mid-price titles under their own label and as a developer for other publishers. Their disk protection was relatively straightforward: a bad-sector check using CBM DOS error 20 (sync not found) on track 36 combined with a directory checksum that verified the number of directory blocks on Track 18. A fast copier would produce the correct directory checksum, but would fail on track 36. A nibbler that copied track 36 would usually produce a track 36 with different error behaviour than the original — sync-not-found vs. checksum-error — since the specific error type was verified by the loader.
Teque's scheme was considered moderate in difficulty for its era because the protection was on a physically accessible track using a known error type, but the exact error-code verification step was not obvious to casual copiers. Experienced parameter programmers needed only to reproduce error 20 faithfully on track 36 to create a working backup.
Timer Disk Protection refers to a family of schemes (documented as a named category by preservation64.de) in which the primary authentication mechanism is a revolution-time check rather than a data content check. The 1541's VIA chip provides two 16-bit timers. The protection loader started one timer running in free-count mode as the head arrived at a specific track, then initiated a read of one full revolution's worth of data. When the read completed, the loader latched the timer value. Because disk rotation speed is constant (300 RPM nominally), this timer value should be reproducible to within a narrow window — but only on an original disk. A copy written at slightly different speed (due to write head alignment, motor variation, or disk-to-disk variation) would produce a timer value outside the allowed window.
This was a clever approach because it operated entirely at the physical layer without requiring exotic sector formats — the data on the timed track was often entirely standard CBM DOS. Copiers that reproduced the data perfectly still failed because the copy's physical rotation timing differed from the original. The protection was, however, sensitive to drive wear and motor speed variation on legitimate disks as well, which made it one of the more commonly cited schemes for false positives on aged hardware.
Burst Nibbler — a parallel-cable nibbler that transferred raw GCR data from the 1541 to the C64 at nearly full disk speed using the user port — became so widespread and capable that some publishers specifically designed protections to defeat it. The Burstnibbler Protection category (as named in preservation64.de) refers to schemes that were specifically robust against the burst-mode transfer, rather than against slow sector-copiers.
The key weakness of burst nibblers was that, despite their speed, they still read data in angular order starting from wherever the head landed — they could not guarantee starting at the same angular offset as the original mastering. Burstnibbler-aware protections used schemes where the protection check was angular-offset-dependent: the key was not a byte value but a timing relationship between the angular position where a particular sector started and the start of the track. A burst nibbler copy would have all the correct sector data, but at shifted angular positions, changing all the offset-dependent relationships. The copy would load data correctly but fail the timing check.
The Cosmetic Disk Id protection is one of the simplest and earliest schemes in the catalogue. Every CBM DOS disk has a two-byte disk ID written into the BAM sector on Track 18 — normally a user-visible identifier like "AB" or "01". These ID bytes are also written into the sector headers of every formatted sector on the disk; standard CBM DOS verifies the header ID matches the BAM ID on every sector read, returning a "disk ID mismatch" error if they differ.
Cosmetic Disk Id exploits this by using ID bytes that are visually normal but contain a specific, unusual value (e.g., ID bytes using characters outside the normal displayable range, or a value that fast-copy programs reset to a default). A fast-copy program that reformatted the destination disk with a default ID and then copied sectors would produce a disk where the BAM says one ID and the sector headers say another — triggering ID mismatch errors on every protected sector. The check is trivial to understand once noticed, but many users never looked at the raw disk ID and spent considerable time wondering why "clean" copies refused to run.
syncr0l0k (stylised with zeros for the letters O) is a protection scheme in the preservation64.de catalogue that applies a sync-counting mechanism taken further than early Vorpal — not only was the number of sync marks on the key track verified, but their relative angular spacing was measured using VIA timer intervals. The scheme write a track with a precisely non-uniform distribution of sync marks: some close together, some far apart. The custom loader measured the time between consecutive sync leading-edges using free-running VIA timer counts and verified that the inter-sync intervals matched a stored pattern.
A copy produced by any tool that re-wrote the sync marks in a standard uniform distribution (as all sector-based copiers do) would produce equal inter-sync spacing, failing the pattern match. Even a raw nibbler that captured all flux transitions might produce slightly different spacing on the write due to motor speed variation. Only a flux-level copier (like those using Kryoflux hardware) that reproduced the exact bit-level timing could reliably copy a syncr0l0k disk.
XELOCK was developed by X-Ample Architectures — the same company as TIMEX creator Ivo Herzeg (Mr. Cursor) — and shares some architectural DNA with TIMEX while being a distinct product targeting disk-level protection rather than runtime decryption. XELOCK V1.0 combined a track-offset scheme (all protected data was stored at physical track positions shifted by a fixed constant, so track N's data was at position N+k) with a custom loader that knew the offset and corrected it at load time.
A standard copier, disk image utility, or nibbler that mapped physical tracks to their apparent logical numbers would produce a disk image where every track's data was associated with the wrong track number. The resulting disk would load the boot sector correctly (since the boot sector was at a known physical location), but all subsequent loads would request incorrect physical tracks and get garbage. Additionally, XELOCK included a VIA timer-based rotation check on the offset track, making it similar to the Timer Disk Protection category but with the offset as an additional layer. NIBTools' documentation specifically calls out XELOCK V1.0 as requiring manual offset correction when converting G64 images to D64.
The XROM System is a protection approach that leverages the 1541's own ROM as a key — a clever inversion of the usual approach. Rather than storing a secret on the disk that the drive reads, XROM stores a value in the loader that was derived from a specific byte pattern in the 1541's DOS ROM at a known address. The loader routine reads from the drive ROM at runtime (via drive RAM code that accesses the ROM address space directly), computes a result, and verifies it against the stored constant.
This made XROM inherently tied to the specific 1541 ROM version on which it was mastered. 1541 drives came with several ROM revisions; the protection would pass on the ROM version it was compiled against but might fail on other revisions where the targeted byte pattern differed. This also meant that emulators running the wrong ROM version would fail the XROM check even with a perfect disk image. The preservation implication is significant: archivists noting XROM-protected software must also document which ROM version the protection was designed for to ensure future emulation compatibility.
V-MAX! — Straight From the Maker
In a remarkable moment for the comp.sys.cbm Usenet group, Harald Seeley himself appeared in the thread in November 1999 to address questions about his creation. His posts — written 12 years after the protection's commercial peak — give us a rare first-hand account of what it was like to build one of the C64's most feared copy protection systems. Key details from that thread and additional technical analysis:
The Evolution of Seven Versions
V-MAX! went through at least seven versions from 1985 to the early 1990s. The earliest version — found on Star Rank Boxing and Diskmaker v3.3b — was primarily a fast loader. The copyright line "V-MAX! © 1985 by Harald Seeley" confirms this origin. From Forrest's analysis in the same thread: this first version was relatively easy to duplicate. It loaded from a specific track (typically track 20 on Thunder Mountain titles) using the EOR-streaming technique, which could be copied with tools of the day.
The protection became increasingly serious with each revision. Markus Brenner described the core technical difference between versions: early V-MAX simply read GCR data continuously and EOR'd consecutive bytes together for decoding. Later V-MAX fundamentally changed the data format itself, implementing a custom encoding scheme similar to RapidLok's "throw away every third bit" approach. The actual byte values stored on disk were not recoverable by any standard decoder.
The RAMBoard Problem
The v3+ era V-MAX required extra drive RAM — specifically, the 8 KB RAMBoard or Supercard expansion (which placed 8 KB starting at $8000 in the 1541's address space) — to duplicate. The standard 2 KB was insufficient to buffer the complex decoding. As "Radioactive Warrior" noted in the thread: RAMBoard was the only thing that would copy V-MAX v3. Burst Nibbler v1.9, even running PAL hardware for the correct timing, refused v3+.
RAMBoard was itself a clone of Megasoft's Supercard 8K board. Megasoft later redesigned the Supercard as "Supercard+" specifically to prevent RAMBoard owners from running Supercard software — suggesting the underground copying ecosystem was sophisticated enough to warrant counter-measures against the counter-measures.
The Fastload Incompatibility
V-MAX! had a side effect that became notorious among casual C64 users: virtually no fastloader cartridge would work with it. Epyx FastLoad, Final Cartridge, and others work by downloading a small program into the 1541's RAM before issuing a LOAD command. V-MAX! required precise control over drive RAM from the very first moments of boot — any pre-existing resident program in drive memory would corrupt the V-MAX! decoder. The game detected the conflict at startup and refused to proceed.
Cameron Kaiser described the experience: a peculiar sick feeling when seeing the blue "V-MAX!" boot screen appear, knowing that if a fastloader was active, the disk wouldn't boot. Some V-MAX versions were more tolerant than others — Defender of the Crown reportedly booted with Epyx FastLoad, while later titles like Arkanoid absolutely refused.
Professional Duplication Challenges
Harald Seeley noted that even professional disk duplication houses struggled with V-MAX!. The precision timing requirements, combined with the non-standard motor speed during recording on some versions, made it difficult to reproducibly master on industrial duplicators. This was an unusual situation: most commercial protections were specifically designed to be duplicatable by the publisher while remaining hard to copy by the public. V-MAX! later versions were so tight that they were genuinely difficult for everyone.
A 1984 View: Protecting (and Defeating) Your Own Programs
In 1984 — before the arms race escalated to custom hardware and bit-slice microcode — T.N. Simstad published the Program Protection Manual for the C-64 through CSM Software. Written for legitimate software developers, it documented every known protection technique available to a solo C64 programmer. Reading it today is a fascinating window into the era before industrial copy protection: a world where protecting a BASIC program required nothing more than a few POKEs, and where understanding the disk's Block Allocation Map gave you tools that no commercial copier had implemented yet.
BASIC Protection: Memory POKEs
The most accessible protection required no disk knowledge whatsoever. A BASIC program could disable nearly all diagnostic access to itself by writing values to specific memory addresses at load time. The table of key locations:
MEMORY LOCATION ORIGINAL PROTECTION EFFECT ───────────────────────────────────────────────────────────────── $01 (1) 55 00 Disable OS and BASIC ROM $2B-$2C (43-44) 01,08 20,09 Move BASIC start pointer $C0 (192) 00 200 Tape interlock (alternate) $C5 (197) current 239 Block keyboard scan $C6 (198) 10 225 Invalidate keyboard buffer $327-$329 (807) 237 230 Disable STOP key $328 (808) 237 237 Disable LIST / RESTORE $332 (818) 237 various Disable SAVE command
The most aggressive: POKE 1,0 disconnects the entire BASIC interpreter and Kernal ROM from the address bus, replacing it with RAM. The microprocessor immediately loses access to every OS routine and crashes completely — unrecoverable without a power cycle. Publishers used this as a "scorched earth" move: if the program detected a bad copy, it would execute this POKE before the user could interrupt execution or examine memory.
A subtler technique used the keyboard buffer (locations 631–641) and character count (location 198) to force the computer to auto-execute a command when a BASIC program ended. By poking a program name and RUN into the buffer, then ending with POKE 198,n, the next program would load and run automatically — enabling chained protection loaders where each stage verified the disk before handing control to the next.
Making Programs Unlistable
Several techniques prevented curious users from listing a BASIC program's source code without affecting execution:
Illegal BASIC characters. Embedding a character that BASIC's tokenizer doesn't recognize (such as Shift+L in standard character set) inside a REM statement caused a ?SYNTAX ERROR whenever the line was listed, while running normally. Listing to a printer — which forced output as raw bytes — was the only way to extract the hidden character.
Self-deleting lines. By typing a line number followed by a very long sequence of DEL characters before pressing RETURN, the line would appear in the program but instantly delete itself when listed, because the BASIC editor interpreted the DEL sequence during list output. The line executed normally when the program ran. This technique was "a little tricky to perform the first time" and required holding SHIFT+DEL for precisely 3 seconds.
Moving the BASIC pointer. Poking a new value into locations 43–44 (the "start of BASIC" low/high bytes) relocated the visible start of the program. Any code below the new pointer address was effectively invisible to LIST but could still be executed if control was transferred to it by ML code. This created programs that appeared to start at one address in the listing but actually contained hidden code in memory below.
Disk Error Checking — The Standard Template
The most common protection scheme available without special hardware: intentional bad blocks. A publisher would format a master disk with a specific sector left in an error state (most commonly error 21, "Read Error" — header not found). The program checked for this error at startup:
10 OPEN15,8,15,"I0:" ; Open error channel, initialize drive 20 OPEN5,8,5,"#" ; Open data channel 30 PRINT#15,"B-R";5;0;1;3 ; Block-Read: channel 5, drive 0, track 1, sector 3 40 INPUT#15,A$,B$,C$,D$ ; Read error channel (error number, message, T, S) 50 IF VAL(A$)=21 THEN 100 ; If error #21 present → jump to start of program 60 SYS 64738 ; Otherwise: RESET the computer ($FF2A = warm start) 100 CLOSE5:CLOSE15 ; Close channels [begin normal program execution]
The check worked because a normal copier would duplicate the sector's data but not its error state — the copy drive would write a valid sector to the copy disk, which then reported no error on read. Common error numbers used as protection keys: 20, 21, 22, 23, 27, and 29. Defeating this was straightforward: change line 50 to IF A$ <> "21" THEN 100 (inverted logic), delete line 60 entirely, or replace line 10 with GOTO 100 to skip the check entirely.
Track 18, Byte 2 — The Write-Protect Trick
One of the most elegant low-level tricks from the manual exploits the 1541's DOS formatting identification byte. Track 18, Sector 0, Byte 2 (the third byte of the Block Allocation Map) normally holds the ASCII value 'A' (hex $41). This byte tells the DOS the disk was formatted by a compatible drive. If this byte is changed to 'E' (hex $45), the 1541 interprets the disk as formatted by an incompatible drive type and permanently refuses to write to it — even though it can still read the disk normally.
'E' on startup — which a standard copy would not have, since copying recreates the BAM with the standard 'A'. Publishers could also use this to create a master disk that could never be accidentally written to during production, protecting the master itself. The modification could not be undone without reformatting (which would erase all data). Additionally, changing this byte to certain other values could make the disk both read- and write-incompatible with the 1541, creating a disk that worked on the original specialized duplicator but on nothing else.
Directory Manipulation — The Endless Loop
The 1541's disk directory is a linked list of blocks, beginning at Track 18, Sector 1. Each entry in the directory contains a pointer to the next entry (track number, sector number). If these pointers are modified to form a circular reference — Sector 1 pointing to Sector 2 pointing back to Sector 1 — the directory becomes an infinite loop. Attempting to list the directory hangs the computer indefinitely. The files on the disk remain perfectly accessible by name (since LOAD "filename",8 searches the directory but can handle the loop in some DOS implementations), but casual inspection reveals nothing.
The CSM manual's own companion disk was shipped with this trick applied. The directory listing was disabled; a note printed to the screen explained that the pointer modification needed to be reversed to make the disk listable. This was deliberately educational: showing purchasers exactly what protection had been applied, as a tutorial example.
The Developer's Dilemma — Protection vs. Legitimacy
Simstad's manual makes clear the tension that every C64 developer faced. Bad-block protection could cause real physical damage to end-users' disk drives — the read/write head pounding against the end stop during the block-not-found retry cycle. Simstad documents his own experience purchasing a $95 program whose protection scheme knocked his drive out of alignment and corrupted his data. His conclusion was pragmatic rather than ideological: the developer's right to protect their software doesn't relieve them of responsibility for the hardware damage their protection causes. He included an alignment utility and a "fix" that prevented many drives from going out of alignment — a rare admission in 1984 that the bad-block technique had real costs.
I cannot begin to tell you of all the people who, after trying to load one of these protected programs, have had their disk drives damaged. If you have not had your disk drive beaten out of alignment, just wait. Your turn is coming!
— T.N. Simstad, Program Protection Manual for the C-64, CSM Software, 1984Cartridge Protection — ROM as a Copy Barrier
Not all C64 software shipped on disk. A subset — particularly arcade conversions from Ocean Software and others — shipped on ROM cartridge. The assumption was that ROM was inherently uncopyable: you can't write to ROM with a standard 1541. But the cracking scene proved this wrong fairly quickly, because the key insight is that ROM only needs to be read once, after which it can be saved to disk and run from RAM.
The Standard Cart Crack — Dolphin DOS + Space Bar
The canonical technique, documented by Antitrack: switch off the C64, enable Dolphin DOS (or any other fast loader that ignores the CBM80 autostart vector), insert the cartridge, then hold SPACE while switching on. The CBM80 cartridge autostart routine fires at power-on, but a hardware reset via the RESTORE key or a correctly timed cold start interrupts it before execution. With the cart's ROM now sitting passively in the $8000–$BFFF window, a simple copy loop reads the entire ROM region to RAM and saves it to disk. Most early cart games don't use the RAM beneath the ROM address range, so loading the saved image and jumping to the start address works directly.
Ocean Software's early cart games used a bank-switching register at $DF01 to page between multiple ROM banks in the $8000–$9FFF window, providing more data than fit in a single 8 KB bank. The crack required iterating through all bank values, reading each 8 KB bank in turn, and assembling a complete memory image. Still straightforward.
TOKI — When Ocean Closed the RAM Loophole
Ocean eventually understood the weakness: if the game didn't need the ROM at runtime, the ROM was useless as protection. Their response with TOKI (1991) was to design a game where the code genuinely needed the ROM space at $8000–$9FFF simultaneously with nearly all of the C64's available RAM — leaving no space to host a substitute loader. The standard crack (save ROM to file, load from disk instead) failed because there was simply nowhere to put the file-loading code while keeping the game intact.
The German cracking group Legend spent three weeks on TOKI. Their solution: remove the in-game music entirely. The music routine was consuming approximately as much RAM as a ROM bank's worth of code — almost certainly deliberate, Antitrack noted. With the music gone, enough RAM was freed to host a custom disk loader, and the entire game was then relocated and rebuilt to use RAM instead of ROM, with standard files replacing the ROM data. After that release, Antitrack observed, Ocean appeared to give up on cartridge protection entirely.
It took Legend three weeks to reprogram and relocate the entire game, so it would use RAM instead of ROM and normal files instead of copied ROM memory, but they succeeded. After that, Ocean Software possibly gave up on cartridge protection.
— Antitrack, commentary on Pete Rittwage's Recollection #2 article, C64 Preservation ProjectPhysical Copy Protection Devices
Not all copy protection lived on the disk. Some schemes moved the lock off the disk entirely — into a physical object that had to accompany the software. The disk could be freely duplicated; without the physical device or document, it was useless. The logic was different from disk tricks: instead of making the disk impossible to copy, it made copying the disk pointless.
Lenslok was invented by John Frost, an electronics consultant, and marketed by ASAP Developments — a subsidiary of J Rothschild Holdings. Released in 1985, it was a small, flat, foldable plastic device containing a vertical row of prisms. When folded flat it was roughly the size of an audio cassette, designed to sit alongside a tape in a standard case. The first game to use it was Elite on the ZX Spectrum (Firebird Software, 1985). On the Commodore 64 specifically, it appeared on two titles: Elite (Firebird) and OCP Art Studio (Rainbird).
How It Worked
Before the game started, the software displayed a two-letter code on screen — but the code was scrambled. The display was divided into vertical bands which were then shuffled into a different order, making the text illegible to direct viewing. Holding the Lenslok device against the screen so that its prisms aligned with the scrambled display restored the correct band order optically: each prism deflected the light from its corresponding scrambled column back to its correct position, and the true two-letter code appeared readable through the device. The player typed in those two letters to proceed.
SCREEN (scrambled): [ C ][ A ][ D ][ B ] ← bands shuffled
↓ Lenslok prisms ↓
SEEN THROUGH DEVICE: [ A ][ B ][ C ][ D ] ← correct order restoredCritically, the device had to be calibrated to the exact screen size before use. The software displayed a sizing guide first — the player adjusted a bar until it matched the physical width of the Lenslok held against the screen. Only if the displayed image was precisely the right size would the prism geometry correctly unscramble the code. Each software title used a slightly different encoding method, and different titles came packaged with different Lenslok variants — so a device from one game might not decode another.
Why It Failed
The calibration requirement was the fatal flaw. The device could not be used at all on televisions that were either too large or too small — the on-screen image would be bigger or smaller than the physical device, making correct alignment geometrically impossible. Since most British households in 1985 were using a wide range of CRT televisions with variable picture sizes and focus quality, this ruled out a significant proportion of the user base entirely.
Approximately 500 boxes of C64 Elite were shipped with the wrong Lenslok variant — one calibrated for a different game's encoding. These users were permanently locked out of their legitimately purchased software with no remedy available. The instructions initially shipped with the device were widely described as confusing. Users received only three attempts to enter the correct code before the software reset — a serious problem on tape-based platforms where reloading could take ten or more minutes, though somewhat less catastrophic on the C64 with its disk-based version.
After a flood of complaints and returns, Firebird removed Lenslok from later pressings of Elite. The Elite Wiki assessed it with the same verdict applied to every subsequent DRM system: it caused undue annoyance to legitimate users while failing to prevent piracy. Cracking the Lenslok check required nothing more exotic than finding the branch instruction that checked the entered code and replacing it with NOPs. As one Lemon64 user recalled: "I went into the program and put no ops in front of the branch that did the security. After that I just had to hit enter three times and I was playing the game."
Lenslok was used in total on only 11 releases across all platforms. A LensKey software emulator (simonowen.com/spectrum/lenskey/), written by Simon Owen, accurately emulates the prism decoding for the supported titles, allowing modern emulator users to handle Lenslok checks without the physical device.
The code wheel was the most elegant physical protection of the era — and in many ways the most honest one. The game disk was completely standard and freely copyable. The protection lay entirely in a circular cardboard or plastic device packed in the retail box. The disk was useless without the wheel; the wheel was cheap to manufacture but (by design) difficult to photocopy.
Physical Construction
A typical code wheel consisted of two or three concentric cardboard discs fastened at the center by a brass brad, able to rotate independently. Each disc carried a ring of information — symbols, images, characters, numbers, or words — arranged so that rotating the discs brought different combinations into alignment through die-cut windows or alignment marks. The exact data encoded on the wheel was unique to each title and matched a lookup table embedded in the game's code.
Anti-copy engineering was built into the physical design. Wheels typically used dark background printing — dense black, dark blue, or brown ink — with light-coloured text or symbols. Standard photocopier technology of the era struggled to reproduce fine detail on dark backgrounds at the correct tonal range. Some wheels used multiple overlapping print layers in registration, so that a photocopy would fail to capture the alignment relationship between the layers correctly. The two-disc construction was itself a photocopying barrier: a flat photocopy of the outer disc gives you the outer ring; it gives you nothing about how the inner disc aligns with it. You needed both discs, printed correctly, and assembled with working brass brads — a meaningful practical obstacle for casual copying, even if not an absolute barrier.
How the Check Worked
At game start (or at a specific gameplay moment), the software presented a challenge: align a specific symbol, image, or value on one ring with a specific symbol on another ring, then read the value visible through the window (or where the alignment arrows met). Enter that value to proceed. Wrong answer: the game typically locked you out immediately, or in some designs imposed an in-game penalty without explicitly stating you'd failed the check.
The Microprose approach became particularly well-regarded for its elegance. Sid Meier's Pirates! (1987) didn't hard-lock on a wrong answer — instead, the game's opening "intro duel" became nearly impossible to win if you failed the pirate-history question. Players without the manual could still play, but from a severely disadvantaged starting position. This was the delayed-effect philosophy applied to a physical check: it didn't announce "WRONG CODE — ACCESS DENIED," it just quietly made the experience much worse.
Notable Code Wheel Designs
Dial-a-Pirate (The Secret of Monkey Island, LucasFilm Games, 1990) is the canonical code wheel and one of the best-remembered pieces of physical game packaging ever produced. The outer ring displayed upper halves of grotesque pirate faces; the inner ring displayed lower halves. The player rotated to match a complete face shown on screen, then read the year revealed through a window. Because the wheel featured hand-painted artwork and carefully designed face splits, a functional photocopy was essentially impossible — the value added by the physical object was inseparable from the protection it provided. Monkey Island 2 followed with the "Mix 'n' Mojo Voodoo Ingredient Proportion Dial," working on the same principle with a different theme.
Bard's Tale III: Thief of Fate (Electronic Arts / Interplay, 1988) used a code wheel as part of the dimension-hopping mechanic — players prompted to enter a number in response to four pieces of information, requiring the wheel's three independent concentric layers. The first two Bard's Tale games used PirateSlayer disk-level protection; the shift to a wheel for the third represented a deliberate design choice to move protection off the disk entirely.
Rocket Ranger (Cinemaware, 1988) shipped with a "Secret Decoder Wheel" themed to the game's 1940s aesthetic. Secret Weapons of the Luftwaffe (LucasArts, 1991) used an aircraft/nose-art wheel where a hole in the plane symbol revealed a woman's name to be entered. SSI's Gold Box D&D titles (Pool of Radiance, Curse of the Azure Bonds, etc.) used translation wheels tied directly into gameplay mechanics — certain in-game spells and abilities required consulting the wheel, making it part of the experience rather than purely a gate.
Bypassing Code Wheels
Code wheels were defeated by three routes. The simplest: the same NOPs approach used on Lenslok — find the comparison branch in the game's code and patch it out, which was straightforward for anyone with a monitor cartridge. The second: transcription. Because the code wheel was a finite lookup table, determined players could systematically work through all combinations by trial and error (or by running the game in an emulator's debugger), extract every valid answer, and publish a complete solution table. For games that only challenged on load, a few dozen tries was often enough to reconstruct the table. The third: high-quality scans and physical replicas. As home scanning and printing improved through the 1990s, accurate wheel reproductions became feasible — though many wheel designs were specifically engineered to resist this.
The code wheel's legacy is more positive than Lenslok's. When done well — Dial-a-Pirate being the exemplar — the wheel was genuinely delightful packaging that added to the game's atmosphere, its loss was noticed and mourned, and it provided meaningful if not absolute protection during the commercial window that mattered. The failure mode when a wheel was lost or damaged was severe: the game became unplayable. Online interactive reproductions (oldgames.sk/codewheel and similar archives) have solved this for preservation purposes.
A dongle is a small hardware device that plugs into a computer port — on the C64, typically the cassette/tape port or one of the two joystick ports. The game's loader checks for the dongle at startup; the dongle's presence is required to proceed. Because the check is a hardware handshake rather than a data comparison, there is nothing to patch on disk that produces a "correct" result — the game genuinely needs the physical device to be connected.
C64 dongles were passive devices — they didn't contain their own CPU or ROM. They worked by presenting specific electrical conditions on the port pins that the software could read. The cassette port (the CIA chip's FLAG line and CNT line) was the most common target: a dongle in the tape port would pull specific lines high or low, and the game checked the resulting bit pattern at a known address. Joystick port dongles read through the CIA registers at $DC00/$DC01. Because the electrical interface was simple and the validation code visible in memory, dongles were generally easier to defeat than disk-level protection — the check could be patched out, or a substitute device wired up.
Known C64 dongle titles (from community records): 10th Frame (tape port dongle), Leaderboard and Leaderboard World Class, Insta-Calc (some versions), Neutral Zone, Paper Clip (joystick port), Coco Coco 2. The Paper Clip word processor's joystick port dongle was notable for being particularly small and easy to lose — several users reported the dongle failing mechanically before the software was retired.