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.
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!
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?
@@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.
@@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!
@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.
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.
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.
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.
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!
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.
@@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?
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. :)
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.
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.
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.
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).
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.
@@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!
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.
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 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. :)
@@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.
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.
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.
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.
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!
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!
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.
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.
@@8_Bit You need to press J or K to select joystick or keyboard and, of course, without a keyboard you cannot select none of them. At lemon64 forum (general) look at "Adding second fire support to some C64 games"... it is my.
Spy Hunter has type 1 header tape, so basic program header, but it's read at $C049 up to $C0F9. After read the loader i found easily starting address ($7000). $C000 it's free to add your routines to 2nd fire management.... joystick check to bypass J key... etc etc
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
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.
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.
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.
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. :-)
@@donnierussellii4659 Sailor is the best one around. He really honoured the game with an excellent effort. That said, level crunching makes a big difference.
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.
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.
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.
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.
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?
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.
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
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.
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...
Amazing job !! And you also keep the old tools available right then.. that makes this video even more enjoyable.
Год назад
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.
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
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?
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.
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 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
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.
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.
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.
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.
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.
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.
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).
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 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)
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 ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-0Ej7ORHqZOM.html ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-zelrHHOERlw.html Crunching ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-4L7O1dnVKYM.html ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-3LepWtXoyJA.html
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!
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!
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.
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?
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.
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!
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
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.
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.
@@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.
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.
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.
