Author of that DisC=overy article here. Very happy that I managed to write it clearly and concisely enough for someone to find a use for it approximately 26 years later. :) Also, kudos for using CLC + BCC [address of the BCC] for a tighter infinite loop rather than BCC'ing back to the CLC like I did back in the day. Can't remember my rationale for it, but I probably wanted to make absolutely sure nothing messed with the carry-flag before I got to invoke the machine code monitor of my Action Replay cartridge.

I learned more about cracking software in these 30 minutes than my entire childhood using a C64. Great video.

One possible reason for the jsr instead of a jmp is to allow the game to check if it was indeed called from the loader by checking the return address on the stack. I don't recall which one, but one of the tape based games I cracked in the 1980s did that, and was from what I recall also using novaload.

That has got to be supremely satisfying to restore a broken game to the authors' intent -- lots of youtube channels restore hardware, very few restore software. :) I'm spoiled by the VICE debugger, and was missing having actual breakpoints when recently using the Super Snapshot V5 to disassemble some lightgun code on real hardware. I did the same thing as you, injecting my own infinite loops to create breakpoints (as you did with the "CLC, BCC $02BD"). That said, I was downloading cartridge manuals yesterday and found that both Action Replay and Retro Replay support breakpoints (up to 5, apparently?), and that the KCS Power Cartridge lets you step through live execution (like VICE) with its "walk" command. I haven't tried these out yet, but I will soon (these images all come on the Ultimate-II cart -- yeah, I know, not original hardware. :) ) Anyway, another great episode of exactly the kind of stuff I (and I'm sure others) love to watch. Thanks!

Floppy disk protection took this sort of thing to the next level. It was an ever-escalating arms race between the hackers and the software companies. From what I understand, cartridges basically had no copy protection because they felt it was not necessary (special hardware needed).

Terrific / informative video. The Super Snapshot cartridge sure is powerful ! I removed the CD/DVD checks from dozens of games I owned back in the 1990's / 2000's, because I got sick and tired of hunting for the game box (somewhere in a wall of boxes), getting the CD/DVD out (and risking damaging the game box as I opened it), putting the disk in the drive, etc every time I wanted to play a game. Even if you had an image of the original CD/DVD on your hard-drive, it often would not be pass the "valid disk" check. The process of removing the CD/DVD check involved tracing the running game in assembler and working out the best way to remove the disk check, and then create a patch to apply to the original game so I could remove the CD/DVD check anytime I wanted in the future if I uninstalled and then re-installed the game years later on.

Absolutely Great video :) It's so amazing to look at the whole process of defining protection and fixing the game! I can imagine how long this actually took to figure it all out and how many trials and errors, great job!

That string starting in 0877 “CUANDO QUIERAS…..” at 20:59 means “whenever you want” or “whenever you’re ready”. Great content as always Robin

I wanted to learn this with my C64 when I was young but never had that external tool and information was not as easy to get as nowadays (only books). Kinda enjoyed to watch this and still miss those days when programmers was actually squeezing the most out of the computer instead of just bloat nowadays.

Thanks for the excellent video @8_Bit! I remember more than a few years ago learning a little bit about interrupting disk fast loaders/auto starters from TLR, but it seemed to be considerably more complicated due to the fact that the disk drive isn't just a dumb device. Much more difficult to digest than this. Thanks again!

Wow! After all this years I finally know what is behind these great crunchers and packers. I always wondered how someone was able to develop it in the early c64 ages.

I so very much enjoyed watching this and how you worked through the process. I used to have an Amstrad CPC464 back in the day and was so jealous of my friends with C64 and their wondrous cartridges that allowed them to do all this cool stuff. Keep up the great videos.

Absolutely love this in-depth series.

As someone who's spent a fair bit of time analysing tape headers, this was brilliant! Thank you for the excellent video 😊

Another masterful episode. Still a bit over my head in skill level, but who knows, maybe one day.. Now that I have a little time to devote to (re)learning my favorite platform, I hope it gets easier in the near future. Just the fact that I can actually follow along is a good sign. 🙂 Having these videos of yours handy while embarking on this journey has been a HUGE help though. I can't wait to see what you do next.

Oh cool! Thank you for posting this. This is literally what I asked for on the last video! I'm stoked to watch this episode :D

