My computer has reached the point that I can run arbitrary code on it. Having sorted out how to get a decent chunk of arbitrary code onto the device without removing the Flash ROM and using frankenprogrammer I’ve turned my attention to what I should run on it.

The TRS-20 is supposed to be able to run old software to tickle my nostalgia. I don’t intend to write everything myself: if I don’t think I’ll learn from it, or have fun with it, I’ll use what already exists. This applies in the case of the operating system, where there’s a wealth of options available for retrobrew Z80/Z180 computers.

My original TRS-80 Model I didn’t have a disk drive, and so it didn’t have a disk operating system. Instead it had a built-in BASIC interpreter and a tape cassette interface for loading programs. Machine language programs were supported, through trickery I don’t recall using. But, all that aside, I’ve no particular desire to take my nostalgia trip so far as to limit myself to TRS-80 Level 1 BASIC.

The banner image is (as it clearly says) TRSDOS, which I never ran. It might be possible to run it, but I don’t see much reason to try - early versions are extremely limited, and I am not sitting on a trove of TRS-80 software I’m itching to run that would need something it provides.

So we move on to CP/M, the dominant disk operating system of the Z80 era. For those unfamiliar with it, as I was, it’s the progenitor of the venerable MS-DOS: Microsoft’s classic operating system reimplemented large parts of CP/M, accusations were made, unpleasantness abounded, long story short Digital Research didn’t last but Microsoft did. The rights for CP/M bounced around for a while, and eventually the company holding them granted a license to the Unofficial CP/M Web Site to distribute the CP/M source code, amongst other things. So CP/M appears perfectly valid to run.

CP/M’s popularity means there is vast amounts of software written for it. Enthusiasts have kept large archives of the stuff online for decades. Some of it is probably going to be worth running… and CP/M 2.2 is easy to port to a Z180 retrobrew system like mine.

Other alternatives include Fuzix, a UNIX for 8-bit processors. It has appeal - but there’s a lot of work involved in porting it to new machines, and I think it’s likely to be permanently in development. On top of that, it’s a ton of C code and expects application software to also be C code, and I’m just not all that keen to pick up an obligation to write more C these days.

There’s also RomWBW which packs a lot into a ROM image: MMU-capable BIOS, support for CP/M 2.2, CP/M 3, ZSDOS 1.1, NZCOM, ZPM3, and some variant of FreeRTOS. It expects a 512K or 1024K ROM, though, and expects ROM to be at physical address 0, RAM at physical address $80000 - the exact opposite of the TRS-20. This assumption is hard-coded in multiple places. It does have nice ideas for a Z180 BIOS to consider: stubs in the 64K space invoking the MMU to jump to larger functions, for example.

In the end, just a plain old CP/M 2.2 is the most plausible starting point. There’s a solid guide for porting it to a new Z80 machine, too. So I added a CP/M BIOS to my boot ROM code, along with a 32Kb ROM disk. The boot code formats a 192Kb RAM disk as well, giving me a large working area. CP/M itself consists of two parts: the BDOS that stays resident while transient programs run, and the CCP command processor that is reloaded on every warm boot.

Running CP/M on the TRS-20

To bootstrap this into operation, I used my isp-writer project to copy the new boot ROM plus CP/M into the second 64Kb of RAM, patch various locations in it accordingly, then use it to boot CP/M. From there, I wrote a small tool to write a file into the Flash ROM, and installed the new ROM image. Satisfying.

In the Virtual TRS-20, I wound up doing something slightly different. The VTRS-20 uses ZSDOS and ZCPR as distributed by David Given in cpmish. On my unwritten TODO list for the TRS-20 is to replace CP/M 2.2 with ZSDOS and ZCPR - which will work out easiest if I rewrite my boot code and be more flexible about loading a BDOS and a CCP from fixed locations in ROM. This will let me update all the parts individually in Flash, rather than building a single image.

The VTRS-20 now supports running a CP/M command file directly from the command line, or booting into a CP/M shell with a set of files pre-loaded into the RAM drive.

The last few posts have been a bit of a catch-up exercise in documenting what I’ve done. From the blog alone, it may appear that after I first got some life out of the CPU board everything more or less stopped - but in truth I’ve been playing around with one aspect or another of the board since then, so much that I’ve fallen far behind on writing up what I’ve done. One consequence of that is that these last couple of posts have been written more out of a desire to just get some words committed to files than with any particular attention to editing. I’ve also been working on a LISP interpreter (because it seems like a fun thing to write) and being able to program the FPGA in-system - so perhaps my next few posts will be a bit less dry. I also still owe myself a final reckoning for how much I’ve spent on this project so far, and how much it would cost to build a CPU board given what I know now, so there’s at least one more rather dull post coming.

The TRS-20 is currently running 24/7, with its USB UART connected to a Raspberry Pi. I got heartily sick of fussing with two USB cables to both power and communicate with the device, and took a brief look into possible Bluetooth UART modules, before realising I could just SSH to the Pi and leave the thing plugged in permanently so I can play with it any time. Which works fine, until I lock it up with some shonky code and have to yank power to reset it. Eventually that might irritate me enough to make a remote reboot facility. Or at least try to sort out a reset button somehow.