Making scene versions of games is something done also in 2018. New games are released, and people find old games to release. How to find games is beyond the scope of this text.

As a basis for this text, I’m assuming a PC running Windows. I do 100% of the work under this environment. The final output is a disk image that can be tested under the real hardware, but even that is strictly not needed. My ambition is to setup a structure where basically the entire piece of work is done using one bat file. What you see here is merely the mechanics and tools used. HOW to crack is for you to learn on your own.

Media

Ripping tapes to a TAP file, I use an internal tool and an interface developed by Rowdy. But I do also have an interface done by Luigi Di Fraia. DC2N version 5 Low Cost. From that I have an image file in TAP format.

Ripping disks can be done using a ZoomFloppy or equivalent. From that you get a disk image in D64 or G64 format.

Ripping files

Extracting from TAP, I either use TapEx, FinalTAP or TAPClean. If that doesn’t work, then I use one of the grand old tape transfers. If that doesn’t work, then I revert to manually cracking the tape loader.

Extracting from D64 or G64 I build my own tools. It’s very difficult to generalize as all models of storing is different but I have done a general purpose ripper that can be configured rather freely using script files. Normally there is a bit of coding. Shamefully it’s GUI driven and hence cannot be scripted.

Understanding the program

Next step is understanding the program you are working on. The best way I have found is using The Regenerator. I pick out the core file and dig through it, documenting and commenting until the point where I understand enough.

It’s a great program but I am eagerly awaiting WIlli Bäckers reassembler to have a second option. Regenerator has a somewhat messy handling of rows. You must select all rows plus another one before performing an action, and changing the start of a block can change all of the block. Plus you can’t manually define a hi/lo pointer. The picture here actually shows this.

Implementing the crack

I use a setup with Sublime as texteditor, VICE as emulator, KickAssembler as assembler and then Swoffas Sublime plugin as glue between the parts.

Here I make at least these main files;

  1. An ASM file where I import a binary, apply patches and then save out the result. The patching here also includes all filling of unused spaces, import of the loader, possibly also including the trainer source. What you see below is a really simple instance of the file. It imports the binary and merely imports my trainer to the project. But normally the file itself is much bigger. Fills of crap, NOPing of stuff I no longer need and so on. On a multiloader, there would be an import of the loader and a lot of adapting code.My trainer is highly modular so the file it imports is also only a file that contains a call for a macro and the actual trainer as argument. The trainer in the source would only be something like “YesNoTrainer($0a2b,$ad,tx0)”

2. An ASM file that builds the D64. Kick Assembler gracefully supports a “.disk” command that allows you to pick the files that will eventually make up your d64. You add the files you want to the D64 in the order and with the name you want it to appear. The only piece I miss is that I would really want to add also dir art, but the opportunity to do that is quite limited. Also the support for proper interleaving on the dir track is not implemented.

 

3. I always add a text file where I document findings. That’s merely a general text document that describes more details; where to freeze, what bytes to look for and all the other parts that is important to keep track of. Great for getting back into a project or when applying the same techniques to another game that uses the same loader.

4. A BAT file (name not important, but I tend to use “make.bat”) – the shell bat that does all the actions needed to generate the end result. It call the assembler files, crunch the files before they are added to the d64. What you see here is 1) running the main assembly (the one you see above), 2) charpacking the binary from step 1, 3) assembling the intro (which already includes the link to the binary blob produced at step 2, 4) crunching the blob from step 3. Normally there should also be another step and that is calling the asm file that generates the d64 as per the step above.

The intro is also a piece where I write the scroller in the normal texteditor and then access the source of the intro to populate the text strings for the game name. The rest I don’t need to touch.

 

 

Thanks for rating this! Now tell the world how you feel - .
How does this post make you feel?
  • Excited
  • Fascinated
  • Amused
  • Bored
  • Sad
  • Angry