I used a Z-80 assembler called M-ZAL from Computer Applications Unlimited. It was a very lean and robust assembler and linker, and it had a good text editor. I also created some tools that converted the pictures I drew into hex data for inclusion in the program, as well as some programs that managed the data tables for the monsters.
The joy of building GemQuest was in constantly coming up with new things to add. (This was probably also why GemQuest never shipped…)
One day while cramming more features into the program, I got an unexpected shock: the linker failed with an “out of memory” error. I knew roughly how much free memory there was on a TRS-80, and I tracked the size of the GemQuest executable, so I hadn’t worried that I was running out of room. However, it turns out (no surprise in retrospect) that in order to link, there needed to be enough free memory not only for the GemQuest executable being built, but for the linker’s own executable, and also the data tables the linker needed in order to do its job.
Now by this time I had a Model 4. The Z-80 processor had 64K of memory address space, and on the Model 4 (running in Model III mode) the bottom 16K was the ROM, and the other 48K was RAM. However, the Model 4 had 128K of memory, with a bank-switching design where you swap the top 32K of RAM for one of two alternate banks of 32K memory. I wondered if there was a way to take advantage of that to break through the limit. At that time, I had no real idea how a linker worked, and I certainly didn’t think I could write one.
What I ended up doing was processing the M-ZAL linker through a disassembler. This gave me a crude assembly-language version of the source code with no comments or labels to figure out what was going on. This was a giant puzzle. I knew a lot of the addresses of various ROM routines, so I started by labeling those. For example, I found code that called the ROM “clear screen” function, and then started drawing the title screen – aha, here was the beginning of the program. I used each clue as the basis for uncovering the next clue, and over the course of an intensive weekend glued to the computer, I ended up creating a fully commented reverse-engineered source code copy of the M-ZAL linker. Moreover, I gained a deep understanding of how linkers worked. I found that the code that wrote the bytes of the linked executable was in one specific place. It was simple to wrap that with some bank-switching code, and I created a version of the linker that wrote the resulting executable into the secondary banks of memory.
I now had a linker that I could use to keep building GemQuest. (In fact, my linker could build a 64K executable, which would be far too big for any TRS-80 to load…)