Being a child of the 80s I loved my ZX Spectrum, did my best to learn BASIC but I felt like the games I was playing (Jetpac, Dizzy, Renegade etc) were perhaps not written using BASIC.

I wondered: how were these early games developed?

These days I've figured (or am guessing) they were written using Z80 assembly, and if that's the case, did the developers literally writing assembly by hand and running it on their Spectrums? How were they running it? How were they testing (or at least recovering from inevitable crashes)?

As a developer myself, I appreciate it's commonplace to have tooling to generate code. Did the developers of these mid-80s games have any tooling?

The only reference I've managed to find was an interview with Matthew Smith talks about building a custom interface board to write to ZX Spectrum ROM via a TRS80. Was that typical?!

  • 8
    I've also spotted anecdotes about VAXs and Exidy Sorcerors as hosts for cross-development tools, and I'm sure the wide array of Z80-targeting tools available for CP/M (including Pascal and C compilers) won't have gone overlooked. Damned if I have a complete answer from the array of vague mentions though.
    – Tommy
    Commented Jul 16, 2017 at 14:33
  • 4
    There's an interview with Sandy White, author of Ant Attack here (youtube.com/watch?v=RdrgBwSH9W8) where he explains how he hand-assembled everything on paper and typed the hex codes into the Spectrum via an interface. I don't know if this is typical either! Commented Jul 16, 2017 at 16:49
  • 5
    Some of the early Spectrum games WERE written using Spectrum BASIC, for example Football Manager by Kevin Toms. I can remember hacking it (trivial for this game) and giving myself almost infinite cash so I could buy the best players like Peter Shilton and Bryan Robson :-)
    – davidjwest
    Commented Jul 17, 2017 at 14:25
  • 2
    Steve Turner (Avalon, Quazatron etc..) write a blog where he often describes the processes he went through when developing on a Spectrum: graftgold.blogspot.co.uk Commented Jul 17, 2017 at 15:15
  • 3
    I did not write for the Spectrum, but I did write Conway's Life for the TRS-80 in hand-written assembly. I tested by writing small functions and testing each using a debugger.
    – Ralph
    Commented Jul 18, 2017 at 9:44

11 Answers 11


Interestingly enough, I stumbled in a related article, that hints firstly the (cross)development at Sinclair was made on CP/M machines, (which corroborates the Matthew Smith Manic Miner development in the TRS 80 reference on the OP question), and later on using CP/M emulated under a VAX for (re)using the original binary (cross)toolchain.

At Sinclair, a £60,000-plus DEC VAX 11/780 was used for software development, email and other shared activities — hardware design was done mostly on Valid workstations (one of which was broken so often it acquired an 'In' before its badge).

Pretty much standard corporate computing for the time, the '780 was a powerful beast capable of supporting forty-odd terminals over miles of serial cables. As the Sinclair lab was on top of the only hill for miles, lightning strikes on a radio mast nearby were common had a habit of frying all the line driver cards in the computer. Amazingly, this was never given as an excuse for delivery delays.

All the Spectrum software development tools ran under CP/M, the standard micro-computer operating system before MS-DOS took over. CP/M was designed to run on the 8080 and Z80 microprocessors, and a card with two Z80s lived in the VAX to run the operating system and interface it to the users. If two people were using the card then you could opt to run a Z80 emulator on the VAX proper — which absolutely soaked up all the processing power it had, slowing things down to an unusable crawl for everyone else.

As for other first developers, the ZX81 already existed at the time, and if memory does not fail me some of the first commercial hits were ZX81 adapted titles. Actually, as far as I remember, there were some oddities in the Speccy ROM that could only be explained from it being initially a conversion job from the ZX81 ROM.

In fact the easiest way to load ZX81 source titles or binaries over, before modifying them, was writing a short ZX81 compatible tape loading routine. Interestingly enough, one of these days, the author of Ant Attack was telling me in a Facebook thread that he first wrote a Z80 interpreter to run the ZX81 binary in Speccy hardware before doing a much improved conversion.

