Cracking a C64 Game From Cassette: Livingstone, I Presume?

[@janlundthomsen]

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.

[@BG101UK]

That machine language monitor in the Action Replay has certainly been handy for nobbling bits of code from other software and modifying it to suit! I could really do with one for each machine!

[@Codetapper]

What's the reason behind using those CLC instructions vs a jump to itself? On the Amiga I would just put a branch to itself by writing $60fe, so I'm wondering what's different on the C64 if you have 3 bytes available anyway?

[@damienretro4416]

@@Codetapper If the code gets moved, the JMP will still point to the old memory location...whereas the CLC and BCC are relative to the current memory location.

[@Codetapper]

@@damienretro4416 Thanks, that makes sense, although in this case the code is not going to move. It seems very strange to me that there is no BRAnch instruction on the 6502!

[@janlundthomsen]

@Codetapper What @damienretro4416 said. Using the machine code monitor to key in a JMP $XXYY would require me to know the address of those 3 bytes. Since BCC uses a relative offset, I could key the hex values ($18, $90, $FD) straight into the memory-dump without thinking. :) And if I would ever run into a protection scheme that moved the code, it would still work.

[@xorfive]

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

[@jonathanwright1507]

about 10 years ago I got a C64 & read the basic book & understood what all the data numbers meant. When I was 13 (1985), I did not really understand the book, just copying the data to make a basic program work.

[@BillAnt]

IKR?! hehe Ah the advantage of modern times and tools. Interestingly the tape drive wasn't very popular here in the US like elsewhere in the world including Canada. I don't remember seeing any for sale in stores back in the 80's, only disk drives.

[@xorfive]

@@ProgNoizesB I'll admit. I was a dumb kid.

[@8_Bit]

Tape was common even in the US if you got into computers early enough. It was a very common format on the VIC-20 in 1981 and that spilled over to the Commodore 64 for the first couple years from 1982-1984. Until 1984 it was easy to find C64 games on tape in the US, and then very rapidly everything switched to disk only.

[@BillAnt]

​@@8_Bit - Well that explains why I didn't see many/any software on tape here in the US after 1984 when I got my first C64. heh

[@c128stuff]

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.

[@DavidYoud]

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!

[@8_Bit]

With Super Snapshot the "BR" command should set the breakpoint vector, and then BRKs should trigger it. I don't know how that compares with the AR/RR method, I'll have to try it sometime. I wonder how the KCS walk will work; it should be fine for "pure" 6510 code but any code that interacts intensely with I/O like the VIC-II, SID, or CIA is bound to have problems as they continue to "tick" away like clockwork unlike VICE which is able to stop all machine functions. The Epyx Fastload monitor has a decent step feature, but again, it's really only good (in my opinion) for debugging non-I/O routines.

[@chrismason7066]

That's why whenever someone messes with me. I spoke 53280,0 their a$$ and they dont mess w me anymore! All hail the poke 53280,0

[@cactuslist]

@@8_Bit you can add intro to this game with trainer+ (poke these opera stuff where needed) and/or maybe show us different fastloader routines :)

[@BillAnt]

​@@8_Bit - Robin, I was wondering if you ever came across of a game or other program which had an auto-run disk-loader protection against the use of SuperSnapshot or other freeze cartridges? In other words, can a disk-loader automatically run a piece of code early on during loading to disable these cartridges, specifically the NMI/IRQ lines?

[@janlundthomsen]

I knew about the “SF” breakpoint command in the Action Replay machine code monitor, but for a while I alternated between the Action Replay and the Expert Cartridge so I picked something that worked on whatever freezer cart I was using. Turned out to be beneficial for the purpose of the article, too. :)

[@JustWasted3HoursHere]

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).

[@geoffreysummerhayes4793]

I remember. Some loaded code on the 1541's buffers. There was one I couldn't figure out. I think it had "dragon" in the name. It started by loading into the ROM area and rolled over to 0000 where it turned the ROM off. It was also full of the undocumented opcodes. Still bugs me, I wish I knew how it worked.

[@JustWasted3HoursHere]