Novaload had to be one of the most common of fast tape loaders, created by the late Paul Woakes of Novagen, and the classic games Encounter and Mercenary.

One more great video Robin! I learn SO MUCH watching your videos! Thanks!

Very interesting and well explained. I've never seen boot tracing applied to a tape game. What a treat!

One game I recall reading about how hackers had a hard time cracking it. They thought they had cracked it, but then the game was unbeatable etc... and they didn't notice this until after they released their crack for it. The reason being is that the developer purposely placed checks in their code to detect hacks and they still let the game run, but they altered certain aspects of the game so it could not be completed. I actually tried this out on my own game (Deluxe Pacman 2 for the PC) where I put in fake variables that were not important and I had code to detect hacks and cheats, if one was detected, I would alter the game so it was easier to get killed, you got a MUCH lower score and it wouldn't let you put your name on the high score list. It was fun to code that way and I had someone who had put out a cheat hack for my game (it wasn't needed, I had ways to cheat built in). I just always wanted to do that. Fun times... for me anyhow. :)

Amazing job !! And you also keep the old tools available right then.. that makes this video even more enjoyable.

Nicely done. It was cracking my favorite C64 game that got me interested in computer security. Been doing that now for 35 years.

All so cool. Looking forward to a full playthrough video. :)

I loved your two videos on this peculiar situation. So much so that I published a video of my own in which I fix a TAP file of the original game, preserving its turbo loader, Novaload.

Really nice and informative video Robin using some proper old-skool methods of tape cracking. :D

Fascinating! Iremember Novaload from back in the day. I always wondered how interactive routines such as "Invadaload" worked, which played the "One Man And His Droid" theme while displaying a perfect;y acceptable Space Invaders clone while the game loaded. I guess that's not just another video, but another series altogether.

Now you need to make a cracktro😅

Brilliant detective work, amazing to watch, thank you very much!

So good, I love the depth of information.

Fasicinating to watch, and flippin well done :)

This was a huge part of my childhood, thanks for making me relive it! But you have to pack it first, then crunch 😅

Great video and well explained, fascinating the tricks that were used.

Another masterclass, thanks for sharing 😀

Great video. I used to do a little cracking on the Amiga when I was a kid so it was fun to see that some of the principals are effectively the same. Also Kudos for using period correct tools :D

Really enjoyed this video. Great content. It was so interesting to see the techniques employed by the original coders to fast load/protect C64 games. I still wonder how the coders built up this knowledge about the C64 operations before the internet. I remember reading books about the C64 like the Programming Reference guide but for me it didn’t really connect the dots between how the C64 worked and what could be achieved through creative programming.

I am so impressed with your skill and knowledge!

I saw that your fix was used by the C64 scene to spread fixed versions of the game. Good stuff.

Great video Robin, thanks for sharing! I really enjoyed watching the process broken down from loading the fast loader without allowing it to auto start, then disabling the auto start of the game and finally insert the fix and slim down the result. Especially given that cartridges like the Action Replay (and perhaps Super Snapshot?) could have allowed you to load the game, patch it and then dump the memory contents to disk (in the case of AR it could even install its own Turboloader to speed things up, saving the crunching step)... I prefer learning how to do it than taking the fast route and not seeing under the covers :) Since the Novaload is a reusable autoloader, perhaps it JSRs to allow the game to do some initial setup, change another vector somewhere and hand back to the autoloader for some additional functions before starting the game loop?

Robin will be the first person ever to finish the game on a c64. Well done 👍👍

You Sir, are a very smart and patient man. Thoroughly enjoyed this episode and am eagerly awaiting a tape remaster episode. You have earned yourself a well deserved cup of tea ;( yes im British lol. take care and enjoy your new fixed/patched game. also, will you be making this fix available to us less smarter/patient folks? Dave.

Nice shot of nostalgia and well explained... back when things were so much simpler...😋

Another fantastic and educational video, thank you!

avid fan here, I LOVE LOVE these videos so much, especially as you're using authentic hardware to do the cracking too

As a young kid, before I could afford a freezer cartridge, I bought a program through a magazine ad that allowed you to "backup" a few games that used common tape loaders including early versions of Novaload. I can't remember the name of the program, but I'm sure it was written by the late great Tony Crowther (although my searches have drawn a blank on any info). At least now I have a better understanding of how it must have worked, intercepting then modifying the loader so that once all game data had loaded you could save a backup.

I'm not sure how well understood this is in Leftpondia, but in the European demo scene, the slash means "of"

I always used "Freeze Machine" back in the 80's which had a 14 second disk drive load time & you could save to tape but not as fast (but it was loaded before about 45 on the tape counter!), saved loads of time waiting for games to load.

thanks, another great video, managed to follow along on my TheC64 with no problems! :)

