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 having 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?!

  • 4
    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 Jul 16 '17 at 14:33
  • 2
    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! – user3570736 Jul 16 '17 at 16:49
  • 1
    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 Jul 17 '17 at 14:25
  • 1
    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 – Steve Smith Jul 17 '17 at 15:15
  • 1
    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 Jul 18 '17 at 9:44
up vote 31 down vote accepted

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 in CP/M emulated under a VAX for reusing 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 - if I am not mistaken, Jetpac from Ultimate Play The Game, was one of those 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 (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, connecting the parallel port of a IBM PC/AT to the EAR and MIC tape port of a ZX Spectrum. (I actually wrote TAPE2TAP in Intel assembly that loads tapes/gets saved data in from an EAR port 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:

tape

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.

SLOW ASSEMBLER

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 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, 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. Nevertheless, it 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, and released the first emulator in Windows for the ZX Spectrum 48k around 96 - 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 util, 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/dev scene to export and import back 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 98.xx%-99.xx% of it 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, 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: in fact in the heydays of Spectrum there were rumours of vestigial CP/M routines in the actual Manic Miner tape, at least in the first launched version. Cannot remember more details.

PS2: There were also rumours 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 – Jürgen A. Erhard Aug 11 '17 at 7:04
  • @JürgenA.Erhard The question does mention it, and contemporary magazines hinted they were not the only ones using advanced computing rigs for cross development. – Rui F Ribeiro Aug 11 '17 at 12:25
  • 1
    Sorry, you're right, I was skimming and missed out a vital piece of text. – Matt Wenham May 14 at 11:41
  • 1
    Wow, this deserves an upvote just for its sheer size! :-) – user6464 Sep 12 at 1:35
  • 2
    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 Sep 28 at 13:22

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 Jul 16 '17 at 19:00
  • The Oliver Twins have their own webpage? That is so cool! – CJ Dennis Jul 17 '17 at 3:20
  • @CJDennis they also have a book out. – mickburkejnr Jul 17 '17 at 9:29
  • TIS-100 is a great game. – JeremyP Jul 17 '17 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 May 14 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 Jul 17 '17 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. :) – Eight-Bit Guru Jul 17 '17 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 Jul 17 '17 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 Jul 18 '17 at 12:10
  • @billk I also had no one to talk to, but the aid of an excellent Spanish Magazine, MicroHobby – Rui F Ribeiro Jul 20 '17 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. – Andy Pennell Jul 18 '17 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? – Rui F Ribeiro Jul 18 '17 at 21:32
  • 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). – Andy Pennell Jul 19 '17 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. – Rui F Ribeiro Jul 19 '17 at 1:13
  • (I did give a run to Hisofts Pascal and C at a friends house though. The little buggers did work). I implemented a known integer circle algortihm in C – Rui F Ribeiro Jul 19 '17 at 10:30

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.

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.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.