Yeah, Paul wrote Novaload. Officially only Ocean/Imagine used Freeload; however it transpired a few companies over the years appear to have "borrowed" big chunks of it :)
There were quite a few tape loaders in the day: Pavloda, Novaload, Jetload, Freeload, Turbotape, etc. In EU that is, don't know if the US managed to implement any fastloaders for tape, since tape medium wasn't used over there after 1984. I am impressed how many multiload games that was released for tape in EU. Did you do some other programming besides loaders Paulie? Like games or utilities? If you want to explore the old software of the past I would like to recommend retrocollector.org which is a site I am working on with several others.
Excellent stuff. I got upgraded straight from the VIC-20 to the C128 by my Dad in 1985 so quickly learned to use Reset and C= to enter the C128's MONITOR to query what was going on in memory in whatever C64 game I'd loaded. ISTR I was able to exit that back into C64 mode without wiping the memory, which enabled me to try jumping in to specific routines using SYS. It also enabled me to strip out funky character sets from games and use them myself as "fonts".
Thanks for uploading this very instructional video FourX2k3! :) I owned a C128, first with only a tape player but later on also a disk drive. I also sold it (unfortunately) to raise money for my later Amiga 500. I always wondered how games were cracked, and even though many of my friends had a C64 or C128, none of them knew. Finally, after more than 25 years I got the explanation!
Oh I remembered those darn tape heads going of sync . I remembered I used Turbo tapes to align the head screw with a screwdriver. First I went slowly one way until the raster wasn't solid then I went the other way till the raster wasn't solid and then I picked an average position between the two and that was the strongest signal. Sometimes the alignment was less than 1 mm movements on the screw. Later they came with those cheat tape drives with bars showing the strength and a knob for the head screw. :)
Wow, this is retro gold for me right here! I often wondered how people got the SYS commands to start the game properly after entering poke and stuff from the mags (Zzap64). Training live and energy was easy, but the sys number I never understood how to get those magic numbers. Its explained perfectly in this video, thank you :D
I did exactly the same thing in the 80s. "Learning by doing" and "Trial and Error" were my own methods at the very beginning until I understood how the assembler code of the 6510 processor works. And why ? Quite simply, we didn't have enough money to buy all these games and even if we did, games from the UK or the USA were on the market much earlier than in Germany.
That was awesome! Wow you started hacking early - My first hack was on a PC game! I always thought it was amazing that by NOP'ing out a few conditional jumps you could pretty much crack anything back then. Of course things got a lot more complicated as people started writting self modifying code and mega complex state machines and multi threads etc. How people crack things these days I've no idea - some smart people out there for sure!
+GadgetUK164 You've inspired me to have a go myself on a C64 game! When I've got some spare time I will have a go and see if I can dump the loader screen and music part. Or is the loader music still contained in memory there in the .prg you have? I always suspected that the loader actually overwrote that area of memory last after the music stopped playing.
+GadgetUK164 It depends on the loader; most of the stuff is left over from the ocean loader. In the video you can still see some of the loader. It in the screen ram at "address 0400 to 07E7" before I enter the SYS16960. If you wanted to dump the loader screen I think you have a good chance it's still in there somewhere.
Saving the whole of the machine's memory and packing it into a single file isn't exactly cracking. One step up from freezing it. Back in the day we would save out just the program code and add a trainer or two. Good effort though.
it's a start. the next step in proper cracking is to remove everything from memory that's not required for the game to start, and if the game checks for stuff that's not actually needed, patch out the checks, and then patch out all the checksums. Then add trainers so you can play the game through to the end. If possible, add a high score saver, but disable it when trainers are used. fix all bugs found that interfere with beating the game.
How is the process when all the images, sprites are compiled into the assembler program?I respect those who understand assembler code. Just played with different kind of "editors" on the Amiga, disc block editor or something, you could change the text etc. Even tried to remove the first sectors to remove the copy protection but of course that wouldn't work out. Some kids did that on Windows program in early 90's, like put text " teacher sucks" on the school windows programs. Wonder if the kids today do the same...PS. And the teacher in someway sucks because she didnt understand some people are clever enough to "change" something inside the program, but praise those who were good to use Word.
You, Sir, are a freakin' legend. I always wanted to know how to do cracks on the C64, and Amiga. If you know how on the Amiga, or know of someone who knows how to crack Amiga games, I'd love to know! Kudos.
i can imagine STA $01 being very common through the C64s memory, not sure why it is significant in the loader. the problem may also be that the jump command might take you some distance into the program, rather than at the start of the program in memory. i guess the Action Replay's approach is to save all memory to disk and start at the current Program Counter on reloading? The loaders were fantastic, i never understood how the IRQ music routines managed to sound continuous instead of stuttering until the SID routine was called again
So I was actually fooling around just trying this for kicks on Batman the Movie. At first I thought I had found the right place, it had an 85 01 on several adresses followed by a JMP command very close by. In the event the first address didn't work, would you simply just go to the next one and start over?
I never tracked that STA $01 (which seems not so helpful), but any critical pointer overwriting (actually anywhere from 768 through 819), particularly those near 788-789 for "autorun" reverse engineering. What they put into those vectors was usually the best clue to know where to search for the loader and, later, the entry point. But since I had no cartridge aids in 1985 or so, my trick was forcing the loading of the very first file into a memory area different than expected (so I could calmly study the code, while the vectors remained untouched and friendly). But damn... a simple LOAD couldn't achieve that, because a SAVE"whatever",1,1 had allegedly been used and intended to force the loading address by default in tape loaders (although NOT in disk), *precisely* to avoid any bad instincts (…), so you ended losing control of the keyboard soon after the FOUND pause... Thus, before I had the skills to tweak the Kernal LOAD routine (to achieve that loading relocation I needed to investigate further), I just used to swap two tapes at the right time: i.e. one I previously saved with random content with forced loading from (let's say) $2000, and the actual one. So, my tape ran until the FOUND pause; then I quickly swapped for the actual tape (placed at the shorter tone after the header), resulting a regular load-and-ready from $2000. Actual top loading address could then be peeked at 174-175 (it was also possible to guess with a plain VERIFY). From that point, I could disassemble the code to see what kind of turbo loader (if any) was used and how. They usually took from 679-767 and/or tape buffer area (820-831 unused bytes were usually taken too) to place the first stages of the loader, often overwriting the vectors or even the screen memory, all in-a-row. Tape buffer use for placing code was not ruined with that swapping trick. *Then* it was the time to look for a suspect JMP or a data copy to upper areas…
Lot of tinkering, wish you could know this trick from video called "Cracking a C64 Game From Cassette: Livingstone, I Presume?", would save you a lot of headache :)
@@sanjyuu2298 Sure, but you didn't have such resources back in 1985, so you had to figure things out in your own way. Anyway it was easier to do than it may seem here.
You could also do that with the finale cartrigde III. Not sure I agree that is "Cracking". In that case cracking have diffirent levels, some just load the game and save it to disk thats "cracking", but I have more respect for the Cracking, where is a little bit diffirent that this. Like modify the loader, remove the copy protection from the loader etc. Not sure the method we see here would be possible in the 80s. The 64k Dump file is compressed using exomizer, which as i see it must be clever enough to take all 64k and compress it and decompress it again on a c64 with 64k, it might have been a very hard task to do on a real c64, since you only have 64k, so there will be no space for the compresser and decompresser but i guess the way the exomizer works is it moves the data around, where thare are space and keep track so it dont overwrite itself or the compressed data. Thats clever.
Just watched this video today. Amazing to have a look on what you guys were doing back then. Could you make a dummy description for me on what's going on crunching/decrunching a game? Furthermore, why was it only possible to load these games with a Turbo Loader back then?
That's good to know, been using Master System pad on C64 for a while, I use quickshot as well... Will not put Mega Drive pad in, I did hear it would mess C64 up.. Nice video.
Cool !! Thats the kind of videos im looking for, great. As im very interesting in commodore tape loaders and how they did their magic doing tape to disk cracking back then, this tutorial is a great source. Please if possible can you do a video on transferring a multiload tape game to disk ? Thanks for sharing your knowledge.
odd method there with the tape counter, wouldnt you be missing some data by this method of freezing with or without a tape counter. Just because the game runs does not mean you have all the data and code associated with all the levels. Just a thought. I like your heavy emphasis on the machine code monitors though. I used to have a final cartiridge iii myself. Loved the assembler on that, have no idea how it compares to others though.
Hrm... This is a very "hit and miss" kind of approach. The proper way to do it is following the logics of the loader and then deduct the real start address from there. Sure, a store to address $01 is often a way a program starts, but it's for sure not at all sure that this method works. I have done a number of videos on the subject (and mind that I have PROPERLY cracked some 200+ tape games) : ua-cam.com/video/0Ej7ORHqZOM/v-deo.html ua-cam.com/video/zelrHHOERlw/v-deo.htmlfeature=shared ua-cam.com/video/moj2e_clBMM/v-deo.htmlfeature=shared ua-cam.com/video/VVqyli96usI/v-deo.htmlfeature=shared
Probably not, the "junk" you see is data that might be used to decrunching. The computer have limited resources so you might need to use the memory area which is screen memory as buffer or data or something, it will not look nice, but people got used to that.
I memberberrie having to do this sort of stuff. Was good to Geek out to. Though a voice over would be nice. I'm sure there's somone out there willing to help.
He. So intresting. Haven't watched the whole video, but did you change the jump "to game" address to an infinite loop jump such that you could dump the 4000-ffff memory when the loader was done ? :)
I use to do this c64 cracking instead of doing my homework back in the days;) To type sys $4240 in screen memory will damage your game.. since there was code witter on that location. its safer to jump start the game from your assembler monitor. next step is finding your life counter and make a trainer menu;) pack your crack intro infront and you'r done! thanks for sharing good memories
Hi. Where did you get the SD drive from? Will this allow you to copy files from the 1541 to a PC computer? I have been wanting to do this for a long time. Thanks.
You can get a SD2IEC from here www.thefuturewas8bit.com/index.php/sd2iec-info The SD2IEC is a 1541 drive emulator, if you saved a memory dump using the action replay with the command SP "OPWOLF" 0400 FFFF , or whatever the equivalent command is for the action replay for example It would save a file called "OPWOLF" to the root of the SD card then you can transfer it using an SD card reader from SD card to your pc.
What a cool site! So will this work with the VICE C64 emulator? My goal is to have the ability to copy old files from my Commodore 64 system to a PC desktop. Thanks.
Absolutely, if your games / programs are in (*.prg) format Vice will play / read them. You can create blank C64 floppy disc images with a pc program called D64Editor then copy it to the SD card, mount the blank floppy disc image with the SD2IEC and copy all your files to it like a real 1541 floppy disc. You can also extract the files from the floppy disk images using D64Editor as well Vice has no problem loading and reading disc formats like (*.d64 or even *.d81)
@@Four_X I had Crush, Crumble and Chomp on cassette and it took at least 20 minutes (perhaps as high as 30) to load at standard speed. Pretty average game too and I only got it to load correctly 2 or 3 times before I forgot about it.
it's an interesting video but it'd be much easier for you and us if you had spoken the explanations instead of writing them besides, it probably would have shortened the video enormously
Nice. It would probably make more sense to crack a disk game. I was only reading up about the tricks that were used, such as writing to sectors of disk at the extreme edges and deliberate bad sectors. Even tricks such as turning down disk drive speeds to crack a game easier.
If you want to go full oldskool there are thousands of dumps from these old cassette games (and most games came out on cassette too) in the form of .TAP format. That is a direct dump of the whole cassette data which is supported by VICE and other emulators.
Howdy! For my sins I wrote the Ocean Loader (Freeload) back in the 80's - nice to see people still tinkering with it :)
Didn't you also do Encounter for Novagen? Great games, great programmer.
Alas, Encounter et al was by the genius that is Paul Woakes :)
It was probably Novaload he was responsible for. I always confuse them. Freeload was also used by USGOLD was it not?
Yeah, Paul wrote Novaload. Officially only Ocean/Imagine used Freeload; however it transpired a few companies over the years appear to have "borrowed" big chunks of it :)
There were quite a few tape loaders in the day: Pavloda, Novaload, Jetload, Freeload, Turbotape, etc. In EU that is, don't know if the US managed to implement any fastloaders for tape, since tape medium wasn't used over there after 1984. I am impressed how many multiload games that was released for tape in EU. Did you do some other programming besides loaders Paulie? Like games or utilities? If you want to explore the old software of the past I would like to recommend retrocollector.org which is a site I am working on with several others.
Excellent stuff. I got upgraded straight from the VIC-20 to the C128 by my Dad in 1985 so quickly learned to use Reset and C= to enter the C128's MONITOR to query what was going on in memory in whatever C64 game I'd loaded. ISTR I was able to exit that back into C64 mode without wiping the memory, which enabled me to try jumping in to specific routines using SYS. It also enabled me to strip out funky character sets from games and use them myself as "fonts".
Thanks for uploading this very instructional video FourX2k3! :) I owned a C128, first with only a tape player but later on also a disk drive. I also sold it (unfortunately) to raise money for my later Amiga 500. I always wondered how games were cracked, and even though many of my friends had a C64 or C128, none of them knew. Finally, after more than 25 years I got the explanation!
Oh I remembered those darn tape heads going of sync . I remembered I used Turbo tapes to align the head screw with a screwdriver. First I went slowly one way until the raster wasn't solid then I went the other way till the raster wasn't solid and then I picked an average position between the two and that was the strongest signal. Sometimes the alignment was less than 1 mm movements on the screw.
Later they came with those cheat tape drives with bars showing the strength and a knob for the head screw. :)
Wow, this is retro gold for me right here! I often wondered how people got the SYS commands to start the game properly after entering poke and stuff from the mags (Zzap64).
Training live and energy was easy, but the sys number I never understood how to get those magic numbers.
Its explained perfectly in this video, thank you :D
There are cartridges like nordic power or action replay that give basic the ability to interprete hex-numbers
I did exactly the same thing in the 80s. "Learning by doing" and "Trial and Error" were my own methods at the very beginning until I understood how the assembler code of the 6510 processor works. And why ? Quite simply, we didn't have enough money to buy all these games and even if we did, games from the UK or the USA were on the market much earlier than in Germany.
many thanks that was a fantastic video. i always wondered how this was done. Keep up the great work
Thanks.
That was awesome! Wow you started hacking early - My first hack was on a PC game! I always thought it was amazing that by NOP'ing out a few conditional jumps you could pretty much crack anything back then. Of course things got a lot more complicated as people started writting self modifying code and mega complex state machines and multi threads etc. How people crack things these days I've no idea - some smart people out there for sure!
+GadgetUK164 You've inspired me to have a go myself on a C64 game! When I've got some spare time I will have a go and see if I can dump the loader screen and music part. Or is the loader music still contained in memory there in the .prg you have? I always suspected that the loader actually overwrote that area of memory last after the music stopped playing.
+GadgetUK164
It depends on the loader; most of the stuff is left over from the ocean loader. In the video you can still see some of the loader. It in the screen ram at "address 0400 to 07E7" before I enter the SYS16960.
If you wanted to dump the loader screen I think you have a good chance it's still in there somewhere.
Excellent video and explanation, well done and thanks for making this :)
Thanks for the 10 minutes of reading
Your welcome.
The trick of resetting the counter, rewinding, then pausing the load just before zero is pretty nifty.
Old School tricks are the best.
If you reset Rambo on the C64, the NMI vectors point to $C000 and Martin's audio development kit was left in the finished game!
Cheers for that. Loved it.
Thanks bud.
Saving the whole of the machine's memory and packing it into a single file isn't exactly cracking. One step up from freezing it. Back in the day we would save out just the program code and add a trainer or two. Good effort though.
it's a start. the next step in proper cracking is to remove everything from memory that's not required for the game to start, and if the game checks for stuff that's not actually needed, patch out the checks, and then patch out all the checksums. Then add trainers so you can play the game through to the end. If possible, add a high score saver, but disable it when trainers are used. fix all bugs found that interfere with beating the game.
How is the process when all the images, sprites are compiled into the assembler program?I respect those who understand assembler code. Just played with different kind of "editors" on the Amiga, disc block editor or something, you could change the text etc. Even tried to remove the first sectors to remove the copy protection but of course that wouldn't work out. Some kids did that on Windows program in early 90's, like put text " teacher sucks" on the school windows programs. Wonder if the kids today do the same...PS. And the teacher in someway sucks because she didnt understand some people are clever enough to "change" something inside the program, but praise those who were good to use Word.
Using a breakpoint would be much easier. I wouldn't use CCS64 for the job but CCS64 also have them. Just look it up from the documentation.
nice! i wish i was as cool of a nerd to have a bunch of nerd friends like that when i was in school!
You, Sir, are a freakin' legend. I always wanted to know how to do cracks on the C64, and Amiga. If you know how on the Amiga, or know of someone who knows how to crack Amiga games, I'd love to know! Kudos.
Thanks. I just used to have fun back in the day.
i can imagine STA $01 being very common through the C64s memory, not sure why it is significant in the loader. the problem may also be that the jump command might take you some distance into the program, rather than at the start of the program in memory. i guess the Action Replay's approach is to save all memory to disk and start at the current Program Counter on reloading? The loaders were fantastic, i never understood how the IRQ music routines managed to sound continuous instead of stuttering until the SID routine was called again
i always wondered how people did that shit.. very fucking cool
So I was actually fooling around just trying this for kicks on Batman the Movie. At first I thought I had found the right place, it had an 85 01 on several adresses followed by a JMP command very close by. In the event the first address didn't work, would you simply just go to the next one and start over?
Awesome work!!
I never tracked that STA $01 (which seems not so helpful), but any critical pointer overwriting (actually anywhere from 768 through 819), particularly those near 788-789 for "autorun" reverse engineering. What they put into those vectors was usually the best clue to know where to search for the loader and, later, the entry point. But since I had no cartridge aids in 1985 or so, my trick was forcing the loading of the very first file into a memory area different than expected (so I could calmly study the code, while the vectors remained untouched and friendly). But damn... a simple LOAD couldn't achieve that, because a SAVE"whatever",1,1 had allegedly been used and intended to force the loading address by default in tape loaders (although NOT in disk), *precisely* to avoid any bad instincts (…), so you ended losing control of the keyboard soon after the FOUND pause... Thus, before I had the skills to tweak the Kernal LOAD routine (to achieve that loading relocation I needed to investigate further), I just used to swap two tapes at the right time: i.e. one I previously saved with random content with forced loading from (let's say) $2000, and the actual one. So, my tape ran until the FOUND pause; then I quickly swapped for the actual tape (placed at the shorter tone after the header), resulting a regular load-and-ready from $2000. Actual top loading address could then be peeked at 174-175 (it was also possible to guess with a plain VERIFY). From that point, I could disassemble the code to see what kind of turbo loader (if any) was used and how. They usually took from 679-767 and/or tape buffer area (820-831 unused bytes were usually taken too) to place the first stages of the loader, often overwriting the vectors or even the screen memory, all in-a-row. Tape buffer use for placing code was not ruined with that swapping trick. *Then* it was the time to look for a suspect JMP or a data copy to upper areas…
Yaaaaaaaaaaawn!!!!
Lot of tinkering, wish you could know this trick from video called "Cracking a C64 Game From Cassette: Livingstone, I Presume?", would save you a lot of headache :)
@@sanjyuu2298 Sure, but you didn't have such resources back in 1985, so you had to figure things out in your own way. Anyway it was easier to do than it may seem here.
This was great thank you
You could also do that with the finale cartrigde III. Not sure I agree that is "Cracking". In that case cracking have diffirent levels, some just load the game and save it to disk thats "cracking", but I have more respect for the Cracking, where is a little bit diffirent that this. Like modify the loader, remove the copy protection from the loader etc. Not sure the method we see here would be possible in the 80s. The 64k Dump file is compressed using exomizer, which as i see it must be clever enough to take all 64k and compress it and decompress it again on a c64 with 64k, it might have been a very hard task to do on a real c64, since you only have 64k, so there will be no space for the compresser and decompresser but i guess the way the exomizer works is it moves the data around, where thare are space and keep track so it dont overwrite itself or the compressed data. Thats clever.
Just watched this video today. Amazing to have a look on what you guys were doing back then. Could you make a dummy description for me on what's going on crunching/decrunching a game? Furthermore, why was it only possible to load these games with a Turbo Loader back then?
Great video. STA $01 work for other loaders to find entry points with the JMP near?
That's good to know, been using Master System pad on C64 for a while, I use quickshot as well... Will not put Mega Drive pad in, I did hear it would mess C64 up.. Nice video.
Cool !! Thats the kind of videos im looking for, great. As im very interesting
in commodore tape loaders and how they did their magic doing tape to disk cracking back then, this tutorial is a great source.
Please if possible can you do a video on transferring a multiload tape game
to disk ?
Thanks for sharing your knowledge.
awesome job dude, thnx for shring
You can also G 4240 from the monitor instead of calling SYS from the basic.
@30:57 "a weird N1" hehe..... that's 'pie'.
odd method there with the tape counter, wouldnt you be missing some data by this method of freezing with or without a tape counter. Just because the game runs does not mean you have all the data and code associated with all the levels. Just a thought. I like your heavy emphasis on the machine code monitors though. I used to have a final cartiridge iii myself. Loved the assembler on that, have no idea how it compares to others though.
Very informative, but a little proofreading before uploading goes a long way. There's a lot of spelling and grammar issues for a text-only video.
pretty interesting! so what was exactly the copy-protection? to "hide" the start-address of the game?
Great video really interesting, i just use to play games on the speccy and 64, always wondered why every 64 copy was cracked, yet speccy games wernt
Hrm... This is a very "hit and miss" kind of approach. The proper way to do it is following the logics of the loader and then deduct the real start address from there. Sure, a store to address $01 is often a way a program starts, but it's for sure not at all sure that this method works.
I have done a number of videos on the subject (and mind that I have PROPERLY cracked some 200+ tape games) :
ua-cam.com/video/0Ej7ORHqZOM/v-deo.html
ua-cam.com/video/zelrHHOERlw/v-deo.htmlfeature=shared
ua-cam.com/video/moj2e_clBMM/v-deo.htmlfeature=shared
ua-cam.com/video/VVqyli96usI/v-deo.htmlfeature=shared
Nice video. Is it possible to get away the junk before it's crunching? Maybe change it to something cooler or nothing at all?
Probably not, the "junk" you see is data that might be used to decrunching. The computer have limited resources so you might need to use the memory area which is screen memory as buffer or data or something, it will not look nice, but people got used to that.
Martin Galway music .. him and Rob Hubbard were the best
FRAPS eats up too much memory. OBS is perfect for capturing the entire screen at a small file size MP4.
I memberberrie having to do this sort of stuff. Was good to Geek out to. Though a voice over would be nice. I'm sure there's somone out there willing to help.
He. So intresting. Haven't watched the whole video, but did you change the jump "to game" address to an infinite loop jump such that you could dump the 4000-ffff memory when the loader was done ? :)
+bwack
Yes, then sys16960 and bingo... Operation Wolf.
I use to do this c64 cracking instead of doing my homework back in the days;) To type sys $4240 in screen memory will damage your game.. since there was code witter on that location. its safer to jump start the game from your assembler monitor. next step is finding your life counter and make a trainer menu;) pack your crack intro infront and you'r done! thanks for sharing good memories
Hi. Where did you get the SD drive from? Will this allow you to copy files from the 1541 to a PC computer? I have been wanting to do this for a long time. Thanks.
You can get a SD2IEC from here
www.thefuturewas8bit.com/index.php/sd2iec-info
The SD2IEC is a 1541 drive emulator, if you saved a memory dump using the action replay with the command
SP "OPWOLF" 0400 FFFF , or whatever the equivalent command is for the action replay for example
It would save a file called "OPWOLF" to the root of the SD card then you can transfer it using an SD card reader from SD card to your pc.
What a cool site! So will this work with the VICE C64 emulator? My goal is to have the ability to copy old files from my Commodore 64 system to a PC desktop. Thanks.
Absolutely, if your games / programs are in (*.prg) format Vice will play / read them.
You can create blank C64 floppy disc images with a pc program called D64Editor then copy it to the SD card, mount the blank floppy disc image with the SD2IEC and copy all your files to it like a real 1541 floppy disc.
You can also extract the files from the floppy disk images using D64Editor as well
Vice has no problem loading and reading disc formats like (*.d64 or even *.d81)
Yes most of them are -- the Basic ones. I do I have a feel SEQ files too.
cool !!! 98% now :) needs an introloader :)
To anyone watching this, 10 minutes of the posters nostalgia at the beginning, nothing actually happens until 10 mins in.
ToryglenBoy mvp
It's a reminder of what it felt like to load games on tape.
It doesn't take 25 minutes to load a C64 game, get over it.
Yes I was exaggerating.
@@Four_X I had Crush, Crumble and Chomp on cassette and it took at least 20 minutes (perhaps as high as 30) to load at standard speed. Pretty average game too and I only got it to load correctly 2 or 3 times before I forgot about it.
Yea, reading a video not my thing pushing 50, and it too small to read on this laptop screen..
Dude fix the description. 'with CCS64 and it's built in MONITOR.' It's *its* not *it's*
it's an interesting video but it'd be much easier for you and us if you had spoken the explanations instead of writing them
besides, it probably would have shortened the video enormously
A question: How were multi load tape games converted to tape, or did you use the original disk versions that you then cracked?
Nice. It would probably make more sense to crack a disk game. I was only reading up about the tricks that were used, such as writing to sectors of disk at the extreme edges and deliberate bad sectors. Even tricks such as turning down disk drive speeds to crack a game easier.
If you want to go full oldskool there are thousands of dumps from these old cassette games (and most games came out on cassette too) in the form of .TAP format. That is a direct dump of the whole cassette data which is supported by VICE and other emulators.