@@geoffreysummerhayes4793 If I remember correctly, "Bruce Lee" was one of the hardest games to crack back in the day. Usually new games would be cracked within a day or two (or even BEFORE they were released; so-called "zero day" cracks, usually by someone on the inside), but Bruce Lee, at least on the C64 took almost a year. It's almost 40 years later so the details might be a little fuzzy though! One floppy scheme actually had physical holes on the floppy disk that could be steered around if the original loader code was present, but if someone replaced that code with their own, the floppy head would go ripping through the disk and it would be destroyed. Luckily this extreme type of copy protection didn't hang on very long. Funny thing about copying software is that you are legally entitled to make 5 backup copies of your software, but the software companies are not obligated in any way to make that process easy!

[@gamingSlasher]

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.

[@NNokia-jz6jb]

Same. It is amazing what the C64 can do with just 64KB of memory. Full applications, full games. Crazy.

[@MarianoLu]

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

[@MarianoLu]

And after all these years we have a cracked and Fixed disk version of Livingston Supongo!!

[@mikegarland4500]

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.

[@eugenetswong]

It is very much over my head, but I am really grateful. Robin, I doubt that you'l read this, but thank you!

[@figurehead1971]

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.

[@astraton2001]

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.

[@NeilRoy]

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. :)

[@SteveGuidi]

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.

[@markmaker2488]

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

[@MrRobbyvent]

Whoever played the original Spanish version could end it

[@markmaker2488]

@@MrRobbyvent i thought it was only on the other platforms like the amstrad that weren’t corrupted 🤷‍♂️

[@xotmatrix]

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

[@8_Bit]

I haven't heard the term "boot tracing" before, it's a good one! Is it a common term with Apple II hackers?

[@xotmatrix]

@@8_Bit Maybe it is Apple II parlance. It's the standard cracking method on the Apple II, just like you showed, modifying each stage of the boot sequence to load the next one and saving it to disk, until you've unlocked everything. Tools like Super Snapshot existed (eg. Senior PROM) but are generally not needed thanks to the Apple II's built-in monitor routines, and if one is careful with rebooting after moving data out of critical areas. Because of the way Apple II disks work (entirely software-defined I/O), boot tracing is an ideal way to get the program to crack itself stage by stage. Nowadays, software exists that completely automates the cracking process, namely Passport by 4am.

[@MyAmazingUsername]

Yarr a pirate, Harry!

[@LordmonkeyTRM]

Now you need to make a cracktro😅

[@mercuryvapoury]

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.

[@talideon]

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

[@Hacker-at-Large]

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

[@kaeriks]

What game was it?

[@TheKetsa]

Absolutely love this in-depth series.

[@JosipRetroBits]

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!

[@iancolquhoun]

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!

[@jonathanwright1507]

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.

[@OscarSommerbo]

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.

[@bmartin427]

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.

[@TJWood]

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.

[@allenhalsted4895]

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. :-)

[@BillAnt]

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

[@lockone1977]

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

[@byteforever7829]

Another masterclass, thanks for sharing 😀

[@brianstuntman4368]

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.

[@thasinister]

That would be very interesting but it could be lost media.

[@whalt]

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.

[@AzagXul666]

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

[@ozwalled2007]

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

[@simonscott1121]

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

[@markwrightrf]

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...

[@eekee6034]

I love the Commode Security _patch_ :)

[@kilbabaplays8944]

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

[@johnrumm4786]

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.

[@classicnosh]

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

[@trelard]

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

[@robsku1]

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

[@8_Bit]

The auto-running and fast-load features of C64 cassette games are a form of copy protection: as I show in the video, you can't just LOAD and then SAVE (ie copy) this game. Removing the auto-run and bypassing the fast load and turning the game into a single regular Commodore file allows it to be copied with the regular LOAD and SAVE commands not only on cassette but also to and from disk. So now it's cracked or de-protected or whatever one wants to call it.

[@etansivad]

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

[@dataroger]

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?

[@stefanfriedt3450]

They did a lot of weird things back then. I rember a tape loading the fast loader after every 1k or so to a different memory location. Today most times you only have to convert the tape to a tap file and can extract the individual parts with tapclean so you only have to find the start adress.

[@singletonjohn7339]

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

[@williefleete]

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

[@StatMatsVidz]

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

[@vlg_bcn2812]

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

[@TheHighlander71]

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.

[@no1leader135]

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.

[@creativesamurai8372]

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.

[@petesapwell]

Fasicinating to watch, and flippin well done :)

[@BG101UK]

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.

[@chrisdixon5241]

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?

[@JohnDlugosz]

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).

[@rhialtothemarvellify]

That's why the low byte is the same.

