Since ever the phoenix represents the the daydream of the immortality. In the early 80’s the limited time or number of lives for arcade video games in the game room was considered natural and also in the roguelike genre or interactive fiction for mainframe/home computer the character death was considered natural and ineluctable. Later with the home computers we switch from video games in which it’s the player who with his actions determines the time elapsing to games of dexterity where the events occur inexorably with the classic three lives. This time instead in the quiet of the domestic walls and with games of greater difficulty than those in the game room strongly returns the yearning for immortality, this time in digital form, so the gamer begins to fantastic thinking about the possibility of have more lives to progress in the game or even have the ability to never die. Now he has everything in his hands, the computer and the video game. At the beginning of the home computer era the first video games were available in the form of long Basic listings published by the specialized magazines and the player who by ascetic patience copied them into the computer memory analyzing the program was able to modify the instructions in order to achieve his forbidden dream, usually after he did his utmost to progress in the game without success.
The story changes when releasing the videogames in the machine language: these are much more complex and shiny than the previous ones in basic, it’s no longer necessary to write anything manually into the computer memory with the risk of committing errors, it’s enough to insert the magnetic tape in the cassette player and wait a few minutes for the videogame loading that starts automatically. All very well, but the player after a happyness first moment is assailed by a distressing thought: he can no longer modify the program to get infinite lives. He takes the computer manual in search of a solution and rereading the manual his attention is focused on a couple of instructions with a short name in Basic language, present in all 8-bit computers of the epoch, which before probably he didn’t give much consideration: the instructions PEEK and POKE. The PEEK instruction is essential to read into the computer memory, but the POKE instruction presents itself to his eyes as the philosopher’s stone as it allows him to modify the data into the computer memory at his leisure, it’s clear that the key to digital immortality is all in that instruction, but at this stage the question rises up: where, what and how to modify the data into the computer memory ? The journey is just beginning.
Nowadays it’s natural to find information for video games through the internet use, but in the early 80’s there’s nothing like this and the only information sources are magazines like Crash, Your Sinclair or ZZap! just to name a few of the most popular. On this magazines in addition to the reviews are published the POKE of eternal youth for some video games and in 1992 the talented hacker Richard Swann who collaborates to Your Sinclair also publishes a guide in which he describes how to set the parameters for the POKE function. The options appear to be only two: either you wait and hope for the POKE publication of their own favorite video game or you have to search by yourself. This is the story and the shared experience of videogamers of the time.
The present tutorial is based on the work of a young boy that instead in 1984 by the simple knowledge of the basic language and the actions of a bunch of Z80 instructions he develops a heuristic method to search the infinite lives without the need to disassemble the game code.
The purpose of this tutorial is to bring the retrogamers closer to the assembly through the videogames, the heuristic method remains useful to define the concepts and the baseline logic, but we’ll be using tools for actual computers. The tutorial is provided for the ZX Spectrum, but the method can be applied to all the computers of the time with the proper tricks and tools.
THE EURISTIC METHOD
First, you should have a crystal view of the problem and as always, from an operative viewpoint, it’s important to pose the “right” questions and produce the proper answers.
Let’s start from the fact that for a microprocessor a program is constituted by groups of instructions within which there is a subset that, according to specific conditions, enables the different groups activation. Now let’s consider any character of a videogame:
WHAT is the life in the reality of this character?
In assigning to the character a parameter that during the game can change due to specific events and is handled by groups of instructions.
WHAT is the death in the reality of this character?
In a set of events that modify that parameter and activate other groups of instructions which end the game.
From an operative viewpoint we now have a good idea of what the character’s life and death is, but there’s still a few pieces to be added to our puzzle:
How the microprocessor handles this parameter ?
The microprocessor manages this parameter (like all the others of course) through the instructions and for speed reasons uses an internal memory whose units are named registers. We can group these instructions into a sub-set of instructions for loading the values in the registers, arithmetic/logic and jump operations. As far as the registers are concerned, they can be arranged in general and special registers sub-sets: the general registers don’t have a specific purpose and they are used to perform the calculation operations related to the program, the special registers are of specific support to the microprocessor internal activities during the instructions execution. We will focus our attention on two special registers that are involved in all the logic-arithmetic operations performed by the A.L.U. (Arithmetic Logic Unit): the accumulator register present in all microprocessors and the flag register whose single bits indicate the calculation system status after the execution of any logic-arithmetic operation. There are other special registers, but for our method these simple elements about the microprocessor working are a good starting point.
WHERE is the parameter and the instructions that manage it?
To operate the microprocessor requires two kinds of memories, a memory that you can just read said R.O.M. (Read Only Memory) where there are the instructions for the proper computer running and another that the user can freely read and write said R.A.M. (Random Access Memory). The microprocessor assigns a unique address to each element of these memories through which it directly accesses the data in them. The parameter and the instructions that handle the character’s life are located in R.A.M. Now that we also have an idea of how a microprocessor works it’s time to understand what and where to search from an operational viewpoint.
HOW TO search?
From the above, the game consists of a instructions and data set in R.A.M. handled by the programmer. The program designer first formulates a game general idea and describes its main functions without entering into the details of its parts. Subsequently, each part of the game is perfected by adding more details. By means of this processing strategy named Top-Down the programmer determines where to put the code, where are allocated the resources: sprites, texts, music, sound effects and in general everything that is necessary for the game.
Instead we are in the condition in which we have all the game details without knowing where the resources are allocated in R.A.M. and we see just a data set that can be whatever: instructions, sprites, lyrics, music, etc.. We know where the code begins and knowing the microprocessor instructions from the details we should go up to the programmer’s general perspective to understand where is the parameter that represents the character’s life and eventually how to made him immortal. This is the inverse path followed by the programmer and this Bottom-Up processing strategy is named reverse engineering. It’s complex to write the game, but it’s much more tricky to retrace the programmer’s logic starting from the data stored in R.A.M. The Top-Down and Bottom-Up information processing methodologies are deterministic, i.e. the game events are generated and handled in an identifiable and preset way and are such that a given cause follows just a given effect both if you program as well as if you reverse the game. The game reverse engineering is very tricky also for an expert who knows in detail the microprocessor and this can require many hours/days just to search the infinite lives. There are no alternatives in the IT paradigm. To try to reduce the search time and simplify the research you have to try to change the paradigm.
What does the expression to change paradigm mean?
It means to observe the system from a different viewpoint, it’s a path to be defined and pursued with trials and errors until the eventual goal achievement. In our case study we can consider the game as a continuous flow of data processed by the microprocessor within which to search for the conditions, we say of pretrigger, that trigger the character’s life events handling. In detail, within this data set we will search for “special” data pairs that allow us to identify the instruction handling for the parameter we are interested in. These data are 8-bit numbers simple pairs and we will make them “special” by associating them to a criteria as the simple number pairs can be everything from instructions to sprites, texts, music, sound effects, etc. not necessarily related to the character’s life handling. We will understand step by step if we are on the right way. This is a heuristic procedure that can be used by people who have a machine code/assembly microprocessor little knowledge and that with a good insight allows you to find the infinite lives for the videogame character in a few minutes/hours.
It’s a bit like fishing by a pole: the fisherman’s ability is to recognize the good fishing area by the proper bait, the sea are the data in R.A.M., the bait are the pairs of data, the fishing pole is your intuition and the fish to capture are the infinite lives.
THE HEURISTIC METHOD APPLICATION
BOT- LIVES HANDLER
Fig.1 – Character Lives Handler
Fig.2 – SET LIVES Block
Fig.3 – EVENT HANDLER Block
From what we said the generic lives handler of our character can be represented by a blocks diagram as shown in Fig.1. We will populate the blocks “SET LIVES” (FIg.2) and “EVENT HANDLER” (Fig.3) with the assembly instructions that we will go to fishing and the mathematical criterion that characterizes them.
Until now the topic was generic, from this moment it will be focused on the ZX Spectrum microprocessor, the Zilog Z80:
Zilog Z80 – ZX Spectrum 48K
Fig.1 – The ZX Spectrum 48K memory
Fig.2 – WIP
Fig.3 – WIP
See you the next time 😉
You try to relate the two documents with that which I wrote entrusting to your insight …
eNJoy aND STay TuNeD WiTH uS!
Raffaele “MOS” Sanapo
This tutorial is just for educational purposes and all information is provided “as is as”. Links to third party websites are provided only for your advantage and information. There is no control and no responsibility for the content or websites of others that are linked. We disclaim all responsibilities for any loss, costs or damages direct or indirect resulting from the use of this tutorial. The use of collected or downloaded information from this tutorial it’s at your exclusive risk or danger. All product names, logos, and brands are property of their respective owners. All company, product and service names used in this tutorial are for identification purposes only. Use of these names, logos, and brands doesn’t imply endorsement of them.