As for Matthew Smith, the experience seems more typical than is evident at first sight (or not), as I will talk further ahead.

I wrote a lot of Z80 asm code using the honorable Gens3 assembler and drinking a lot from the Spectrum ROM disassembly book and MicroHobby magazines.

I had the Gens3 assembler even before I knew assembly (1984), however I also wrote and input machine code by hand when I had my cassette recorder broken (which sadly was its normal state); it is actually doable to do the entire conversion process by hand, however it would just be easier writing the asm code in a another foreign contemporary platform, cross assembling it, and then just copy the opcodes by hand if need be.

In fact, some magazines at the time had Basic programs with a somewhat de facto "standard" hexadecimal format aka hexa loaders (with slight variations depending on the magazine you were reading), hexadecimal data lines with a checksum, to input programs by hand, which you could also easily use and adopt.

Nevertheless, the CP/M or the PC XT/AT and the Speccy processor bus were pretty well documented and understood even at the time, and it made much more sense cross assembling programs and developing/ hacking together a small electronic interface to bit bang data between two machines than inputting all the cross-developed code by hand before the appearance of the ZX Interface 1 expansion module in 1983 (basically in the 2nd year the ZX Spectrum was available).

Or instead of the data bus, using the parallel port of a IBM PC/AT to load Spectrum tapes. (I actually wrote TAPE2TAP in Intel assembly that loads tapes/gets saved data in the native ZX Spectrum ROM format using an IBM PC parallel interface). The electronic schematics are simple enough for exporting data out of the ZX Spectrum and are here as to show it ought to be simple to complement them to import data too.

. you need a 25-pin D-type connector (just like the one that plugs your 
  printer to your computer)
. a jack connector to plug to tape recorder
. some cable

        (1)     (2)   (Female connector seen from solder side)
  13  \  o   .   o   .   .   .   .   .   .   .   .   .   .  / 1
       \   .   .   .   .   .   .   .   .   .   .   .   .   /
     25 \_________________________________________________/ 14

