Retro-Invaders! - Part 2

Shawn Delahunty's picture

"That's No Moon, It's A Space-Station!"

Hey again! Time for Part 2 of my little foray into retro-system game programming. This time around, I'm going to jabber on a bit about the process I went through while actually experimenting and coding "The Idea". To bring this "Retro Masterpiece" of slow-poke BASIC code to life took me a grand total of about 18-20 hours; and that includes the time I spent mucking around trying to get the &*#%$-ing cassette port working, plus writing the various bits of test code. (Hah! Take that 3D-Realms!)

But my real dilemma for a while was, what to call it? During the coding process, I put a placeholder in for the title screen. During that time, the game went through several truly idiotic working-titles. In idle moments, while pondering what to type next, I would amuse myself by putting in the most ridiculous things I could think of. It was really quality stuff, like "The Crap-Tastical Retro Invaders", and "Blip-Holes from Mars". The final title came to me during the process of trying to figure out how the little alien baddies could drop bombs on the player, without slowing the already hideously slow game to something that would drag on until roughly the heat-death of the known universe...

Eventually, after trying several different things, inspiration came from just outside my home-office window. A storm front was coming, and the rumble of distant thunder crossed a couple of neurons in my head. Instead of bombs, or missiles, how about if the aliens could summon a small cloud and send down lightning bolts? This solved a whole bunch of problems for me, put an interesting spin on the gameplay, and inspired a suitable name..

Thus was born,


retrozap_titlescreenIn the beginning, there was RETRO-ZAP!...
retrozap_bonus_saucerChasing the saucer...

There is no sound. There is no color. There isn't even much in the way of graphics animation. But to borrow a very apt quote from the infamous Dr. Frankenstein: "IT'S ALIVE!"

retrozap_zappedARGH! ZAPPED!
retrozap_gameoverSorry Charlie...

For those who wish to skip past my description of the coding process, feel free to scroll to the bottom of this article for the YouTube links to the videos on my channel. There are two different videos. One covers the machine, some information for anyone trying to get data either onto or off of these old TRS-80 systems, and some bits from the making of the game. The second is devoted to the game itself, and covers various aspects of the finished code.

Haven't skipped ahead? Still here? All right! You are MY kind of nerds.. uhm, people... Onwards we go.

If you wish to try the finished game for yourself, you will almost certainly need to download and install a TRS-80 emulator too. After all, how many folks, have an actual, honest-to-God TRS-80 machine lurking in the back of the closet? (Yeah, yeah... I know that Bill probably has ALL of them... in multiple colors. I'm viridian with envy over that man's collection of retro-cool computing awesomeness.) An excellent place to begin exploring the various TRS-80 and Tandy 8-bit computer emulators is with Ira Goldklang's website.

For those that do care to monkey about with the game, either on an emulator or on the real machine, you can obtain a download of the finished program at the bottom of this blog post. The ZIP file contains the program in 3 formats:

  1. retrozap.flac This is a FLAC audio file--just a WAV in drag. This is the file you want if you are trying to load onto a real piece of hardware. You simply play the FLAC out of your favorite audio program and directly into the cassette port of a real TRS-80 machine, as I demonstrate in the videos.
  2. retrozap.8bit.mono.wav This is just what the name looks like; a WAV file down-converted from the original recording on my laptop. The emulator I used for testing could input and output 8-bit, monophonic files, and I assume most others do as well, so I provided it for you. It is possible to use this file with the real hardware, but it can be fussy. I really recommend the FLAC for that purpose.
  3. retrozap.cas If you're using an emulator, your best bet is this file. CAS, or cassette image files, are used by most TRS-80 emulators to fake-load things from "virtual cassette tapes." The details of how to get them into the virtual machine will vary depending on which emulator package you choose. Refer to the documentation that comes with your emulation software for configuration details.