Boy the Livingstone theme sure is relaxing.

Very interesting video. I haven't seen a tape fastloader game cracked before. Now the next level would be cracking a game which uses multiload, like Creatures 1. :) But I guess that was not cracked from tape to disk, but rather the disk version was cracked directly. There were also games which were transfered from cartridge to tape or disk. That would be again something very interesting to see how it was done as you have the cartridge port occupied with the game and you can't use a snapshot cartridge. Especially with game cartridges using bank switching.

Fascinating. I remember playing this game on my MSX as a kid. I wouldn't be too surprised if I still have it in a drawer somewhere. I never owned a C64, but I would be very interested in learning how the fast loader works. On an MSX the defaullt baud rate was already 1200 and could be bumped up to 2400 from within basic. I think the maximum reliable rate was around 4800 baud, but I know Philips published a game collection on an audio CD that contained the games recorded at 9600 baud. However, the BIOS handled most of it. The "speed settings" were just a bunch of parameters in system RAM. Encoding and decoding is done at a hardware level using an op-amp and some resistors and capacitors.

Cool video, eventhough I don't have a clue what you're talking about. All that codestuff is really something I don't understand. :)

Melancolia, gracias hermano ♥️

On the subject of tape fastloader "Mr. Z turbo" is really fascinating, and it was endemic in Europe at least. In the 90s I learned that Zoltan Kelemen (Mr. Z) was a Swede.

Long ago I made a game in Javascript that was intentionally unwinnable. It was hacking themed game. No matter what you did the computer would cheat and you would loose. Naturally being a hacking game the only way to truly win the game and see the end credits was to hack the code. Which is why I chose Javascript in the first place. Most people just assumed it was bugged and gave me a bad review even though the code made it obvious what you had to do and the "you lose game over" taunts from the computer strongly hint at it. Anyway videos like this make me think that if I remade it in a compiled language then at least Robin would enjoy it. :-)

Thank you for this video. 👏 Now, I could get my game "Turbo Esprit Challenge" from cassette to disk. It has a multiple loader. Without having a Snapshot 5 cartridge, I had to use my "C64 magazine (German) ML monitor S-MON" to disassemble the code.

Glad you mentioned ECA Compactor -- that was my tool of choice for this type for compacting and linking work! I remember using ECA for an "intro" I added to several download programs looooong ago🙂. More recently however, I found an old sid/interrupt-driven music player I wrote in the 90s. It consisted of a small assembly routine to play the music, a BASIC front-end to load/start/stop the music, and a custom character set I borrowed from some software. All of that was compacted and linked in one executable so the individual components didn't need to be loaded in an adhoc fashion. I was initially only interested in the BASIC listing of the program and couldn't figure out why I could only see the BASIC program in memory after the program had run. Why would I put such complex copy protection that would fool future-me? One of the local C= club members immediately pointed out the de-compacting routine and it all came back me.

Ah those packers and crunchers. I had to beg Strider from Fairlight to let me have one of theirs, it was not widely distributed back in the day, it was a closely kept secret by the warez groups. heh

What a nice video! Very instructive..

