Interview with the Creator of 21 Second Backup
Conducted by Milasoft · Published Lemon64 Forum · March 2022
The 21 Second Backup Story
The 21 Second Backup was one of the most technically remarkable — and most impenetrable — disk copy utilities ever produced for the Commodore 64. Released in the mid-1980s and distributed by VG Data Shack, it used a parallel cable between the C64's user port and the 1541 drive to achieve disk copies in a fraction of the normal time. But it was the protection on the original disk itself that made it legendary among the copy-protection community: spiral tracks, consecutive zero-byte tricks, and a decryption system tied to the 6522 timer that defeated virtually every other tool of the era.
For years, the author was known only by name from the disk itself — Charles Leborgne.
Creator of 21 Second Backup and Super File Copier for the Commodore 64. Distributed via VG Data Shack. Active approximately 1984–1986. Origin: Quebec, Canada.
Questions & Answers
I had some personal projects on PET, Vic-20, and later on on Amiga. Nothing that went out of my bedroom.
They were the distributors — no relation otherwise.
Not lucrative at all money wise. Educative though.
I don't remember clearly. For sure there is no 4.3.
I used my software extensively — I never had any issue. Hard to tell what went wrong. To consider: there were many 1541 drive generations with varying hardware tolerances.
Yes — it used a spiral track with consecutive zero bytes writing.
I also used another strategy: writing consecutive zeroes, then re-reading — it had to come back random. Writing three or more consecutive zero bits made the read result potentially random. A copier would copy the false "ones" and the result would no longer be random on the copy.
That is precisely why Commodore used a 4-to-5 bit encoding scheme in the first place.
It was just writing while stepping. Reading back, it would first find a sync block and step at the same place. That part was easy to code.
What I recall is that all the logic occurred after decryption. I don't remember if I had specific logic to check for the cable. And yes — everything was written at 300 rpm.
For the protection, I made sure it would take some time to crack. The decryption key used the 6522 timer, and the decryption code itself was constructed so that attempting to step-debug or placing a breakpoint would cause the decryption key to fail.
"HI FOLKS! CALL VG'S DATA SHACK TO KNOW MORE ABOUT THE 21 SECOND BACK-UP. IT GOTS ALSO THIS AMAZING PROTECTION. CHARLES LEBORGNE — ALLO PIRATES! VOUS NE DEVRIEZ PAS ETRE ICI, MAIS J'ESPERE QUE VOUS AVEZ EU DU PLAISIR A Y ARRIVER. CIAO!"
For sure I did not write that — I was not proficient in English at that time. Nothing to do with me.
Nope — nothing rings a bell here.
I wrote a 2-to-3 encoding scheme that avoided skipping sectors while reading — very tight assembly coding. There was no writing while skipping, but after skipping, the next sector had to be right there. That certainly made copying arduous if you didn't know that detail.
Nope.
I have nothing.
Since then I have been renting my brain to the most offering. Nothing glorious.
— Milasoft
Community Responses
The following responses are from the original Lemon64 thread, March 21–22, 2022.
I was hoping he'd have more to tell. The protection he was able to put together on his tools was very impressive. I would have liked to know how he tested and did troubleshooting given the intricacies — drive code and transfer routines can fail under normal conditions with little indication as to what went wrong. With what he was doing, it could be a total mystery.
The only "consecutive zeroes" I've seen on his products were on the spiral track. They aren't checked specifically; the tracks are just wiped before the protection data is written so that there's no interference from neighbouring data. Perhaps he used this on earlier revisions? I can also confirm that the protection track on later releases did indeed use a drive running at a slower speed. The text in the protection came from the Super File Back-Up and Utilities program — if he didn't write it, then someone he worked with on that program did.
It's very difficult to remember things from long ago. I look at code I wrote even a few years ago, and it's like someone else did it.
Same here. I am a sucker for all the details.
So who's from Quebec? Because that's where I live and the city can be small — who knows if we know each other.
I'll admit when I read his answers, I was disappointed. I wanted a novel to read, but as suggested, perhaps it's been years and maybe there wasn't much to say. All things considered, I thought it might be a good read for those who are fascinated by it.
Boy, do I know that feeling — looking at old cracks I did back in 1987 and 1988, it's like somebody else did them. I found one of my "cheat" sheets folded and tucked inside a floppy sleeve and all the code I wrote for file loading after capturing the data looked like gibberish. But it made sense back then. Lost too much sleep and had to take an extra half year and summer school just to get enough credits to graduate. No regrets at all — way too much fun, running a crack group and a BBS.
What BBS and group and where was it located? I called boards all over, which didn't make my wallet happy when the bill arrived — nor my parents. I love reading about all the different boards and groups out there; those were such fun times.
How the Protection Worked
The Spiral Track System
The 21 Second Backup's protection was layered in ways that defeated virtually every contemporary tool. The core techniques, now confirmed by the author and elaborated by community experts, were:
- Spiral tracks — Data was written while the drive head was physically stepping between tracks. The resulting data arc (e.g. tracks 10 → 10.5 → 11 → 10.5 → 10) could only be reproduced by a tool that also stepped in the same sequence during writing — something no generic nibbler of the era did.
- Consecutive zero bytes — Writing long runs of zeroes to the magnetic surface exploits a property of FM/GCR encoding: three or more consecutive zero bits become potentially random on re-read. A copier would lock in the false "ones" it read, producing a copy that looked correct but failed on verification.
- 6522 timer-based decryption key — The main program's decryption was tied to the CIA 6522 chip's hardware timer. Attempting to step-debug through the code, or placing a software breakpoint, altered the timer's state and caused the key to fail — making the disk appear blank or corrupt to anyone trying to analyse it.
- 2-to-3 bit encoding (Speed Load) — A custom encoding scheme for fast loading avoided sector skipping by requiring the next sector to be immediately in position after the head stepped — making any copy that didn't reproduce this precise timing fail silently.
- Unique per-disk personalisation — Each physical copy was apparently written with slightly different track patterns, meaning no two originals were identical and comparison-based cracking approaches could not produce a universal bypass.
Why It Stumped the Best Tools
Jim Drew — whose SuperCard Pro is among the most capable C64 preservation hardware ever built — confirmed that neither the Kryoflux nor the SuperCard Pro could successfully copy the 21 Second Backup original. The program could not copy itself. This was not a limitation of those tools' general capability; it was a consequence of the spiral-track write strategy being physically unreproducible by any tool that treated the disk as a static medium rather than a dynamic one.