Important Emulation Note:
If you wish to try out this game, you'll need to download and install a TRS-80 Model III or Model IV emulator. The game actually does function on a Model I, in a manner of speaking, but it looks terrible. (It's certainly no stunner on a Model III or IV, but it looks much less terrible.) On a Model I, the game will not display the cute little bitmapped graphics that you see in the video. Instead, you'll get funky looking blobs. This limitation of the Model I machine stems from the character-graphics ROM chip used. It does not offer the full 8-bit range of characters available on the later TRS-80 models.

Important non-Emulation Note:
If you want to download the game to a real machine, you'll likely want to patch the cassette-port cabling into the microphone and headphone jacks on a modern computer. You may want to watch my YouTube video on the development of the game, as getting the thing set up initially was a tad fiddly.

Some Nitty Gritty Bitty Bits...

The first question people might have is, "Why on Earth would you waste your time on this, writing a game in BASIC for an obsolete platform?" My response is, "What are you doing, wasting your time asking questions like that on Armchair Arcade? BECAUSE WE CAN!"

Part of that question isn't completely silly though. Why did I choose BASIC, and eschew any machine-code?

Firstly, because for a lot of folks, machine-code is an impenetrable barrier; a near-mystical wall of hexadecimal gibberish. Most folks can at least fumble their way through BASIC and get the gist of things. Also, it takes a lot more effort to write and test code in Assembly on the original machine--as I'm not doing this for moola, that limits how hardcore I want to get.