That took me back a bit :-) I got a 1541 to use with my expanded VIC-20 in 1985. Needless to say very little VIC software was available on disk, so one of the first things I wanted to do was transfer tape based software onto disk. Many titles used similar tricks to load and auto run programs. Typically loading into the the small block of RAM below the system vectors (the buffer started lower at $02A1 on the VIC). They would normally run off the end of the buffer, and overwrite the BASIC warm start vector at $0302. That would immediately run the stub loader program when the system completed the load and attempted to return to BASIC. Most games could be ported just using the VICMON cartridge to load main program, and then save it to disk. Then you needed to re-write the stub loader to load from device 8, (and also usually add a system call to SETNAM to specify a name of the file to load - tape games typically did not bother to do this). I would then use the same vector trampling trick in my loader so that just loading the stub (with a ,8,1 to force it to not relocate) would auto load and run the main program from disk. A few titles would load code into screen RAM - so on those you could not manually do the move in the monitor since the screen interaction would corrupt the code. For those you needed to write some assembler to automate the load and save so that the screen RAM was not altered in the process. The irony was that with some games, the challenge of working out how to get it working on disk was actually more fun the playing the actual game! Not to mention learning loads about how all the technology worked.

Nice video! Just missing crack intro! 😁

Oh the feeling of satisfaction when you make a clean kill like this 🙂Now we just need a janky intro with potty-mouthed scroll text... Greetings to Robin...

My mate had a C64 back in the day (I had Spectrum and 800XL). He had a disk drive and cartridge (some sort of freeze frame or action replay) and he would be forever "packing" his pirated games onto disk, which bemused me at the time. Fascinating stuff, back in the day you could have a job with Fairlight.) We used to have work farmed out to us by a group (cant remember the name) but we all had handles from Star Trek. My mate was Mr Sulu..... I used to hand draw the art work for cracktros and he would add the scrolly text things and music. Fun days.

One of my games was cracked from 4 disk sides down to only one, with nothing cut, and faster loading; quite amazing.

The development support code looks like a couple of different things that got layered on top of each other. I think the earliest part was a BASIC program that looked something like: ... 1 IF A=0 THEN A=1:LOAD "RS232-CBM",8,1 2 POKE 248,200:PRINT"CUANDO QUIERAS .......":SYS 828 (where 'cuando quieras' is Spanish for 'when you want') It looks like that basic program got overwritten with a short ML routine which changed banks with interrupts off, then called kernal functions to open a file, call it PRUEBA.BIN, then save memory to the file, then changed banks with interrupts off again. Then that got stomped with a basic NEW command to zero out 0801-0802, plus a couple of other random clobbered bytes.

Really great video!!

I've had a look at the KERNAL routines you used to load from tape. Someone's done some clever investigative work here to figure out how to load a tape file.

I love the Commode Security _patch_ :)

This reminds me of buying Spy Vs. Spy on disk back in the day and being disappointed that my Epyx Fastload cartridge did nothing to speed up its very long load time. I figured out that the game was loading into low memory and was thus overwriting the disk routine vectors with the original values rather than the ones being used by Fastload. So with a disk sector editor I went in and changed the vectors in position within the file to the Fastload ones. I wound up with a game that loaded much faster but would only work on a computer that had the Fastload cartridge plugged in. Considering I rarely took it out that was fine by me.

Very interesting, many thanks for sharing. 😊

Super interesting. I've never really looked into any of this. One question I have though is if there are KERNAL load routines like you showed in this video, but for disk instead of for tape?

Oh yes, this is fascinating! While technically not cracking, which literally means circumventing the copy protection, the skills required for this would have enabled one to crack games back then as well - and not just 8-bit ones that fit in a couple dozen KB's. But just as well with 16-bit DOS games. I had a whole load of copied games between pre-teen and teen years. Most were cracked - the copy protection was always some question you needed the actual manual or accessory, but people were very inventive in copying them. But they were often quite cumbersome, and one game I had to pick the correct image of a character in the game and I didn't have any other way than to start the game again and again until I guessed right :D I now realize that I would have had the skills, but it never dawned to me - I was too much into simply make my own creations :P

It's amazing you are able to learn all this. I was totally lost after you put the cassette into the player and pushed the button. Then you talked about casting spells (isn't that what a hex is?) and nibbling at something? I am so glad I was born stupid! So well done, but after 7 minutes I need to come up for some air and pay some space invaders. I understand that!

Really interesting. Thank you!

Story from my C64 cracking days. One fastloader used an exclusive or command on each byte from the tape so it was garbled data on the tape that was changed before storing it in RAM. The loader loaded several parts, each with a header with a start and end address. Several parts was just one byte with the address on the immediate byte of the EOR command. Effectively making the next part having data, including the start and end address being encoded differently. Other times it loaded a single immediate byte into the loop counter for the wait branch until reading the next signal from the tape head, effectively changing the speed of the data from tape for the next part. So to crack these games you had to read in one and one part to see what happened, is it game data or some more protection code?

