However, it wasn't going to just be a case of loading up a tape to disc program, hooking up a tape and disk drive and letting the micro do the work. These were only the games that had your Average Joe stumped. The ones where disassembling them brought up seemingly nonsense hexadecimal codes. Where the ordinary loading messages were replaced with strings of numbers, changing filenames or hidden execution addresses.

Playing around to evade the pirates back in the Eighties meant problems for emulation too. There's still no uef (tape images) of a lot of the stuff I successfully 'hacked' and ported to disc. Hopefully, you all noticed games like THE HACKER, MISSION IMPOSSIBLE and ONE LAST GAME popping up in the Haven section of this web site. But there's still a few games to be done yet, so if you're familiar with assembly language but need a bit of inspiration to kickstart you into action, here's an article about six of the games I have transferred. If you can answer any questions I have, then please do contact me.

1. a page of encrypted game code
2. meaningless bytes for a delay loop, or
3. an address to which the machine code loader is directed to get the next group of bytes.

Here is part of that loader:

If you poke an instruction in at &EB7 to divert the routine through some code:

P%=&EB7:[JMP &900:]
P%=&900:[PHA:LDA &5E:JSR &B545:LDA &64:JSR &B545:PLA:JMP (&64):]

then this will keep a watch on where the routine goes to load in the next page (&E57 for BIRDSTRIKE, until loading is complete when it is &600).

The following poke:

P%=&900:[PHA:LDA &5E:JSR &B545:PLA:JMP (&64):]

shows you which page the code is being loaded into - page &06, page &1E ... &2F, &07.

Note that &B545 is the address of a routine in BASIC 2 to print the accumulator in hex and, in the case of BIRDSTRIKE, &5E/F contains the address where the code is being loaded.

Armed with this information we can intercept the program just before it JuMPs to &600 to decrypt and execute, and save it to disk!

This technique worked perfectly on BIRDSTRIKE, THE HACKER and VIDEO CLASSICS. Unfortunately, it doesn't work with STAR DRIFTER and so far I've drawn a blank at decrypting this last title. Does anyone reading this have any ideas?

There are originally four parts to this game so putting it on disc is made much more difficult as I do not know what instruction is executed when the end of any part is reached. I presume it will try to *RUN the next part from tape, because the game is so big it needed to have all disc systems disabled before it runs proper.

I ended up writing a (rudimentary) menu system to allow the user to select which of the four parts he wished to play every time the game loaded. In time I might be able to do some more surgery on the game code to re-select the disc system for loading the next part. But that does seem rather difficult - ordinarily it's impossible to reinitialise a system like ADFS after its workspace has been corrupted with game data!

Of course, if you transfer the file to disc then load it, these two locations are empty and so JMP (&3CB) won't work! After downloading all the parts, the solution is just to jump to address we know - JMP &1100 - instead.

The puzzling RTS at the end (Where does it return to?) makes sense when you realise that a new return address minus one had been pushed onto the stack beforehand.

I hope that's given a bit of insight into the methods commerical programmers used to protect their programs. I'm busy working on lots more conversions from tape to disc and will see you all in the next EUG!

Mr Spock, EUG #65