My second reason is somewhat complex. In essence though, the much, much slower speed of a BASIC program is actually a benefit to a novice programmer; which is precisely the kind of person I expect to take an interest in this goofy little project. Using BASIC strongly reinforces the value of:

  1. A good understanding of the hardware limitations of a machine. Machines today are ridiculously overpowered, and all software suffers as a result--in my opinion, most programmers today are insanely lazy, and chew up far too many resources. Programs which require an installation DVD are almost certainly over-bloated crap. (I'll excuse most games from this for the most part, if the bulk of the DVD is devoted to sounds and textures. If, however, the installer is 230 MB in size, then I hereby put you on notice: YOU ARE CODING IT WRONG. DO IT OVER.)
  2. Good Algorithms. Again, overpowered modern hardware means that sloppy thinking and sloppy/inefficient algorithms get used far too often. On these old platforms, a good algorithm was probably still slow--but bad algorithms are GLACIALLY slow. (In Retro-Zap! this can be seen in the marching columns of the aliens. This code is tweaked to be as efficient as possible--and I still had to kind of, "code around" the problem, by throwing in sections where the aliens stop marching completely in order to animate the BONUS saucer and the Zap! attacks.)

Thirdly, if anyone felt inspired by my little experiment and wanted to mess with it, had I used assembly code their task would be magnitudes harder. They would have to find a Z-80 Assembler program DSK-image, and then get that running properly on their old machine or emulator. Then they'd have to work out the ugly details of Z-80 machine code if they weren't familiar with it already. Not a great option, obviously. The BASIC interpreter is already a part of the machine ROMS--just start the machine or emulator and go to town. (If anyone IS interested in messing about with Z-80 assembly on a TRS-80, the program you are looking for is called TBUG. There are some DSK images for it floating about on the Web. Yes, there may be some other Z-80 assemblers for the TRS-80. Save yourself the pain and just find TBUG.)

My last reason for choosing BASIC, and probably the most important, is to try and approximate an "Oranges-to-Oranges" comparison between the early days of the 8-bit platforms, and today. What do I mean? Well, there is a fair bit of similarity between the BASIC of yesteryear, and the GameMaker type utility of today. Back in the late 1970's and early 1980's, it was actually possible to write a program in BASIC and make at least a few bucks in sales from the thing. The same type of situation is true now; there are several commercial games available, mostly of the JRPG and Adventure variety, written in GameMaker. (Several games written using the commercial product Dark-Basic come to mind as well.) It doesn't take a huge investment in learning complex programming, or super expensive tools to write a game of that type--just a goodly helping of dedication and time, and a desire to craft good gameplay.

Given how inaccessible and stratified modern game development has become, I felt it was important to give folks a little bit of a reality-check--it is possible to still write good, even popular games, without trying to fund a AAA studio. Want a 'fer instance'? One word: ROVIO. With the Angry Birds franchise/explosion, those dudes are worth roughly 53 Squintillion bucks. They probably earn more in a month than EA has spent in the past 4-5 years. Is it common? No, it's the wet-dream of all game developers. But it both can and does happen.

Am I going to start a retro-game craze and cash-out to retirement with RETRO-ZAP!. Nope. But I did only spend 20-odd hours on the thing. If I came up with some cool gameplay on a modern system, which had a retro-styled "feel" to it? Well, I might very well be able to go pick out a new Ferrari while wearing my stylish money-hat. Think I'm joking? Look at MineCraft. Really look at it. You don't get much more retro. It just takes one break.

But that's enough pipe-dreaming for now...

The BAD Parts:

Since everybody asks for the "bad news" first, I thought I should begin here. For the record: No, my little experiment wasn't a complete and utter nostalgia-gasm, filled with shimmering rainbows of joy and sparkly unicorn farts. There were some things about this process that I classify squarely in the BAD category; some of it was downright AWFUL, in point of fact.

When I began this side-project, I fully expected that there would be snags and hiccups and irritations. Mostly, I assumed that they would center around the ghastly slowness of line-numbered BASIC, and the lack of other 'niceties' provided by more advanced programming languages. (Writing code in line-numbered BASIC is really almost exactly like writing software in pure assembly code. You have no crutches, no shortcuts, no automated anything. It's just you, the keyboard, and an antagonizingly literal CPU--eyeing you with an aloof stare, as if daring you to try and make it function.)

It turned out I was completely mistaken.

The worst thing about writing this game, on an actual TRS-80, was the physical pain. Yep, it actually, physically, hurt me to write code on this beast--thanks to the absolutely crap ergonomics. First off, let me lambast the keyboard, as that's the programmer's primary tool.

To begin with, there is a peculiar and odd spacing to the keys. It looks like the keys on an IBM Selectric, but I got news for you, it AIN'T an IBM Selectric. The weird spacing (coupled with some temperamental key switches) caused no end of typos, and also gave me pretty severe wrist pain in a troublingly short period. A couple of hours in, I actually started having flashbacks to the aching wrists I would get in high school. All I can say is Thank God for ergonomic keyboards, or I'd now be typing with hooks for hands or a pencil taped to my forehead.

Next up, you have the non-standard, and frankly wonky layout of the keys. It's technically a variation of QWERTY, but only just. While in the throe of pounding out an idea, I suffered a great tendency to hit the Clear key, when instinctively going for the Backspace. Naturally, hitting Clear causes the TRASH-80 to completely dump you out of the line you were editing, so you get the joy of retyping THE WHOLE DAMN LINE, while listening to the crunch of your wrist tendons abrading. What nitwit thought that was a good idea?!?

After the keyboard, the next-worst ergonomic issue with the TRS-80 is the CRT. This was exceptionally irritating to me, as my eyes are senstive to the refresh-flicker of CRT monitors, even when they're jacked up to 75-85 Hz. This thing strobes like a disco light, and provides a nice, glossy, glaring, reflective surface to boot. Trying to get proper lighting without reflecting it all into my retinas was not a fun experience.

My hassle with the CRT was made more frustrating because of the typeface. Spending hours squinting at the slightly fuzzy display, with the OVERLY PACKED ALL CAPS FONT, was unpleasant. My Lord but it's a wonder I didn't end up completely blind by the age of 23, staring at these old, dodgy CRT screens.

My last ergonomic gripe is the form-factor of the whole machine. Having the tiny monitor all scrunched up next to the keyboard led to some serious neck and back pain. Being a taller guy, it's similar to the problem I still fight with laptops, trying to compromise between good arm/wrist angles, a good eye-line to avoid neck pain, and trying to keep overhead lights from bouncing off the screen and blinding me.

I went through a bizarre, not-quite-humorous set of contortions while working the machine. I kept hunching down to get a good view of the screen and ease up the throbbing in my wrists. Then after a little while, I'd have to straighten back up to give my neck a break. Immediately the painful ache in my wrist tendons returned.

My late grandmother had a quirky, impolite expression she used on us kids to admonish us about our poor-posture;

"Quit sitting there all humped up like a turd!"

We always thought it was hilarious then. Sorry Grandma. Now I know what a humped-up turd must feel like...

With regards to writing code in ancient, line-numbered BASIC, the hardest part was being limited to 2-Letter variable names. I'd honestly forgotten just how much this sucked in just about every way you can imagine. (It also sucked in some ways that you don't want to imagine.) For those who don't know what I'm talking about, here's a simple example. Put on your thinking caps, and recall a tiny bit of Algebra:

We're going to give the machine a couple variables, and assign a value to them--just like in your Algebra class.
A = 4
B = 9
PRINT "A=";A;" B=";B

Type those commands into the TRS-80, and it helpfully spits out:

A= 4 B= 9

Nothing weird there, right? Looks just like the simple stuff we expected. Now, we try a slight variation:

ELM = 9
ELDER = 32

What does the machine dump out now?

ELM= 32 ELDER= 32

Yep. The machine only 'sees' the 'EL' part of the variable name. So it assigns it the value of '9', then immediately assigns it the value of '32'. Grrr..

What makes this so difficult is remembering what all the 1-letter and 2-letter variable names actually mean. I ended up staring at the screen for long periods, wondering what the hell I was doing wrong, when in fact I had typed 'MO' (em-oh) in one spot, and 'M0' (em-zero) in another. This is the kind of brain-dead mistake which modern compilers and modern computers have (mostly) eliminated.

Another horrendous difficulty I encountered had to do with the entry of the code instructions themselves. The "Line Editing Mode" offered on the TRS-80 can save you re-typing a whole line from scratch, but it's so slow and clunky and underpowered, that I hardly ever used it. Even "back in the day", we just re-typed a line with the bug-fix--it was immensely faster.

You might ask, "Why not use an editor on the TRS-80?"

Answer: There is no room in the machine to stuff it in there along with the program code I'm writing! With only 16 KILO-bytes of RAM, there isn't enough room to spare--even a cheese-ball little editor would chew up 3-4K of that. As this program eats about 8.5K, and consumes another 4-5K when running, there just isn't room.

There is just no good way to edit blocks of code on the thing. Oh HOW I wished so many times during this little experiment, that I had not committed myself to, "the full-on RETRO experience." I almost caved in a couple of times, since my laptop was sitting on the desk adjacent to this hulking old beast... I could almost hear the TRS-80 emulator and my favorite code editor calling out to me. (Not that anybody gives a ding-dang-doodly, but I use a variation of the UNIX 'vi' editor for nearly everything; code, documents, hexadecimal binaries. Yes, I'm even writing this blog post in it.)

The Good Parts:

Despite the physical pain in my wrists and the frustration of struggling to enter changes and bug-fixes in the code, the actual typing-it-out process of writing this game was the biggest thrill for me--hands down. Much of that joy stemmed from the fact that I made the thing up, completely on-the-fly. There was no outline, there was no flow-chart, there wasn't even a basic list of requirements, much less a "Design Document". I just sat down over several evenings, and banged out code. In each session, I tested it, made changes, and rapped out more.

People who aren't coders will likely be utterly confused as to why I enjoyed this process so much. Which is completely fine; you don't have to. I understand it, and that's enough.

I should point out that "...just sitting down and starting to bang out code..." goes completely against my normal methods, and violates nearly every programming and software design dictum I lecture about in my upcoming book. In my defense though, because I've been writing code for 30+ years now, composing a completely improvisational piece of this tiny size isn't difficult for me. There are many instances in which, even today in my work, I'll throw together a quick command-line utility in C, Perl, or some other language, for a one-off task. (If I find myself using the thing more than once though, 99% of the time I'll go back and fix it up, add comments, and re-write portions of it for greater efficiency, greater clarity, and more user configurability. If you hadn't guessed, I'm pretty picky about software, and I can let things slide only so much.)

A second terrific experience came from the rose-tinted rush of adrenaline I got when I first saw the old extended-ASCII characters dance and twitch around the screen. I really did experience the whole "flood of memories" cliche in that moment, which was a bit weird. Seldom do I look back at my now fuzzily-distant high school years; if for no other reason than I didn't enjoy it much. I wasn't widely regarded as "the nerdy kid", by some miraculous combination of events. However, I always felt like the nerdy kid. It was an awkward time, and I couldn't wait to get the hell out of there and "get on with REAL LIFE." But this helped me remember some pretty good times I spent hacking with friends.

Third up on the list, I'd have to say that seeing the game run for the first time, fully complete, was a neat (if geeky) thrill. It's been a long time since I sat down and wrote any kind of computer game code; the last example was a piece of console-based example code for my nearly-complete programming book. Before that? Despite dredging around in my memory banks, I can't recall when. Although this game is seriously slow and goofy, I enjoy it.

Fourth, I was surprised by the profound realization of just how far my programming and design skills have grown. When attempting to squeeze every bit of performance out of the BASIC code, it was stunningly simple for me to restructure things completely in my head; to mentally "try out" alternatives, and then implement them in a ridiculously short span. I can clearly recall sitting and scratching my noggin for hours as a kid, trying to debug things or come up with an alternative solution.

Fifthly, (..try saying that without sounding like you've got a bee-sting on your lip...)

Fifthly, and I'm a little embarassed to admit this, I actually enjoyed playing my cheezeball little game. For a little while at least. After I got the various gameplay parameters tweaked, I think I hit upon a good mix of challenges and rewards--the balance feels right to me. Being able to pull that off, within the constraints of a pure BASIC program, is something that I am moderately proud of. (I just wish I could zip back in time and hand a copy to my younger self--I'd certainly score some popularity points with the old computer crew...)

The last "Good Bit" I'll mention here is actually something of a negative, but turned on it's head. Quite simply, it is the full awareness of how grossly primitive this system truly is. I am extremely grateful I don't have to work on such prehistoric platforms now. My appreciation for the simple luxury of a good code editor is tremendously renewed. There is also the wondrous luxury of not having to fight crap tools, unstable save/storage methods, lack of RAM, lack of memory protection... the list is really endless. I think it would be a terrifically educational experience for all programmers to be forced to take a couple days, and write up some kind of game on one of the old platforms. The process, the struggle of it, would teach more appreciation and respect for "old time coders" and the niceties provided by modern systems, than any amount of lectures or books.

Final Thoughts on the "TRS-80 Experience":

After all is said and done, I have some mixed feelings about RETRO-ZAP! and the time spent writing it. While I loved the trip down "Memory Bus Lane", the fact that I am seriously considering icing down my wrists to stop the throbbing ache, is a real drag. I cannot stress enough how much of an ergonomic nightmare my TRS-80 really is. And while I enjoyed being able to throw down a good bit of 'old time' code just for the pure fun of it, I have to question putting twenty-something hours into a project that will get played by a grand total of about 3 people.

However, getting to find out how far I could squeeze this old machine, and still have it run at decent enough speed to be playable, was a real treat. I am also quite delighted with the new gampelay variation I introduced to the tired old "Space Invaders" theme. The introduction of the "ZAP!" attack not only changes the gameplay and strategy of the game, it also solved the speed issues I had when experimenting with the classic, "...alien turds falling from the sky" game mechanic. This unexpected development was wonderful--it's a fantastic example of how design constraints can drive innovation.

To be sure, what I did here is absolutely NOT the proper way to write software. Even small utilities should be better planned than this, and should have decent levels of commenting. I did not comment this code much, simply because the miniscule RAM limitations prevented it. Further, there is a nasty level of "spaghetti-fication" going on in the source code. Some of this stemmed from my rushing to get the thing working. Some of it is a result of not having a decent editor to work with--to fix things properly would require going back and manually re-typing EVERYTHING. My wrists, back, and patience simply couldn't take it...

As a consequence, the code listing for this program is in many way a pretty decent example of, "What NOT to do." There are painful examples of code duplication, and likely a couple of other missed opportunities for RAM-usage/space optimizations. I know for certain that there is still at least one minor display bug in the code, whereby an alien can temporarily disappear if you 'graze' it with a missile. At one point, there was also a GINORMOUSLY crash-tastic logic hole you could fall through--if you shot the little alien dudes in the correct weird/obscure sqeuence. I think I tracked it down and fixed it, but....

(HINT: The gaping logic bug hit in the part of the code around LINE #309. While chasing it down, I stuck in that code to detect an "impossible" condition. Hence why it force-exits the program with a "** FATAL ERROR! **" message. I wasn't able to reproduce it in a sane period of time since my 'fix', but I left in the forced-exit in there just in case.)
Feel free to chase down any remaining bugs and fix them--I haven't the time or inclination to bother with them.

There are some other interesting morsels and juicy nuggets in this game, including a "cheat/hack" option I used for testing the "wave cleared" code, and a "debug" option I managed to cram into the tiny RAM footprint. But as I cover those in the YouTube videos, I shall omit the details here.

In all, I rate this experience a pleasant one, and place this project squarely in the "Fun and Success" column. That said, I think I'm done monkeying about on the TRS-80 for a loooong while.... I got my fix, and then some.

If anyone is interested in actually messing about with this program, whether to fix it, add to it, or change it as you please, feel free. As indicated in the leading comments of the BASIC source code, I hereby release it to the world under the terms and conditions of the GPL-version 3 license. A copy of this license is available online at:

Thanks everyone for reading, and please chime in below with any questions, comments, critiques or suggestions. (Or snickers, or chortles, or gut-busting guffaws... )

Happy Gaming!

I do not check the comments section on YouTube very often. So if you came here to Armchair Arcade and this blog from the links embedded in the YouTube videos, please comment here after the blog posting, rather than on YouTube.

The RETRO-ZAP! program code in WAV, FLAC, and CAS format:
The Retro-ZAP! game in a ZIP.

YouTube link #1: Retro-Zap! Development, part 1

Retro-Gaming Chronicles 001

YouTube Link #2: Retro-Zap! Gameplay + features + commentary, part 2

Retro-Gaming Chronicles 002

YouTube Link #3: Retro-Zap! Gameplay + features + commentary, part 3

Retro-Gaming Chronicles 003

YouTube Link #4: My personal YouTube channel -- The Scroungineering Chronicles

retrozap.zip4.79 MB


Mark Vergeer
Mark Vergeer's picture
Joined: 01/16/2006

Wow we had the exact same type of computers in school. I remember those well.

Love the way you explained your code design choices. On the commodore putting game logic in functions would actually speed things up as the functions were 'transformed' into machine code by the interpreter resulting in faster execution. Also using as much basic statements on a single program line as possible would make it run faster than a program using the same instructions dispersed over more lines of code.

Was there ever a basic compiler for the TRS80?

Shawn Delahunty
Shawn Delahunty's picture
Joined: 08/01/2011
Ahh, the Commodore

As I wrote in the blog, my first hope had been to code the project on my old VIC-20. (I'm still waiting on the replacement ROM chip.)

Even on the TRS-80, stuffing multiple commands on a single line allowed the interpreter to run a smidgen faster. But the speed difference wasn't as dramatic as on the Commodore machines, and despite some experimentation, the GOSUB stuff on the TRS-80 doesn't seem any faster.

In a way, I suppose for a demo project it was better that I didn't write it on the VIC-20. The program listing would have turned into a "Wall of Text", as I would have crammed so much more per each line, and tracing the logic-flow would have been "GOSUB hell". This way, it's a little more clearly laid out.

The other thing that I remember about the Commodore machines was using the 2-character "shortcut" commands, to save RAM. Instead of typing out "POKE", you'd type "P" then "Shift-O". It would save 2 bytes, and yet the BASIC tokenizer would still recognize the command as POKE, plus it would show up as "POKE" in the program listing. (It was a pain though, since if you had to make a bug-fix, you had to remember to re-type the entire line of code, using all the 2-character command shortcuts... If you just ran the cursor up to the line and made one fix, the dumb thing would "re-enter" the whole line, with the longer-form/bigger-version of the BASIC commands...)

As for a BASIC compiler on the TRS-80, I really don't know. We never had one. And after doing a little bit of Z-80 assembly code, we didn't bother with BASIC very much anyway.


Shawn Delahunty
Shawn Delahunty's picture
Joined: 08/01/2011

Hey Mark,

After I wrote that response, something twanged my subconscious.. I knew it couldn't quite be correct. So I went back and experimented a bit more.

Sure enough, the "GOSUB-makes-it-faster" statement is accurate for the TRS-80. It makes sense, since Micro-Soft sold the same Level2 basic to Tandy, Commodore, and others. It's actually more of a cache/token-convert issue than "convert to machine code", but still--- you can see this in the finished game. The first time the ZAP! sequence runs, or the first time an "explosion animation" is run, there is a weird hesitancy as the BASIC interpreter chugs through the tokens and converts it. Every time after that, things are visibly smoother/faster.

Thanks for pointing that out.


Mark Vergeer
Mark Vergeer's picture
Joined: 01/16/2006

Ah thanks, yes it was some sort of cached action that could make go subs and functions faster on those types of basic. Loved the videos and the article!

Shawn Delahunty
Shawn Delahunty's picture
Joined: 08/01/2011
More RETRO-ZAP! Goodies

Ok folks, I've got some great updates.

The past 24 hours has been interesting and exciting.

This morning, I received an Email from Ira Goldklang, creator of THE pre-eminent website for TRS-80 nostalgia, computing, and emulation. Ira has very kindly posted a link here to Armchair Arcade on the NEWS section of his website. To all who come here from the TRS-80 community--WELCOME.

During the wee dark hours of last night, I had a great back-and-forth Email exchange with George Phillips, creator of a very hardware-accurate TRS-80 emulator. I mentioned George and his brother in an earlier comment, and he posted back. During our exchange, George stated that his brother Peter would be hosting Retro-ZAP! on his web-page, so that you could quickly "click-load" it into the JavaScript-driven TRS-80 emulator there. It will probably go up this coming Monday, so please look for it. I will update this blog comment-thread when it happens with a link to Peter's webpage.

After some testing and experimenting, I have verified something George stated last night--the JavaScript based emulator should "just work" if hosted on any old plain-jane webserver. I will be working with Bill and Matt to try and get an emulation page set up here on Armchair Arcade so you can play Retro-ZAP! (and possibly other old TRS-80 games) right here.


Matt Barton
Matt Barton's picture
Joined: 01/16/2006
Congratulations, Shawn! I bet

Congratulations, Shawn! I bet in a few days every TRS-80 enthusiast on the net will be playing RETRO-ZAP!

Mark Vergeer
Mark Vergeer's picture
Joined: 01/16/2006
I would love to get my hands on...

A TRS80 like I programmed in high school. Or a real coco computer. Excellent 'stuff' Shawn!


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.