At the jack (mono):

    (1)     (2)
     |       |
     |       |
     .-D1>---.          Don't try to see if this works without the
     |       |       diode and the resistor. If you do that you can
     |       R1      severely damage your printer port!
     |       |
      \      [ (4)
       \     [
    (3)  [   [     <-- This pretends to be a mono jack

R1 = 100 Ohms
D1 = 4.7V Zener diode

Actually the schematics for both directions are here in a better, and slightly more complex design:

(source: archive.org)

So contemporary cheap interfaces could be put together that cost peanuts for shifting data in and out of Speccy for PCs (I would swear there was a much similar design for getting tapes into an Amiga emulator, but I never owned one).

As such, while there are contemporary tales of Speccy titles stitching together multiple Gens3 runs, for any serious software house, and as the years go by in the 80s, it stops making much sense developing big titles directly in a Spectrum, as the memory, keyboard and screen size provide(d) a subpar experience compared to more advanced/professional platforms.

By probably much earlier on than the middle '80s, I believe you already had in widespread use (cross)assemblers running in CPM and DOS, but even failing that, or lacking the funds to buy one, the Z80/speccy architecture was simple enough to justify developing your own internal productivity tools for bigger projects (and for multiple titles).

Besides the ROM Basic, basic Pascal, extended BASIC and C compilers were available in the ZX Spectrum, however they were pretty limited, and if memory does not fail me the libraries also used up valuable memory (never used them much).

Despite the (many) limitations, many games were written using Hisoft's Gens3 assembler, which had an integrated editor/text IDE that was quite interesting back in the day. Gens3 also had a companion, Mons3 to disassembly and debug Z80 code step-by-step. Hisoft Devpac Both were released in 1983.

GENS, the program-generator, lets you type in up to 30K of program text in one lump on any Spectrum. This is enough for between 2K and 5K of machine code, though you can compile larger programs from disk, as explained later.

There's no fixed relationship between the size of an assembler program in text form and the corresponding machine code. The ratio depends on your programming style, and whether or not you include comments so you can understand what you've written when you come back to it after a few months.

Editing is fairly painless if you're used to line editors in the style of CP/M's ED or Microsoft BASIC's EDIT. Lines are stored in numeric order, and can be edited individually by moving a cursor back and forth along the line in a variety of modes. This is no substitute for a screen editor, but it's not too hard to get used to and doesn't need much code, leaving extra space for text.

The display can use standard 32-column text or a compact but readable 51 characters per line. Assembler programs are written in five columns

  • line number, label, instruction, operand and comment - so I prefer the > 51-column display even though it's a bit slow, taking about four seconds to redraw the whole screen. Groups of spaces are compressed into a single byte when a line is stored, saving memory.

The cursor keys have rather arbitrary effects - the right arrow is a tab key to skip between columns, but the left arrow throws away the entire line. The up and down arrows don't appear to have any effect at all!

The editor includes a full set of multiline commands, including automatic line-number generation, renumbering, searching for text - you can replace it with something else - block printing, deleting, saving and loading. Files can be stored and catalogued on disk, tape and RAM disk.


GENS can translate your completed program into code at about 50 lines a second, if the program text is already loaded. That may seem rather slow, but it won't bother you if you only assemble a few hundred lines at a time.

If you want to assemble a big program you must split the text into several files and tell GENS to read the text from disk rather than from RAM. This slows things down even more, especially as GENS has to read the entire text twice. Version 5.1 assembles about 309 lines a second when reading text from RAM disk, and 20 lines a second from floppy.

If you're really prolific you can spread a program over two drives and the RAM disk, so there's virtually no limit on the size of program you can assemble if you're willing to wait a 16K program could take about 7 minutes.

The assembler has some professional facilities. You can use macros with parameters: in other words, you define new symbolic commands that stand for a group of instructions of your choice, saving typing and text space. Whenever you write a macro name GENS inserts the whole group of instructions, plugging parameters in as required.

There was also many "rumours" and interviews in Speccy magazines in the heydays of Spectrum that hinted big software houses had developed (or bought) "powerful" cross-assembler/emulator tools, and (cross)development was being made in IBM PCs and Commodore Amigas. The resulting machine code routines were then transferred to a ZX Spectrum using either a interface 1 expansion module with a rs232 interface or manipulating directly RAM via the Spectrum bus interface. However, there were also hints the (first) emulator tools had not achieved yet 100% hardware emulation capabilities in software, at a decent speed (for several reasons).

I do remember (vaguely), an interview in Yes Sinclair (I think), were the developer of a known software house, while talking about the development phase of a recently released game, talked about their first experience using a cross-development environment. He was also complaining the debugging and testing phases were too limited on that environment for such a complex game. Apparently, they lost valuable time transferring multiple times data to a real Spectrum, only to find out a modification to a routine would not work (via saving a tape on the cross development system, and loading it on a real Spectrum, or via a serial interface, I think, not having a more streamlined process due to hardware limitations). That particular interview also dealt with the next steps they were planning to improve their cross-development rig for the next project, but sadly I do not remember much more of it, except them commenting it would allow them to run directly Spectrum binaries too. Nevertheless, the interview was not that rich in technical details. People kept under wraps whatever they were using.

I also found an interesting reference to Ultimate Games, which appeared earlier on in the life of the ZX Spectrum:

From the beginning, Ultimate developed games in a way very different from the typical Speccy bedroom coder. As with so much else about Ultimate, details of their development system are not entirely clear, but those early interviews do describe it as a 32-bit multi-user system on which they could write and compile their code and ship it over to an attached Spectrum for execution. (A best guess would be a 68000-based Unix workstation.) The methodology obviously borrowed heavily from that used by Zilec and their competitors for writing arcade firmware, and cost “several thousand pounds.”

As for Hewson (1988), already a bit later on the game, but here for the sake of completeness and history:

As you can see from the photographs, a lot more equipment is used in developing Spectrum games than a single Spectrum and cassette-based assembler! The Spectrum is actually developed on an IBM compatible PC which runs a fast Z80 cross-assembler that can compile a 200K source file in a few seconds. After the program has been assembled, it can be downloaded to the Spectrum via a parallel link, ready for testing.

The graphics are all designed on an Atari ST using the Advanced Art Studio. This package (programmed by my good friend Chris ‘8-bits are crap’ Hinsley) also features a ‘map editor’ that enables all the screens in a game to be chopped and changed very quickly. The ST format graphics are converted to Spectrum format data to be incorporated into the main program.

This type of set-up has many advantages over developing the program on the Spectrum itself. For a start you never have to worry about the Spectrum crashing, as the program is permanently stored on the PC’s hard disk. The program’s development time is cut down by a huge amount. The idea was to be able to write games using the (limited) full 48KB memory in games and speed up the development process.

Later on the life of Spectrum, around the mid 80s, people also used the 128K models as souped-up development rigs, notably with the Laser Genius assembler and the Gens4 assembler , which were expanded to be 128K aware and were thus able to use the extra memory.

GENS4 is a fast, two-pass Z80 assembler which assembles all standard Z80 mnemonics and has added features which include macros, conditional assembly, many assembler commands and a binary-tree symbol table.

Back in the dying years of Spectrum, emulation and cross assemblers/cross compilers started being written by "common" people, first in assembly, JPP and Z80 the better known for DOS, and, as more powerful CPUs started being more affordable for domestic use, using the extra CPU power and development kits allowing writing near same speed emulators in high level languages.

(I myself wrote an emulator/step-by-step debugger for it in C for DOS around 1990, using TASM as a cross-assembler for Z80 code. Release the DOS emulator in a local BBS around 1992 and released the first emulator for Windows for the ZX Spectrum 48k around 96, announcing it in comp.sys.sinclair - see First computer emulator in Windows and wspecem).

Common user ported games to/from emulator platforms using tape. I myself wrote too in 80x86 assembly an open source routine to load ZX Spectrum tapes in an IBM PC TAPE2TAP,that was used in a wspecem companion utility, and adapted for the Warajevo emulator (with my blessing).

By the Z80, wspecem and Warajevo emulators time, there were already several emulators and utilities in the emulation/development scene to export and import back Z80 Spectrum binaries via tape.

The .TAP and shortly later on the .TZX file formats started being more used to store images of emulated tapes. By that time, the Speccy, Z80 and ULA behaviour was also relatively well understood, and maybe 98.xx% of the expected (and unexpected) behaviour was fairly well emulated.

Up to these days people normally develop for the ZX Spectrum in more modern hardware, and load the resulting machine code via tape or micro SD card adapter interfaces, of which the most known is the DivMMC

PS Coming back to the Manic Miner lore.

The story goes Matthew Smith developed and tested the core of Manic Miner running in the TRS80 before the Speccy was launched. (in fact in the heydays of Spectrum there were rumours of vestigial CP/M routines in the actual Manic Miner tape...cannot remember the details)

He then wrote blindly the Spectrum specific routines.

Using his personal connections, got (paid) access to the Sinclair development rig one entire weekend from Friday evening to Monday morning, one or two weeks before the Spectrum official launch, to debug and save the final version to tape, in a truly hit or miss marathon.

So as it appears, the game actually was ready by the time the Spectrum hit the shelves. What Matthew Smith did not count on was the delays on the distributor logistic. If memory does not betray me, the original one even managed to miss the Christmas season.

The rest, as they say, is history.

As far as I remember, after the Manic Miner money downfall, he got his own ZX Spectrum cross-development rig, from the same supplier of the Sinclair team.

Disclaimer: the details are too hazy after all this years. While I think not, I might have mistaken this Manic Miner story for other game.

PS: There were rumours of vestigial CP/M routines in the actual Manic Miner tape, at least in the first launched version, and nowadays there are also proofs of source code remnants in the speccy address space.

From http://skoolkit.ca/disassemblies/manic_miner/reference/facts.html#sourceCodeRemnants

Before the game starts for the first time, the 512-byte cavern buffer at 32768 contains source code remnants (shown below). The DB directives define part of the title screen tune data at 33902. There are more source code remnants at 37708.

This bit of information actually suggests the memory was not actually bit-banged in binary format from CPM, but was originally loaded in an intermediate format, or at least part of it.

see also First computer emulator in Windows

  • 1
    That part about SW dev at Sinclair... isn't really relevant, since that's more about system software (developing the machine itself) than developing SW for the Spectrum. Of course you can't fully dev the ROM for the Spectrum on the Spectrum, since at that point in time there is no Spectrum to dev on :D Commented Aug 11, 2017 at 7:04
  • 1
    Sorry, you're right, I was skimming and missed out a vital piece of text.
    – Matti Wens
    Commented May 14, 2018 at 11:41
  • 1
    Wow, this deserves an upvote just for its sheer size! :-)
    – user6464
    Commented Sep 12, 2018 at 1:35
  • 6
    Matthew Smith hand made a cable from the TRS-80 to the Spectrum to transfer data direct. The same cable worked on the Atari ST, I know because he gave it to me. He still also has the original source code to Manic Miner on his ancient TRS-80.
    – WLGfx
    Commented Sep 28, 2018 at 13:22
  • 2
    I enjoyed reading ROM Disassembly much more than adventure thrillers in those times. For each label which was mentioned in the listing I completed list of all instruction which referred the label in question. This cross-reference table is still available online at vitsoft.info/zxref.htm
    – vitsoft
    Commented Apr 27, 2020 at 18:50

This is quite a wide-ranging question.

There are some resources online which help:

Jonathan Cauldwell, author of various Spectrum hits, has a How to write games for the Spectrum" guide, which seems to mainly cover modern Speccy development.

The Oliver Twins (authors of many Codemasters-published titles back in the day) detail some of their development processes in their History pages.

Apparently I need more reputation to publish more than two links. Darn.

From my own knowledge of Amstrad CPC gaming, a popular native assember was Maxam, which could be loaded from disk, tape or a custom ROM package attached to the interface port of the machine. The Multiface was a similar tool which allowed the user to break into a currently running program at the press of an external button, whereupon the user can view and modify memory and the CPU's registers, which I imagine would have helped with debugging games. It certainly did help when hacking them!

Tools such as C and Pascal compilers, which did exist for these early machines, were workable but would not produce assembly of sufficient speed to eek every bit of power from the CPU, which typically only ran at around 4MHz. All of this speed was definitely needed to deliver realtime arcade-style games. Of course memory was also tight and optimised assembly routines would usually take up less space than the equivalent code compiled from a higher-level language. Programmers would often employ tricks to reduce processing requirements by a few clock ticks including using then-undocumented Z80 assembler commands and writing self-modifying code.

If developed in assembly language, a program is translated into Z80 opcodes and placed into a specific starting address in memory. To run the program, the address is called, which means the CPU's Program Counter is set to the address required. This can usually be done from BASIC.

To test a routine, it can again be directly called, but first the CPU's registers must be set to the values expected by that routine, akin to method parameters today. The 'return value' from such routines would again be placed across the various registers, meaning a routine could return more than one value. Of course routines could read/write memory and so on as well. If the program crashed or locked, the machine would have to be reset and the program reloaded from disk or tape.

(Aside: if you want to get a feel for how development was on these old machines, I wholeheartedly recommend TIS-100, which simulates a computer with very limited memory and a restricted command set. Unfortunately it's a multi-core system, which no machines were at the time, but it certainly sets the right tone).

As evident elsewhere, it was fairly common in the larger software houses to connect the target 8-bit micro to something more powerful on which the actual development work would be done, perhaps an IBM-PC or similar. Many games however were written on the machine itself, at home, in the spare time of schoolchildren, students and people employed in non-gaming industries, making this a true technical revolution which touched the lives of most young people at the time.

I hope this has helped a little.

  • 7
    The six paragraphs you posted afterwards are exactly the reason you need more reputation to post more links (apart from spam, of course). Welcome to Retrocomputing Stack Exchange. Please read the tour then have a go at answering some more questions!
    – wizzwizz4
    Commented Jul 16, 2017 at 19:00
  • The Oliver Twins have their own webpage? That is so cool!
    – CJ Dennis
    Commented Jul 17, 2017 at 3:20
  • @CJDennis they also have a book out. Commented Jul 17, 2017 at 9:29
  • 1
    TIS-100 is a great game.
    – JeremyP
    Commented Jul 17, 2017 at 9:45
  • 2
    @MattWenham Of course it's possible to create a C compiler for these CPU-s (there's also some for MOS 6502), but the result won't be very efficient. Given the severe restrictions in speed and memory size, you certainly can't afford such overhead in most projects. Maybe, if you restrict yourself to use global variables only, and you have some very smart compiler that will certainly has to run on another more powerful computer...
    – ddekany
    Commented May 14, 2018 at 12:03

I remember a friend of mine who did a lot of C64 coding. I distinctly remember seeing him writing out the assembly mnemonics on a lined notepad, then working out what the hex codes were for each instruction, then writing a BASIC program to POKE them into memory before running them. He did eventually get a disk assembler (store a text file on a floppy disk, then run the compiler from same disk, output binary was written to same disk), but in the early days of C64, that wasn't really an option. Although the programs he wrote back then, with this method, weren't 'games', he did get a few listings published in magazines, and later, one conversion that was a MASSIVE hit.

  • 1
    This is the manly way of programming. Seriously, when I was a kid programming my C64 in assembly, I saved up and bought an assembler cart. I can't remember the name of it.
    – cbmeeks
    Commented Jul 17, 2017 at 12:33
  • Probably the Programmers Aid Cartridge, which had a pretty good Machine Code Monitor in the feature-set. Or maybe SuperMon, which was my weapon of choice. Today of course I use VSCode, KickAssembler, and VICE. :) Commented Jul 17, 2017 at 14:21
  • 2
    This is how I learned on the TRS-80 with nothing but a flimsy knowledge of basic and a z80 assembly manual. How I would have loved to have someone--ANYONE--who was even remotely into the same thing that I could talk with about it. Don't for get to save your program onto cassette tape before running it because the slightest coding error means a full reset/rewind your tape/hit play/"cload". Still, easier than submitting a punched card deck.
    – Bill K
    Commented Jul 17, 2017 at 16:34
  • @BillK, one of my full assembler programs on the Atari 800 XL was a floppy disk (360K!) tool - it could do custom disk formats and such things. I dare you, no, I double dare you to guess how I lost the program. :D
    – AnoE
    Commented Jul 18, 2017 at 12:10
  • @billk I also had no one to talk to, but the aid of an excellent Spanish Magazine, MicroHobby Commented Jul 20, 2017 at 7:33

Many, many Spectrum games were written with Devpac, on the Spectrum itself. Devpac was written by HiSoft, where I worked during this period (on the 68k Devpac, I never worked on the Z80 stuff myself).

HiSoft themselves developed their Z80 software on CP/M machines (using their own Z80 assembler), though for the life of me I cannot remember how they got the code from the CP/M machines into the Spectrum.

  • 1
    Slight correction: Devpac may not have been the term used, but Gens and Mons (in the post below) were the assembler and debugger that I was referring to. The Devpac term may have in fact started with the 68k stuff (Atari/Amiga), that I created. Commented Jul 18, 2017 at 15:55
  • Reread your answer and it just dawned in me you mentioned working in Hisoft. Trivia question, where Gens3, Mons3, and/or Hisoft C and Pascal compiler running in Z80 natively or into p-code? Commented Jul 18, 2017 at 21:32
  • 1
    They were all written in Z80 and C and Pascal generated Z80 directly: no p-code. There were limitations (eg no floating point is one I can recall). The first time we wrote anything in a high-level language was the linker for the Atari ST (which was my first experience with C). Commented Jul 19, 2017 at 0:58
  • Interesting, I could swear the whole family of tools generated p-code, but truth be told, I mastered assembly on the ZX Spectrum, and never cared about using other languages on it. By the end of the eighties I was already introduced to HP/UX, Xenix, Turbo Pascal/C and Microsoft C and MASM. Commented Jul 19, 2017 at 1:13
  • 1
    @AndyPennell, me and another guy used Devpac for the ZX Spectrum quite a bit, though never for anything as big as a game. We always called it 'Devpac' as the 'Gens' and 'Mons' names in the manual were too naff to say out loud eighty times a day :-) Great piece of software, wondered why your name was familiar...
    – TonyM
    Commented Oct 18, 2017 at 9:02

I wrote loads of ZX Spectrum games in the 80’s for Firebird, Masterteonic and Software Projects. I had a Tatung Einstein hooked up to a spectrum via a custom RS232 cable. I had a program running on the Einstein that let me code in Z-80 assembler before porting it over to the spectrum to test. The port took about 10 seconds which allowed for rapid development. The Einstein also had a built in drive and diskettes which made life a lot easier too.


I can only answer authoritatively for Adventure International UK, as I worked there.

The ZX spectrum games were cross assembled on a TRS80 (model III or 4 I think III but it was a long time ago) with floppy disks using the standard rather nice TRS80 Z80 development tools. We had a magic cable that went from the TRS80 to the tape port of the spectrum and a tool that bitbanged the spectrum tape protocol.


I did a lot of work on the ZX Spectrum in the 80's using an assembler that I created myself, which ran on the Spectrum itself. I started out doing machine code, but it was not productive and made it hard to go back and change things later on (it was write-only, as Phillipe Khan once said).

Creating an assembler made it a lot more productive, especially as I added macros, etc.

Mostly I worked on games and hacker utilities, the latter being used to investigate games to discover pokes, etc.


Writing games those days was a long process, full of write - save - compile - run - crash - load - edit cycles. It was very frustrating, especially in the case you had only the tape recorder. Microdrives or floppy shorts the save / load time to minimum...

So basically: yes, you can develop the game on the ZX Spectrum itself. The assembler itself takes some memory, but the game is not only code, but there are also a lot of graphics or sprite data, etc. So you could write smaller parts of code, e.g. music routines, graphic routines, intro, each of them debugged, and on the very end of the whole process, you simply load all of those pieces together.

I have used DevPac (GENS/MONS) at first, then I moved to the PikAsm and V.A.S.T. combination.

But of course, cross-compiling / cross-development with another computer was more comfortable, but not accessible to everyone.

  • Hi, what were the advantages of pikasm over gens? Commented Aug 18, 2021 at 10:24
  • Pikasm has fullscreen 64 columns width editor, GENS uses line-based editor with commands. It is much more comfortable to work with. Commented Aug 18, 2021 at 11:52

I remember assembling by hand, and then inputting the hex code using a BASIC program called EZ-code, whose listing was provided in a book, which I still have (although it is falling to pieces), called Spectrum Machine Language for the Absolute Beginner by William Tang:

Spectrum Machine Language for the Absolute Beginner

As there was a limit1 to the size of the code, due to the size of EZ-code's BASIC code, the coding had to be done in chunks, with each chunk written to tape, and then the respective parts where then "linked" using another BASIC program, from the same book, called Hexloader, with each chunk being read from the tape and then saving the code as a whole back out on to tape.

Arduous? Yes, but well worth the effort.

I also remember there being a, rather pricey, Disassembler and Monitor produced by Sinclair themselves, and there was an Assembler too:

Disassembler and Monitor and Zeus Assembler boxes

1 A limit of around 800 bytes and 200 instructions.

  • 2
    Zeus is still in use and under development by one of the original authors: Zeus
    – scruss
    Commented May 13, 2019 at 1:48
  • Zeus could be used stand alone, or both Crystal utilities loaded to make a more comprehensive development system. As well as the Sinclair branded versions, Crystal sold directly into the market via retail outlets.
    – user24174
    Commented Aug 2, 2022 at 15:07

I sometimes used OCP Fullscreen Editor/Assembler to assembler some routines, but I would compile all the code using Hexloader V2 (from Your Sinclair October 1989), which was basically a fullscreen hexloader that allowed me to scroll through memory. The hexloader fitted in 700 bytes so it was small.

Also, I used Forth using White Lightning.


...but I felt like the games I was playing (Jetpac, Dizzy, Renegade etc) were perhaps not written using BASIC.

They certainly were not! As you surmise, most games were written in Z80 assembly.

...did the developers literally writing assembly by hand and running it on their Spectrums? How were they running it? How were they testing (or at least recovering from inevitable crashes)?

Most games were targeted to a Spectrum loading from cassette tape. Generally they were writing the games either by using a Spectrum with various expansions that the end-user was not likely to have or by doing cross-development. For some descriptions of typical development systems, see my answer to this question.

The game could simply be run from memory if they were developing on the target platform itself (with memory restrictions as described in my answer above). If doing cross-development, after building the game they would have to copy it to the target platform; a serial link was one way of doing this.

If the game crashed, they could use a reset (or sometimes an NMI) to bring up a small debugger that would let them poke around to see what went wrong, or they could just reload the entire game after using whatever information they had to figure out the problem. It was no doubt common to put temporary diagnostic code into a program that would help indicate what was going wrong in a problem area, just as we do today. And also to run just parts of a program (either by jumping directly to that part from the start or just leaving out part of the code) so that you could get directly to the point in the program you were working on.

The only reference I've managed to find was an interview with Matthew Smith talks about building a custom interface board to write to ZX Spectrum ROM via a TRS80. Was that typical?!

It entirely depended on the output format, but it was typical to use some other method, faster than the final distribution format, for loading the program into the target machine, as mentioned above.

I am not clear on why one would be writing a ZX Spectrum ROM; this was not how games were normally distributed, though it could be used for software for a hardware expansion device.

It's possible that he actually made hardware for ROM emulation, and would download code to the emulator which then would appear as ROM to the Spectrum. That is one of many ways to get code into the target computer more quickly.

As a developer myself, I appreciate it's commonplace to have tooling to generate code. Did the developers of these mid-80s games have any tooling?

Absolutely. The same book I mentioned in the answer above, Bob Pape's It's Behind You, discusses this. From page 43:

At home in Swansea I started work on the game, or rather the tools I'd need to write the game, as it was obvious that some sort of level editor would be needed to create and map the levels and also a sprite editor for the sprites and graphics. There were a few of these kind of programs around at the time but they tended to be written by a coder for a specific game or were totally generic in nature. In the former case you usually had to deal with some non-standard way the output data was created or you'd find one that looked promising but forced you to work with tiles or characters in a way that just wouldn't work for your game and in the latter, generic case, you usually ended up with way too much data.

This meant I had no choice but to write my own editors, which would take some time but would produce the graphics in exactly the right layout I wanted rather than trying to convert somebody else’s format. When I say "I" of course I really mean Mark Jones, who would be handling the level mapping, sprite design and all other graphics for the game.


I do have to put my hands up to cheating slightly on the tool coding though, TileD and ED209 (the names I gave to the Spectrum based R-Type level and sprite editors) had a copy of the commercial Melbourne Draw art package embedded in them which handled all the character creation and drawing functions. Not having to create basic graphic functions from scratch saved both of us a lot of important set-up time.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .