How to disassemble Sinclair ZX Spectrum Games - part 1

These series of instructions give you some hints about how to take apart a (16 or 48K) Sinclair ZX Spectrum game. The techniques are generally applicable to other platforms, programs and systems with some changes. I assume you are doing this simply for ‘academic’ interest (learning, etc.). I accept no responsibility for any liability and I will not show any techniques that involve breaking copy protection.

The techniques here are generally a form of reverse engineering.

I’ve put a brief introduction to the legal implications at the bottom ... because it’s important no one gets into trouble about this.

First Steps

You need a binary image of the Spectrum memory. Generally a snapshot of the memory when the game/program has loaded is much easier to deal with, for several reasons. It can be disassembled into Z80 code and graphics directly. For games on World-of-Spectrum, SNA or Z80 formats. Alternatively load the .tap/tzx file into a ZX Spectrum emulator and save as one of these formats. Getting a game off a physical tape into a modern computer is outside the scope of this article - but there are plenty of resources. As soon as it runs on an emulator, you are good to go.

For later games, this snapshot format generally has had any unpacking or unscrambling (simple encryption used on later ZX Spectrum games) already done, which mean the code, graphics and text strings are in plain format.

Next let’s look at the types data we will want to examine.

Z80 Machine code

These are the routines that run the game. The ZX Spectrum had a Z80 microprocessor, so has a specific machine 'language' or code. Each subroutine can be analysed to various depths - depending upon the information required. We will want to change the binary numbers of the machine code into assembler mnemonics - human readable version of the instructions.

Sometimes there are complexities like self-modifying code, but it’s safe to ignore these at this early stage.

Occasionally, a game will have been written in a high-level non-compiled language (e.g. Forth, BASIC, etc.). These can be analysed, but we’ll ignore these at this time. - they tend to be rare on the ZX Spectrum. (Occasionally there will be important pieces of Spectrum BASIC to look at. That’s much easier to handle.)

Text strings

These are usually quite easy to see, and hence the addresses of such string provide useful ‘landmarks’ in the code. Some later games (e.g. Jet Set Willy 2) have some compression using a dictionary of common words.

Graphics

Again, for most games the 2D graphics are generally easy to view - usually they are one, two or four bytes wide, although other formats exist.

3D graphics are more difficult, and you’ll probably need to examine the code, unless someone else on the web has already documented them.

Other binary data (working data or ‘reference’ data).

This can be the hardest to understand, but with the assembler code, we can work out what it means and what it does.

Sometimes you’ll want a hex editor program to view this - or a program to dump the hex or decimal numbers of the data. Some disassemblers allow you to use a control file to specify which bits are data so they aren’t disassembled incorrectly.

Other resources

The annotated Spectrum ROM disassembly is very useful. Many games depend on either data or subroutines in the Spectrum ROM. One possibility is the book, you can get this online here:

http://www.worldofspectrum.org/infoseekid.cgi?id=2000076

Zilog Z80 instruction reference - there are plenty of web sites and books with this. Use your favourite internet search tool.

The Spectrum BASIC manual is often useful. http://www.worldofspectrum.org/infoseekid.cgi?id=2000438

There are other interesting books here: http://www.worldofspectrum.org/books.html

Finally Legal

I’m not a lawyer - so take this section with a big pinch of salt http://en.wikipedia.org/wiki/Grain_of_salt - but these might be some things you need to consider when disassembling. This is a *very* short summary of the most common areas - one sentence each for each topic really isn’t enough detail to make informed decisions. Also I cannot say it’s in any way comprehensive.

Reverse engineering is *generally* legal, for various reasons - but not necessarily everywhere. However laws like the U.S.’s DMCA (digital millennium copyright act) and EU Computer Program Directive can make it legally ‘difficult’ especially if ‘technologically protected’. EULA on modern programs can make such reverse engineering a breach of contract. See http://en.wikipedia.org/wiki/Reverse_engineering#Legality for more details. You’ll notice no get out clause for historical interest (which is the case with 1980’s computer and video games) or for learning - just interoperability - which is rubbish, in my opinion - especially since your reason is likely not to abuse copyright or misuse someone else’s work.

But let’s look at the individual pieces. Various forms of ‘intellectual property’ and agreements need to be taken into account when reverse engineering any software.

Copyright - generally doesn’t stop you from taking things apart for personal use. But distributing (or in some cases using) the disassembly or reusing pieces of code - even translated into other (human or computer) languages - would require permission from the copyright holder. It doesn’t stop you learning or reusing the general principles or algorithm.

Patents - this basically gives the holder of the patent (not necessarily the inventor) a exclusive right to particular solution. I don’t know of any 1980’s Spectrum games that had patented parts but knowing there is *any* patent is a big problem (even for places that don’t recognise software patents...). However, it shouldn’t affect private study. (One possible advantage of patents is that the solution patented for a problem is made public - so reverse engineering is not necessary. The reality, however, is that patents often don’t describe things clearly or in enough detail to be useful - quite often improvements are made into trade secrets.) Another thing to consider is that the term of patents is generally at most 20 years - so for any patents on 1980’s computer games most have either run out or are shortly to run out.

Licence agreements - for example EULA - have been shown in some countries to be legally binding and override the permissions of copyright law. Some (a lot!) of these modern EULA prohibit reverse engineering. How legal this specific prohibition for reverse engineering is, at best, unclear. However, I’m not aware of any 1980’s ZX Spectrum games coming with license agreements.

Other contractual agreements can affect what you may do - e.g. NDA (non-disclosure agreements http://en.wikipedia.org/wiki/Non-disclosure_agreement). I’ll assume you know if you have agreed to those(!) and what it says. Otherwise you are probably in the clear.

Trade secrets - not generally applicable to reverse engineering (unless you work or have worked for the company).

Trademarks, industrial design rights, trade dress - in some ways similar to copyright in terms of what you are allowed to do - i.e. not replicate without the owners permission.

'Fair use' - I won’t cover that here because it’s complex and lots of variation. Don’t *assume* this will protect you, is my advice, unless you have a sponsor with money and/or a legal team http://en.wikipedia.org/wiki/Fair_use


Legal Summary

When in doubt check with a lawyer. Don’t distribute any disassembly without (written) permission. Personal review is probably ok. Producing documents about how it works should be fine in most places - but check local laws before doing so - or better still, get (written) permission from the copyright holder. Fair use is complex and contended, you’d be well advised to be cautious.


In part 2 I’ll cover actually getting the disassembly...