TRS-80 Compiler ROM
September 2026
When I was a kid I was interested in this program. It’s for the Radio Shack TRS-80. It fills the screen with random dots.
10 CLS 20 SET(RND(128)-1, RND(48)-1) 30 GOTO 20
I remember letting it run overnight and in the morning there were still some black pixels. It’s very slow:
One day this cassette showed up:
It’s a BASIC compiler, you load it into high memory, write your program normally, then press the Z, X, and C keys at the same time to compile it. The first thing I tried it on was this random dots program, and my memory is that the screen filled up near-instantly, like in two or three seconds. This is actually what I saw:
It’s a lot faster, but not three seconds at all, which goes to show how much you can trust your memory.
I have a similar memory of seeing 1200 baud for the first time, after using 300 baud for years, and it was also a screen’s worth of text appearing near-instantly. That memory is wrong too! 1200 baud is not very fast.
Eight years ago I started wondering why ROMs at the time had a BASIC interpreter, and not a compiler. Maybe we could have all written proper games in BASIC this whole time.
Either they didn’t think about it, or they tried it and it just didn’t fit in ROM (or the result in RAM). I wanted to find out if it would fit, so I wrote a fresh ROM for the Apple II. It looks and works just like the regular ROM but compiles when you type RUN.
I wrote the compiler in C, which compiles to really inefficient 6502 code, so I ran out of ROM before I could implement strings or floating point.
Here’s a Mandelbrot set in interpreted BASIC:
And the same program in my compiled BASIC. It’s about 10 times faster:
It bugged me that I hadn’t actually been able to answer my question about whether a compiler could fit in ROM, so I did it again, this time for the TRS-80 and in assembly.
Again it looks and works mostly like the interpreter, you got line numbers and everything.
Here’s that same program that fills the screen with dots, but compiled:
It’s 1.7x as fast as ZBasic, I wonder why. Maybe my SET routine is faster.
Speaking of SET, I was poking through the TRS-80 ROM and found that they do the vertical divide-by-3 by doing repeated subtraction, which means that a SET at the top of the screen is faster than one at the bottom! I’ve timed it, from BASIC it’s 14% faster at the top, but called from machine language it’s almost twice as fast at the top.
My version of SET uses a lookup table instead. It’s 24% faster on average, but it costs 55 more bytes of ROM, which is probably why they didn’t do it that way.
Here’s a program in interpreted BASIC that fills the screen using character blocks:
10 FOR I=15360 TO 16383 20 POKE I,191 30 NEXT I
Here it is in my compiler:
It’s 68 times faster. You can type LLIST to show the assembly of the compiled code:
Thanks to Matt Boytim for the disassembler, which he wrote for George Phillips’s contest a few years ago.
And here’s a simple game written in BASIC, running interpreted:
You can move left and right and fire on these aliens.
Here it is in my compiler ROM:
I still didn’t get around to adding strings and floating point, but not because I ran out of ROM, I just ran out of motivation. The compiler uses 35% of ROM space so far. That leaves about 8k, which should be enough for strings, floats, and things like cassette access.
So yeah I think we could have had an alternative universe where we wrote games in BASIC instead of having to resort to assembly.
I can think of two reasons why they didn’t use a compiler. One is that Radio Shack wasn’t in the business of developing ROMs, that was Microsoft’s job, and Microsoft licensed ROMs with an interpreter.
The other is that with a compiler you need enough RAM to store the compiled version, that was impractical on 4K and 16K machines, and by the time they were selling 32K and 48K machines it was too late to switch.
I gave a talk about it at Tandy Assembly 2026:
The source code is available on GitHub.