A Complete Guide to Creating POKEs on the Spectrum, Richard P Swann
A complete guide to creating POKEs on the Spectrum, featuring full examples. Devised and written by Richard P Swann
NB : This document was originally intended to be printed in Your Sinclair magazine. It is split into "pages" of 58 lines.
CONTENTS
WHAT YOU WILL NEED...........................Page 1
THE BASIC IDEA...............................Page 2
Getting started with hacking
CONVENTIONAL HACKING TECHNIQUES..............Page 8
Forwards trace and backwards trace
EASY LOADING SYSTEMS.........................Page 11
Headerless loaders, turboloads and compression
DECRYPTERS...................................Page 18
Single decrypter loading systems
ADVANCED HACKING METHODS.....................Page 24
Stack trace and interrupt trace
COMMERCIAL PROTECTION SYSTEMS................Page 26
Bleepload, Ultimate loader, Mikro Gen Loader, Powerload, Search Loader, Paul Owens Protection System, Speedlocks
EPILOGUE.....................................Page 59
Scrolling credits etc. etc.
GLOSSARY AND INDEX...........................Page 60
WHAT YOU WILL NEED
If you want to use this book successfully, you will need the following:
- An understanding of Spectrum BASIC. If you are total beginner, you will almost certainly find this book too complicated, and hence useless to you. If you can understand most of the Spectrum manual, then you should be all right. If you don't understand a word of the section on using +3 DOS in machine code in the +3 manual, don't worry, 'cause I don't either!
- A disassembler or a monitor program. You can, in theory, hack anything without one of these, but in practice, it would be impossible for a beginner, and next to impossible for someone experienced. My personal choice is Hisoft's DEVPAC, but if you have the programs STK and 007 Disassembler (which were on the covertapes of YS #75 and #77), that'll do fine for this book.
- Some games to hack. Obviously business software is out of the window because it's illegal to hack it, and you don't need to anyway. Strategy and adventure games are pretty unlikely to demand a POKE (although it's possible, and I'll show you how I hacked an adventure later on), so you're left with arcade and arcade adventure games. Most of the time you'll want to find infinite lives and/or energy, but there are always exceptions. This book concentrates on games that you're likely to have, which are games which have been on magazine covertapes, or bestsellers.
- Patience and determination. This is the most important thing of all. Finding POKEs is challenging without any knowledge of how the program works, or even a knowledge of the language it's written in! So be prepared to do some serious THINKING!
- A Multiface or other "magic box" device. This is not essential, but it is extremely useful, and a few sections in this book require you to have one (but as few as possible, I might point out!)
PART ONE - The Basic Idea
Before we get down to some serious hacking, it will be a good idea to know what we are looking for. Okay, I know that some of you may think that this is pointless, but if you don't know what you're aiming at, you'll never get anywhere.
Basically, we are going to examine a program, and change it so that certain instructions are altered so that the game becomes more easier to the user. This may be in the form of infinite lives, infinite energy, immunity, infinite bullets etc.
The only way we can hope to do this is to understand what is going on in the game. And because most games are written in machine code, we're going to have to understand that as well. Please don't be put off by the thought of learning a new language; in fact you need know very little machine code knowledge to hack most games.
To start with, we'll just look at infinite lives. Lives are normally a small number, between 3 and 9 (although some games may have more), and the common thing with all games that have lives is that somewhere in the game, the amount of lives are set as a definite number, and somewhere else, the amount of lives goes down by one. In order to get infinite lives, we would have to remove the command in the program which decreased a player's lives.
You probably have and idea about how a lives system would work in BASIC. Say if, for argument's sake, a BASIC game had three lives, you would expect to see something like...
100 LET LIVES=3...contained in the program. Then, a bit further on, you'd expect to see...
500 LET LIVES=LIVES-1In order to get infinite lives, we would simply remove line 500 altogether and RUN the program.
A similar idea appears in machine code, but the way it's done is slightly different.
For starters, machine code doesn't have any variables! You might therefore wonder how on earth the computer can store anything. In actual fact, the computer can store information anywhere in RAM, as you may well know, and this is exactly what happens in machine code.
In Chapter 24 ("The Memory") of the Spectrum manual, there's a detailed description of the Spectrum's memory. The best way to visualise the memory, I think, is to imagine 65,536 boxes, each one containing a piece of paper with a number from 0 to 255 written on it.
Therefore, it is no problem for a computer to store the number of lives in machine code, since it can just put it as a byte in a memory location, leave it there, and come back to it later.
You should be aware that in machine code, commands are also stored in memory locations as bytes; so if you get commands and data mixed up in memory, the computer could easily try and execute the data, thinking it's a command, and trying to execute it. Unlike BASIC, there are no errors in machine code, and the computer can execute anything it finds, so in this case you will get a crash. So most programs keep program data and program commands separately.
Anyway, in order to store three lives in machine code, we'd put the number 3 in a memory location. Unfortunately, we can't do this straight away in machine code, and we can only do it by using what are called registers.
Registers store information in the same way as memory locations. They are bit more versatile though, as you can perform calculations with them. All the same, they are not the same as variables in BASIC, and are more like a pair of hands used for counting.
The main register we'll look at for now is the A register (sometimes called the accumulator), which can store a single byte and have sums done to it.
What we would do to store the number three in a memory location is to put the number 3 into the A register, then put the contents of the A register (which are of course, 3) into a memory location.
The actual way of writing this in machine code is:
LD A,3 LD (#8000),AActually, strictly speaking, the above isn't machine code at all! Machine code as the computer sees it is, as I explained earlier, consists of many bytes in memory, which are pretty meaningless to humans. So some people invented assembly language (which is what the above is), where each instruction carried out by the computer is given a name (called a mnemonic).
The above program features one command used in two different ways. The command is LD, which is pronounced "load". This has nothing at all to do with loading a program from tape. It basically is a transfer of information from one place to another.
The comma in the instructions is read as "with", so the whole instruction is read as "Load A with 3". It now seems obvious that this instruction is putting the number 3 into the A register.
The second command is also LD, but the way its used is slightly different. The brackets mean "the contents of", so the whole instruction is read as "load the contents of #8000 with A". (Think of a bracket as a byte in memory, where everything in the bracket is part of that byte) Therefore, this instruction would make the computer take whatever value is in the A register, and store it in memory location #8000 (of course, it could be any other memory location as long as it is unused).
So the overall result of the two commands (normally called operations) would be to put the number 3 in memory location #8000.
Congratulations! You've just learned the first way to hack. Clearly, if in a real program, we found these operations, we could change the LD A,3 to something like LD A,100 to get 100 lives!
Before we can do any "real" hacking, I'd better discuss how "real" machine code is written.
Every machine code instruction contains and opcode, and some instructions need an operand. An opcode is simply the instruction the computer is going to do. Every number from 0 to #FF corresponds with a specific opcode. You can find a complete list of opcodes in Appendix A of your Spectrum manual.
The operand is used whenever there is ambiguity over something. If you look in Appendix A of the Spectrum manual, you will see that the opcode #3E is "LD A,n". "n" in this case can mean any single byte number ie: a number from 0 to 255. But it's possible to put any number within this range eg: LD A,3 or LD A,#40 or LD A,#80 etc. The computer has to somehow know what data it is dealing with, and this is where the operand comes in. In machine code, whenever the computer comes across the opcode #3E, it looks at the byte after the opcode, and assumes it's the data needed. So, if the computer came across the bytes #3E and #40 in succession, it would put the value #40 in the A register. In this example, #3E is the opcode, while #40 is the operand. After executing the instruction, the computer goes to the byte after the operand, and starts running code from there.
In the second instruction of our example, the opcode is #32, ie: "LD (NN),A". The ambiguity is in the address where we are going to store the value of the A register. In this case, the operand takes up two bytes, hence the "NN", which again comes after the opcode. You should note that this is an address in memory, and is always referred to as two bytes. So you might expect the machine code equivalent of LD (#8000),A to be #32 #80 #00. Except it isn't! For some odd reason, in machine code, all two byte operands are written the wrong way round, so the actual machine code equivalent of LD (#8000),A is #32 #00 #80. There is no hard and fast reason why, it's just vitally important that you remember this.
In short, the program of the previous page is written as...
#3E #03 #32 #00 #80...which takes up five bytes.
Not all instructions require operands. For example, DEC A (short for "decrease A", which subtracts one from the A register) has no ambiguity at all. There is only one way to decrease the value in the A register, so the instruction only takes up one byte, in this case #3D. No operands are needed.
Right, time for your first bit of hacking! From what we've discussed above, we want to find, somewhere in the game's code, a set of instructions which put the number of lives into a byte in memory. So if the game had three lives, we could expect to see the bytes...
#3E #03 #32...unfortunately, we don't know where in memory the number of lives is going to go, so we can't work out the operands for the second instruction (#32). But in fact, we don't need to, for if we find the above sequence of bytes in a program, we can simply examine the two bytes after this sequence to find out where in memory the number is being put.
So let's put this into practice and hack an actual game. For convenience I've chosen Sweevo's World, which featured on a YS Covertape Issue 60 December 1990. I would have chosen a more recent game, but they all have some form of protection on them. Besides, obtaining infinite lives is relatively easy.
Getting the game in memory without it running is easy. If you've typed out a fair few POKEs in your time, this will be no problem. Just MERGE the BASIC loader and put a STOP statement before the RANDOMIZE USR statement. Then RUN the program and wait for it to load, until the OK message appears.
Now we have the game in memory, we can load STK and examine it. You have to be a bit careful here, because STK occupies 6K of the Spectrum's memory. Although it can be anywhere in memory, it possible to overwrite the all-important lives code in the game with STK, so we have to be careful. The best places to put STK are in the graphics, map or sound data. There's no easy way to tell where this is, so you'll have to try pot luck. But it helps if you know where the game loads to, so load up STK at any address, and press J and then Caps+9 to read in a header a couple of times. Then read the headers of the three blocks of code after the BASIC. They are:
Bytes: S 4000,1B00 Bytes: M FB90,043D Bytes: P 60E0,82B0The first block is the loading screen. The second block is in actual fact the game's music (but you wouldn't be expected to know this), and the third block is the actual game itself. Therefore, we can put STK anywhere above (60E0+82B0)=E390. For argument's sake, let's put it at EA60, which is 60000 decimal. When we've finished hacking, we can reload "Bytes: M" and run the program. Load up STK (after having stopped the BASIC and returned with a STOP statement) at address 60000.
Now at last, some hacking. Bearing in mind that you start the game with five lives. Press Q to search for a byte. Enter the address we want to start searching at as 60E0, because that's the start of the game. Now type in the following:
#3E #05 #32These are the search bytes we described on the previous page. Keep pressing N for "next" until all of the memory has been searched. You will get the following addresses: 905C and EEDC. You can ignore the one at EEDC, because it's in the middle of STK and outside the main game code, so that leaves just the one at 905C. Press E for edit and type #905C. You'll see the following bytes:
3E 05 32 1A 61So this tells us that the computer puts the number five in box number 611A (remember that 2 byte numbers are reversed!) Now to hack the game, we simply change the number 5 at 905D to any number of lives we want (the maximum is #FF).
Now, get out of STK, reload the "Bytes: M" file and RANDOMIZE USR 24800 (the original command in the BASIC), and hey presto - you will have whatever amount of lives you wanted!
All that remains to do is to write a proper hack for it. 905D is 36957 in decimal, so your hack would be something like "MERGE the BASIC loader, and insert POKE 36957,n before the RANDOMIZE USR statement, where 'n' is the number of lives."
And it's as simple as that. If you can understand what we've done so far, you're doing well, so stick at it.
Any unprotected game like Sweevo's World is hacked in the same way, except you will probably have to reload STK to a different address, and you may find that in your search for #3e #32, you may come across several locations in memory outside STK that have this pattern. In this case, you'll have to use trial and error to work out which one holds the number of lives.
It is, of course, perfectly possible for you now to find 'number of lives' POKEs for any unprotected game under the sun, and in the early days of Spectrums ('82-'84), this would have been perfectly adequate. Of course, what your really need is the real nitty gritty - INFINITE lives. This is done by taking things just a step further.
What you basically need to do is find out which memory location the number of lives are being put in. Then you need to search for parts of the program which put the value of that memory location in a register, subtract one from it, and put the new value in the register back. Then you have to rewrite the code slightly so that the computer "forgets" to decrease the value in the register, and simply puts the old value back in again.
Coming back to Sweevo's World, we already know that the number of lives are stored at memory location 611A. I normally refer to this memory location as the "lives store" for obvious reasons. All we have to do is search for all the occurrences of the address of the lives store. So, search for #1A,#61, and you will find it referred to at the following addresses:
779B 8160 81A9 905F EEDCYou can ignore the one at EEDC because it's in STK, but you can also ignore the one at 905F, since that's part of the lives setting routine we discussed earlier. So the routine to decrease the number of lives must lie at one of the other locations.
You should note, that any instruction that involves the lives store will begin at the byte before, because 1A and 61 are two byte operands (see page 3 for more about operands).
So for starters, press E to edit an address and type in #779A.
You'll see the following:
779A - 3A 1A 61 C3 61 99After the computer has executed the three byte instruction 3A 1A 61 (which is LD A,(611A in mnemonics), it executes the instruction C3. If you look up C3 in Appendix A of your Spectrum manual, you'll see it corresponds to the instruction JP. JP is short for "jump", and is in a sense like GOTO in BASIC. What the computer does is to jump to a location in memory. As you can see, there is ambiguity as to where it is going to jump, so we need a two byte operand. Like the ones me have met before, the bytes are written the wrong way round. So C3 61 99 means JP 9961. In this case, the computer would go to address 9961, and start executing code from there.
It is possible that the code to decrease the number of lives is at 9961, but is unlikely, because it pointless to have to jump to a completely different area of memory. So we'll leave this part of memory, and go onto the next instruction, at 8160. Press EDIT to leave the editing procedure, and edit address 815F. You'll see the following:
815F - 21 1A 61 3521 is the instruction LD HL,NN. HL is another register like A, but its main difference is that it can store two bytes at once. So LD HL,NN requires a two byte operand, whereas LD A,N only requires one. So here the instruction 21 1A 61 means LD HL,611A. The next instruction, 35 doesn't need any operands, and is the instruction we've been looking for. 35 means DEC (HL). You've already come across brackets meaning "the contents of", so as you might have guessed, DEC (HL) decreases whatever is at the memory location with the same number as HL by one. In this case, we know that HL is 611A, because we've just set it in the last instruction. So DEC (HL) will decrease the value of whatever is in memory location 611A by one in this case.
But we already know that the number of lives is stored at memory location 611A. So clearly DEC (HL) is going to decrease the number of lives by one!
What we need to do to make an infinite lives POKE is to somehow overwrite the DEC (HL) so that the computer doesn't decrease the number of lives. There are two things that can be done. Firstly the address containing DEC (HL) can be replaced by 0. The number 0 relates to an instruction called NOP. NOP is short for "No operand", and in short means absolutely nothing! When the computer encounters the instruction NOP, it will do nothing and execute the next instruction. So if we overwrite DEC (HL) with NOP, the computer won't decrease the number of lives, but do nothing instead. The vast majority of POKEs have the format POKE address,0 for the reasons described above.
If you run Sweevo's World changing the DEC (HL) to NOP, you'll find you only get one life instead of five! In this case, you should overwrite the DEC (HL) with OR (HL). OR (HL) is a single byte instruction, B6. Don't worry about what it does, because it isn't important. What is important is to remember to do this if you only get one life.
Rerun Sweevo's World, replacing the DEC (HL) with OR (HL), and you'll have your infinite lives! The DEC (HL) is at address 8162, which is 33122 decimal, while B6 is 182 decimal, so the POKE would go something like "MERGE the loader, and put POKE 33122,182 before the RANDOMIZE USR statement, RUN the program and restart the tape."
Now we've covered the rudiments of machine code involved in hacking, we can look at more detailed ways of finding POKEs.
PART 2 - Conventional Hacking Techniques
By now, you should have an idea of how simple machine code works. Now we're going to look at the usual techniques of hacking. There are five techniques, which are called Forwards Trace, Backwards Trace, Stack Trace and Interrupt Trace, in that order of difficulty. Of these, Forwards Trace and Backwards trace are the only techniques you can use without a Multiface, and are the most reliable methods. You should only really have to use the others in exceptional circumstances, which are, on the whole, games which don't have a lives system or a GAME OVER message. Very few games use unusual routines, since it's just a hindrance to the programmer.
We'll start with Forwards Trace. You've already had a go at this from the last part, so hopefully it won't be too hard to understand. Then we'll look at the backwards trace, followed by some practical examples.
FORWARDS TRACE:
For the forwards trace, you start with the lives initialisation routine, and then work forwards from there.
The first thing you need to do is to find where the number of lives are defined. We've already seen how numbers are put into memory locations, and this is exactly what happens in most games.
(From now on, all the machine code programs discussed here will be written as hexadecimal bytes, and as mnemonics.)
3E XX LD A,XX (where XX is the number of lives) 32 XX XX LD (XXXX),A (where XXXX is a memory location, which we will refer to as the "lives store".)You have already come across these instructions, but just to resume, the number of lives is put in the A register, which in turn is put in the lives store, the overall result being the number of lives being put in the lives store.
To find this, use the search function on your disassembler (QUEST 16384 on STK), and search for 3E . So if you had five lives, you'd search for 3E 05. You may find that this instruction occurs a few times, but you will probably find that only one actually puts the value of A in a memory location straight away. If there appear to be two occurrences where the number of lives is put into a memory location, then you may have to test all of them. You can, in general, rule out memory locations in which the number of lives is put in twice.
If you want to confirm you've found the lives store, you need a Multiface. Load the game up, and while playing the game, alter the value in what you think is the lives store. If the number of lives varies, you've found the lives store. If not, try another possible location. If you can't find any memory location which looks like a lives store, you won't be able to forwards trace, I'm afraid, in which case you should try the backwards trace instead.
Once you've found the lives store, you'll have to search for occurrences of it. You are basically looking for code which takes the value out of the lives store and puts it in a register (normally the A register), decreases the number by one, and puts the new result back in the lives store. To get infinite lives, you have to overwrite the decrement instruction with a blank instruction so that the number of lives is left intact. The code you want normally takes one of two formats:
1st type: 3A XX XX LD A,(XXXX) where XXXX is the lives store 3D DEC A (we want to remove this) 32 XX XX LD (XXXX),A (putting the new value in the lives store)You may find that there are other instructions between these. Don't worry about what they mean, just ignore them.2nd type:21 XX XX LD HL,XXXX where XXXX is the lives store 35 DEC (HL) We want to remove this
In order to remove the decrement instruction, we have to do one of two things. The most common is to replace the DEC A or DEC (HL) with a NOP (code 00). If this gives you only one life, replace the DEC A with OR A (code B7), or replace the DEC (HL) with OR (HL) (code B6). Don't worry why!
BACKWARDS TRACE:
Also known as "backtracking", a backwards trace starts from the GAME OVER message, and goes back from there to the lives routine. It is normally used when a forwards trace does not work or is unsuitable (eg: when finding infinite energy), the easiest alternative is to use a backwards trace.
The first thing you need to do is to find out what message is printed on the screen when you die. Nine times out of ten it's "GAME OVER", but there are exceptions.
For GAME OVER you have to search for the following bytes : 47 41 4D 45 32 4F 56 45 52. This is GAME OVER in ASCII (look up the codes in Appendix A of the Spectrum manual if you like). Sometimes, you may not find it, in which case just search for 47 41 4D 45 (GAME in ASCII). If that search fails, then the GAME OVER text is not in an ASCII format (this is rare, because printing routines are considerably smaller when ASCII is used), and you can't do a backwards trace.
Once you've found the GAME OVER message, you need to find out which part of the program refers to it. Normally, a print routine will load a register with the address of the GAME OVER routine, then print it. One possible register is HL (as we have met before), but also two other registers called BC and DE. Normally, all of these three registers are referred to as "register pairs", because they are two registers, each the same size as the A register, working together, so they can address all of the memory. You want to look for the following:
01 XX XX LD BC,XXXX (where XXXX is the address of the GAME OVER MESSAGE) 11 XX XX LD DE,XXXX (as above) 21 XX XX LD HL,XXXX (as above)(Remember that XXXX will be written "backwards" in the game's machine code!)
You should only find one occurrence of any of the above instructions. If you can't find any, repeat the search but take one away from the address the GAME OVER text is. (This is because sometimes there are Spectrum ASCII control codes such as 16 XX for PAPER XX before the actual text, and these are referred to as the start of the message). If that doesn't work, repeat the search taking one away again. Keep doing this and you'll soon find one of the above instructions.
When you've found the instruction, note down where it occurs. The part of the code you are now in is part of the GAME OVER printing routine. What you now need to do is go back through the code until you find either the code C3 XX XX (which is JP XXXX), or C9 (which is RET, which behaves exactly the same way as RETURN in BASIC.) Alternatively, you may find a blank area of memory (00 00 00 00 00 00 etc.) The address after one of these instructions is the START of the GAME OVER routine.
When you've found the start of the GAME OVER routine, you can find out which part of the code calls it. Then, to get a cheat, you can remove all parts of the code which branch to the GAME OVER routine. Search for the address of the start of the routine. You will probably find some of the following:
CD XX XX CALL XXXX CC XX XX CALL Z, XXXX C4 XX XX CALL NZ, XXXX C3 XX XX JP XXXX CA XX XX JP Z,XXXX C2 XX XX JP NZ,XXXX...where XXXX is the start of the game over routine. JP is similar to GOTO in BASIC, while CALL is similar to GOSUB (so that a RET instruction will return to the instruction after the call - except in some protection systems, but more about that later).To cheat, simply poke all three bytes of the instruction you find with 00 (so as to disable the CALL or JP). And there you have it!
Using the techniques of forwards trace and backwards trace, you should be able to hack most old, unprotected games!
PART 3 - EASY LOADING SYSTEMS
So far, you've worked out the all important basics of hacking. However, there is another, equally important facet of hacking games that you should know about.
Few games these days are unprotected. They feature "protection systems" which prevent you from breaking into a program and fiddling about with it. The difficulty level varies, but in general they use two concepts - headerless loading and decryption.
Before we do anything, I should point out that you're going to need a disassembler from now on. The machine code listings in this book use Devpac's notation, but 007 Disassembler's notation is almost identical, except it uses decimal instead of hex. Hopefully, you shouldn't get lost if you use
Anyway, for now, we'll forget about decryption and concentrate of headerless loaders, since they're common to all protection systems.
A headerless loader will look something like this:
DD 21 XX XX LD IX,XXXX 11 XX XX LD DE,XXXX 3E FF LD A,#FF 37 SCF CD 56 05 CALL #0556...where XX can be any number from #00 to #FF. IX is another register similar to HL, but has slightly different properties, which you don't need to worry about right now. The value put into IX is always the start address of the block to be loaded, and the value put into DE is always the length of the block to be loaded. So the routine works exactly like loading and saving bytes in BASIC.
The only differences you should ever find are that the CALL is to a different address (#0556 is the ROM loading routine, so other CALLS are to turboloaders in RAM), the LD A,#FF has some other value loaded into A instead, or is missing, or the SCF is missing. Basically, if you see DD 21 XX XX 11 XX XX in a protection system, you can be pretty sure it will be used to load something.
Now we know how a headerless loader works, let's try and hack a real one. As an example, I've chosen Ethnipod, which was on the May 1991 YS Covertape.
First of all, load up STK at any address (I'd suggest 32768, but you don't have to) and press Z to BLOAD in the BASIC. Then use STK to list the basic, and you'll get the following:
10 BORDER 0: PAPER 0: INK 7: CLEAR 24999: LOAD "" CODE 65000: RANDOMIZE USR 65000Therefore, we should type in CLEAR 24999:LOAD "" CODE 65000 and restart the tape. When the OK message appears, stop the tape, load up your disassembler, and have a look at address 65000 (#FDE8). Here's a complete disassembly of the code you'll find there.
FDE8 21 00 40 LD HL,#4000 FDEB 11 01 40 LD DE,#4001 FDEE 01 FF 1A LD BC,#1AFF FDF1 36 00 LD (HL),#00 FDF3 ED B0 LDIRLDIR is a command we haven't met before, but it's easy to understand. It's a copying routine. The start address of the block you want to copy is put in HL, the length of the block you want to copy is put in BC, and the start address of the area of memory you want to copy it to is put in DE. So, in the example above, the area of memory from #4000 is copied to #4001 for #1AFF bytes. In short, this routine is overlaying each address in this area of memory with the byte of the previous address.
The LD (HL),00 means that byte #00 is put into address #4000. Therefore, the whole of the memory from #4000 to #5AFF is filled with 0. In case you didn't know, the whole of this memory is the screen memory, so this bit of code is what makes the screen black when loading the game normally. If you want, you can change the byte at #FDED to #00 to give LD DE,#0001, so the contents of the screen memory are copied into the ROM (except that they aren't because the ROM is a read-only memory and you can't write anything into it.) This will stop the screen going black. You don't actually need to do it at all, but there we go.
Continuting the disassembly:
FDF5 11 00 1B LD DE,#1B00 FDF8 DD 21 00 80 LD IX,#8000 FDFC 3E FF LD A,#FF FDFE 37 SCF FDFF CD 56 05 CALL #0556This portion of code loads in a block of code, with the start #8000 and the length #1B00.
FE02 3E 00 LD A,#00 FE04 D3 FE OUT (#FE),AThis part of the code includes an OUT instruction, but OUT in machine code is exactly indentical to that in BASIC. So, this routine is basically the equivalent of OUT 254,0 in BASIC. If you don't know what that does, it sets the border to black.
FE06 11 00 40 LD DE,#4000 FE09 21 00 80 LD HL,#8000 FE0C 01 00 1B LD BC,#1B00 FE0F ED B0 LDIRThis is another LDIR, and it moves the code from #8000 to #4000 for #1B00 bytes. In other words, it copies the screen picture into the screen memory so you can see it.
FE11 11 60 9D LD DE,#9D60 FE14 DD 21 B4 5F LD IX,#5FB4 FE18 37 SCF FE19 3E FF LD A,#FF FE1B CD 56 05 CALL #0556This part of code loads another block, with start 5FB4 and length 9D60.
FE1E C3 C7 61 JP 61C7This part of the routine jumps to the game itself once it is loaded.
To hack the game, replace the C3 at FE1E with C9. This will put a RET at the end of all the code, so the loader will return to BASIC when all loading has finished.
When the OK message comes up, you can hack the game as you've done with unprotected games. If you load STK into address #6000 (24576 decimal), and hack the game using a forwards trace, you'll eventually find that changing #EF09 to 0 gives you infinite lives for player one. Then to start the game, type RANDOMIZE USR 25031 (61C7 in decimal), and bingo!
To write a hack, we need to rewrite the BASIC loader, but make the modifications so we can put POKEs in:
10 CLEAR 24999 20 LOAD "" CODE 65000This comes directly from the BASIC loader and loads the small headerless loader code.
30 POKE 65054,201This means that control will return to BASIC when all the headerless code has been loaded
40 RANDOMIZE USR 65000This starts off the headerless loader.
50 POKE 61193,0This is the infinite lives POKE
60 RANDOMIZE USR 25031This starts the game itself. Easy when you know how!
Now we know how a simple headerless loader works, let's crack a turboloader. There are loads of YS covertape games which have a suitable loader, but I'm going to choose Pixy the Microdot 2, although you'll find that any YS game which uses blue, black and magenta stripes when loading is almost identical.
First of all, load up STK at address 58550 (you'll find out why later on), to find out what the BASIC loader has to say, using the same method as with Ethnipod. It starts running at line 0.
1 BORDER 0:PAPER 0:CLEAR 64999:LOAD "" CODE 2 RANDOMIZE USR 65146 20 CLEAR 64999:LOAD "mc" CODE:LOAD "pixldsy" CODE:SAVE "t:":SAVE "PIXY" LINE 1:SAVE "x" CODE 65146,200:LOAD "screen" SCREEN$:RANDOMIZE USR 65000The BASIC starts at line 1. The commands should be obvious to you. Type CLEAR 64999:LOAD "" CODE, start the tape, and load in the first block of code. Stop the tape when the OK message comes up.
Now load your disassembler and examine the code at 65146, which is FE7A hex.
FE7A F3 DIDI is short for "disable interrupts". What are interrupts, I hear you ask? Well, imagine you're watching TV when suddenly, someone says "We interrupt this program to give you an important newsflash!" Then, after the newsflash, the program you were watching resumes. Well, computer interrupts work in exactly the same way. In fact, every fiftieth of a second, a program is "interrupted" by the computer, which then checks to see if you're pressing any keys, and resumes the original program. The command DI simply stops this happening, and your program continues without any interruption! This makes the program run faster. However, you CANNOT get back to BASIC by a RET command, because the computer won't be checking the keyboard, and so it has effectively locked up. To get round this, you must execute the command EI (enable interrupts) first, so control can be resumed. Don't worry about doing this now, though.
FE7B 31 60 61 LD SP,6160This is a new instruction. SP (short for "stack pointer") is a 16-bit register, like BC, DE and HL. However, it's far more important as far as BASIC is concerned. In machine code, there are two ways of storing numbers. The first, using memory locations, we've already come across. However, there is another method by storing numbers on what is called a stack. Think of a stack as a big spike on which you can push pieces of paper with information on. Then, later on, you can take them off the stack and use them. If you think about it, if you put the numbers 1, 2 and 3 on the stack, in that order, you'll have to take 3 off first, then 2, then 1 (think about it). And it's the same in machine code. There are instructions which enable values of registers to be put on the stack, and which enable the value on the top of the stack to be taken off and put in a register.
The stack, like everything else, has to go somewhere in memory. The SP (stack pointer) register gives the address of the top of the stack. So LD SP,6160 will mean that the stack is to start at address 6160.
This is bad news if you want to return to BASIC, because the Spectrum's ROM program puts lots of information on the stack, so if you change the stack pointer, it's going to receive garbage when it takes all the values off what it thinks is the stack. And that, of course, will mean a crash. So the general rule is LEAVE THE STACK POINTER ALONE!
You can change the value of the stack pointer using CLEAR from BASIC. If a machine code instruction has LD SP,XXXX, you can type CLEAR (XXXX)-1. So here, we should CLEAR (#6160)-1 = #615F. Bear in mind that the value will have to be in decimal, which is 24927. So exit from STK, CLEAR 24927, and go back into it again. This will mean that later on we can do the EI / RET as described above. Then you have to remove the LD SP instruction, which is most easily done by changing FE7B to 21, so it reads LD HL,6160. This is harmless in this case.
Carrying on through the code....
FE7E DD 21 00 40 LD IX,4000 FE82 11 00 1B LD DE,1B00 FE85 CD 97 FE CALL FE97As you can probably see, this loads a headerless block, the loading screen, in fact. However, you'll notice, as I said eariler, that some of the other commands (LD A,#FF and SCF) are missing, and the CALL goes to a different address. This is because it's a turboloader.
FE88 DD 21 60 61 LD IX,6160 FE8C 11 4B 83 LD DE,834B FE8F CD 97 FE CALL FE97This loads another block, start 6160 and length 834B. This means, that all the memory from 6160 to E4AB will be overwritten. Fortunately, you loaded STK into address 58550, which is E4B6 hex, so it won't be overwritten. Clever, eh? Meanwhile....
FE92 30 F4 JR NC,FE88Something I haven't told you yet is that after a headerless load, a JR NC will result in that JR if there is a tape loading error. So, if there was a tape loading error in loading this game, the JR NC,FE88 would be executed (so that computer would try and reload the block).
FE94 C3 60 61 JP 6160This starts the main program running.
To crack the loader, therefore, POKE FE94 with FB (for EI) and FE95 with C9 (for RET), along with the modifications I've already told you about. Then RANDOMIZE USR 65146, and restart the tape (it is possible that you didn't stop the tape quickly enough the previous time, so you'll miss the turboload header, in which case wind back just before it). When the game has finished loading, an OK message will appear.
And that's it! Well, actually it's not, because the game is actually compressed, and needs to be unpacked first. Don't worry, because it's easy to hack. Go into STK again, and look at address 6160. You're looking for a JP instruction to the game, which is what is executed when the game is unpacked. You'll find it at 61A3. So POKE 61A3,FB and 61A4,C9 (for an EI / RET), and RANDOMIZE USR 24928. Wait a few seconds until BASIC returns. And there we are - you've cracked the loader!
You might be wondering how you can tell that the game is compressed. Well, there are two things. Firstly, the JP from the loader (6160) is to a very low address in the usuable RAM (which only starts at 5B00). But more noticeable, you won't be able to do a forwards trace or a backwards trace until you run the decompressor. In fact, in general, if you think you should be able to forwards trace or backwards trace a game for infinite lives, and haven't overloaded any important code with a disassembler, but nothing happens, its worth looking at the start of the code executed and seeing if there's a JP a bit later on to a completely different address.
So now, perhaps, we should write a complete hack for the game.
10 CLEAR 24927:LOAD "" CODEThis is from the BASIC loader and loads in the first block of code. We've changed the CLEAR though, so the stack is in the right place.
20 POKE 65147,33This changes the LD SP,6160 into LD HL,6160 so the SP isn't tampered with.
30 POKE 65172,251:POKE 65173,201This changes the JP 6160 to an EI / RET so control will return to our hack once the game has loaded.
40 RANDOMIZE USR 65146This starts the game loading
50 POKE 24995,251:POKE 24996,201This changes the JP 86CE to an EI / RET so control will return to our hack once the game has decompressed
60 RANDOMIZE USR 24928This starts the game decompressor.
70 POKE 28402,0This is the infinite lives POKE, which you'll find out when you do a forwards trace on the uncompressed game.
80 RANDOMIZE USR 34510This is the start of the game.
Now that you've done that, why not crack another game which uses the same loader? They're nearly all the same, except some of the JP addresses will be different. And then when you've done that, why not have a look at some other headerless loaders - most games by Codemasters use them.
You will find, however, that you will sometimes have to overwrite some of the memory with your disassembler. There's no easy way to tell where it should be, I'm afraid, so you'll have to take pot luck. If your forwards trace and backwards trace are both unsuccessful, try loading the disassembler elsewhere in memory, or look to see if the game is compressed.
PART 4 - DECRYPTERS
By this point, you should be familiar with headerless loaders, which take up the bulk of most protection systems these days. However, there is one other important aspect of protection that you need to know about if you are to crack the more complex protection systems. It's encryption.
Encryption works like a secret code. You start off with somthing unintelligable, then you use the "secret rules" to change it into something that makes sense. So, IBDLFST doesn't make much sense, but if you take the previous letter in the alphabet each time, you get HACKERS, which makes perfect sense. Encryption works in roughly the same way. We've already seen that a loading system occupies a small area of memory. An encrypted loading system will appear as a block of code which makes absolutely no sense whatsoever. There will also be a short program which changes all this nonsense into workable code so the loading system can be run. Some really tough loading systems, have more than one decrypter, such as the Alkatrazz loading system which has 250 of the damn things; in practice I've got through about 25 before going mad and hacking something else (don't worry, there's another way of hacking them which I'll tell you about later.)
To make it easier for you to understand decryption, its best to have a look at a real loading system. As an example, I've chosen Impossaball, which was on the YS#75 covertape. Load up STK at address 50000 (it's a safe address), and see what the BASIC has to say for itself by BLOADing it......
10 CLEAR 64530: LOAD "" CODE:RANDOMIZE USR 64531 20 LOAD "" CODE 16384 21 FOR i=1 TO 40 STEP - RANDOMIZE USR 50000Fair enough - so enter CLEAR 64530:LOAD "" CODE and start the tape. The first code block loads in, and then - it crashes! What's going on? Don't worry, you have just fallen victim to the first type of encryption - BASIC encryption.
In BASIC, any numerical constant (technotwaddle for "number") between 0 and 65,535 is stored in the memory as follows. First, there is the number in it's ASCII form, which takes between 1 and 5 bytes. So, the number 1234 will appear as #30,#31#,#32,#33 here. Then, come the numbers #0E,#00 and 00 (this is always the case). Then, there is the number stored in it's two byte form (as in machine code). What happens it that the computer prints the ASCII form (which is what you get when you LIST a program), but uses the two-byte form in calculations and expressions. The upshot of all this is that what you see isn't always what you get! As an example, type in this:
1 PRINT 1Now type POKE 23760,50 (which changes the ASCII value of the number 1 from "1" to "2"). Now if you LIST the program, you will see 1 PRINT 2, but if you RUN the program, the computer will print the number 1 instead!
Needless to say, protection systems use the same idea. Sometimes, the numbers listed are obviously fake (if you list a program and you get something like 0 CLEAR 0:RANDOMIZE USR 0 it's obviously got encrypted BASIC), but some programs, like the Impossaball are not obvious at all until you try executing what you see.
There was a program called *List printed ages ago in YS, but if you haven't got that, I've reprinted it here. So type it in, SAVE it to tape, RUN it and reload the Impossaball BASIC loader.
loading LINE 10 LEN 81
10 CLEAR 25599: LOAD "" CODE: RANDOMIZE USR 64512 20 LOAD "" CODE 16384 21 FOR i=1 TO 40 STEP ????....Now that's what you really get! Type CLEAR 25599:LOAD "" CODE and load in the first block of code. When that's done, load up your disassembler, and disassemble address 64512 (FC00 hex) to have a look at the decrypter.
FC00 01 99 02 LD BC,#0299 FC03 21 13 FC LD HL,#FC13 FC06 11 14 FC LD DE,#FC14This part of the program sets up all the initial values for the decrypters in some of the registers.
FC09 1A LD A,(DE)We've come across brackets before, but briefly what happens here is that the contents of the address with the value of the DE register (which starts of as #FC14) are put into the A register. So now the A register could contain any byte.
FC0A AE XOR (HL)We haven't seen XOR before, so I'll explain what it does. It is in technical terms a Boolean Operation. You may have seen XOR gates if you studied (or are studying!) Physics, Electronics or Computer Science at school. An XOR gate has two inputs, which can each either be 0 or 1, and one output, which can be either 0 or 1 as well. If the two inputs are the same (0 and 0, or 1 and 1), the output is 0, otherwise it is 1. In machine code, you XOR the A register with a number or contents of a register, and what happens is that each bit in the A register is XORed with the same bit in the number or register contents, and the result is stored in the A register. If you're confused, look at the example below.
Contents of the A register 00100101 Number to be XORed with 01010011 Result 01110110(Notice that all the numbers are in binary - see your Spectrum manual for more information about this).
If you still don't understand, just remember that an XOR will change the contents of the A register. That's all you need to remember for now.
Continuing the disassembly...
FC0B 77 LD (HL),AThis puts the value of A (which has just been changed) into the bytes at the address with the value of the HL register (which starts off as #FC13).
So, the routine has basically taken a byte out of a memory location, changed it a bit, and put the altered value back again. This is decryption in its most obvious form - the changed values make up a working machine code program.
FC0C 23 INC HL FC0D 13 INC DE FC0E 0B DEC BCI don't think I've mentioned INC before, but it's basically the opposite of DEC in that it increases the value in whatever register. So the values in the HL and DE registers are incremented, and the value in the BC register is decremented.
FC0F 78 LD A,B FC10 B1 OR C FC11 20 F6 JR NZ,#FC09This is a standard piece of code, and it essentially means "If BC isn't 0, then jump to #FC09". In other words, another byte will be decrypted until the value of BC is 0 (which happens when everything has been decrypted), and the decrypter ends.
Continuing the disassembly...
FC13 5C LD E,H FC14 9F SBC A,A FC15 A5 AND L FC16 5B LD E,E FC17 13 INC DE FC18 5B LD E,E ....Hang on - this code doesn't make sense! It has no relation to the code above, and the instruction LD E,E is pointless anyway. Well, you'll remember that the initial value of decryption is #FC13, which means that all the code from there onwards has to be decrypted. So we'll have to crack the decrypter to go any further.
Sometimes, it is possible to put an EI/RET instruction directly after the decrypter, but this is not possible here, as you will see. So instead, we'll have to move the decrypter somewhere else in memory, and put the EI/RET on the end (in actual fact we don't need the EI because there is no DI command in the decrypter). This is easily done by using the LDIR command. Type in the following program:
1 FOR N=23296 TO 23310:INPUT A:POKE N,A:NEXT NNow RUN it and enter the following numbers:
33,0,252,17,128,91,1,1,18,0,237,176,54,201,201
The program you have just typed in is this:
LD HL,FC00 LD DE,5B80 LD BC,0012 LDIR LD (HL),C9 RETNow RANDOMIZE USR 23296 and the decrypter will be copied to 5B80 and a RET will be stuck on the end. Just RANDOMIZE USR 23424 (5B80 in decimal) to run the decrypter. When the OK message comes up, restart the disassembler and look at FC13 again:
FC13 C3 3A FE JP #FE3AThis jumps to #FE3A, to start the loading.
FE3A F3 DI FE3B 21 00 58 LD HL,#5800 FE3E 11 01 58 LD DE,#5801 FE41 01 FF 02 LD BC,#02FF FE44 36 00 LDIRAs you already know, this makes the screen black.
FE48 CD 81 FE CALL #FE81 FE4B CD 00 80 CALL #8000If you look at the code at #FE81, you'll see it's a headerless loader. The routine at #8000 prints the loading screen.
FE4E CD 81 FE CALL #FE81 FE51 CD 00 64 CALL #6400This loads another block (the main game), and prints another screen (the border for the game).
FE54 F3 DI FE55 31 FF FF LD SP,#FFFFThis disables interrupts and changes the stack pointer, so we'll have to change that in the final hack.
FE58 21 00 6D LD HL,#6000 FE5B 11 00 5B LD DE,#5B00 FE5E 01 00 8F LD BC,#8F00 FE61 ED BO LDIRThis is another LDIR command, but if you know how the Spectrum's memory is organised, you will see that the BASIC system variables are overwritten, which means we can't return to BASIC when the game has loaded. Fortunately, there's a short routine to get round this, which I'll explain in a mo.
FE63 21 71 FE LD HL,#FE71 FE66 11 00 F0 LD DE,#F000 FE69 01 10 00 LD BC,#0010 FE6C ED B0 LDIR FE6E C3 00 F0 JP F000This moves the code from FE71 to F000, and jumps to F000. Obviously, then, the code at FE71 is important.
FE71 21 00 FC LD HL,#FC00 FE74 11 01 FC LD DE,#FC01 FE77 01 FF 01 LD BC,#01FF FE7A 36 00 LD (HL),0 FE7C ED B0 LDIR FE7E C3 00 80 JP #8000This routine wipes out all the memory from #FC00 to #FC01, but in actual fact you don't need to do this. Then it jumps to #8000, which is the start of the game. So, we can put a machine code routine to put a POKE in, and then jump to #8000.
However, we've got to find the POKE first, and there's the problem that we can't use BASIC because it is overwritten. Luckily, there is a short routine you can use which will cause a NEW to a certain address. Put it into the above program by typing in the following:
1 FOR N=65137 TO 65144:INPUT A:POKE N,A:NEXT NThen RUN it, and enter these numbers in turn:
243,175,17,0,95,195,203,17
The program you've just typed in is the following:
DI XOR A LD DE,#5F00 JP #11CBDI disables interrupts, XOR A loads A with 0 (think about what would happen if you XORed the value of the A register with itself, LD DE,#5F00 means we want to NEW up to #5F00 (this value can be changed from about #5D00 to #FFFF), and JP #11CB starts the NEW.
Now RANDOMIZE USR 65082 (#FE3A in decimal), and restart the game tape. When the computer resets, you can load STK into address 24320 to find POKEs.
Phew! And that's about all of that protection system cleared up. If you can get your way through that lot, I think you're probably ready to have a go at a "commercial" protection system. First, though, we'll write a complete hack for the game.
10 CLEAR 25599:LOAD "" CODEThis is from the BASIC loader, and it loads in the first machine code block
20 FOR N=23296 TO 23310:READ A:POKE N,A:NEXT NThis line POKEs in the machine code program to move the decrypter.
30 DATA 33,0,252,17,128,91,1,19,0,237,176,54,201,201And here's the actual machine code itself
40 RANDOMIZE USR 23296This line calls the decrypter and returns to BASIC
40 FOR N=65137 TO 65143: READ A:POKE N,A:NEXT NThis line POKEs in our hacking program
50 DATA 175,50,??,??,195,0,128And here's the hacking program, which loads ???? with 0 (which is the infinite lives POKE), and jumps to #8000.
60 RANDOMIZE USR 65082This starts the whole loading system off, with the POKE firmly in place.
And that's about it. A bit of a long piece of work, but it was worth it!
PART 5 - Advanced Hacking Methods
Remember in Part 2, when I said there were other ways of hacking, apart from forwards and backwards tracing? Well, you can find them here. But you need a Multiface to be able to use them. The two we're interested with here are what I call a stack trace and an interrupt trace.
STACK TRACE:
We've already come across the stack as a means of storing numbers. What you haven't come across yet is how the stack is used. Well, in a CALL to a subroutine, what actually happens is that the return address from the subroutine (which is the address after the CALL instruction) is stored on the stack, and with a RET, the top value of the stack is taken off and jumped to.
With a Multiface, the value on the top of the stack is the return address to the program. and subsequent values refer to return addresses in subroutines.
To do a stack trace, load and play the game, and wait until the "death effect" occurs - this may be a beep, a flashing border or something else recognisable. Now quickly press the Multiface button during this effect - if you're too slow, you won't get the values you're looking for (so return to the game and die again). Now, look at the value of the stack pointer (your Multiface manual will tell you how to do this), and write down all the values on top of the stack for the first ten bytes. All numbers are stored in the normal reversed two-byte form, so if the bytes on the top of the stack were #00,#80,#80,#70,#90,#60, the values would be #8000,#7080 and #6090. Have a look at all of these addresses - you should find that some of them are addresses right after CALL instructions.
Now for the hacking bit - go to one of these address and write down the two bytes there. Then change them to the magic codes #18 and #FE (this is the machine code version of JR -2, which is an endless loop, a bit like 1 GOTO 1 in BASIC). Restart the game, and hopefully, you'll find that the game pauses as soon as you do something which would normally result in you losing a life! (If not, replace the #18FE with the original two bytes, look at another address on the "hit list" and repeat the whole procedure).
Once you've found a target address, try putting a RET (#C9) at the start of the subroutine. If this just cancels the death effect, but you still "die", activate the Genie Disassembler if you have it (or use the NEW routine in Part 4 at any address, then load in STK or Devpac somewhere far away from the area of memory you're looking at), and search for CALLs to this routine. Then go back from this CALL until you find a RET or a JP, and search for the address of the instruction after this (if nothing comes up, search for one more than this, then two more etc.). You will hopefully either see one of these:
JP Z JP NZ JP C JP NC(The JP may be a JR or a CALL instead)
Simply overwrite this instruction with NOPs to get immunity or something similar.
On the other hand, when searching from the CALL address, you may find a JP Z or JP NZ, etc. Change this to an unconditional JP to get immunity.
INTERRUPT TRACE:
This involves looking at the interrupt routine in the game. Since the whole routine must be executed in 1/50th of a second, the routines are usually quite short, especially if there is a LDIR or something similar. Most of the time you'll find infinite time in this routine (because interrupts work in real time, so its an ideal place to put a time routine), and you need a Multiface to find it.
Load the game and start playing as normal. Then activate the Multiface, and have a look at the I register. If the value is #3F, there are no special interrupts, so forget about an interrupt trace altogether (but you can use a stack trace which will make the clock loop round to 99 or whatever when it reaches 0). If it is between #80 and #FF (and if it's not in that range and not #3F you've probably crashed the computer!), go to the address #100 time that of the value in the I register (so if the value of I is #F0, look at #F000). You will see an area of memory filled with the same number. Go to this address (if this area of memory is filled with #FE, go to #FEFE etc.) There will either be a jump to the interrupts routine, or the interrupts routine itself. Have a look at the routine, and somewhere you will see the commands to decrease the timer - just remove the DEC instruction to get infinite time.
PART 6 - Commercial Protection Systems
If you can understand everything we've done so far, you can now probably crack just about any budget game or YS covergame that's thrown at you. And indeed, you can probably get featured in "Practical POKEs" month in month out (like a load of anonymous hackers, I might add!) by using the knowledge you've got. However, if you want to become a hacking legend, you should have a go at some of the numerous commercial protection systems, which have been written by freelancers for software houses.
I think we're getting seriously into Multiface territory now, but I'll try and do as much as possible with only STK and 007 Disassembler.
I think I should also say that cracking commercial protection systems is NOT easy. The code is deliberately badly structured and obscurely coded to put you off, so you'll have to perservere. You really do need something like a Multiface or Devpac to crack some of these systems, because they can overwrite the system variabes in BASIC, and you sometimes need to know the values of certain registers, which is impossible to determine using BASIC. You'll also need some games other than YS stuff to hack, but fortunately, protection systems such as Speedlock or Alkatrazz are so common, you're bound to have a game with one of them on. I'll be doing examples specific to one game, but you'll find that onther game with the same protection is pretty much the same, except you're likely to find that some of the addresses will be different.
Before we start, I'd just like to point out that I'll be referring to the term "breakpoint" a lot. This is simply a small bit of code which will stop the program dead in its tracks. Using DEVPAC, you just press the W key. On a Multiface, you do the same as a stack trace, by writing down the two bytes at the place you want to put a breakpoint, then replacing them with #18 and #FE. If you are using 007 disassembler and/or STK, you'll need to put a jump to the start of the program (#C3 #00 #40 for 007 disassembler; STK varies depending on where you put it).
So let's start with something relatively simple....
BLEEPLOAD
"Bleepload" first appeared on Firebird games around March 1987, and was used by them on every release by them from then on until their demise in 1989. It emulates a BBC loading system in that each file loads in a series of blocks, which are numbered in hexadecimal. The hardness is not because it uses non standard cde, it's just that it jumps around so much in memory you need to put in an awful lot of software patches.
I'll be hacking Bubble Bobble as an example.
First of all, load in *Hack, and load in the BASIC loader.
Bubble LINE 10 LEN 179
10 REM 20 CLEAR 50000 30 BORDER 0:PAPER 0:INK 0:CLS 40 PRINT AT 1,7;PAPER 1;INK 7;"BUBBLE BOBBLE" 50 LOAD "Bobble" CODE 52480 60 RANDOMIZE USR 52480There is absolutely nothing difficult about this BASIC loader, so just type CLEAR 50000:LOAD "" CODE and start the tape to load the first block of code. Stop the tape when it's loaded, and load in your disassembler into address 32768 (it's a safe one), and have a look at the code at CD00.
CD00 3A 5C 5B LD A,(#5B5C) CD03 32 00 60 LD (#6000),AThis takes the byte at #5B5C and puts it in #6000. #5B5C is the system variable for the 128K page number, in case you're interested.
CD06 3E 02 LD A,#02 CD08 CD 01 16 CALL #1601This is a standard ROM routine, and all it does it to tell the computer we want to print something on the screen.
CD0B AF XOR A CD0C 32 6B 5C LD (#5C6B),AAs you may be aware, poking #5C6B (23659 decimal) with 0 will cause the computer to crash if you press BREAK or return to BASIC. So POKE CD0E,0 which changes it to LD (#006B),A; this is harmless.
CD0F CD CE CE CALL #CECEThe routine at #CECE prints the message "Searching" on screen.
CD12 10 09 DJNZ #CD1DWe haven't come across the command DJNZ before. It basically means "decrease the value in the B register, and jump if B is not zero."
CD14 11 08 FF LD DE,#FF08 CD17 16 00 LD D,0 CD19 CD 1A CE CALL #CEA1This routine prints the number 00 on screen.
CD1C 3E 08 LD A,#08 CD1E 32 15 FF LD (#FF15),A CD21 CD 74 CD CALL #CD74This routine loads in a block of code from tape (in actual fact the start address is #FE00 and its length is #100 bytes).
CD24 3E 00 FA LD A,(#FE00) CD27 FE 64 CP #64 CD29 20 F6 JR NZ,#CD21This routine loads A with the value at #FE00. The CP instruction compares the value in the A register with something, in this case the number #64. If there is no match, the routine jumps back to #CD21, otherwise it continues. This routine actually checks to see if the block is found.
CD2B 3A 01 FF LD A,(#FF01) CD2E BA CP D CD2F 28 05 JR Z,#CD36This routine checks to see if the block has been loaded successfully. If so, it jumps to #CD36, otherwise it continues.
CD31 CD 84 CE CALL #CE84 CD34 18 EB JP #CD21This routine prints up the "loading error" message, and attemps to load the block again.
CD36 CD 30 CE CALL #CE30The routine at #CE30 is a decrypter (have a look - do you see why?), which decrypts the block loaded in ie: from #FE00 to FEFF.
You don't need to crack it yourself.
CD39 BE CP (HL) CD3A 28 05 JR Z,#CD41This routine reloads the block if the value of A equals the value at (HL). Don't ask me why.
CD41 CD 5F CD CALL #CD5FThis routine moves the code at #FE00 to where it should really be in memory.
CD44 CD 5D CE CALL #CE5DThis routine prints the "loading" message on the screen, but this should in actual fact be "loaded", because the block has just been read in at this point of the code.
CD47 21 04 FF LD HL,#FF04 CD4A 7E LD A,(HL) CD4B 23 INC HL CD4C 3D DEC A CD4D 20 FC JR NZ,#CD4B CD4F 23 INC HL CD50 23 INC HL CD51 23 INC HL CD52 23 INC HL CD53 7E LD A,(HL) CD54 2B DEC HL CD55 2B DEC HL CD56 2B DEC HL CD57 E6 07 AND #07 CD59 3C INC A CD5A 32 15 FF LD (#FF15),A CD5D 14 INC D CD5E E9 JP (HL)This routine starts off with HL as FF04, then does a lot of sums, and comes out with a value in the HL register, which it jumps to after its loaded the block. This is what we need to hack. So POKE CD5E with C9 and RANDOMIZE USR 52480 - you'll find out it loads in one block and then stops. However, this isn't much use as you can't find out the value of the HL register. So put this routine somewhere, such as #5B00.
5B00 CD 00 CD CALL #CD00 5B03 22 10 5B LD (#5B10),HL 5B06 C9 RETThis routine simply loads the first block, and puts the value of HL in #5B10 so we can find out what it is from BASIC.
Now rewind the tape before the first Bleepload block again, and RANDOMIZE USR 23296. When that's finished, type PRINT PEEK 23312+256*PEEK 23313. You should get the answer 65293, which is #FF0D. Disassemble this address. FF0D C3 21 CD JP #CD21 This will go back and load the next block from tape. We can crack it in the same way as the first be changing our routine at 5B00.
5B00 CD 00 CD CALL #CD00 5B03 CD 21 CD CALL #CD21 5B06 22 10 5B LD (#5B10),HL 5B09 C9 RETNow wind the tape back to the first Bleepload block again, RANDOMIZE USR 23296 and start the tape. When the OK message comes up, type PRINT PEEK 23312+256*PEEK 23313, and you should get 65286 which is FF06 hex. Disassemble this address.
FF06 C3 21 CD JP #CD21This goes back and loads another block. By now, you might have guessed that the value of HL will always contain the address of a JP #CD21 instruction - except for the last block which will jump elsewhere. Now we can write a routine which will load any block as long as it jumps to #CD21 at the end. I'm putting the routine at #CCEC, because it's right next to the loading system, and hence is unlikely to be overloaded (although it could be, in which case we'd just put the routine elsewhere). The routine goes like this.
CCEC CD 00 CD CALL #CD00This is just loading the first block
CCEF CD 21 CD CALL #CD21This loads in a block from tape.
CCF0 23 INC HL CCF1 7E LD A,(HL) CCF2 2B DEC HLThis routine loads the A register with the value of (HL+1). This will be #21 if another block is to be loaded.
CCF3 FE 21 CP #21 CCF5 20 02 JR NZ,#CCF8 CCF6 18 F7 JR #CCEFThis compares the value in the A register to 21. If there is no match, then the routine jumps to the end to preserve the value of HL, and to return to BASIC. Otherwise, it goes back to load another block.
CCF8 22 FE CC LD (#CCFE),HL CCFBThis puts the value of HL in address #CCFE, then returns to control of the disassembler.
Now, run this routine (RANDOMIZE USR 52463), rewind to the first Bleepload block, and start loading. The program will now load blocks 00-2D, and return to control of the disassembler. The value at #CCFE is #FF06, so disassemble this address.
FF06 C3 00 5B JP #5B00Now disassemble #5B00, which is the real meat of the loading system!
5B00 DD E5 PUSH IX 5B02 CD 74 CD CALL #CD74 5B05 CD 30 CE CALL #CE30 5B08 28 07 JR Z,#5B12 5B0B 06 00 LD B,#00 5B0D CD 84 CE CALL #CE84 5B10 18 F0 JR #5B02This routine loads in another block of code, and will jump to 5B12 when it has been successfully loaded.
5B12 F3 DI 5B13 E1 POP HL 5B14 2E 00 LD L,#00 5B16 ED 5B E7 FE LD DE,(#FEE7) 5B1A 1A LD A,(#DE) 5B1B AE XOR (HL) 5B1C 24 INC H 5B1D AE XOR (HL) 5B1E 25 DEC H 5B1F 12 LD (#DE),A 5B20 2C INC L 5B21 IC INC E 5B22 20 F6 JR NZ,#5B1AThis routine is a decrypter, which decrypts some of the code we just loaded in from tape.
5B24 ED 5B E7 FE LD DE,(#FEE7) 5B26 21 40 5B LD HL,#5B40 5B2B 1A LD A,(DE) 5B2C AE XOR (HL) 5B2D 77 LD (HL),A 5B2E 1C INC E 5B2F 2C INC L 5B30 20 F9 JR NZ,#5B2BThis code decrypts some more code loaded in from tape, but it puts it at #5B40, which is right in the middle of the code we are working on at the moment. So put a breakpoint at #5B32 (the first instruction after the decrypter), and jump to #5B00 (because we haven't executed any of the code from #5B00 onwards yet!)
5B32 21 00 00 LD HL,#0000 5B35 22 B0 5C LD (#5CB0),HL 5B38 2E 02 LD A,#02 5B3A 32 6B 5C LD (#5C6B),AThis puts the value #0000 into #5CB0, but I'm not sure why, because #5CB0 is an unused system variable. It then changes the value of #5C6B to #02, which is what it was originally before it was changed to protect the loader.
5B3D ED 5B E7 FE LD DE,(#FEE7) 5B41 2A E9 FE LD HL,(#FEE9) 5B44 1A LD A,(DE) 5B45 AE XOR (HL) 5B46 77 LD (HL),A 5B47 23 INC HL 5B48 IC INC E 5B49 20 F9 JR NZ,#5B44 5B4B 3A EC FE LD A,(#FEEC) 5B4E BC CP H 5B4F 20 F3 JR NZ,#5B44This is another decrypter, which works in exactly the same way as the others.
5B51 31 FF 60 LD SP,#60FF 5B54 21 00 CF LD HL,#CF00 5B57 11 00 40 LD DE,#4000 5B5A 01 00 1B LD BC,#1B00 5B5D ED B0 LDIR 5B5F 21 00 EA LD HL,#EA00 5B62 11 00 61 LD DE,#6100 5B65 01 00 10 LD BC,#1000 5B68 ED B0 LDIRThis code moves all the decrypted code to where it should be. This includes the loading screen (as you can see by the reference to #4000.)
5B6A 3E 65 LD A,#65 5B6C 32 00 5B LD (#5B00),A 5B6F 21 0F 14 LD HL,#140F 5B72 22 01 5B LD (#5B01),HL 5B75 21 0F 00 LD HL,#004F 5N78 22 03 5B LD (#5B03),HL 5B7B CD 00 FA CALL #FA00This code loads the next Bleepload block, from 00 to 87, but will return to 5B7E when it's finished.
5B7E 21 00 40 LD HL,#4000 5B81 11 01 40 LD DE,#4001 5B84 36 00 LD (HL),0 5B86 01 FF 1A LD BC,#1AFF 5B89 ED B0 LDIR 5B8B 3E 66 LD A,#66 5B8D 32 00 5B LD (#5B00),A 5B90 21 0A 0A LD HL,#0A0A 5B92 22 01 5B LD (#5B01),HL 5B96 21 0D 0A LD HL,#0A0D 5B99 22 03 5B LD (#5B03),HL 5B9C CD 00 FA CALL #FA00This code blanks out the screen and loads some code into it. Some Bleepload games do not have this code, and it is only used on games whos game code overwrites the loading system at #FA00.
5B9F 21 00 40 LD HL,#4000 5BA2 11 00 FA LD DE,#FA00 5BA5 01 00 06 LD BC,#0600 5BA8 ED B0 LDIRThis moves the code loaded from the screen to #FA00 (where it should be).
5BAA 3A 00 60 LD A,(#6000) 5BAD 32 5C 5B LD (#5B5C),A 5BB0 31 A7 61 LD SP,#61A7 5BB3 CD 8E 02 CALL #28E 5BB6 28 1D JR Z,#5BD5This routine restores the value of #5B5C that was stored in #6000 right at the very start. It then sets the stack to #61A7, and calls the ROM keycheck routine. If no key is pressed (and there shouldn't be), the routine jumps to 5BD5. In fact, it must jump there, otherwise it would attempt to load a normal headerless block, and there are none!
5BD5 C3 BC F5 JP #F5BCThis is what we've all been waiting for - the JP to the game itself. You can simply put POKEs on the end of #5BD5, and follow them with a JP #F5BC to load the game. For now, though, it might be a good idea to put the NEW routine up to #61A7 there, instead, and JP to #5B32 (where we left off). Then load the rest of the game, which will reset at the end, enabling you to load in STK, Devpac or whatever.
Now we've gone all the way through Bleepload, perhaps we should write a hack for the complete game. However, I'm going to put most of the hack in machine code, rather than have long lines of decimal DATA statements. You should be able to convert the machine code into DATA statements and get a short program which reads them in and POKEs them into memory.
The only thing that has to be done from BASIC is the CLEAR 50000:LOAD "" CODE 52480 from the BASIC loader. The machine code hack will consist of the first routine we wrote, followed by a few patches to the main loading system, so that the JP to the game is overwritten with our POKEs. I'll be putting it at #CC80, because it's a safe place in memory.
CC80 3E C9 LD A,#C9 CC82 32 5E CD LD (#CD5E),AThis puts a RET in place of the JP (HL) at #CD5E so we can CALL the loading system.
CC85 CD 00 CD CALL #CD00This loads in the first Bleepload block.
CC88 CD 21 CD CALL #CD21This loads in another Bleepload block.
CC8B 23 INC HL CC8C 7E LD A,(HL) CC8D 2B DEC HL CC8E FE 21 CP #21 CC90 20 02 JR NZ,#CC94 CC92 18 F4 JR #CC88This checks to see if all the Bleepload blocks have been loaded, and jumps ahead if they have, otherwise it jumps back to load the next block.
CC94 3E C3 LD A,#C3 CC96 32 32 5B LD (#5B32),A CC99 21 A1 CC LD HL,CCA1 CC9B 22 33 5B LD (#5B33),HL CC9E C3 00 5B JP #5B00This puts the instruction JP #CCA1 at #5B32 so the loader decrypter will return to our hack at #CCA1 when finished.
CCA1 21 B2 CC LD HL,#CCB2 CCA4 11 D5 5B LD DE,#5BD5 CCA7 01 08 00 LD BC,#0008 CCAA ED B0 LDIRThis copies the final part of our hacking routine to #5BD5, where it will be executed once the whole game has been loaded.
CCAC 21 00 00 LD HL,#0000 CCAF C3 35 5B JP #5B35The LD HL,#0000 instruction is important, because it's the instruction we overwrote with out JP back to the hack. Therefore, we've got to execute it, otherwise the loading system may crash. Then it resumes loading at #5B35 with the POKEs firmly in place.
CCB2 3E B6 LD A,#B6 CCB4 32 5F AB LD (#AB5F),A CCB7 C3 BC F5 JP #F5BCThis is the hacking routine which will be copied into the loading system. AB5F,B6 is the POKE for infinite lives (which can be worked out by a forwards or a backwards trace), and JP #F5BC jumps to the game.
And that's about it for Bleepload! Hopefully, if you were hacking a different game, you still managed to do it (they're all virtually identical anyway).
ULTIMATE LOADER
Remember Ultimate? They were one of the finest software houses of all time. Most of their games from 1983 to 1987 had the same type of loader (but a few were Speedlocked - more about them later). On the face of it, it just looks like a totally unprotected BASIC loader, but the appearance is deceptive. The five blocks it loads are the loading screen, the game itself, a decrypter at #5B80, and two very short blocks of system variables. The system variables are, in actual fact the BASIC clock, and determine how many 50ths of a second the computer has been switched on for. The decrypter works using this system variable. The upshot of all this is that if you stop the program for even 1/50th of a second, you'll mess up the decrypter. You can get round this with a Multiface by loading in the first three blocks of code, then replacing the code at #5B80 with #F3,#18 and #FE. This disables interrupts, so the system variable doesn't get updated, and causes an endless loop. Load in the last two blocks, activate the Multiface, and find out what the system variable should be. Then you can put this into the decrypter automatically.
MIKRO-GEN LOADER
This loading system appeared on just about every game released by the software house Mikro-Gen (oddly enough!) from about mid-84 to their demise in 1987. They come in two varieties, and you'll need a Multiface to hack some of the later ones, unfortunately.
The first type are recognised by black and white loading stripes, which loads in a screen block, and then the main game block separately. I'll be doing Pyjamarama as an example, but any Mikro Gen game which fits the above description will do.
So the first thing to do is to *Hack the BASIC loader.
PYJAMARAMA LINE 0 LEN 504
0 BORDER 7:PAPER 7:INK 0:BRIGHT 0:FLASH 0:CLS:PRINT AT 12,12;"LOADING":RANDOMIZE USR (PEEK 23627+256*PEEK 23628+6) 20 POKE 23756,0:POKE 23757,0:SAVE "PYJAMARAMA" LINE 0:RANDOMIZE USR 33040The BASIC loader actually features much more than what we can list. If you're old enough to remember the ZX81, you'll recall that the best place to put a machine code program is in a REM statement. And that's almost the case here, except the machine code comes after the ASCII code #0D (newline), so you can't list it. But it's there. It's activated by the RANDOMIZE USR command. Type PRINT (PEEK 23627+256*PEEK 23628+6) and you'll find out the start address of the code. I made it 23984, which is 5DB0 hex (but you might find it to be something different), so disassemble this address.
5DB0 F3 DI 5DB1 31 00 00 LD SP,#0000 5DB4 2A 4B 5C LD HL,(#5C4B) 5DB7 11 1C 00 LD DE,#001C 5DBA 19 ADD HL,DE 5DBB 11 16 80 LD DE,8016 5DBE 01 E7 00 LD BC,00E7 5DC1 ED B0 LDIR 5DC3 C3 16 80 JP 8016Hopefully the DI and the LD SP,#0000 should be familiar. The next line loads HL with the two byte value starting at 5C4B. I made it 5DAA. This then has 1C added onto it, making it 5DC6. The rest of the code is a simple LDIR command, which puts the loading system to where it should be.
In our hack, we can simply use a headerless loader to load the code into place. We know that 5DC6 goes to 8016. BASIC always starts at the value in #5C53, which is #5CCB in this case. We know that the length is 504, or #1F8 hex bytes long, and the start address is (#5CCB-#5DC6)+8016 = #7F1B. So, run the following routine.
5B00 DD 21 1B 7F LD IX,#7F1B 5B04 11 F8 01 LD DE,#01F8 5B07 3E FF LD A,#FF 5B09 37 SCF 5B0A CD 56 05 CALL #0556 5B0D 30 F1 JR NC,#5B00 5B0F C9 RETI've put a JR NC,#5B00 in, so that the computer ignores the BASIC header, and will only return on loading the main BASIC block. You should also note, that in the final hack, we'll have to add a DI and a LD SP,#0000 sometime. For now, disassemble #8016
8016 DD 21 00 40 LD IX,#4000 801A 11 01 1B LD DE,#1B01 801D CD 4F 80 CALL #804FThis code activates the turboloader, which loads in the title screen.
8020 21 00 40 LD HL,#4000 8023 01 00 1B LD BC,#1B00 8026 CD 3F 80 CALL #803FThis code verifies that the screen has loaded in properly (the routine at #803F adds up all the memory with start HL and length BC, and compares it with the byte after this block), and resets the computer if it hasn't.
8029 DD 21 00 82 LD IX,#8200 802D 11 A0 7A LD DE,#7AA0 8030 CD 4F 80 CALL #804F 8033 21 00 82 LD HL,#8200 8036 01 9F 7A LD BC,#7A9F 8039 CD 3F 80 CALL #803FThis is exactly the same as with the previous code, except it loads and checks the main game instead of the loading screen.
803C C3 89 FC JP #FC89Put a breakpoint over this instruction. Now POKE #8012 with F3, #8013 with #31, #8014 with #00 and #8015 with #00 (because we didn't execute the DI:LD SP,#0000 from the BASIC loader, and the game will not load otherwise), JP #8012 and start the tape. When the main game's loaded, disassemble #FC89.
FC89 21 EF B4 LD HL,#B4EF FC8C 11 00 40 LD DE,#4000 FC8F 01 00 1B LD BC,#1B00 FC92 1A LD A,(DE) FC93 AE XOR (HL) FC94 77 LD (HL),A FC95 23 INC HL FC96 13 INC DE FC97 0B DEC BC FC98 78 LD A,B FC99 B1 OR C FC9A 20 F6 JR NZ,#FC92 FC9C C3 EA BE JP #BEEAThis decrypter uses values in the screen memory, so you'll have to put a breakpoint at FC9C, put a JP #FC89 at #8029, JP to #8012 and reload the loading screen before you can run it. Then disassemble #BEEA.
BEEA 31 00 00 LD SP,#0000 BEED CD CC BE CALL #BECC BEF0 C3 00 82 JP #8200This code puts the stack pointer back at #0000, CALLs another decrypter, and JPs to #8200, which is the start of the game. Change the #8200 to a suitable place to put POKEs; finish them with a JP #8200 to start the game.
Here's the final hack, and I've put it at #5B00, because it doesn't get overloaded, apart from the byte at #5B00 itself, which is no longer needed by that time. Also, I've executed the DI:LD SP,#0000 directly, as well as the code from BEEA to BEF2.
5B00 DD 21 1B 7F LD IX,#7F1B 5B04 11 F8 01 LD DE,#01F8 5B07 3E FF LD A,#FF 5B09 37 SCF 5B0A CD 56 05 CALL #0556 5B0D 30 F1 JR NC,#5B00 5B0F 21 1C 5B LD HL,#5B1C 5B12 22 3D 80 LD (#803D),HL 5B15 F3 DI 5B16 31 00 00 LD SP,#0000 5B19 C3 16 80 JP #8016 5B1C 21 25 5B LD HL,#5B25 5B1F 22 9D FC LD (#FC9D),HL 5B22 C3 89 FC JP #FC89 5B25 31 00 00 LD SP,#0000 5B28 CD CC BE CALL #BECC 5B2B AF XOR A 5B2C 32 ?? ?? LD (????),A 5B2F C3 00 82 JP #8200The other type of Mikro Gen loader is almost identical, except the whole game loads in one long block. Then end of the BASIC loading system is missing to start with, and is only loaded right at the end of the main headerless block. You can find out the missing code by loading the game as normal, then stopping it with a Multiface in the pause between the game loading, and the game starting (approx. 3 seconds), and hack it in the same way as Pyjamarama.
POWERLOAD
This protection system appeared first around the start of 1984, and was written by "Tag" (Phil Taglione) for Incentive Software. However, it's been used by quite a lot of other software companies as well, including Beyond, Mirrorsoft, Prism and Ariolasoft. It can be recognised by the screen turning black, accompnied by a few ascending beeps. It then loads one short headerless block, and then a longer headerless block, which includes the attribute file for the game coming up "backwards" ie: right to left, starting from the bottom. The game also stops loading just before the end of the long headerless block.
The only thing I know of that YS have put on the covertape that has Powerload is the Graphic Adventure Creator, but that's pointless hacking, so instead I'll be hacking Dynamite Dan. Of course, most other Powerload games are identical apart from some addresses, and, in fact, the BASIC loaders are all identical.
Before we start, I need to explain a little more about the stack, because Powerload uses it a lot. There are four commands which use the stack, and they are:
PUSH X (where X is any register) - this takes the value in a register, and puts it onto the stack. The stack pointer then decreases by two (to be in the right place to store another value).
POP X - this takes the two byte value at the stack pointer (ie: the top of the stack), and puts them in a register. This also increases the stack pointer by two.
CALL XXXX - when you CALL a subroutine, the return address (ie: the address after the call) is PUSHed onto the stack, and the subroutine is JPed to. The stack pointer also decreases by two.
RET - when a RET instruction occurs, the computer takes the value on the top of the stack, and JPs to it. The stack pointer increases by two.
Now we've cleared that up, let's start hacking. *Hack the BASIC as usual.
D.D. LINE 0 LEN 496
0 REM 10 CLEAR 59999:POKE 23693,0:POKE 23624,0:POKE 23697,0:CLS:POKE 23659,0:FOR N=30 TO 36:BEEP .075,N:NEXT N:RANDOMIZE USR 24146:RANDOMIZE USR 0 100 REMThe POKEs in line 10 just make the screen black and prevent you from pressing break. 24146 is #5E52 hex; but a breakpoint at #5E52 and GOTO 0. This is because the stack is set up in a specific way by the BASIC commands.
5E52 F3 DI 5E53 21 00 00 LD HL,#0000 5E56 39 ADD HL,SP 5E57 22 F2 5D LD (#5DF2),HLThis code simply puts the value of the stack pointer into address #5DF2, so it can be retreived later.
5E5A 31 95 5E LD SP,#5E95 5E5D 26 5E LD H,#5E 5E5F E5 PUSH HL 5E60 21 68 5E LD HL,#5E68 5E63 E9 JP (HL) 5E68 3E 12 LD A,#12 5E6A 32 93 53 LD (#5E93),A 5E6D E1 POP HL 5E6E E5 PUSH HL 5E6F D1 POP DE 5E70 C9 RETPut a breakpoint at 5E70 and JP to 5E52. At 5E70, the value on the top of the stack is #5E76, so a RET will JP to there.
5E76 C1 POP BC 5E77 7E LD A,(HL) 5E78 ED 44 NEG 5E7A 77 LD (HL),A 5E7B 23 INC HL 5E7C 10 F9 DJNZ #5E77This code is, as you might realise, a decrypter. The start value of HL is #5E12, and the initial value of B is #3A. In case you're interested, the NEG instruction turns the value in the A register into its negative form; in other words, the value in A is subtracted from #100 hex. Put a breakpoint at #5E7E and JP #5E70 (which is where we left off).
5E7E E1 POP HL 5E7F 22 78 5E LD (#5E78),HL 5E82 C1 POP BC 5E83 3E C9 LD A,#C9 5E85 32 7E 5E LD (#5E7E),A 5E88 3E 00 LD A,#00 5E8A 32 7A 5E LD (#5E7A),A 5E8D 5D PUSH DE 5E8E E1 POP HL 5E8F C9 RETThis code changes the previous decrypter slightly, and RETs to 5E77. Put a breakpoint at 5E8F and JP #5E7E.
5E77 7E LD A,(HL) 5E78 ED 67 RRD 5E7A 00 NOP 5E7B 23 INC HL 5E7C 10 F9 DJNZ #5E77 5E7E C9 RETThis code works with the same values as the previous one; HL=5E12 and B=3A. It then RETs to 5E12. Put a breakpoint at #5E7E, and JP #5E8F (where we left off last time).
5E12 21 B4 5F LD HL,#5FB4 5E15 11 B5 5F LD DE,#5FB5 5E18 01 B8 88 LD BC,#88B8 5E1B ED B0 LDIR 5E1D E1 POP HL 5E1E 54 LD D,H 5E1F 5D LD E,L 5E20 1C INC E 5E21 C1 POP BC 5E22 ED B0 LDIRThese two LDIR commands wipe all the memory that isn't being used by the loading system. To get round this, you should change #5E1B, #5E1C, #5E22 and #5E23 to #00, to stop them being executed. Put a breakpoint at #5E24 and JP #5E7E (where we left off).
5E24 06 1E LD B,#1E 5E26 E1 POP HL 5E27 7E LD A,(HL) 5E28 EE A3 XOR #A3 5E2A 77 LD (HL),A 5E2B 23 INC HL 5E2C 10 F9 DJNZ 5E27The value in HL for this decrypter is #5E2E, which is right after the decrypter. To crack it, therefore, move the code from #5E24 to #5E2D somewhere safe (such as #5B00), put a breakpoint on the end, and run the code from there. When that's done, put a breakpoint at #5E2E and JP to #5E2E (so that you're back in the right place in the loading system).
Carrying on with the loader....
5E2E E1 POP HL 5E2F 22 02 5E LD (#5E02),HL 5E32 E1 POP HL 5E33 22 05 5E LD (#5E05),HL 5E36 37 SCF 5E37 3E 07 LD A,#07 5E39 CD 00 5E CALL #5E00This code takes some values off the stack, and puts them into the subroutine at #5E00, which is then CALLed. Put a breakpoint at #5E39 and JP to #5E2E.
5E00 DD 21 40 9C LD IX,#9C40 5E04 11 90 1 LD DE,#190 5E07 14 INC D 5E08 08 EX AF,AF' 5E09 15 DEC D 5E0A 3E 0F LD A,#0F 5E0C DB FE OUT (#FE),A 5E0E CD 62 05 CALL #0562 5E11 C9 RETThis routine is a headerless loader. The start is #9C40 and the length is #190. Also the value of A is 7, and the carry flag has been set. In effect, we could have used a standard CALL #0556 headerless loader. Put a breakpoint at #5E3C and JP to #5E39. Start the tape and load in the first short headerless block. Then continue disassembling.
5E3C D2 01 00 JP NC,#0001This code resets the computer if there was a loading error from the first headerless block.
5E3F 21 40 9C LD HL,#9C40 5E42 06 FF LD B,#FF 5E44 CD 77 5E CALL #5E77 5E47 06 FF LD B,#FF 5E49 CD 77 5E CALL #5E77 5E4C F3 DI 5E4D C9 RETThis code decrypts the headerless file we have just loaded in. The decrypter is CALLed to, and it's the same one we had before (with the RRD). So, in actual fact, we can forget about the BASIC loader; just load in the headerless file normally and run our own decrypter. For now, just put a breakpoint at #5E4D and JP to #5E3F. The RET is to #9C40
9C40 21 52 9C LD HL,#9C52 9C43 01 90 01 LD BC,#0190 9C46 16 A5 LD D,#A5 9C48 7E LD A,(HL) 9C49 AA XOR D 9C4A 77 LD (HL),A 9C4B 23 INC HL 9C4C 0B DEC BC 9C4D 78 LD A,B 9C4E B1 OR C 9C4F C2 48 9C JP NZ,9C48This is a decrypter, and you can crack it in one of two ways. Firstly, you can copy if to somewhere else, put a breakpoint on the end, and run it from there, or you can replace the JP NZ,9C48 with JR NZ,9C48. Both do the same thing, but the JR NZ only uses two bytes. This means we can put a RET at #9C51 and CALL the decrypter. So change #9C4F to #20, #9C50 to #F7 and #9C51 to #C9, then put a CALL #9C40 and a breakpoint somewhere convenient (such as #5B00) and run the decrypter from there. When decrypted, the code continues at #9C52.
9C52 21 63 9C LD HL,#9C63 9C55 11 45 FE LD DE,#FE45 9C58 01 90 01 LD BC,#0190 9C5B ED B0 LDIR 9C5D 31 84 FD LD SP,#FD84 9C60 C3 45 FE JP #FE45This moves the code we've just decrypted to #FE45, sets the stack pointer to #FD84, and JPs to #FE45. Put a breakpoint at #9C60 and JP to #9C52.
Now at #FE45, we come to the actual loading system itself.
FE45 3E 84 LD A,#84 FE47 11 00 18 LD DE,#1800 FE4A DD 21 00 40 LD IX,#4000 FE4E CD AB FE CALL #FEABThis code loads in a headerless file with start #4000 and length #1800 (which is the display file for the screen). Nothing too unusual about that.....
FE51 11 00 04 LD DE,#0400 FE54 DD 21 FF 5B LD IX,#5BFF FE58 CD 2A FF CALL #FF2A....except that as soon as it's done that,it loads in a block with start #5BFF and length #0400 straight away. This block is "sandwiched" right next to the other block on the tape. This particular block loads "backwards".
FE5B 11 E1 01 LD DE,#01E1 FE5E DD 21 1F FE LD IX,#FE1F FE62 CD FA FA CALL #FEFAAnd here's another block of the same kind, except it's loaded forwards this time. What's worse is that it's going to overwrite the code we're looking at now, so it must be a "modification" to the loading system (similar to the Mikro-Gen loader). To get round this, we would have to copy the code somewhere else, stick a breakpoint on the end, and run it from there. But remember that the loading system was copied from address #9C63, so there is, in actual fact, a copy of the code anyway. You want to put a breakpoint at #9C83 (the instruction after loading these three blocks), and JP to #9C63. Then start the tape and load in the next headerless block. The loading screen will appear, and the game will load for about four seconds, then control will return to the disassembler. Now look at the code at #FE65.
FE65 11 1D 9F LD DE,#9F1D FE68 DD 21 1C FA LD IX,#FA1C FE6C CD 2A FF CALL #FF2AThis code loads the main game backwards. This will overwrite your disassembler, so you will have to put the NEW routine at #FE6F (but write down all the bytes you are replacing, because you'll need to restore all the original code later). Then you will have to go back and load the first block, because there isn't a header for the main game block. Change #FE4D to #01, #FE57 to #10 and #FE61 to #01 - this will make the computer try to load the three blocks into the ROM. Then rewind the tape back to the start of this headerless block, JP #FE45, and start the tape. Upond loading the whole block, the computer will reset. Load in your disassembler, and replace the code from the NEW routine to the values they should be. Now you can tackle the final part of the loading system.
FE6F 11 E4 12 LD DE,#12E4 FE72 DD 21 FF FF LD IX,#FFFF FE76 C3 70 FF JP #FF70 FF70 3E 00 LD A,0 FF72 D3 FE OUT (#FE),A FF74 CD 1F FE CALL #FE1F FF77 21 43 FE LD HL,#FE43 FF7A BE CP (HL) FF7B CA 89 FF JP Z,#FF89 FF7E 21 48 EE LD HL,#EE48 FF81 01 FF FF LD BC,#FFFF FF84 11 49 EE LD DE,#EE49 FF87 ED B0 LDIRThe routine at #FE1F adds up all the memory in the screen to get a value in the D register. This is then compared with the value of the byte at #FE43. If there is no match, all the memory is blanked out, so the value in the D register must be the same as the byte at #FE43. You should find that the byte is #E6. You need to know this for later on.
FF89 21 A3 FF LD HL,#FFA3 FF8C 01 45 00 LD BC,#0045 FF8F 7A LD A,D FF90 AE XOR (HL) FF92 23 INC HL FF93 0B DEC BC FF94 78 LD A,B FF95 B1 OR C FF96 C2 8F FF JP NZ,#FF8FThis is all we can disassemble for the moment, because the code from #FF89 to #FF98 decrypts the final part of the loader. Change the byte at #FF87 to #16, and the byte at #FF88 to #E6 (this is LD D,#E6, which is used in the decrypter), put a breakpoint at #FF99, and JP to #FF87. Then continue the disassembly.
FF99 CD 31 FE CALL #FE31 FF9C 21 44 FE LD HL,#FE44 FF9F BE CP (HL) FFA0 C2 7E FF JP NZ,#FF7EThis code checks the main game, coming out with a result in the E register. However, this value is never used, so you can ignore this whole routine.
Following on.....
FFA3 21 C0 5D LD HL,#5DC0 FFA6 01 30 75 LD BC,#7530 FFA9 CD D4 FF CALL #FFD4 FFAC 21 C0 5D LD HL,#5DC0 FFAF 01 30 75 LD BC,#7530 FFB2 CD DE FF CALL #FFDE FFB5 21 1C FA LD HL,#FA1C FFB8 11 1C FF LD DE,#FF1C FFBB 01 1D 9F LD BC,#9F1D FFBE ED B8 LDIR FFC0 21 10 A7 LD HL,#A710 FFC3 22 36 5C LD (#5C36),HL FFC6 01 10 DF LD BC,#DF10 FFC9 AF XOR A FFCA ED 42 SBC HL,BC FFCC 31 FF FF LD SP,FFFF FFCF ED 56 IM1 FFD1 C3 6F 00 JP #006F 006F E9 JP (HL)This routine runs the game decrypters, moves the game into the right place, sets the stack and the interrupts, and puts the start address for the game in the HL register. Change the #006F at #FFD2 to somewhere where you can put a NEW routine (such as #5B00), because the disassembler will be overwritten. Then, change the value at #FFA1 to 16, and the value at #FFA2 to #E6 (because one decrypter uses the value in the D register), and JP to #FFA2. When that's done, you can reload your disassembler, and hack the game using a forwards and backwards trace (but you won't be able to run the code because some of it's missing!)
Now we'll write a complete hack for the game. You have to be a bit careful about where you put your hack in memory, because a lot of memory is overloaded. The first free address we can put the code at is #FA1D.
FA1D DD 21 40 9C LD IX,#9C40 FA21 11 90 01 LD DE,#0190 FA24 3E 07 LD A,#07 FA26 37 SCF FA27 CD 56 05 CALL #0556 FA2A 30 F1 JR NC,#FA1DThis loads in the first headerless block using the values set up in the BASIC loader.
FA2C 06 FF LD B,#FF FA2E 21 40 9C LD HL,#9C40 FA31 7E LD A,(HL) FA32 ED 67 RRD FA34 23 INC HL FA35 10 FA DJNZ #FA31 FA37 06 FF LD B,#FF FA39 7E LD A,(HL) FA3A ED 67 RRD FA3C 23 INC HL FA3D 10 FA DJNZ #FA39This decrypts the headerless block.
FA3F 21 20 F7 LD HL,#F720 FA42 22 4F 9C LD (#9C4F),HL FA45 3E C9 LD A,#C9 FA46 32 51 9C LD (#9C51),A FA49 CD 40 9C CALL #9C40This changes the JP NZ at #9C4F to a JR NZ and a RET, then calls the decrypter.
FA4C 3E C3 LD A,#C3 FA4E 32 83 9C LD (#9C83),A FA51 21 5A FA LD HL,#FA5A FA54 22 84 9C LD (#9C84),HL FA57 C3 63 9C JP #9C63This puts a JP back to our hack at #9C83, and jumps to #9C63 to load the first part of the headerless block.
FA5A 3E C9 LD A,#C9 FA5C 32 6F FE LD (#FE6F),A FA5F CD 65 FE CALL #FE65This puts a RET after the code to load the rest of the game, then CALLs that loading procedure.
FA62 21 E6 16 LD HL,#16E6 FA65 22 87 FF LD (#FF87),HL FA68 3E C9 LD A,#C9 FA6A 32 99 FF LD (#FF99),A FA6D CD 87 FF CALL #FF87This patches in the LD D,#E6, puts a RET at the end of the decrypter, and CALLs it.
FA70 21 7E FA LD HL,#FA7E FA73 11 00 40 LD DE,#4000 FA76 01 20 00 LD BC,#0020 FA79 ED B0 LDIR FA7B C3 00 40 JP #4000This code moves our hack into the screen memory (so it isn't affected by the LDIR which overwrites it in the next bit of code), and jumps to it there.
FA7E 21 0B 40 LD HL,#400B FA81 22 D2 FF LD (#FFD2),HL FA84 16 E6 LD D,#E6 FA86 C3 A3 FF JP #FFA3This code replaces the JP #006F with a JP back to our hack (which is in the screen memory by this time), and JPs to #FFA3. We have to include the LD D,#E6 again, because the value of DE was corrupted by the LDIR.
FA89 AF XOR A FA8A 32 C6 CD LD (#CDC6),A FA8D E9 JP (HL)This sets the infinite lives POKE, and does a JP (HL) to start the game.
Phew! I hope you managed to get all that, because it's really hard to do without a Multiface. If you can do it, then you've definitely got the hang of things, so keep it up!
SEARCH LOADER
This loading system appears on every game ever written by Steve Marsden (who wrote the original loading system), as well as a few others. You can recognise them by their fancy front end, which consists of a countdown timer, accompnied by animated graphics and/or instructions, which appear as the game loads. The only game I've actually got at the moment that's got a Search Loader on it is Technician Ted, so I'm going to have to hack that.
So, *Hack the BASIC loader, and let's see what it's got to offer....
Chip Fact LINE 0 LEN 736
0 RANDOMIZE USR 24341The rest of the BASIC is a load of garbage which consists of the machine code for the game. It is stored in a similar way to that in the Mikro Gen loader. 24341 is 5F15 hex, so disassemble this address.
5F15 F3 DI 5F16 21 00 40 LD HL,#4000 5F19 11 01 40 LD DE,#4001 5F1C 01 FF 17 LD BC,#17FF 5F1F 36 00 LD (HL),0 5F21 ED B0 LDIRThis code blanks out the screen.
5F23 CD 32 5E CALL #5E32The routine at #5E32 sets up the attributes for the screen ie: red banners at the top and bottom, black background with varying ink colours in the middle.
5F26 C3 38 5F JP #5F38 5F38 21 AB 5F LD HL,#5FAB 5F3B 01 59 A0 LD BC,#A059 5F3E 31 00 5C LD SP,#5C00 5F41 3A A8 5F LD A,(#5FA8) 5F44 57 LD D,A 5F45 1E 0B LD E,#0B 5F47 7A LD A,D 5F48 87 ADD A,A 5F49 87 ADD A,A 5F4A 87 ADD A,A 5F4B 87 ADD A,A 5F4C 82 ADD A,D 5F4D 83 ADD A,E 5F4E 57 LD D,A 5F4F 77 LD (HL),A 5F50 23 INC HL 5F51 0B DEC BC 5F52 78 LD A,B 5F53 B1 OR C 5F54 20 F1 JR NZ,#5F47This routine fills all of the memory above #5FAB with unexecutable code. It is, however, extremely important code, as we shall see later on.
5F56 CD 93 5F CALL #5F93This routine at #5F93 just messes around with the garbage a bit more.
5F59 CD 80 5D CALL #5D80The routine at #5D80 scrolls in the title messages for the game, accompnied by annoying clicks.
5F5C 3A 66 80 LD A,(#8066) 5F5F 6F LD L,A 5F60 3A E6 60 LD A,(#60E6) 5F63 67 LD H,A 5F64 E5 PUSH HL 5F65 3A 4F FC LD A,(#FC4F) 5F68 5F LE E,A 5F69 3A 0F 60 LD A,(#600F) 5F6C 57 LD D,A 5F6D DD E1 POP IX 5F6F 37 SCF 5F70 3E FF LD A,#FF 5F72 14 INC D 5F73 08 EX AF,AF' 5F74 15 DEC D 5F75 3A 66 63 LD A,(#6366) 5F78 6F LD L,A 5F79 3A E6 63 LD A,(#63E6) 5F7C 67 LD H,A 5F7D E5 PUSH HL 5F7E DB FE OUT (#FE),A 5F80 1F RRA 5F81 E6 20 AND #20 5F83 F6 01 OR #01 5F85 4F LD C,A 5F86 BF CP A 5F87 F5 PUSH AF 5F88 3A 87 65 LD A,(#6587) 5F8B 6F LD L,A 5F8C 3A 85 64 LD A,(#6485) 5F8F 67 LD H,A 5F90 F1 POP AF 5F91 E5 PUSH HL 5F92 C9 RETThis code takes values out of the garbage and puts them in certain registers. It then imitates the start of the ROM loading routine, and puts some values on the stack. At #5F92, the values of the registers are: Hl= #056B, DE=#03C3, IX=#8000, and the values on the stack are first #056B, then #8000. So, this code will load a headerless file with start #8000 and length #0363, then will JP straight to #8000. We can do away with the BASIC loader altogether in the final hack by mimicing the headerless loader. This is done using the following program.
5B00 F3 DI 5B01 31 00 5C LD SP,#5C00 5B04 DD 21 00 80 LD IX,#8000 5B08 11 C3 03 LD DE,#03C3 5B0B 3E FF LD A,#FF 5B0D 37 SCF 5B0E 14 INC D 5B0F 08 EX AF,AF' 5B10 15 DEC D 5B11 AF XOR A 5B12 DB FE OUT (#FE),A 5B14 1F RRA 5B15 E6 20 AND #20 5B17 F6 01 OR #01 5B19 4F LD C,A 5B1A CD 6B 05 CALL #056B 5B1DThis routine is slightly different than the one in the loader for two reasons. Firstly, I've put values into the registers directly, rather than have their values taken from bytes in memory. Secondly, you aren't allowed by law to rip off someone else's code; if you directly copied a loading system into a hack, you could be sued. In fact, someone was, once! You're probably alright copying a five byte decrypter from Powerload across, because there really isn't any other code which can do the job in the same way. In general, I would say don't copy code into your hack unless you have to. If you do, change it if you can so it does the same job in a different way. Copying 40 bytes of code directly out of a loading system is definitely out, and most magazines wouldn't print the routine anyway.
There are a few commands we haven't met in the routine. EX AF', AF' concerns the swapping of registers. In the Z80, in actual fact, there are two different sets of each register, although only one set can ever be used at once. Think of it like a TV set, although both registers (A and A' in this case) are there, you can only see one at a time. EX AF,AF' exchanges both the A register and the contents of the flags. Don't worry any more about swapping registers for now.
RRA rotates all the bits in the A register to the right. Actually, it doesn't quite do this, but we don't need to know about it.
If you're not using a Multiface, the garbage routine will have overwritten the disassembler, so reload it in anywhere below #8000. Then run the routine and restart the tape from where you left off. A small part of the headerless block will load in, and control will return to the disassembler. Have a look at address #8000.
8000 D2 00 00 JP NC,#0000This resets the computer if the previous headerless block didn't load properly.
8003 3E 08 LD A,#08 8005 D3 FE OUT (#FE),AThis makes the border black, and sends a signal to the cassette recorder.
8007 D9 EXXEXX is a "general exchange" instruction, and changes the registers B,C,D,E,H and L for their alternate sets.
800E 0E 00 LD C,#00 800A D9 EXX 800B 26 00 LD H,#00 800D 06 80 LD B,#80 800F DD 21 1C 8C LD IX,#8C1C 8013 16 05 LD D,#05 8015 CD 41 83 CALL #8341 8018 D2 00 00 JP NC,#0000 801B 06 B1 LD B,#B1 801D 15 DEC D 801E 20 F5 JR NZ,#8015This code loads in five bytes of tape (the routine at #8341 loads in information off tape into the address pointed to by the IX register), starting at #8C1C. Therefore, this tape routine will start loading code at #8C1C.
8020 11 D8 72 LD DE,#72D8 8023 D9 EXX 8024 0C INC C 8025 D9 EXX 8026 C3 7D 83 JP #837D 837D 2E 01 LD L,#01 837F CD 41 83 CALL #8341 8382 D2 00 00 JP NC,#0000 8385 3E CB LD A,#CB 8387 B8 CP B 8388 17 RLA 8389 D9 EXX 838A 47 LD B,A 838B E6 01 AND #01 838D 3D INC A 838F 11 6B 80 LD DE,#806B 8392 1A LD A,(DE) 8393 A7 AND A 8394 C4 77 82 CALL NZ,#8277This loads in a set number of bytes from tape, and then prints some sprites on screen (the routine at #8277). This produces all the men walking forwards and backwards while the game loads.
8397 CB 18 RRB 8399 D9 EXX 839A CB 15 RL L 839C 06 B1 LD B,#B1 839E 30 DF JR NC,#837F 83A0 7C LD A,H 83A1 AD XOR L 83A2 67 LD H,A 83A3 7A LD A,D 83A4 B3 OR E 83A5 20 CE JR NZ,#8375This updates the computer ready to do the next loading and animation sequence.
83A7 7C LD A,H 83A8 A7 AND A 83A9 C2 00 00 JP NZ,#0000 83AC 11 2F EC LD DE,#EC2F 83AF 06 EB LD B,#EB 83B1 CD 41 83 CALL #8431 83B4 D2 00 00 JP NC,#0000 83B7 3E EA LD A,#EA 83B9 B8 CP #0B 83BA D2 00 00 JP NC,#0000 83BD 42 LD B,D 83BE 15 DEC D 83BF 1D DEC E 83C0 C2 B1 83 JP NZ,#83B1This loads in some more bytes from tape. When these have finished, the computer will continue execution at address #83C3. The code beyond this address does nothing except fiddle about with registers, so there might as well be nothing there. The first bit of useful code will appear at #8C1C, but this hasn't been loaded yet. Instead, put a breakpoint at #83C3, move the headerless loading routine so the CALL #056B is at #7FFD, and run the code from there. Rewind the tape a bit and reload in all of the main headerless block. When finished, you'll find the following code at #8C1C.
8C1C 3E 5C LD A,#5C 8C1E 21 00 40 LD HL,#4000 8C21 54 LD D,H 8C22 5D LD E,L 8C23 EB EX DE,HL 8C24 4E LD C,(HL) 8C25 23 INC HL 8C26 46 LD B,(HL) 8C27 23 INC HL 8C28 EB EX DE,HL 8C29 09 ADD HL,BC 8C2A BA CP D 8C2B 20 F6 JR NZ,8C23 8C2D 11 92 5C LD DE,#5C92 8C30 EE 5C XOR 5C 8C32 28 EF JR Z,#8C23 8C34 E5 PUSH HLThis routine adds up every single byte in memory to get a value in HL, which is pushed onto the stack. This value is important, because it is used in decrypting. This is what the garbage was all used for - to get the right value. It's impossible to calculate it yourself, because any programs you right will mean you get the wrong answer. The only way I can think of to get this value is to load the game as normal, and stop the game with a Multiface as soon as the timer hits 000. Then put a breakpoint at #8C35 and return. Wait a few seconds, then reactivate the Multiface and have a look at the stack. The first value will be #8C35, the second will be the value of HL you want. You should find it's #4DBD.
Carrying on the disassembly....
8C35 21 00 58 LD HL,#5800 8C38 11 01 58 LD DE,#5801 8C3B 01 FF 02 LD BC,#02FF 8C3E 36 00 LD (HL),#00 8C40 ED B0 LDIR 8C42 E1 POP HLThis clears the screen and restores the value of HL, which is used for the following decrypter.
8C43 11 60 8C LD DE,#8C60 8C46 0E 29 LD C,#29 8C48 7C LD A,H 8C49 65 LD H,L 8C4A 47 LD B,A 8C4B 09 ADD HL,BC 8C4C 1A LD A,(DE) 8C4D AD XOR L 8C4E 12 LD (DE),A 8C4F 6F LD L,A 8C50 13 INC DE 8C51 1A LD A,(DE) 8C52 AC XOR H 8C53 12 LD (DE),A 8C54 13 INC DE 8C55 CB 7A BIT 7,D 8C57 20 F0 JR NZ,#8C49 8C59 FB EI 8C5A 67 LD H,A 8C5B 11 70 71 LD DE,#7170 8C5E 19 ADD HL,DE 8C5F E9 JP (HL)First of all, POKE #8C40, #8C41 and #8C42 with #21, #BD and #4D respectively (so you get the right value of HL), put a breakpoint at #8C5B (nearest place possible to the JP (HL) that we can place a breakpoint), and JP #8C40. On return, the value of HL is #38F5. Add this to #7170 (which is what happens in the next two commands) to get #AA65. This is the start address of the game. So put a JP to your POKEing routine (anywhere from #5B00 to #5BA0 is fine) at #8C5B, and finish your POKEs with a JP #AA65.
You will have to do a stack trace to find infinite lives in the actual game itself. There is a complete hack for this game by myself in YS #78, so why not disassemble it and have a look. It's slightly different to what we've done in that it intercepts the RET at the end of the loading system rather than mimic the first headerless loader, and puts a JP back to the hack at #83C3, but apart from that, it's more or less everything we'e discussed above put together.
PAUL OWEN'S PROTECTION SYSTEM
This has been used on a few Ocean games, but is in fact a standard headerless loader in disguise. The value of A to use is always #98. Load in the BASIC loader and the first block of code, then stop it with a Multiface, and use a stack trace to find out the values of IX and DE for each block, and the JP to the game.
SPEEDLOCK
Concluding the look at protection systems, I think it's only fitting that we end in quite possible the most famous protection system of all time.
Speedlock was first written by two guys called David Looker and David Aubery Jones around late 1983, although it wasn't commercially used until October 1984, on Daley Thompson's Decathlon, by which time it had reached it's third version. Since then, it has been used by many major sofware companies, especially Ocean. Its also gone many modifications, and can be split into three distinct generations.
I should state at this point that you need to have a Multiface to crack most of these Speedlocks, because they completely disrupt the operating system which will lock up any disassembler which relies on ROM routines. The Multiface relies on its own ROM, which isn't affected by the Speedlock code.
Type 1 - have one or two BASIC loaders, and load the main code with the infamous "clicking" leader tones (you know, instead of a steady "bleep", they go "blip, blip, blip, blip" a few times).
Type 2 - have one short BASIC loader, a long CODE block, lots of annoying beeps, then a similar loader to Type 1, minus the clicking leader tones, plus a countdown timer.
Type 3 - as for Type 2, except there is just one very long BASIC loader. The protection system crashes if a Multiface is left switched on. Mazemania on YS #77 covertape used a Type 3.
So, let's start at the very beginning (a very good place to start) with Type 1. In fact, there are about four different difficulty levels of Type 1 Speedlocks; the difficulty goes in chronological order (as you might expect).
The very first Type Ones were completely different to later ones, having the same initialisation routine, but a completely standard decrypter. The only differences between this Speedlock and an ordinary decrypting loader were its initialisation routine and its use of the IY register.
We came across index registers when we first met headerless loaders. There are, in fact, two index registers, IX and IY. In BASIC, the IX register is free for use in a machine code program run from a USR command, but the IY register must always contain the value #5C3A, which is the base address of the BASIC system variables which are wiped with a NEW command. If you return to BASIC with the value of IY anything other than #5C3A, the computer will crash, even if you use the "exit to BASIC" feature on a Multiface. The value of IY must also be #5C3A whenever a BASIC interrupt occurs. Both Devpac and 007 Disassembler run under the BASIC interrupts. They also use built in ROM routines, such as those to check the keyboard and print text; this is preferable, otherwise they'd have to waste memory rewriting their own versions of the routines. Hence the value of IY must always equal #5C3A.
The only safe way of using the IY register is to disable interrupts and write the whole program in RAM without using any built in ROM routines. And Speedlock fits this bill exactly, so it uses the IY register for most of its decrypter calculations.
Speedlock code also uses a lot of undocumented instructions. In theory, you cannot split the sixteen bit IY register into two eight bit registers. But the processor doesn't understand this, and you can split the IY register into two if you want. You simply put the code #FD on the front of any instructions using H or L. There are no standard names for the two halves of the IY register, but I will refer to them as IYH (Hi part of IY) and IYL (Lo part of IY).
Now let's hack a Speedlock game. To start with, I'm hacking Knight Lore, but the following games are also suitable: Beach Head, Daley Thompson's Decathlon, Gilligan's Gold and Underwurlde. Anything released after these will be explained later.
So first *Hack the BASIC loader.
KNIGHT LINE 0 LEN 1037
0 BEEP 0.1,1:BEEP 0.1,2:BEEP 0.1,3:BEEP 0.1,4:BEEP 0.1,5:PAPER 0:BORDER 0:INK 0:BRIGHT 1:CLS:PRINT BRIGHT 1;INK 0;AT 9,5; "LOADING: KNIGHT LORE";AT 12,10;"PLEASE WAIT" 0 POKE (PEEK 23641+256*PEEK 23642),PEEK 23649:POKE (PEEK 23641+ 256*PEEK 23642)+1,PEEK 23650 0 POKE (PEEK 23613+256*PEEK 23614),PEEK 23627:POKE (PEEK 23613+ 256*PEEK 23614)+1,PEEK 23628 0 POKE 23662,PEEK 23618:POKE 23663,PEEK 23619:POKE 23664,PEEK 23621 23676 "REM CLOSE #ATTR....Wait a minute, there's absolutely no sign of a RANDOMIZE USR command anywhere! There's just some BASIC which beeps a bit, sets the colours, and prints a message, a whole load of POKEs, and then a load of garbage. Surely the computer will do everything, then report with an error message as soon as it reaches 23676?
Well, that's not actually the case. Look at the third line 0 (the one which starts POKE [PEEK 23613+256* etc.). This system variable is known as ERR SP. What happens is that when an error occurs (and it will do here), the computer jumps to the value in this register. This value is PEEK 23627+256*PEEK 23628. PRINT this value, and there's the start of the machine code. You might get a different result to me, but I made the start address #60A8.
Disassemble this address.
60A8 F3 DI 60A9 FD 25 DEC IYH 60AB FD 7C LD A,IYH 60AD FD AD XOR IYLThe DI is very important, because otherwise the I register can't be used. Given that IY starts off as being #5C3A, the value in A will end up being #5B XORed with #3A, which is #61.
60AF FD 26 F3 LD IYH,#F3 60B2 FD 2E A6 LD IYL,#A6 60B5 3B DEC SP 60B6 3B DEC SP 60B7 01 54 FE LD BC,#FE54 60BA FD E3 EX (SP),IYFirst of all, this loads IY with the value #F3A6. It then decreases the stack pointer by two. By doing this, the stack pointer is now pointing to the start address of the machine code, which is #60A8. EX (SP),IY is a variation to the register exchange commands we've already come across. It basically swaps the value in the address pointed by the stack pointer with the value in the IY register. So, after this instruction, IY will contain #60A8, and the value on the top of the stack will be #F3A6.
60BC 21 30 F2 LD HL,#F230 60BF FD 09 ADD IY,BC 60C1 01 AC 01 LD BC,#01AC 60C4 FD 5D LD E,IYL 60C6 FD 54 LD D,IYH 60C8 EB EX DE,HLHere, HL is being loaded with #F230. The value in BC (#FE54) is added to the value in IY (#60A8), making the value in IY #5EFC. Then BC is loaded with #01AC, and the value in IY is transferred into DE. Then the values of DE and HL are swapped. So, by the end of the code we've looked at so far, HL will equal #5EFC, DE will equal #F230, BC will equal #01AC, and A will equal #61. These values are all used in the decrypter which follows.
60C9 AE XOR (HL) 60CA 12 LD (DE),A 60CB 7E LD (HL),A 60CC 23 INC HL 60CD 13 INC DE 60CE 0B DEC BC 60CF FD 6F LD IYL,A 60D1 78 LD A,B 60D2 B1 OR C 60D3 FD 7D LD A,IYL 60D5 20 F2 JR NZ,#60C9 60D7 C9 RETThis is a straightforward decrypter, except the value for A (which is needed throughout the decrypter) is temporarily stored in part of the IY register. The RET is to #F3A6 (the top value on the stack).
To crack this, we can set up the register values manually, CALL the decrypter, and then hack the main loader ourselves. Type out this program:
5B00 F3 DI 5B01 21 FC 5E LD HL,#5EFC 5B04 11 30 F2 LD DE,#F230 5B07 01 AC 01 LD BC,#01AC 5B0A 3E 61 LD A,#61 5B0C CD C9 60 CALL #60C9 5B0F FD 21 3A 5C LD IY,#5C3A 5B13Notice that we've disabled interrupts to avoid crashing, and we need to restore the value of IY to #5C3A afterwards, so your disassembler won't crash. RUN the program, and have a look at the code at #F3A6. You'll find it's just a straightforward headerless loader with absoultely no frills, and you should be able to hack it no problem.
As for the final hack, load the BASIC into address #5CCB, run the decryption routine above, patch the JP in the main turboloader to your POKEs, and start running.
All other Speedlock Type 1s have the same sort of decrypter. The code for the decrypter is very complicated, with the result that I have been unable to reproduce it here. Luckily, you don't have to touch the code; you can write your own decrypter as long as you have a Multiface.
I'll be doing Tapper as an example, but any other Speedlock follows this procedure almost exactly. *Hack your game and note down the length of the code (you'll need it later). I made it 1453, which is #05AD hex. Now look at address #5EFD. The byte at #5EFD is always decrypted to give the byte #42, and the byte at #5EFD is always decrypted to give the byte #55. The decrypter works by XORing the encrypted byte with a number taken from the R register. By inspecting the code before and after running, you'll see the XORing number starts off as #CB, and increases by #0A each time. If the result is more than #FF, the result has #80 subtracted from it. We can incorporate this into our decrypter. The start of the code is #5EFD, and the length is (PEEK 23627+ 256*PEEK 23628)-#5EFD, which is #01ED in the case of Tapper. The following code will simulate the decrypter.
LD HL, LD BC, LD D, *** LD A,(HL) XOR D LD (HL),A LD A,D ADD #0A SET 7,A LD D,A INC HL DEC BC JR NZ, ***Once you've done that decrypter, you've got to do the whole lot again, starting at #5EFD. The byte there will be decrypted to either #3E or #ED - you'll have to guess which decrypting value to use. For Tapper, the start is #5F2B, the length is #1BF, and the second decrypter value is #AB.
When you've done that, you'll either get the complete loading system or another decrypter. If you've got the loading system, then reload the BASIC loader, and do a stack trace to find out where it should go. You should have no problems with the loader.
If you've got another decrpyter, go along five bytes and find a LD DE,(XXXX). Add #2E to this value, and that's where you move it to. The length is the same as that for the second decrypter. The decrypter itself can be cracked by changing a JP Z in the code about forty bytes later (the value of this is the start of the turboloader), but the decrypter itself uses a byte which is worked out by adding all the memory together in the loading system. Since we've got an exact copy of this system elsewhere in memory, just change the value of XXXX in the aforementioned LD DE,(XXXX), and then JP to the start of the decrypter.
If the first decrypting value you used was #CB, then you can just change the JP in the turboloader to your POKEs.
If the value was #CD, then you'll need to know about the Standard Speedlock patch. Somewhere in the loading system there will be the two bytes ED 53 [LD DE,(XXXX)]. Change the XXXX to the address of your POKEs (#5BA0 is normally safe), and end your POKEs with a JP to the value you overwrote. You'll have to use this patch for the later Speedlocks as well.
There was a Speedlock Type 1 MultiPOKE in YS#79. RUN the program, press BREAK and disassemble address #5B00 to find out what to do in your own hacks.
Type 2 Speedlocks feature a very easy BASIC loader, and one big block of code, which has six short decrypters and a complex moving routine. The decrypters are all easy peasy, just move them to somewhere else in memory (such as #5B00), bung a RET on the end, and CALL the decrypter from there (but watch out for the third decrypter, which checks for a Multiface and crashes if it finds it. The moving routine fiddles about with the loader. Search for 31, which means LD SP,XXXX. Hopefully, you'll find a LD SP,#0000, with perhaps a DI right before it. Write down the address and run the moving routine (you may have to restart the tape, because some of the moving routines insist on a signal coming into the tape recorder). Use a stack trace to find out where the code has gone to. Now you can move all the code from the moving routine to the end of the machine code block to where it should be, given that you know where the LD SP,#0000 goes to. Once moved, patch the loader in the same way as the first Speedlock.
Type 3s have just one long BASIC loader, with about 144 decrypters, but that's nothing to worry about. *Hack the BASIC loader, and have a look at the first bit of code which moves the rest of the code into the right place (you can then use a headerless loader to load this into the right place in memory). The tricky bit is changing a byte in memory so a CALL to the loading system at the very top of the code is changed to a CALL somewhere else once all the decrypters have been run. The only way you can do this is to change the address of the hi byte of this CALL to something else, and RUN the huge load of the decrypters. The computer will crash if you have a Multiface attached, but only after everything's been decrypted, so then look and see what the CALL's been changed to. If it's suitable, remember the patch, position your hack around this, change the CALL to what it should be,and put in the usual Speedlock patch. Look at the start address in the turboloader. This address will be overwritten by a decrypter once loading finishes. This decrypter is nothing special, so just crack it as usual, and watch out for the game moving around.
Jon North's Pokerama Tapes usually have a Speedlock Type 3 crack on it - load up the Pokerama, choose your POKE, then do a stack trace to find it and have a look at it.
Part 7 - Epilogue
Well folks, I'm sorry to have to break this to you, but I've just about told everything you should ever need to know to crack every protection system under the sun. So I'll just say some final words and credits, and then sign off, okay?
The idea of this book, its production and its writing were done entirely by Richard Swann, from February to June 1992.
Some suggestions and tips came from two people to whom this book is dedicated, Matt Corby from "down-the-road", and Niall "Mr Incredibly Technical" Daley. Thanks, guys!
Thanks to YS for putting disassemblers and the like on recent covertapes; it saved me the trouble of writing one!
Thanks to Jon North for some of the info on hacking he gave to me on disk recently - much appreciated, mate.
Thanks for YOU for buying this. There aren't many Speccy hackers around right now, so we need to make the numbers up. Good luck!
What's that? "I don't understand this bit at all!" I hear you say. Well, send me any queries that you may have about this book, stating exactly what the problem is, along with an SAE (very important that), and I'll do my best to reply to them. DON'T write to me asking me to hack a whole list of games for you - I just haven't got the time. However, I've got a big book of Multiface POKEs which you can obtain for œ1.50 and an A4 SAE if you want it, so that might come in handy.
Thought for the year: Seven years ago, Spectrum and Commodore owners were at each other's throats. Spectrum owners would vow never to have anything to do with Commodore. Then why do I hear of so many Spectrum owners that have upgraded to a Commodore Amiga? Personally, I can't stand the Amiga's operating system - it's terrible!
Well, that seems to be about it, so I'll just leave you know in the hands of a glossary of terms. Happy hacking!
RICHARD SWANN - June 1992
GLOSSARY
Breakpoint - an instruction put in by a disassembler which will return control to it when it is executed. Also something to do with tennis.
Crack/cracking - writing a routine or executing some code which will get round some element of a protection system, enabling the user to put a POKE into the game.
Crash - an undesired effect which the programmer or user did not intend to happen. Classic example is the computer resetting itself to give the old "(C) 1982 Sinclair etc.etc.", or a whole load of flashing squares. Also a now defunct computer magazine.
Decrypter - a short program contained in a protection system which, when run will change garbage into runnable code. You need to crack a decrypter to write a hack for it.
Endless loop - the Multiface equivalent of a breakpoint, put in hacking a protection system or doing a stack trace. The computer will keep executing the same code over and over again, indefinitely, unless the Multiface button is pressed. See also endless loop (ho ho ho!)
Garbage - A block of machine code which does not make sense to a human. The computer will attempt to process it, but will almost certainly crash. Also what the dustmen collect in America.
Hack - a self-standing program which when run will load a game and activate certain cheats. Also the act of getting round a protection system. (See also crack). Also a lot of anonymous people from Scotland.
Headerless loader - a loader which does not contain the first "header part" of a file specifying it's name, length etc, but has it ready built into memory. This makes the program harder to hack.
Interrupt - small program which occurs every 150 of a second, regardless of what the computer is doing.
Loader - any program which reads a file off tape into memory, and executes it. This may consist of simple BASIC commands, a headerless loader, a turboloader or even a protection system.
Operating system - this the built in program into the computer to deal with all the basic things like reading the keyboard and loading software. This is BASIC in the case of the Spectrum. Most protection systems deliberately confuse the operating system or lock you out of it.
Patch - replacing a bit of code whith something designed to hack it. This patch may consist of a jump elsewhere in memory, or a breakpoint. Also something that pirates wear on one eye.
POKE - the process in which a single byte of memory is changed. Originally, games were hacked by one or two POKEs.
Protection system - A block of code which tags on the front of a game's loader and prevents anyone from accessing the code it is protecting. At least, that's what it's supposed to do!
Trace - looking through a block of code with the aim of finding something specific (such as an infinite lives POKE). This may be forwards, backwards, interrupt or stack trace.
Turboloader - a loader which loads in a file off tape at a faster speed than usual. This speeds up loading. The turboloader may be hidden by a protection system.
THE END