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.
Early bad-sector checks had a tell: the drive's head would audibly rattle as it retried the deliberately broken sector. Publishers noticed that users could hear the protection check happening. Later implementations read the error sector silently and only once, removing that giveaway. Copiers adapted in turn: even a sector with a bad checksum could have its actual data read and used — the checksum mismatch just meant the standard loader wouldn't accept it.
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.
EA's early fat-track check was loose enough that simply writing the standard tracks back cleanly was sometimes enough to pass it — the magnetic field from a narrow write naturally spread slightly into adjacent positions. Later and stricter fat-track implementations were less forgiving, and required professional mastering equipment to reproduce correctly. Consumer disk drives could not write a genuine fat track at all.
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 half-track data in the first place required professional mastering equipment — a standard 1541 could not reliably do it. This meant the protection could be read by a consumer drive with the right software, but not reproduced by one.
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 reads different parts of a disk at different speeds to make efficient use of the varying track lengths from the outside to the inside of the disk. A protection scheme deliberately wrote a track at the wrong speed — the track was physically there and readable, but any standard reader using the expected speed would get garbage. Only a custom loader that knew the "wrong" speed to use could decode it correctly.
An even more disruptive variant changed speed within a single track — partway through a revolution, the data was written at a different rate. No standard drive expected this, so the reader lost its place at exactly that point. The protection's own loader knew when to switch and handled it correctly. Because standard copy tools never looked for mid-track speed changes, this variant was almost invisible to them.
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 long track squeezes more data onto a circular track than fits in one full revolution of the disk — either by cramming it tighter or by slowing the drive motor during recording so more bytes could be written before the disk came back 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.
V-MAX!'s long-track implementation used a custom encoding scheme that decoded data on-the-fly as the disk spun, without needing to buffer the whole track first. This made the approach serve as both a fast loader and a protection mechanism simultaneously — standard copy programs failed because the track simply didn't fit in the drive's available memory.
On a floppy disk, a "sync mark" is a special sequence of bits that tells the drive where a new data block begins. Clever schemes exploit the gap 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. On original disks, this count is fixed at manufacturing time. On a copy, the nibbler might write slightly different numbers of sync marks, failing the check.
- 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.
- Framing Drift: A deliberately placed region on the disk causes the read electronics to lose their place — they can no longer tell where one byte ends and the next begins. Only the protection's own custom decoder knew how to compensate for this and read the data correctly.
Between sectors on a disk track, there is a small gap region that the drive fills with filler bytes during normal formatting. Standard copy programs throw this gap data away — they only bother with the actual data blocks. Protection schemes hid important key bytes in these gaps, which the game's custom loader read at the right moment.
One real-world example combined hidden gap bytes with data that was stored backwards on the disk. The gap bytes were used to decrypt the main data as it loaded — without them, the game's data was unreadable. Standard copiers missed the gap bytes entirely, so even a technically complete copy had no decryption key and couldn't run.
Gap protection lost its edge once more powerful copy tools emerged that transferred entire tracks at once, gaps and all. At that point the technique became just one layer among several rather than a reliable standalone barrier.
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 an important hardware difference that caught many users off guard: the original 1541 (and 1541-C) genuinely produced random output when it hit these blank regions — making the protection work as intended. The later 1541-II stabilised on a fixed output instead of going random. This meant a weak-bit protection that passed on an original 1541 would fail its own protection check on a 1541-II — because the drive consistently returned the same bytes, which the protection read as a sign of a copy. Legitimate owners with a 1541-II found their own original disks wouldn't load, through no fault of their own.
Every sector on a standard disk has a unique identifier. Normally a disk reader, upon finding the first sector with the right ID, stops looking. Nothing prevented a disk from having the same sector ID appear twice on the same track — the hardware simply didn't forbid it.
A protection scheme exploited this by writing two sectors with identical IDs on the same track. A standard loader or copy program saw only the first one and ignored the second — it was effectively invisible. The protection's custom loader skipped past the first instance and went specifically for the second, which contained the actual key data. Standard copy programs reproduced only the first sector, leaving the hidden second one missing from any copy.
Some schemes extended this across multiple tracks, placing a secret sector at the same logical address on two different physical tracks. The standard loader picked up one; only the custom loader knew to look for the other. Defeating it required copy tools that reproduced every sector on a track without any filtering — raw track copiers rather than sector-by-sector ones.
RapidLok, developed for Accolade, was one of the most technically demanding protections of the era — and one of the most speed-sensitive.
The protected tracks used a custom encoding format that was completely unreadable to any standard disk reader — only RapidLok's own decoder, which was downloaded into the drive's memory at load time, knew the correct way to read them. The directory track was kept in standard format so the disk would boot normally, but everything after that was RapidLok's own private format.
After downloading its decoder, RapidLok read an authentication key from a hidden track beyond the normal range of the disk. The key's position was timing-sensitive — the loader had to read it at exactly the right moment as the disk spun. This is why RapidLok was famously drive-speed-sensitive.
The key's position was so timing-sensitive that if a 1541's motor speed was even slightly off, the head would be in the right place 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 1999Copying RapidLok required tools that specifically understood its format. Generic copy programs would produce a disk that appeared fine but silently missed the key — the copy would seem to work but crash or refuse to load protected content.
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. The disk was formatted in a custom streaming format that the drive decoded on-the-fly as it read. This was fast but not especially hard to copy once you understood the approach. Pete Rittwage noted that Star Rank Boxing was more devious than it appeared — it contained additional protection checks that fired randomly during gameplay, meaning a cracker who removed only the boot-time check would still encounter crashes mid-game.
Take Down Wrestling — the most extreme V-MAX! v1 variant. Among the hardest V-MAX! titles to crack, it ran decryption code simultaneously on both the computer and the disk drive, with the two machines passing data back and forth to decode each other's routines on the fly. This mutual decryption phase lasted roughly 30 real-world seconds — the disk spent nearly half a minute doing nothing but running a cryptographic handshake before any game code was ever loaded. Cracking it required reverse-engineering both sides in parallel, as neither made sense without the other.
Versions 2–3 (1986–1987): Added non-standard data encoding on certain tracks, making those tracks unreadable to anything using standard settings. Defender of the Crown, Bop N Rumble, and Howard the Duck used this era. Most V-MAX games of this period would refuse to load with a FastLoad cartridge inserted because the protection required clean, empty drive memory to work.
Versions 3+ (1988 onward): The version people remember and fear. The drive could run and decode the data normally, but copying it required more working memory inside the drive than a standard 1541 had. To copy this version at all, you needed a RAM expansion board for the drive. 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, 1999Vorpal 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 firmware can't find where data blocks begin. Vorpal's custom decoder read data purely by timing — counting the rhythm of magnetic transitions on the disk rather than looking for the usual signposts. This was technically demanding to implement and even harder to copy.
Early Vorpal also hid key bytes in the normally-ignored gaps between sectors. Later versions added non-standard data encoding on top of that. The combination made Vorpal one of the more respected protection systems of its era.
TIMEX was created by Ivo Herzeg (scene handle: Mr. Cursor), a German freelance programmer who also designed the 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 that ran continuously in the background while the game was playing.
Game code was stored on disk in encrypted form. When the game loaded, a small background routine began continuously decrypting memory as the game ran. The game never existed in its readable form all at once — it was only ever decoded a piece at a time, in step with the running game.
This was a fundamentally different kind of protection. A byte-perfect disk copy was useless without the decryption routine, because the code loaded from it was just encrypted garbage. And the standard approach of freezing the machine with a cartridge and examining memory didn't work either — freezing caught the code in a half-decoded state that made no sense.
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 protecting commercial disk magazines. 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 shuffled the entire layout of the disk — every track's data was stored at a physically different position than a standard disk reader would expect. A standard copy tool would read the disk and get complete garbage from every track, because it was looking for data in the wrong places.
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 (20th Century Software, 1991) using it. He improved the system to close every weakness he'd found while cracking previous versions:
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 tape edition of Rubicon added a custom loader so fast that the publisher's own industrial tape duplication machinery couldn't reproduce it. 20th Century Software had to contact Snacky directly for help manufacturing their own game.
The disk edition added a physical signature unique to Rubicon: a three-letter code — "SKY", an abbreviation of Snacky's name — was embedded in the disk at a specific point and verified as part of the authentication. It is the only game known to use its creator's initials as the unlock key for its own copy protection.
On a factory-mastered original disk, every track starts at a precise, fixed rotational angle relative to every other track — because the pressing machine used a physical reference hole to align them all. A home disk drive has no such reference; it just starts writing wherever the disk happens to be when you press go, which is different every time.
The protection measured the angular relationship between specific points on two or three different tracks. On an original, this relationship was always the same fixed ratio. On any copy written without a reference hole, the tracks started at random positions relative to each other, so the ratio was random. Getting all three timing values right simultaneously without factory equipment was essentially impossible. Antitrack described the method: "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.
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.
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 closely related to EA's early protection, but placed the overlapping tracks at different positions. At least one XEMAG title — F-15 Strike Eagle — placed the fat track at an entirely different part of the disk, showing the technique was flexible. Like EA fat tracks, XEMAG disks relied on a timing relationship between tracks that a home disk drive had no way to reproduce.
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 fail, because each track would start at a random angular position rather than the precise factory-aligned one. Later Vorpal was one of the few protections that truly required specialized hardware to archive at all.
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, causing games like Katakis to fail. The protection combined factory index-hole alignment with non-standard data encoding, making it sensitive to both the angular position of tracks and the density at which they were written. Magic Bytes (a sister/related label) used the same scheme.
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 worked. A specific track was written with no sync marks at all. The standard drive firmware was completely unable to read it — without sync marks, it couldn't find where data began. PirateBusters' own code, loaded into the drive's memory, read that track by timing alone, looking for a known pattern that was placed at a precise location during factory mastering. On an original disk, the pattern was always in the right place. On a copy made by a standard nibbler — which simply never copied the no-sync track at all — the check found nothing and failed. On a copy made by a more advanced tool that did reproduce the raw track, subtle drive-speed differences shifted the pattern just enough to cause intermittent failures. This is why PirateBusters/PirateSlayer copies were notoriously unreliable: a copy might work on one drive and fail on another.
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 factory index hole while others were not. This inconsistency was itself a trap for copiers: tools configured for one approach would corrupt the titles that used the other. On top of all that, the boot loader — noted by Antitrack as "really a little bit nasty" — ran its own code through a virtual machine layer and modified itself as it ran, making it nearly impossible to analyse statically. Even after defeating the disk-level protection, a cracker still faced a loader that was actively rewriting itself while executing.
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. 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 tools built for one would not work on the other.
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 loaded its stages into the same memory areas, overwriting each previous stage as it went. If you froze the machine at any point, you only ever saw a fragment — the earlier stages were already gone, and the later ones hadn't arrived yet. Following the full execution path required tracing through multiple loading phases in sequence, each one unpacking the next. The drive-side and computer-side components each depended on the other; neither made sense examined in isolation.
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. The first portion of the disk uses half-tracks for protection data. The rest of the disk is standard format. One track additionally verified how many raw bytes of data a full disk revolution contained — a number that depended on the exact drive speed. A copy written on a different drive would have slightly different timing and fail this check. This is why Bounty Bob copies were notoriously finicky — they might show the title screen but hang on the "Player 1" screen, confusing players into thinking the game actually worked.
Mindscape used extremely long tracks — longer than a single revolution of the disk — combined with deliberately blank regions that caused the drive's read electronics to produce a predictable stream of empty output. The protection verified that a specific region on the disk produced exactly the right length of blank output. This only worked if the disk had been written with exactly the right blank-zone length at the factory. Combined with factory index-hole alignment for fixed track positioning, Mindscape disks were very difficult to archive accurately.
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.
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 data encoding on specific tracks. The loader verified that sectors appeared in a specific order as the disk spun — any copy tool that reproduced the sectors in a different sequence would fail the check.
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.
Later CYAN variants added a gap-based component: key bytes hidden in the gaps between sectors, with the loader verifying both the value of those bytes and precisely how long the gap was. Standard copy programs threw gap data away entirely, so the copy had no key and the gap length was wrong. CYAN was notable for being used across multiple publishers rather than being a single company's 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. The sectors on the key track were laid out in an unusual order — not the standard arrangement a copy program would use when writing a copy. The loader timed how long it took to read consecutive sectors; on an original disk with the unusual layout, the timing fell in the expected window. On a copy where the sectors had been written in the standard order, the timing was wrong and the check failed.
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 non-standard data encoding on the key track, making it unreadable to anything using standard settings. V2 extended this by adding a section of the track with no sync marks at all, read by timing alone. V3, the most sophisticated, added a check that the drive's memory hadn't been touched by any cartridge or fast-loader — if anything foreign was already present, the load silently aborted with no error, making the problem extremely hard to diagnose.
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: key data stored at half-track positions, sectors with non-standard gap lengths, and a custom verification routine that measured the rotation time between sectors and checked it against a fixed expected value. Each yearly version changed the half-track position, gap length, and timing constant — so tools built for GMA85 were useless against GMA87. GMA's SecuriSpeed branding appeared on some of these disks.
Kingsoft, the German publisher responsible for titles like Katakis and numerous budget releases, used an in-house protection based on a checksum of a specific part of the disk's directory structure. The loader verified that a specific region of the disk index matched a hard-coded value. A sector copier reproduced the data correctly, but also quietly adjusted the directory for its own use — altering exactly the bytes the checksum covered, causing the check to fail.
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 centred on extra tracks beyond the normal range combined with a key track that held more sectors than the drive's standard firmware expected for its physical position. The standard firmware, looking for the wrong number of sectors, would time out or read partial data. The protection's own loader knew the correct sector count and retrieved valid data.
The protection was particularly resistant to standard copy tools because they would copy the raw data correctly but then reformat the copy with the standard sector count — destroying the key in the process.
Microprose's disk-level protection used multiple sectors with different kinds of deliberate errors on a dedicated protection track. The loader verified not just that errors were present, but that specific types of error appeared in a specific order. A generic bad-sector copier that reproduced errors but homogenised their types would fail the check.
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. Rather than exotic non-standard formats, it relied on a layered boot sequence. The disk had a standard directory, but the loader used non-standard sector ordering to load a secondary loader, which then downloaded a verification routine into the drive's memory. That routine checked for a specific extra sector on a designated track — one more than standard — containing a specific signature value.
Ivo Herzeg (Mr. Cursor), creator of TIMEX, is associated with some Starbyte releases, which may explain a runtime decryption component found in some STP-protected titles that resembles early TIMEX. The STP scheme was not broken by generic copy tools; it required dedicated analysis.
Teque Software (UK) used a straightforward two-layer protection: a deliberately broken sector on an extra track combined with a checksum of the disk directory. A fast copier would pass the directory check but fail on the broken sector. A nibbler that copied the broken sector would usually reproduce a slightly different kind of error than the original, which the loader distinguished and rejected.
Experienced copiers could produce a working backup by reproducing the exact error type faithfully — but casual copiers typically produced the wrong kind of error and wondered why their copy didn't work.
Timer Disk Protection refers to a family of schemes where the primary check was a revolution-time measurement rather than a content check. The loader timed how long it took to read one full revolution of a specific track. Because disk rotation speed was meant to be constant, this time should be the same on every original. A copy written at a slightly different speed — due to drive variation, motor wear, or simply a different drive being used — would produce a timing value outside the allowed window and fail.
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.
Even though burst nibblers were fast and thorough, they still started reading from wherever the disk happened to be at that moment — they couldn't guarantee starting at the same rotational position as the original factory mastering. Protections designed against these tools used timing checks that depended on where sectors appeared relative to each other rotationally. A burst nibbler copy had all the right data, but each sector sat at a slightly different position on the disk, changing those timing relationships. The copy would load but fail the 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) took sync-counting further than early Vorpal. Not only was the number of sync marks on a track verified, but their spacing was measured — how far apart each pair of marks appeared as the disk spun. The track was written with a deliberately uneven distribution of sync marks: some close together, some far apart. The loader measured the time between each pair and verified that the pattern matched exactly.
Any copy tool that wrote the sync marks in a standard even distribution would fail the pattern check. Even raw copy tools that captured all magnetic transitions might reproduce them at slightly different spacings due to drive speed variation. Accurately copying it required flux-level hardware that could reproduce the exact original timing.
XELOCK was developed by X-Ample Architectures — the same company as TIMEX creator Ivo Herzeg (Mr. Cursor) — and is a distinct disk-level protection rather than a runtime decryption system. XELOCK shifted the entire layout of the disk: every track's data was stored at a physically different position than you'd expect. A standard copier mapping tracks normally would get complete garbage, because it was reading everything from the wrong place.
A standard copier would load the boot sector correctly (it was at a known location), but everything after that would be requested from the wrong physical track — producing garbage. XELOCK also included a rotation timing check on top of the offset scheme, adding a second layer that a copier had to get right independently.
The XROM System used the 1541's own built-in ROM firmware as a key — a clever inversion of the usual approach. Rather than hiding a secret on the disk, XROM read a specific value from the drive's own internal firmware and verified it against a stored constant. If the firmware value matched, the game loaded. If not, it refused.
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. Early V-MAX used a simple on-the-fly decoding trick that was breakable once understood. Later V-MAX fundamentally changed the data format on disk, using a completely proprietary encoding that no standard decoder could read — only V-MAX's own drive-side code knew how to interpret it.
The RAMBoard Problem
The v3+ era V-MAX required extra drive RAM — specifically, the 8 KB RAMBoard or Supercard expansion — 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.
Physical 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
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. 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 chip or circuitry. They worked by presenting specific electrical conditions on the port pins that the software could detect. The tape port was the most common target, with the dongle pulling specific lines to expected states. Joystick port dongles worked similarly. Because the electrical interface was simple and the check code was 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.
K-dos is K as in Kaminski-dos and not Keydos