Retro-Invaders! - Part 2

warning: Creating default object from empty value in /home/buckman/public_html/neo/modules/advanced_forum/advanced_forum.module on line 492.

Sun, 03/11/2012 - 9:35pm — Shawn Delahunty

"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,

Retro-Zap!

In the beginning, there was RETRO-ZAP!...

Chasing 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!"

ARGH! ZAPPED!

Sorry 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:

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.

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.

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:

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.)

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
PRINT "ELM=";ELM;" ELDER=";ELDER

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: www.gnu.org/licenses/#GPL

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!
-Shawn

PS:
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.

Thank you Matt, I'm most grateful for the compliment. I have to say though, this is rather piddly compared to your Match 3 Invaders release.

Unfortunately, the sole browser-based TRS-80 emulator which I found only runs the Level I version of TRS-80/Microsoft BASIC. Retro-ZAP! requires the Level II Basic, and any emulation must also provide hardware-level access/fakery, so that the POKE/PEEK statements can access the 1K of video RAM.

If anyone is aware of a browser-based TRS-80 Model III or IV emulator, PLEASE post here in the comments! I'll update the blog and the YouTube video with the extra links, and see about getting the game hosted there.

Cheers,
-Shawn

P.S. Any hope of getting the ZIP file hosted here on Armchair? Or should I look at MediaFire or something?

The submission form still complained about the ZIP extension on the filename, but I spoofed things by renaming the file to 'retrozap.zip.txt' and it uploaded fine. The blog posting also has all the links updated properly, I think.

I've sent an Email about Armchair Arcade and the blog posting to Ira Goldklang's TRS-80 website, so I'm hoping that will bring some eyeballs here. Further, I put annotations and links on the YouTube videos pointing folks here to Armchair Arcade. Are there any guidelines you want me to follow for promoting Armchair Arcade? I'm just kind of winging it...

The submission form still complained about the ZIP extension on the filename, but I spoofed things by renaming the file to 'retrozap.zip.txt' and it uploaded fine. The blog posting also has all the links updated properly, I think.

I've sent an Email about Armchair Arcade and the blog posting to Ira Goldklang's TRS-80 website, so I'm hoping that will bring some eyeballs here. Further, I put annotations and links on the YouTube videos pointing folks here to Armchair Arcade. Are there any guidelines you want me to follow for promoting Armchair Arcade? I'm just kind of winging it...

Cheers,
-Shawn

No, no specific guidelines, so promote any way you wish.

.ZIP is one of the "safe" file types, so you shouldn't have had an issue. Let me give it a try and see if it works from my end...

If you find it not working for you in the future, we'll bump your permissions again.

I started digging around further this evening, and in short order located a couple of Model III emulators written in JavaScript. They all appear derived from work by Peter Phillips and his twin brother. Here are some of the sites which offer it, along with some "click 2 load" images of the classic games on the system.

The code for the emulator itself is even released under the GPL, which is wonderful. HOWEVER there are 2 major problems:

(1) I'm extremely uneasy as to the legality of the ROM images which are included in the JavaScript code. Everything I can find indicates that those are still held by Tandy/Microsoft. They haven't done anything about the hobbyist community floating these old ROMs around... yet. But...

(2) Aside from typing in the whole program from scratch, there is no good way to get Retro-ZAP! into the emulator. I downloaded the JavaScript file & crafted a basic HTML webpage... and sure enough, I can get the thing to run on Chrome from my local drive. But the fundamental problem is that the bloody thing requires AJAX to load program images into the emulation--which means setting up and running the whole server-side mess to support it. I am not about to fool with that kind of a headache, since I already have the actual machine and native-code emulators.

Thus, I'm at a crossroads and would like some input or suggestions here...

(1) Would this be something that Armchair Arcade would like to host on the games page? (I'm guessing that to be "HELL NO." given the legal grey area concerning the included ROMs.)
(2) DoDOES anyone think it's genuinely worth attempting to contact one of these sites and get them to add Retro-ZAP! to their site?
(3) Something I'm not thinking of?

This is a tough call. I have no issues with hosting anything, save for the issue with the legality of the ROMs. At the same time, though, I think in this particular case since these can be considered abandoned IPs, I'm leaning towards being fine with doing it. That just leaves the issue of how we get your game (and potentially other authorized games) in there... I don't know the answer to that one.

If you don't decide to host the game elsewhere I'm sure Peter would put it on his site. He's away for a few days or I'd ask him immediately.

There's no requirement for any server-side setup, just that the file has to live on the same server as the JavaScript due to the usual security restrictions. AJAX just happens to be how to get JavaScript to read a file from the server.

Seeing as how you have a real TRS-80 Model III, I'm wondering if you could try something for me. My Model III appears to have an obscure problem but I don't know if the problem is common or unique to it. You could help test that by going to http://members.shaw.ca/gp2000/bug32.html and download and run the test program there. Refer to http://members.shaw.ca/gp2000/trsrun.html for a pointer to "Play Cas" which makes downloading easy.

First off, a HUGE "Thank You" for your fantastic work on the TRS-80 emulation!

I actually just finished reading your "Beam Hack" entries last night, including the double-wide instruction/bus bug. Nifty stuff. I'll run the bug-test for you in the next day or so---I don't use Windows much, so I'll have to reboot one of my machines and get PlayCAS working. Do you have an Email you'd like me to use, or should I just post the results here?

I should probably clarify something about my setup concerning my statement about AJAX--I'm not running a server at all. I merely stuck the JS file and the PNG files into a directory, ripped a copy of Peter's web-page HTML, and pointed Chrome at it with the 'file:///' URL. As I indicated above, the emulator itself runs fine that way. But without setting up some kind of a server process to answer the fetch-request from the onClick on the HTML page, it's clearly not going to work--the emulator barfs up: "Error loading URL file...blah-blah. NETWORK_ERR: XMLHttpRequest Exception 101"

You're saying it doesn't have to be AJAX then? Anything that answers the onClick HTTP request would work? (My coding background is on the bare metal, not webservers, so I'm a wee bit fuzzy here.)

I'd love to have Peter host the program if he's willing. Please have him Email me or post here if he has any questions. The CAS file is inside the ZIP posted above.