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.
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 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
