In my last article, I wrote at length about my experience making Retro-ZAP! on my near-ancient TRS-80 Model III computer. As I described, the experience was a fun and interesting one. It provided a mix of both high- and low-points, all of which were fun to write about. What I did not expect however, was the level of attention that would be generated by a Space Invaders knockoff, written in interpreted BASIC.
First, I was extremely pleased to have Retro-ZAP! featured here on Armchair Arcade. I greatly enjoy writing for this terrific publication, and it's always great to see the worthwhile commenting and debating. My article also got a front-page news entry on Ira Goldklang's TRS-80 Website. Ira runs what is essentially the preeminent website dedicated to TRS-80 machines, emulation, programs, and preservations efforts. I'd dropped him a short Email, summarizing my article, and providing a link here to Armchair Arcade. I receieved a brief personal note from Ira in response, indicating he really liked the project, and he was most kind in posting a NEWS item pointing his viewers here.
To see more of their work, please refer to the following links to their personal websites:
(You'll note that on Peter's site, you can click-load several games auto-magically into the browser emulation. He has kindly agreed to add Retro-ZAP! to that offering! I'm quite pleased about that...)
It's not all been wine and roses and dancing girls though. There is a harsh, cold, unforgiving reality that comes with writing software and then being either brave enough, or foolish enough, to "throw it all out there" for people to actually use. Namely, software generally has to be maintained and supported.
I know what some of you might be thinking: "Software Support? Yeah, ok, I can see that--people might have questions. But Software MAINTENANCE??..."
This may sound weird to people who aren't familiar with coding and software development. After all, software is digital, right? Ones and Zeroes; everything is definitive, clear-cut, black-and-white. There aren't any moving parts; nothing to wear out, nothing to fail over time, nothing to fade and wither and crumble to dust. Is there?
Well, technically, that layman's understand is completely correct. The phrase "code rot", which gets thrown around far too easily in certain programming circles, is an absolute LIE. Code does NOT rot. It can't. It can get corrupted or broken, by a physical failure in the machine. Yet code by itself is exactly like Mathematics--an ideal thing, an eternal abstract, unchanging, immune to the ravages of time.
But like so many things, there's a catch.
Specifically, it's that code is written by humans. Irrational, emotional, hasty, imperfect and otherwise hopelessly flawed humans. (I speak from great experience in this regard, having written code for fully 75% of my life, and having been an emotions-driven goober for ALL of it.)
As we are imperfect beings, we occasionally (frequently? always?) make these nasty, messy things called MISTAKES. And because we as programmers commit them into the code, these MISTAKES, NEVER GO AWAY. They sit there, alongside our gorgeous creative ideas, detracting from the view. They are held up there for all to see--eternal, unchanging, immune to ever being forgotten no matter how much we wish we could.
To put it a little less poetically, programs have BUGS. Some programs, like Retro-ZAP!, written too quickly and not tested properly, have really problematic BUGS. There are BUGS which can make the program crash. Worse, there are BUGS that won't crash the game, but which make it behave strangely--those are a pain to track down. Worst of all, lurking there at the bottom of the messy, smelly pile, are the BUGS which make the game UN-FUN.
And that's where the headaches begin for a programmer. Because now, you have to start fixing those BUGS. Congratulations! You've now entered the software development phase known as "Maintenance and Support".
In a similar vein, I never intended to do much/any bug-fixing for Retro-ZAP! I stated as much in the YouTube videos. As I put the code out there under the Gnu Public License v3, it's available to anybody who wants it, to do anything they like with it. That includes fixing the bugs.
However, I, in my self-absorbed and foolish optimism, forgot one teensy detail--most people aren't programmers. Even if they are programmers though, they generally just want to play the game.
It came as a slight surprise to me, but I actually started getting a couple of Emails from folks who played the game far more than I ever did. Naturally, they found problems. (I never made a secret of the fact that I did nearly zero playtesting of the game. For me, the buzz and thrill comes from writing the game.)
Given that I don't like people to think ill of me, or to be disappointed because of something silly or stupid I've done, I took a few minutes and dug into the code--and have "fixed" the BUGS. Most of them anyway. I'm leaving the "grazing shot creates inviso-Alien" behavior. That's a FEATURE dangit!
So there we have it. I doubt that anyone noticed, but I have been surreptitiously updating the ZIPfile containing the program code for Retro-ZAP! It's actually been updated about 4 times now. As of the last update, done in the wee dark hours of last night, I think/believe/hope/pray that the major BUGS are now gone. However, rather than keep the process quiet any longer, I felt it would be educational to let people know what really goes into maintaining a piece of software--even one so simple and generally silly as Retro-ZAP!.
Here is a link to the latest ZIPfile for the game, so you don't have to dig in my last blog post:
So what did I fix? Well, there were a handful of BUGS which adversely affected gameplay.
I made a few other code changes, mostly to "clean things up". The game should now be playable, as originally intended. (As I mentioned though, the "grazing shot/briefly invisible alien" glitch is still there as a GAME FEATURE.)
There was a little bit of criticism on YouTube that the ZAP! attacks happen too often at the beginning of the game. However, I've left things as they are--I like the game balance, and people need to understand that games for these old systems tended to be mercilessly hard. It came as a consequence of people being used to the rough, quarter-sucking gameplay of the full-sized arcade machines.
As shown at the top of the article, the new title-screen for Retro-ZAP! now reflects the version number of the current program. I really don't anticipate updating it further, though if anyone does create an update, or adds features, or fixes some obscure bug, please send me a CAS file with the updates. I'm very curious to see what other folks come up with.
As for the other tantalizing bits of that screenshot? Well, we here at Armchair Arcade are planning on hosting Retro-ZAP! and other pieces of TRS-80 retro-gaming history here on the website, for all to enjoy. Look for an annoucement soon, with a link on our Games Page to the new TRS-80 games & emulation page!
Well, that's all for this time. Thank you everyone for reading, and please stick around and take part in the gaming and game-related discussions here on Armchair Arcade!
P.S. If you have written a piece of game software for the TRS-80, or if my efforts have inspired you to try, please send it to me at:
If we like your game, we'll see about hosting it here for everyone to play!
Shawn, thanks for posting this experience on programming the TRS-80. I read this excitedly when you first posted this series of blogs, but didn't have the energy to post a response back then. Your posting of the online emulated version here on AA reminded me to respond, 10 years (it seems) later.
My very first personal computer experiences were with the TRS-80 Model 1 Level II at school. It had a separate keyboard and monitor, and it had a standard cassette player/recorder for loading programs. I did a fair amount of Basic programming on it, and I did some rudimentary adventure games and graphics stuff on it. I was intimately familiar with the "CHR$" command, and did a number of animations using the graphics symbols/characters in the character set.
I just saw the "Retro-Zap" game (emulated) posted on AA tonight. I did originally play it on that other site (along with the few other games they had listed!).
Something I noticed tonight that I didn't when I first played "Retro-Zap" was the fact that you had strange characters for both the aliens and the player's ship/cannon/base. I do not recall such characters in the TRS-80 (model 1) character set. Did they change the character set in the Model III? It appears from your game that the "block" characters remained the same, but the simpler "Space Invaders" knockoffs I saw often used the letter "A" used as the invaders.
Then again, if I recall correctly, the Model I didn't even have lower case letters. I may be mistaken, though, that's how fuzzy my memory is. I still have the original TRS-80 programmer's manual somewhere.
Anyhow, my mind is too fuzzy to keep rambling. I appreciated the series and have enjoyed the game!
You are correct, the Model I did not have the "extended characters". And the original version of the Model I ROM did not have lower-case characters either. Your memory is quite sound on that point. There were some hacks done at the time which added full upper- and lower-case characters, and I have some information that indicates some late production Model I machines had both character sets out of the factory.
As for the "blob"/"block" characters vs. the bitmapped ones? Well that's why I cautioned folks about running the game on a real Model I or on a Model I emulator. It can only handle characters 0-191. On the Model III/IV machines, there was an extended graphics ROM which "filled in" characters 192-255. There were actually 2 sets of these 'higher # characters'--one provides these higher resolution graphics characters, the other provided some basic Kanji characters.
I'm glad you enjoyed my series of articles! As for the emulation page--SSSHHHH!.... That's still in a state of flux, but I'll be making a formal front-page announcement in the next few days. :-)