Thanks for sharing your genius hacking, Robin!

I wasn’t around during the tape loading era but was still interesting to watch

Seeing the execution of code in screen memory brings back some memories😊

Thanks to your suggestions I improved the cracking speed... Spy hunter craked and modded to be C64 GS compatible. 🤩

Your fill value of 0xBB does make a lot of sense. It's not even a standard 6502 opcode.

wow i had wanted to crunch some programs thanks for showing that process.

Chotaire was around in the 90s when I was an uni, used to catch up regularly with him on IRC :)

I'd love to see a deep-dive from you showing how C64 "loaders" work exactly, specifically how they speed up the loading

Without the game crackers scene and "software archiving", I would not still be involved with computers today. We couldn't afford to buy the games but myself and many friends used to copy games from an older friend who i think even had the internet way back when, because he seemed to have basically all games :D

What if you tried pressing the "stop/restore" combo during that colorful screen (at least right when it reaches a time that you know it would be done but before the software starts running in a way that may disable stop/restore?

Fascinating video! .. About fastloaders: I wonder how many of us "liberated" the fast-loader from commercial software to use on our own programs? (Disk fastloader in my case, from one of the disks which came bundled with my 1541, modified slightly to point at my own program). I used my Action Replay for this, which is currently plugged into one of my C64Cs.

Great job 👏

Yarr a pirate, Harry!

You need to add a “cracktro” ….. just put the thanks to the patrons bit you have at the end of the video:)

I could have never achieved this as a kid - I just used a Final Cartridge III to save a running game to disk after loading from tape - it was a long time ago and didn't work with every game - probably due to what you mentioned in some previous video about the memory range used by the freezer cart. Not that I knew! if memory serves some games would work if I froze them just as they finished loading - perhaps I captured them in a decrunching state that didn't occupy the freezer range at that moment (it was usually games from magazine tapes so likely using compression)

Strange that the NOVA load didn't load compressed data that is then decompressed before the game runs. This could have made the load time even shorter. It would be interesting if you could convert your crunched file to use NOVA load tape and see what the time difference would be or maybe modern tape loaders could be faster than the old NOVA load.

4:09 Can't the Super Snapshot just save all RAM to a disk file? 24:15 Can the monitor SAVE the RAM under the Kernal as well? 29:52 You'd think something like this would be built into the Super Snapshot.

They had a shop in Sheffield in the early 80s. You could walk in and try the games out before release.

My name was there on the screen as Jans article was a reply to an article I wrote in the issue before :) I have also done episodes on cracking and compression: Tape cracking kzfaq.info/get/bejne/ZquaarKDrde-f4E.html kzfaq.info/get/bejne/sMucpat5tKu2nKs.html Crunching kzfaq.info/get/bejne/arJngpSV07yviYE.html kzfaq.info/get/bejne/abKVo7qlvdXdenU.html

You have featured many games that I knew about, some that I have played, others that I haven't.. Do you have anything on other games that I've spent the most time in: Seven Cities of Gold, Pool of Radiance, and F-19 Stealth Fighter? I realize it's a long shot, and I can't think of anything that really stood out in those that would make a great episode, but if anyone can do it, you could, Robin.

The Phil Collins byte 😂😂

Am I right in guessing that the reason the packers and and crunchers work well is because the target is a game with lots of what amount to bitmaps?

13:00 If the Stop Vector is called after each *byte* is read from the cassette, it will be called the first time when only half of the vector is overwritten. It will write the low byte first (presuming the data stream is in natural order).

ive been wanting to understand how to fix c64 stuff for a while, my favorite xmas tradition is playing John Henry's Christmas Carols but the d64 from the web has some graphical errors with some of the images and it seems like it might have protection on it, but some of the bad images hurt my heart cause its a tradition going back to when i was 6 or 7. i have the original disc and not sure if it is still good but id expect id be able to compare code between them to get 1 best copy. something for a future project i guess lol

@24:00 LOL, welcome to my world. Hours and hours of head scratching and staring at code usually to find one character/byte causing the issue.

Please I would like more videos of this kind