[@Breakfast_of_Champions]

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

[@TotallyAqua]

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.

[@HoffmanYouTube]

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

[@coldobajose]

Melancolia, gracias hermano ♥️

[@SledgeFox]

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

[@Mmouse_]

This is why these obscure text files from way back when and even geocities websites from later on should be saved and be searchable... Things like that aren't really created any more, and it makes me sad... I made a few myself but they were about obscure electronics. I wonder if there's a way to do all of this on completely stock hardware of the time. I'm sure there is. "there's some trial and error involved" haha much of modern hacking is glitching low voltages to an Ic at just the right time - proof of concept might be a little micro button, and you press it to drop a voltage around where you think is the right place... Then after weeks it works once at 2am and you wake your wife and newborn up shouting YES!

[@magnustveten492]

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

[@csbruce]

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.

[@8_Bit]

Yes, Super Snapshot can freeze or "snapshot" all RAM and most I/O state to a disk file. This process includes some level of "crunching", somewhat out of necessity, as otherwise the file size of the full 64K + I/O would be excessive. Using this process, while useful, isn't considered a "true" crack (at least by those in the "scene") because it typically restores the game state already in the process of running; the music is already playing, VIC and CIA interrupts may already be firing, and memory has already been modified. It might just be half a second too late that you press that freeze button, but it's still less than perfect or "clean" as it's sometimes called. Yes, the monitor can save the RAM under the Kernal with the exception of location $FFFF. Like many other monitors, that last byte is elusive due to the Commodore tradition of the specified last address being +1, and $0000 isn't accepted as $FFFF.

[@janlundthomsen]

@@8_Bit +1 on the “true” crack ethos. Like I wrote in the article “anyone can press a button.” :)

[@stephenwhite506]

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.

[@talideon]

Novaload is one of the older loaders. I've never poked around its innards, but my understanding is that it got used so much because it was reliable, easy to license, and you could easily slot in a loader image and music routine. Keep in mind how awful the built-in loader was in the KERNAL.

[@PontusBerg]

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 kzbin.info/www/bejne/ZnbNaIKIfdaNha8 kzbin.info/www/bejne/sJbPo3t-hKqFotk Crunching kzbin.info/www/bejne/an2agGSao7t-j68 kzbin.info/www/bejne/aX3IoYqqjdSsgKM

[@benjaminhanke79]

"... turned into .wav and saved on a real cassette" That sounds like a job for Techmoan. Would love to see a crossover.

[@spocklodgic]

So good, I love the depth of information.

[@TheHighlander71]

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?

[@firstsurname9893]

No not really, to the 64 disk drives are just serial devices connected to the IEC bus. That's why CBM basic has no commands to do things like formatting a disk or deleting files.

[@TheHighlander71]

@@firstsurname9893 Thanks.

[@GeoffSeeley]

@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.

[@thasinister]

Ofcourse the easy way out is to just use the freeze button as soon as the game starts and use the "backup" option :D, that's what I did, anyway. Edit: Not necessarily optimal for "commercial" cracks, but adequate enough for home use and the filesize isn't much bigger. Ofcourse some compromises relating to the beginning of the execution have to be made, but that's a worthy sacrifice in home use for the ease of it. Gotta remember to turn off the disk drive first to not trip that copy protection on some games!

[@PigDogBay]

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

[@alschannel]

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

[@yogibear2k220]

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!

[@aresaurelian]

I didn't expect anyone to fix this before the devs themselves gave some hint of how to. Good work @8-Bit Show And Tell.

[@eugenetswong]

Thanks for sharing your genius hacking, Robin!

[@pauledwards2817]

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

[@Berend70]

What a nice video! Very instructive..

[@anon_y_mousse]

Personally, I'd rather run the compression program from another computer, even if it has to be through an emulator, as long as the emulator allowed you to speed it up. This kind of reminds me of using UPX back in the day when I wanted to really squeeze every last byte out of a binary. Use either lcc or tcc to produce minuscule binaries in the first place, then strip them and upx them. It could be a little insane, but the way some devs would just not care and have a 10mb "hello world" program kind of irked me. For me, I love retro computers, but I'm definitely over having slow runtimes. I want the accessibility of the hardware, with none of the waiting.

[@marcuslinkert1139]

cracktro and trainer please!

[@LordOrwell]

couldn't you have just loaded the program fully into memory and dumped ram to floppy disk with your super snapshot? It would take up about a third of a floppy but works every time.

[@8_Bit]

I could have, but as you say, the file size would have been a lot bigger, and it would have had the glitchy start characteristic of all "snapshotted" games. This is the cleaner way of doing it, but of course it's more work.

[@nicolaibrowinkel3473]

Really great video!!

[@diwest1737]

The Phil Collins byte 😂😂

[@RichRauenzahn]

Did the c64 allow hexadecimal literals? I’m wondering these days why they didn’t allow the like sys $c000… and bit twiddling would have been easier with hex in basic.

[@8_Bit]

The built-in C64 BASIC didn't support hex literals or math, but some of the add-on extension cartridges did. Almost every short-coming of C64 BASIC can be traced back to the fact that the whole thing fits in about 8 or 9 KB of ROM.

[@VulpisFoxfire]

@@8_Bit Yep. And I seem to recall a few wedge programs that would do that as well....the downside being that they required the BASIC ROM swapped out for RAM in order to do so....which would break anything like Livingston which uses that RAM itself.

[@50shadesofbeige88]

The song sounds like the theme from a 70s game show. I can't put my finger on it.

[@johnglielmi6428]

So those were early compression tools. I imagine they remove white space in the files to reduce the size.

[@logiciananimal]

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?

[@MrRobbyvent]

Please I would like more videos of this kind

[@digitalman2112]

Really interesting. Thank you!

[@hugoegon8148]

Very interesting, many thanks for sharing. 😊

[@spacechase6042]

Was that a „Phil byte“ at 9:30? 🤣🤣

[@8_Bit]

Yes, Phil Byte aka Fill Collins made another appearance! :)

[@benjaminhanke79]

You should have used the sound of "In the Air tonight ft. Deer"

[@Drew-Dastardly]

I have to admit I spent more time cracking software than playing or using them. Once cracked in the library they go never to be seen again. 0-day warez boards.

[@JeanB-br9nw]

I remember a bug in Mountie Mick’s Death Ride, where you can’t pass the cars, and another annoying one in Rampage (no restoring of damage, despite eating and “jump when you see smoke”}. Can you fix a solution for those?

[@DanielMolina1982]

CUANDO QUIERAS.... means "Whenever you want"

[@awilliams1701]

me: wait.....why would it use a JSR to start the game. you: I don't know why it wouldn't just use a JMP. lol

[@terryraymond7984]

how did .SDA packing work ?

[@c64onlinede38]

At 24:19 you saved the memory range up to $C800, but at 30:34 the cruncher stopped at $C000. What about the missing range from $C000 to $C800?

[@8_Bit]

The cruncher started counting at $0000, not the start address (of $0800 or $0801) and shows length, not the absolute address. The actual file being crunched is $C000 bytes long, so it's correct.

[@terryraymond7984]

can we download youre fixed version I would like that game please?

[@terryraymond7984]

kind of like the Maverick tools it gets very complex.

[@agentmith]

Is it possible to do this with only software via emulation? I’ve been getting into Commodore systems lately, and I tried to figure out how to patch the T64 file after seeing your last video but realized this is way beyond my current skill set. I’m curious if it’s even possible, though.

[@NozomuYume]

Yes, emulators often include debugging tools to let you do things like edit memory, set breakpoints, etc. You could even emulate the super snapshot cartridge and do step by step exactly what he did in the video.

[@c128stuff]

Using vice, it has a ml monitor, and you can set breakpoints and watches. That is even easier. But.. a T64 file is not really a tape image, it is an archive comparable to something like 'zip'. You rarely ever need this kind of tricks to deal with a T64 file, but you absolutely have to learn how to use a ML monitor, and at least be able to read and somewhat modify 6502 code for patching.

[@agentmith]

@@c128stuff yeah I found that out towards the end of the video and got a .tap version to try patching instead.

[@c128stuff]

@@agentmith the t64 image should be easier, as there exist standard (pc) tools for extracting the file(s) on it, at least vice does. That means you won't need to first mess with the tape loader, and can directly work on the program(s) contained in the t64 file.

[@bufordmaddogtannen]

You can replicate everything with an emulator, including the use of any freeze cartridge of your choice.

[@Electronics-Rocks]

This makes me wish I kept a diary as used to hack games but I had a compression tool /fast loader which flicker like a professional version. I wish I could remember the software names I used. I did have a c128 so used in built monitor