ZX81 Computer – Reid's For Fun

Not My Best Try at Programming an Ultima Clone

Steven Reid — Wed, 31 Mar 2021 00:39:00 -0600

I've talked about ZX-Ultima before. It was first attempt at building an Ultima like game on the ZX81 using BASIC. Written in 2012, it was a pretty ambitious project for me. I really enjoyed playing Ultima III on my C64 as a teenager. I always wondered what it would look like on my ZX81. It was bad. Yet, at the same time you could see the seeds of what would come later.

What was I thinking.
Writing a ZX81 Ultima game was always going to be a challenge. I mean, the ZX81 uses it's z80 processor to display the screen. Right off the bat, that cost me 80% of the CPU. Add in that I'm using interpreted BASIC, and you realize I didn't have a lot to work with. Yet, I had an idea!

The ZX81 is pretty fast at printing large amounts of text. As I've shown before, a large PRINT AT statement allows you to quickly print a lot of text to the screen. Having played a bit with some double buffering arrays, I wondered if I could build the screen in an array and print it. In fact, I would create two arrays. This would allow me two frames of animation. Not much, but good enough!

Trying the game out.
With the idea in mind, I started to build out a graphic engine around that concept. I would use two screen arrays, J$ and K$, and splice in the tiles. The math wasn't too complex and, after a few tries, I had the basic idea working.

The tile code looked like the following-I just removed the ZX81 graphics.

1490 REM ****WATER
1500 LET J$(SLOC TO SLOC+3)="XXX
X"
1510 LET J$(SLOC+32 TO SLOC+35)=
"XXXX"
1520 LET J$(SLOC+64 TO SLOC+67)=
"XXXX"
1530 LET J$(SLOC+96 TO SLOC+99)=
"XXXX"
1540 LET K$(SLOC TO SLOC+3)="XXX
X"
1550 LET K$(SLOC+32 TO SLOC+35)=
"XXXX"
1560 LET K$(SLOC+64 TO SLOC+67)=
"XXXX"
1570 LET K$(SLOC+96 TO SLOC+99)=
"XXXX"
1580 RETURN

Using the screen real estate I had, I ended up with a 5x5 grid of tiles. I had water, castles with flags, and your fighter avatar. You might notice that they aren't too different from what I now have in Gem Quest. Reading from a world array, I would load in each tile and follow call the routine above for each location.

To my surprise, the graphics looked good. There wasn't any noticeable little lag in the display. The animations, although simple, worked well. Although, for the water, I was limited to two frames versus the eight I use today. Still, the game had an overall Ultima vibe to it.

ZX-Ultima, by Steven Reid, 2012

Quickly hitting a wall.
To my dismay, the similarities ended there. Although the black and white graphics could be pawned off as artistic, the game play couldn't. I could move around the world map, but it was painful. Even using FAST mode, it takes 6 to 10 seconds to build the new display. Once done, the display is fine. But just moving a few tiles is an exercise in extreme patience.

Even if this game had worked, I don't think I'd have gone far with it. Since the array was the screen, I would have had to put all the text into the two arrays. That would have been slow and tedious. I also didn't know how I would deal with locations yet. Maybe with time I could have improved the speed. It wasn't to be. Like Tiles and the first version of Gem Quest, ZX-Ultima became a programming exercise.

As noted in an earlier article, I gave up on this version of the game. I found better and faster ways to get the display to work using MCODER. Of course, those attempts had their own limitations. Now in 2021, ZX-Ultima is now Gem Quest. Learning z80 assembler, I've programmed the game in machine code. Though it is still fun to look back on my original idea. The spark that lit a fire, so to speak.

Back to the present.
Speaking of fires. Two months in, I just finished adding in the last location today. The game is shaping up quite nicely, with a lot more graphics and game mechanics. I have about 645 bytes free at the moment. That doesn't sound like much, until you realize I've packed in over a dozen locations, multiple NPCs, more graphic tiles, game text, and play mechanics. For contrast, compare the latest screen shot with the image above:

Screen Shot 2021-03-29 at 10.49.37 PM by Steven Reid, on Flickr

I'm not done with Gem Quest. I have a long laundry list of to do items. Some of those ideas I may reject or rework still. But I'm having a blast! I'm not sure if it is the longest I've spent on a ZX81 game, but it is pretty close. I do know that it is the most diverse and interesting game I've written. If only I'd done this back in the 80's.

A Developer Diary in Pictures for Gem Quest, a ZX81 RPG

Steven Reid — Sun, 07 Mar 2021 11:21:00 -0600

If you've been following me the last couple of months, you know I've been revisiting Gem Quest. Intended to be an Ultima style game for the ZX81, outside of a few demo's I really hadn't gotten far. That isn't the case now. I've spent the last month learning z80 assembly code and hacking my way through the game. Tracking my progress, I've been capturing that journey in pictures and movies, which I've uploaded into a Flickr album.

Getting everything organized and working.

A good part of my early journey was learning z80 assembler and finding a way to compile it. I ended up landing on a pretty rapid development workflow. I started by downloading Visual Studio Code, and a few add-ins, as my editor. I figured out that I could use JSZeddy to quickly compile code and see the results. Although not great for debugging, I use z80asm and ZXSP for that, it is nice having the debugger and emulator together. By the middle of February, I was ready to start coding again.

Gem Quest Development, Screen Shot 2021-02-12 at 10.39.58 PM, Steven Reid, 2021

To get started, I managed to get my first attempt at creating the Gem Quest screen working. JSZeddy is picky, preferring everything to be lowercase. Once I figured that out, I found I could just copy the code from my editor into JSZeddy, then assemble and run it. With my development environment figured out, I was ready to start building the game.

Beginning to make progress.

Another advantage of using JSZeddy is that I could keep all my documentation open next to it. I have the online version of "Mastering Machine Code on Your ZX81," by Toni Baker. I use the annotated version by Thunor. I also keep a copy of the "Sinclair ZX81 BASIC Programming," by Steven Vickers, up for character code and some memory references.

Gem Quest Development, Screen Shot 2021-02-13 at 9.11.26 AM, Steven Reid, 2021

Given I was learning z80 assembler at the same time I'm trying to develop a game, I started slow. My first goal was to poke a tile into the display. Once I got that working, I then poked a screenful of the same tiles. I then got them to animate, using some variables.

Gem Quest Development, Screen Shot 2021-02-13 at 9.42.54 AM, Steven Reid, 2021

My first thought, when I started, was add in the functionality from my previous attempts. I was thinking baby steps, trying to get my mind to think in assembler. I envisioned another tech demo, not sure how far I'd get in the project. After a few days, I had the world map working, having a lot of fun figuring things out.

Gem Quest Development, Screen Shot 2021-02-13 at 10.16.55 PM, Steven Reid, 2021

Development was progressing smoothly.

My next focus was on movement. I had to figure out how to read the keyboard and then act on it. That took a bit of trial and error on my part. Once I figured it out, though, I was rapidly iterating. At this point, I got the message window working, including scrolling. I added in some stats, even if just fake. Movement was working, along with some place holders for other commands.

Gem Quest Development, Screen Shot 2021-02-14 at 10.16.27 PM, Steven Reid, 2021

At this point, Gem Quest started to look like a game. And, at this point, I started to move away from just creating a tech demo to making something you could play. I dug out my old game notes and started adding new ideas to them. My mind started to fill with game ideas beyond what I had originally planned. And, looking at my memory consumption, I was pretty sure I had room for them.

I had been using Excel to build out the graphics. I know you're probably asking why. To be honest, it was convenient and I could use the cells as a graph paper. I could also copy sheets into tabs, keeping all my ideas in one file. I should look for a better program, but it has been working for me. I started to clean up old tiles and build new graphics.

Gem Quest Development, Screen Shot 2021-02-18 at 11.39.51 PM, Steven Reid, 2021

Going for something new: monsters, people and more.

At this point, development was going much faster. I was finishing up adding in the features from my first Gem Quest. I figured out how to add in statistics, with health and food now changing as you moved. It was at this point that I began moving beyond what I'd coding in my original games. I now had monsters!

Gem Quest Development, Screen Shot 2021-02-21 at 1.35.14 AM, Steven Reid, 2021

They weren't super exciting yet, but it was fun seeing different items now in the world. I started to add more graphics, such as the royal castle and chests. Ah, chests! You could now open them. But beware, they could be trapped and cause you pain. I also started to add in game elements such as the shrine and gems. Those will become a key part of the game play in the future.

Gem Quest Development, Screen Shot 2021-02-22 at 12.06.04 AM, Steven Reid, 2021

From the end of February until this weekend, but development was full of fits and spurts. I didn't have a huge amount of time to work on the game, but it filled my thoughts. I spent a lot of time thinking about how the game will progress. I'll really should capture some of that in my developer diary.

But the bigger challenge was thinking through more difficult challenges. Getting the NPCs added to the world was iterative. I created and refactored ways to add them into the game. I worked on combat, which to my surprise was pretty easy. The cool factor for me was when I got a chest to drop. I was so excited! Gem Quest was starting to play like a real game.

Gem Quest Development, Screen Shot 2021-02-22 at 12.06.26 AM, Steven Reid, 2021

The biggest challenge was trying to get the NPCs to move. I found that random movement was easy, but getting them to follow was a pain. I couldn't quite get the math right. And then, it hit me! I figured out how to clear the current row using an AND. The algorithm just fell into place, and was much shorter than I had envisioned.

Gem Quest Development, Screen Shot 2021-03-05 at 10.59.28 PM, Steven Reid, 2021

Dynamic graphics engine and the future.

Emboldened by my accomplishments, I started to add in more advanced functions. I wanted a more dynamic world, one that would give it an Ultima feeling. I really wanted to add darkness to the game. Reworking my the original graphic engine, I took a different approach to building the screen. Not only was I able to add in line of sight code, but I tightened it up quite a bit.

Gem Quest Development, Screen Shot 2021-03-07 at 1.49.14 AM, Steven Reid, 2021

That brings us to the present where I have most of the game mechanics in place. I have a functional and fast graphics engine. My next task is to start building in the game locations such as castles and dungeons. In my notes, I have most of the story laid out. But I need to finish the final couple of game elements before I can piece it together.

Gem Quest Development, Screen Shot 2021-03-07 at 7.38.44 AM, Steven Reid, 2021

I expect it will take me most this month to get that done. If all goes well, I might have the fist draft of the game by this Spring. For now, I'll leave you with some game play video. Let me know what you think!

How to Build a ZX81 Ultima Game Part 2: Gem Quest

Steven Reid — Thu, 25 Feb 2021 23:32:00 -0600

After sharing Tiles, I started to dig into my previous attempts at building an adventure game. Digging through my past research, I thought about encoding the world differently. Sadly, my experiments using MCODER failed. This spurred me to try assembler again and, to my surprise, build a good start to my game. But first, a trip down memory lane and review my first attempt at building Gem Quest.

Early fits and starts.

After finishing Tiles in 2013, I started research on what the game would be about. Liking the idea of stones or gems, I researched different gemology sites and legends. I found the legends about the Bali and Vala most intriguing. In those legends, the demon's body becomes the gems populating our world. Combing different ideas, it became the starting idea for my game called Gem Quest.

But, I was stuck on the game itself. Although the game engine was working well, I was already running low on memory. It spurred me to learn z80 assembly. The idea was that I could write the game as machine code. Doing so would give me both speed and memory. I had the title screen working in no time, but I didn't get much further.

Soon afterwards, I decided to replace my aging Toshiba laptop with a MacBook Pro. The problem is that the development environment I was using, FASMW-ZX, was for Windows. Given the Mac was Intel based, I was able to get EightyOne, the emulator I was using, working in WINE. Yet, I never got around to wrapping FASMW-ZX. As such, my foray into assembler was short lived.

Time moves on.

Three years after my first attempt to build an Ultima style game for the ZX81, I tried to get Gem Quest working again. By 2016, I had a lot of time to dream up new ideas. One thought was about reducing memory by storing the tiles in REM statements. This would make them static memory, which wasn't compiled. This negating the need for an array and allowed me to leave the BASIC alone. The technique worked well enough, saving me much needed memory.

Contrary to my plans, things after that didn't go well. I started coding more complex routines. I was able to get some stats working, including a food and health routine. As the food diminished, your health would drop as well. The mechanic worked well enough and the world screen looked better. I even made it possible to buy food and health at the castles.

Gem Quest, ZX81 screenshot, Steven Reid, 2016

Even with the memory saving ideas I knew I was going to be hitting the ZX81's limit. Using MCODER meant I had three programs in memory. The BASIC code for the game, the machine code, and the complier. Although Gem Quest works well as a tech demo, there isn't much memory left for a real game. Knowing that, I decided I needed to refactor things a bit.

Although I hoped to find some wasted memory, it didn't seem to help. In fact, the game stopped working altogether. I tried several different rewrites, even using side by side listings. Nothing worked. I even tried adding more memory, using a 48K system. I'm pretty sure that I was executing code outside of the allowed limits. MCODER didn't offer me much in debugging though.

At this point, Gem Quest fell to the wayside again. But it always was there too. I had loaded Tiles on my site as a tech demo. Yet, being incomplete, I hadn't done anything with it. I kept thinking about new ways to reduce memory further, but didn't act on that. Until last month. Working to share what I'd down with the original demo, I thought it time to actually get to work on it again.

Bringing us to the present.

After writing my article on Tiles, I started to think about different ways to encode the world. I knew that I could do stacked compiles with MCODER. I wondered if I could build my game in layers, removing the BASIC code after I compiled it. The hope was this would save enough memory to build a small game. Before getting to that, though, I had another idea to try out.

I was thinking about Ultima and how the world map might have worked. Thinking about ways to reuse space, I wondered if I could place objets using the extra bytes in tiles. The goal was to compress the world array and save more space. Instead of working on the game though, I decided to test that theory by writing a test program. That was where I went wrong, or in the end, right.

My attempt at building a BASIC version of the routine was successful. Using simple math, I was able to save two tiles in one location. It might not be enough for the real game, but it was a start. I then loaded up MCODER to assemble it into machine code. Like before, trouble brewed. The program didn't work. It complied fine and parts of it did work, but the numbers weren't matching the BASIC results

Stumped, and frustrated, I decided to give up on MCODER. Instead, I went back to my first idea from 2013, write Gem Quest in Assembler. In a way, my failure set me up for success. I spent the rest of the month working on getting the game engine working. To my surprise, I got much further. In fact, I have almost everything working from Gem Quest, and much more. That, however, is a story for for the next chapter.

How to Build a ZX81 Ultima Game

Steven Reid — Sun, 31 Jan 2021 11:50:00 -0600

In 2012 I wanted to see if I could make an Ultima style game on the ZX81. I had an ambitious plan centered on the tile based graphics. After a few months of testing, I was able to create a working prototype called Tiles. Although the game isn't done, the idea behind it shows promise. You can move around the map using the standard ASDW movements. Other commands are placeholders for what could be. This article explores how Tiles came to be.

Starting from the top, what is Ultima?

When my parents bought me a used C64, one of the first games I played was Ultima III. The previous owner had left wonderful cloth map in the box, which reminded me of my D&D days. Diving in, it was so fun to move my little character around a gigantic map. Before long, I was hacking and slashing my way through the world.

The game itself uses a tile based graphics system. On the disk, Ultima builds a map using codes for each tile. The codes correspond to the tile graphic to display. Given the map is larger than the screen, the game engine only displays what the player can see. The game overwrites any default tiles with the monster, player, and battle graphics.

Being a curious kid, I had a disk hex editor that I used on my Ultima save disk. It didn't take much for me to find the maps and, using that editor, make a few tweaks. I still remember swapping out the Lord British initials is the main castle for my own. Those were fun times.

Can I make a tile game on a ZX81?

This was the question I asked myself when I started this project. Although I'd created games that used maps and tile like graphics, I'd never combined the idea before. Even more ambitious, I'd never covered the screen in those graphics. My first challenge was to figure out how to do that.

Before I could code anything, I needed graphics. I designed some simple 4x4 character based tiles using the ZX81 character set. This gave me an effective 8x8 pixel resolution without color. Although, I did use some other characters for variety. Like Ultima, I wanted some of the tiles to have a sense of movement. I added things like flags waving, water shifting, and your sword rainsing up and down.

Tiles, ZX81 Screenshot Showing Different Tiles, Steven Reid, 2013

To determine how the graphics would work, I built a quick test program. Although slow, it ran well enough to see that I was heading in the right direction. I wanted to build my own Ultima style game.

Building the initial game.

As expected, I titled my first attempt ZX-Ultima, which I wrote in BASIC. My first thought was to use PRINT AT to display each tile. But that wasn't going to be possible. My other programs only print a couple of characters on the screen, which is pretty fast. Canvasing the screen in a 5x5 pattern of tiles was a bit more involved.

Given I wanted to have dynamic graphics, along with movement, I knew I needed to do something else. Plus, I realized I would need a lot of math. Given that math can be very slow in BASIC, it only added to the challenge. Adding to that, I also had to keep memory usage as low as possible. I started to wonder if the ZX81 could handle this.

Laying out the framework for the engine, I decided to use an array that I would splice the graphics into. This took a bit of work to figure out the math, but ultimately worked-no pun intended. I would slice in each tile into the array and then print it to the screen as normal. As long as you stayed still, the routine was fast enough, although you could see some lag as it printed.

In reality, I used two arrays. Each held a frame of animation to display to the screen. The tile graphics, in this version, could only have two animations. This works quite well, but had the downside of taking forever to create the arrays. Even using FAST mode, each time you move it will take almost 10 seconds to build the screen.

The other problem was the array held the entire screen display. Printing portions of the array would have been much slower, as I would only be able to print a line at a time. This meant that I would have to put any text in the array as well. Thinking back, I could have gone Ultima II style and put the text at the bottom. But that wasn't quite the look I was going for.

Building a new graphics engine.

I knew at the start that BASIC was going to be too slow, but I was hopeful. Having proved myself right, I decided to take a different approach. Given I'd been converting my games to MCODER at the time, I decided I'd use it to speed up the game. Yet, converting wasn't going to be trivial. As I've written about before, MCODER requires changing your approach to how you code things.

Tiles, Screenshot of Moving Around the Map, Steven Reid, 2013

Looking at my first few attempts, I tried to convert what I'd already built. Yes, those large arrays weren't going to work. Besides sucking up precious memory, MCODER doesn't like arrays splicing. Running those old programs again, the display results are quite entertaining. I went through a few iterations of this before deciding to start over.

Taking a step back, I thought about the different ways I could print the graphics to the screen. The challenge was finding a routine that was small and fast. I knew that PRINT wasn't going to be any faster in machine code. PRINT doesn't only print characters, but manages the display map. Given this program wouldn't load into a 1K ZX81, those checks weren't much use. I wondered if I could do something different.

Time to poke memory.

As I thought through the design challenge, I wondered if I could POKE the graphics into the display. Other games I'd played had done this with success. But I wasn't sure if the ZX81 would be fast enough. To be sure, I decided to try out a couple of different techniques to see what would work best.

Using a program called POKETEST, I tried out four different methods. The fastest, and the one I landed on for my Tiles prototype, was a two step process. The first step, was to take each of the tile graphics and convert them from characters into integers. The program then loaded those integers into a multidimensional array.

The second step was to write a FOR loop. That loop would go through each tile position and print the required graphic. To do so, it would first read from the internal map, another array, what tile to display. It would then call a routine with the current position of that tile. Using some simple math, it would calculate where to print the tile. Then using another loop, it would POKE each graphic from the array onto the screen.

It sounds complicated, but the routine itself was only a few lines of code. This also eliminated both of the array's I used earlier, freeing up a lot of memory. And it was fast. I mean, really fast. Running the same routine in BASIC was a joke due to the floating point math. But in machine code, it was all integer math.

At this point, I hacked the test code into my original program and compiled it. I could now move around the screen in real time with almost no display lag. Yes, it was that fast! I would later refine this technique even further, but I'll save that for a future article.

Putting it all together.

Armed with that knowledge, I hacked together the first version of Tiles. Moving around the map was smooth and had a very Ultima vibe to it. In the BASIC version, I used a static game map, another array, that held what tiles were where. For the prototype, I wanted something a bit more random.

Tiles, Creating World ZX81 screenshot, Steven Reid, 2013

By generating each map, it solved two problems. The first was adding variety to the demo. The second was to keep memory usage down. I could generate the array at start, thus allowing the game to stay below 16K when I removed the BASIC. This is the version that you can play. My emulator should jump to 32K when you attempt to use higher memory, but I found in practice it didn't always work. On a real ZX81 you have to tell it use that extra RAM. In either case, you can view the BASIC code for the 32K version of Tiles to see how it came together.

To further give it that Ultima vibe, I added in commands and would display them to the right of the screen. This routine was fun to write as I had to create a scrolling function. Before I print each line, I call a little routine that PEEK's the character and POKE's it to the line above. I then do a simple PRINT for the new text.

Stagnation and the future.

By the time I completed Tiles in 2013, I was pretty burnt out on it. The prototype itself was hacked together and looking rough. I had a game idea in mind, but I wasn't sure if I'd have enough memory to build it. The program languished.

In 2016, I picked up the idea again and started to put together Gem Quest. It was my first attempt at cleaning up the prototype and making it into a real game. I thought about sharing those experiences here, but I've decided to wait. Digging through those programs, I realized I had done a lot more work that would be fun to share in the future.

I'm still bullish on completing a real game using this engine. I proved the ZX81 has the power to run a tile based game. But there is a lot more to do still. Even so, the demo is a fun program to see what could have been. Figuring this might kick start me finishing it, I decided to clean things up enough to share. Enjoy the prototype. I haven't given up yet.

How I Used My ZX81 to Draw the Iconic OP Logo

Steven Reid — Sun, 27 Dec 2020 14:14:00 -0600

As 2020 wound down, I had a couple of different ideas for new ZX81 programs. Most of them were graphic programs of various sorts. Themes ranged from dumpster fire pictures, an advent calendar, a virus action game, to a solo RPG. Although they were all great ideas, I didn't think I'd get any complete enough to publish. In the end, I decided to enter in one of my old graphic programs of the Ocean Pacific logo.

Is the ZX81 that slow?

Running the program, I it will bore you quickly watching it draw the O and top of the P. Although the ZX81 had great math routines, it does everything with floating point. This tended to make them slow. The various SIN, COS, TAN and their arc versions being the worst offenders. As such, drawing circles is like watching paint dry.

Fortunately, drawing lines is way faster. The rest of the program almost screams once the circles are draw. I had to fill in a few spots using normal PLOT commands. The text is a PRINT statement, I didn't bother trying to draw the words. I could have done some better kerning on the P and C of pacific. Outside of that, the logo looks pretty good for an almost 40 year old computer with B/W boxy graphics.

OP, ZX81 Screenshot by Steven Reid, 2020

The original program would print to an attached printer using the COPY command. I still have my printouts floating around somewhere, having laminated a couple. Funny thing is, I don't remember owning any OP clothes. Since I didn't expect most folks would want to print the logo, I replaced that routine. I added a delay, using some more math, and a screen wipe effect. You can bypass the delay by pressing any key.

No arguments here.

Code wise, you'll find OP works pretty much like my other drawing programs (Bolt or TS). There are two drawing routines. Starting at 1000, the function that prints a line can be found. Starting at 2000 is a simple circle routine. There is no complex math here. The program is a bunch of LET statements defining arguments, and a GOSUB to the proper function. Oh how simple things were back then. If only the ZX81 supported real functions.

Like my last program, I wrote the program out in a text file first. I then copied it into JSZeddy to compile. I ran into a bit of an issue where the lines with X1 or Y1 needed to be entered again. They displayed correctly, but the ZX81 was giving me an out of memory error when trying to run them. It was an easy fix, but something I'll have to watch.

There isn't much else to change.

Outside of the kerning issues I noted above, I could have designed the letters better. The logo itself is decent and doesn't need improving. I do like how the waves came out. The code might be brute forced, but it works. I could have created an array or something, but it would have meant a lot of typing for no real value.

As the title noted, there isn't anything I'd do different. And that is the best way to end the year. It is nice to close with a decent ZX81 program from my youth that works well, looks good, and wasn't too hard to enter.

For 2021, I plan to work on some newer ideas. I have a few larger programs still to enter and share from childhood. Now, I need to make sure I find the time to get them all done.

Creating Charts on Your ZX81 Couldn't Be More Simple

Steven Reid — Mon, 30 Nov 2020 23:20:00 -0600

As usual, I procrastinated a bit in finishing my ZX81 program for November. Between holidays, work, and NaNoWriMo, I didn't get around to it until this last weekend. I decided to try something a little different for this month's program. The program itself, Charts, is a simple line graph plotter-spelling and bugs galore. As interesting as that program is, the real story is how I entered it.

A different workflow, sort of.

Coming out of my failure last month, I decided to shortcut the whole ordeal this month. After digging through my programs, I decided on a program with limited graphics. This was on purpose. I wanted a program I could type quickly into a text editor. Well, in this case a text box in JSZeddy. This time, I skipped the whole entering the program in a ZX81 emulator and, well, entered it into an editor.

The advantage was I could type the program using real and responsive keyboard. The ZX81 was never a typing powerhouse, lacking horsepower and that whole slow mode. But my Mac, even 7 years old, is great for that. The hardest part, of all things, was entering in some the few graphic characters that were in the listing. Funny enough, I had to go search for the character set. Sadly, I don't have the hex codes memorized.

Funny enough, it worked very well. In no time, I had a program that ran. I did some quick testing and a few tweaks. But otherwise, it was the same as my listing. I panicked for a bit when I noticed the hex wasn't filled out. Running the autosave fixed that issue. Once I had the hex code, I did what I did last time! I copied it into a file, ran my hex2bin.pl program and voil�!

Charts, ZX81 Starting Screenshot by Steven Reid, 2020

Making pictures.

As much as I want not to, I still had to run EightyOne. To my tastes, the screenshots from it look better than my other options. Unfortunately, my VirtualBox stopped working. Ugh. Apparently my upgrade to Big Sur required some new extensions. After updating to the latest version of VirtualBox, and crashing a few times, I figured out what I missed. I approved the extensions and rebooted. With Windows working, I could get back to work.

First, I ran Charts a few more times. Mostly this was so I could enter in data for the print out. For my example, I used some iPhones sales data I found online. Entering data in Charts is a bit of a pain The verbiage I used doesn't match what I use today. Using say X or Y axis would have made more sense.

Charts, ZX81 Screenshot of iPhone Data by Steven Reid, 2020

The other program I had was that Charts doesn't normalize the data. The first time I entered in the data, I got an out of bounds error. The PLOT I used was off the screen. I ran the program again, this time dividing by ten to keep the data on the screen. Although that worked, it would be an easy change in the program.

The display is also a bit of a pain. I only print four characters of the entry. Also, that entry is right against the left axis title. Although the effect is cool, printing the text horizontal, it really needed to be spaced out. To compensate, I added a space, which further reduced what would display. Given he size constraint, I used the last two digits of the year, creating a nice display.

Which brings me the unit's title. It is printed at the bottom of the screen instead of closer to the data. Again, not sure why I didn't adjust this based on location. Granted, I was a teenager and had little knowledge of data visualization and presentation. But still? I mean, it looks weird. But, hey, it was on a computer. Everything was cool to me back then.

I should note that there is a bug in the code. The projections code doesn't seem to work. To be honest, I didn't perform extensive testing. It could be that I did something wrong, but the display didn't match the data I entered. Moving on to other things, like writing this article, I decided to leave the debugging for another day.

Finishing things up.

After grabbing a few screenshots, it was time to finish up a few things. First, I saved the program as a TZX file, which some other emulators used. I converted the screenshots into PNG files. After minifying them, I then uploaded them into my site. I create a little description file and then archived everything. The P and ZIP files then get uploaded, I update the database, and a ZX81 program from 30 years ago is now on my website.

I've already talked about Charts, so let me share a bit about how I write my articles. Funny enough, it isn't as straightforward as you might believe. My first step was is to write the article. I use Scrivener as my editor, which is a great writing tool. I organize all my articles and can snapshot the different versions I write.

Once done, I typically load it into Hemingway Editor. I find it does a great job of telling me how hackneyed my writing is and correcting it. I tend to use a lot of passive tense and adverbs. Something Hemeingway tells me not to do. With that done, I dump the text into my website and add in the metadata, images, and other things needed. Yet, I'm not quite done.

The last step, or in this case the first one, is to write the title. A long time ago, I ran across an article about how to write better headlines. This led me to CoSchedule's Headline Analyzer. I find it useful for improving from the generic headlines I used to write to something interesting. They aren't perfect, and don't always score well, but they are better. Afterwards, I capitalize them correctly using an online tool. You can search to find a couple of good ones. I tend to bounce between them.

With that done, I publish my article. It seems like a lot, but it actually isn't any different from the normal process most editors go through. From draft to final, these are the tools I use to get there. You could use others, there are plenty. This is what I do and I find it works well. That said, I'm always looking for new ways to do things. My workflow is never complete.

Until next tomorrow, enjoy this month's ZX81 program.

Entering a Program Shouldn't Be This Frustrating

Steven Reid — Sun, 25 Oct 2020 21:41:00 -0600

Back in July, I made a mistake and entered in Star Probe again. I had forgotten that I'd already shared it. But, unlike my first attempt, I had taken a different approach which made it a much different game. Jumping ahead, I decided to finish what I started. Here is Star Probe Redo, an updated version as October's program.

Struggling a bit with writing.

To be honest, I'd already written the original blog post when I was thinking this was the first time I was sharing. I've had the game done for a couple of weeks, but couldn't figure out how to write about it. I don't normal have writers block. Once I get started, words seem to flow. This time, nothing. The struggle is real, and I was living it.

Since I don't talk about the process of writing these articles, let me explain a bit. The first few articles tended to have a simplistic structure, often a few paragraphs about the program. As time went on, I tended to stick to a common theme: play, program, and improvements. The advantage to the formula is that I generally could focus on the what without worrying about the how.

To avoid being too formulaic, I've often taken different approaches to each article. Yet, the main theme is still there. You'd think that would make it easy to write, but some programs don't fit the formula. It can be too dry or boring at times, and I try to add in some flavor. Those are often bits about my childhood or outside influences to my programs.

For Star Probe, it was that last part that I struggled with. I couldn't come up with a starting theme that I liked. Given this was a redo of a previous article, I wanted it to have some flavor, a different color. Funny enough, I landed on sharing my struggle. It was right in my face, the inner monologue that was kicking around my head was the discussion.

Writing and programming have similar contexts. If you relate, to this, don't fret and the creative juices will find a way. If you're here for the program, fear not. I ended up sticking with my original theme for the rest of the article-sort of.

An adventure game, again.

It's not easy being a star probe. Space is hard and unforgiving, which explains why we often think of space as the new frontier. An homage to the old west, forgetting that much of the west's problems were man made. In this short space adventure, you are an intrepid star probe with a problem.

Star Probe Redo is at its heart a puzzle game. Although, it is not as sophisticated as an Infocom game. There is no text parsing or objects to manipulate. Instead, the player must figure out what to do by inputing numbers.

It is fitting that the game removes the guesswork given you play the role of the Star Probe, a mechanical device. As an added benefit, it simplifies the game design. Trying to use words would have required a much more sophisticated parser.

It won't take more than a few minutes to finish the game, but I do recommend you play through a few times. Alter what you do, trying different things to see how the game changes. Decisions you make in earlier stages can alter later ones. Think of it as an adventure to figure out the adventure.

Star Probe Redo, ZX81 Screenshot by Steven Reid, 2020

Reworking the game.

Now the first time-err, second time as I realized later-I entered in Star Probe I decided to enter it using SZ81. I had been having issues with my Windows VM and thought I'd give it a try. After entering it in, I tried to load it up later to fix something and realized the program was corrupt. Frustrated, I went to bed to try again later.

Although disappointed, I'd been here before. Having lived through programing hell of the eighties, losing a program wasn't new to me. I generally remember what I did, even if it never quite matches the original. I got back to work. Unable to load the images from SZ81, I started over using ZXSP. A program I've used before.

I had started off by typing in Star Probe again. In doing so, like before, I noticed there were a ton of spelling and grammatical errors. I was going to leave these in, but as I got into the second half of the game, my mind shifted. There were a couple of flow issues I didn't like and it pushed me over the top. Good thing too, as this made Star Probe Redo a much different game.

To make things easier, I typed the story text in Scrivener. This allowed me to edit and correct it first. Entering a large amount of text on the ZX81 can be painful. Your cursor only moves from right to left. Even in FAST mode, the ZX81 is an unforgiving machine.

Once I had all the text written out and edited, I go to work updating the program. Not only was it faster to edit, things made more sense now. I'd removed much of the repetitive text and cleaned up the prose. Now I could work on the program.

Coding for reusability and readability.

With the text done, I started to clean up the display routines. Star Probe Redo breaks up each section into screens of text. Yet, those screens weren't consistent. To fix this, I added some subroutines that provided a consistent look to the text.

Along the same lines, I also cleaned up the responses. The original game tended to print words, often clearing the screen between input. In my new version, I coded in some pauses with prompts for the player to press a key. This also allowed me to combine some of the responses onto the same screen, making it easier to read and follow.

The last major change was to include adding new boolean variables. The game expected the player to try different numbers to see what would happen. However, it didn't save the state of those responses. The result of which was later text didn't make sense if the player had discovered something already.

Adding state required writing new text to differentiate the answers. Back to my editor, I wrote all the new alternative text. I also added in some error checking text in case the player used numbers that didn't make sense. Although more work then I planned, the results were worth it. Star Probe Redo now has a decent adventure prose.

A better experience.

With its bones now fleshed out, Star Probe Redo flowed better across its three acts. The first act starts off as an introduction to the games mechanics. After some opening text, it drops you into the first puzzle to solve. This one has no time limit, instead waiting for the player to figure out what to do next.

The second act, unlike the first, does have a time limit to solve the problem. It is more than enough time, even after cutting down the loop, to solve the problem. I debated dropping it further, but decided it was a fitting length to the middle act.

The last and final act, provides the player an opportunity to solve the game. It may not offer any revelations, but there is some satisfaction in figuring out how to win. Three acts, three puzzles. Not a huge game, but still enough to whittle away some time.

With all the different states now programmed in, the game is repayable.If you die, it isn't the end of the world. You can start over and try again. If you do succeed, I recommend playing again to see what happens with different input. I had a lot of fun testing all the different combinations. Hopefully I didn't miss any!

Programming failure once more.

After a long night of coding, I decided it was time for bed and started saving my file. Given I was close to finishing, I did some final testing and noticed some wording was wrong. I decided to load up an older version of the program, only to find the files wouldn't load.

Frustrated, I loaded up a previous save and saw the same thing. This was the second time I had this issue. I was distraught. I tried loading some of my earlier saves. Only the first one worked. That was something I guess.

I started hunting around for other ways to read the file, but my attempts failed. Back to square one. Although I had my text still, I didn't want to have to start over. At this point, I still had forgotten that I'd already entered it. I went to bed in frustration.

Starting over once more.

The next weekend. When I returned to it, I realized I'd blogged about Star Probe before. At that point, I gave up and wrote about another program instead. That was where I left the program for the next couple of months.

At the beginning of October, I thought it was worth digging into Star Probe Redo again. I thought my reworked version would be worth sharing. I had all the text still, but I wanted to see if I could load up the original code.

I had my VM working and decided to try loading the program into EightyOne. I tried a couple of different ways, from machine states and different formats. None worked. But, I did find that I could read the code in the hex editor. Thinking some of the pointers were wrong, I tried adjusting them to no avail.

Although the program wouldn't load, seeing the data in the hex editor made me wonder if I could list it. Loading it into my website, to my surprise I realized I could! Okay, that was something. That got me wondering, maybe I could compile the code. JSZeddy, the javascript emulator I use, allows you do just that.

After some trial and error, I had the program compiled. But there was still a problem. I didn't have a way to save it. I tried pulling the program out of the editor, but it was in a hex format that doesn't work as a binary program. But, after doing some research, I realized that I needed to convert the text to binary. Theoretically, that would make a .P program that I can load.

Jumping into Perl, I wrote a little program called hex2bin.pl. After some more trial and error, I figured it out. I found the right routines that would read in the hex code and output the appropriate binary data. Loading that file into EightyOne, I was excited to see my program working again!

Back to fixing things.

Excited that I had a working program again, I got to work doing some final testing. I found a couple more bugs that needed fixing. I was glad I had that old text still as a couple of the routines didn't sound right. I made some more edits and fixed the code.

By now, I was planning on making this a proper rewrite. One of the ideas I had before was to remove the INPUT. It is too easy to mess that up and is confusing for modern players. Using INKEY$ instead, I rewrote the input routine completely.

Now, I could have gone further. The display, which clears the screen between text, would work better as scrolling text. I liked the way the old Infocom text games worked and creating a similar routine would be nice. I decided that was a bit too much for this program.

Wrapping up.

There are, of course a few things I could still do. As written, the puzzles rely on hard coded checks with text. Using a data structure would provide greater flexibility and variety.

The game is very linear as written. That isn't bad. But, adding a more varied story with exploration would make the game last longer and more enjoyable. To be honest, that would be a complete rewrite. Given all the challenges I've had, that is out of scope for this effort.

With all the distractions and failures, it is amazing this program is even getting shared. As frustrated as I could have been, to be honest that is life. Instead, Star Probe Redo ended up a being a much better game in the end.

Here Is a Silly Test Program for the ZX81

Steven Reid — Tue, 29 Sep 2020 23:40:00 -0600

September proved to be a rather busy month, at work and home. It isn't unusual for me, and I usually find time to throw a render or program together. As this month closed, I found myself in need of a program to share and not a lot of time. While cleaning up a few things on my laptop, I found this little test program I wrote last month that fit the need.

A testing we will go.
Funny enough, I wrote the program back in August while testing out a new JavaScript emulator. It was short and sweet and did the job intended. Sadly, the export routine is a JSON file. I didn't spent the time to figure out how to convert it to a something other emulators can use. yet, the program was short enough that I could grab a screenshot.

Test, ZX81 Listing by Steven Reid, 2020

The program, as is, is a fun little demo. It prints ZX81 randomly on the screen-forever! It is basically a big loop that scrolls the text upwards. Nothing super exciting, but it worked great. Specifically, it allowed me to test a few things.

First, it tests how PRINT works. Surprisingly, this is a pretty complex routine on the ZX81 and a good test of how the overall emulator works and interprets the ZX81's ROM. In addition, I used boolean logic, functions and other stuff. Everything worked great.

The other thing it tests is the SCROLL routine, which causes the display to bounce a bit when used on a real ZX81. I suspect it because of the way the ZX81 is designed to shrink the display when not using a 16K RAM pack. Most JavaScript emulators don't emulate the TV display, so I wasn't expecting that to work. It didn't, but still made for a good test.

The last part is that I added a SAVE routine to test any tape emulation. Again, most JavaScript editors don't emulate the tape interface. As before, a good test to see what does and doesn't work.

Recreating for publishing.
Since I just had the screenshot, I needed to get the program into a .P file I could run on most emulators. Given the program is short, I just loaded up my emulator and typed it in. Easy as every. I wish programs on my site were this easy. I spent an hour digging through my CMS code to change few lines. Of course, nostalgia only goes so far.

Test, ZX81 Screenshot by Steven Reid, 2020

I won't get into what could be different. As a test program, it does its job and is fun to watch. Designed to be easy to enter, I actually tried it on an emulator for iOS as well. Sadly, I can't save there either, but it was fun to play.

And there you have it. A busy month and a simple test program for your ZX81. Give me a shout if you decide to use it anywhere. Although I'm sure you can write something even better.

Here Is My Crazy Idea to Make a ZX81 Game with a Printer

Steven Reid — Sat, 29 Aug 2020 17:59:00 -0600

Back in the day I learned to program on school PDP-11 with a 6 teletypes and a CRT attached. I was still in computer club at the time, thinking the 8" floppies were pretty cool. To my despair, the poor thing died that Summer and, when I took my programming class, it was on an Atari 800. But the programs I wrote the previous year stuck with me. Printer Car harkens back to those days.

Typewriters and teletypes.

I grew up learning how to type. My dad brought home an old Royal manual when I was like 9 or 10. I spent that time learning to type, often creating D&D player sheets. But I also created pictures, or typewriter art. It was a fun way to pass the time.

Fast forwarding a couple of years. One of my friends, who was a year older, showed me some printouts of the computer programs he was writing. I was hooked. The yellow paper of printed text reminded me of earlier experiments on my typewriter. I couldn't wait until I was in sixth grade to try it myself.

A year later, I had signed up for computer club and was playing on that PDP-11. My computer teacher provided me a BASIC manual and I started to write programs. Of course, I did what I knew. I created pictures!

It wasn't long before I wrote real programs. Given this was on a teletype machine, the printouts were like the art I made on my typewriter. As the teletype printed each line, it advanced the paper, scrolling it up. I still have my medusa printout somewhere. It was a simple program, but it was a start.

And then there were printers.

Of course, a year or so later I had my own computer and was writing programs on it. It was a ton of fun and, at some point, I owned a printer. I'm not sure if it came with the computer, or was a later gift. Given I didn't list old programs, I'm guessing the later.

In any case, it was a TS204 printer and used rolls of paper. Sound familiar? Yep, this printer didn't use paper sheets, but rolls like that old teletype. Yet, it wasn't quite the same given it was a spark printer instead of the ink of the teletype.

This leads to a different look and quality, but it works. Well, most of the time. My printer stopped printing two columns of information at some point. The printer has two heads and, given the other columns show, I'm guessing something came loose.

Now, I didn't neglect my printer. Besides listings, I wrote many programs that printed to the screen. Some were art screenshots using the COPY command. Others, such as Tabular, used sophisticated hacks. Yet, Printer Car, were a homage to those teletype days.

Printer Car - Game Play by Steven Reid, on Flickr

Games on printers.

Of course, the ZX81 isn't a teletype machine. Like most home computers of the era, it was designed to work with a TV. In the ZX81's case, it was a black and white television. Dot crawl and screen artifacts were normal and part of the experience.

Yet, the ZX81 could print lines of to the printer as well using LPRINT. Unlike the display, I didn't need to use SCROLL since the printer advanced on its own, like the teletype did. Inspired, I wondered if I could write a game for it.

Printer Car isn't unique, designed as a simple wall dodge game. I'd played many of other games written like it, along with writing my own. But this one was different. This one used the printer as a display, much like games I'd written for that PDP-11.

Of course, the printer isn't very fast. Even as close as the walls are, the game isn't hard. Yet, it does play very much like it would on the screen. Each line of data is printed and then, using the keyboard, you move to avoid the walls.

If you can survive a 100 lines, you win! If not, you crash and start over. To my surprise, it all works very well. I even tried it out using my emulators printer. Mimicking the old TS2040 or printer, it played pretty much like I remember it did. Fun times.

Printer Car, circa 1983, ZX81 Gameplay by Steven Reid

After the fact complexity.

The program's code is short and sweet. Using a simple loop, Printer Car displays each line and then checks if you moved. If you hit a wall, the game ends. If you don't, it keeps looping until you win or crash.

The original code could use a little optimization. It has some duplicate code in it that I could tidy up. Otherwise it is straightforward and readable program. Yet, the program stops when it ends, requiring you use RUN to play it again.

Printer Car - Listing by Steven Reid, on Flickr

That doesn't work well for an online game. Also, I don't have a printer option in the JavaScript editor I'm using. As such, I decided to add a few customizations that let it run on the screen and let you keep playing it.

The program here, then, allows you to choose which mode to run. By default, it will use the screen, but if you load it up it will ask you if you want to use a printer. If so, the game plays much like the original game.

If you decide to use the screen, it required a bit more work to emulate the printer. Usually, the ZX81 doesn't automatically scroll the screen when full. Instead, you have to use the SCROLL command to make text move from the bottom up.

Printer Car, circa 1983, ZX81 Screenshot by Steven Reid

Switching out the LPRINT for PRINT was easy, but now I had to add SCROLL to each line. Even worse, the way TAB works is a bit different. I kept getting memory errors playing the screen version of the game. After some testing I realized that the TAB was causing the line to advance, even if it wasn't printing anything.

To correct the problem, I used PRINT AT to fix the memory issue. I thought it would slow things down, but I didn't notice any difference. With all the errors gone, I now had a mirror copy of my game working on the screen.

That said, the program is now much larger and more complex. A good portion of the original version was dedicated to printing lines. Even with a few optimizations, the new code was still complex. The new program was almost twice as big.

For better or worse.

Even with the modification, the game didn't need much tweaking. Outside of a few optimizations noted above, I don't think I'd change much. I thought I could remove that extra LPRINT that adds double spacing. I added it later given it has a a line number not ending in zero.

Thinking about why it was there, I'm sure I added it to advance the paper up enough to see it. The TS2040 printer head was below the case line. I'm assuming I needed to advance it a bit to make the game playable. Thus, it is an oddity that was practical at the time.

The only other thought would be to create a variable wall or add objects to dodge. That would make the game more playable, but given the medium, it wouldn't make a lot of sense. Perhaps for a screen based game, but as written it works fine.

Plus, the program was meant to be simple. I designed it to emulate a typewriter, not a TV. The game isn't quite the same as the teletype didn't have an INKEY$ function. You had to hit enter to get it to scroll. As such, Printer Car is an experiment-a "what if" game. As that, it does an exceptional job.

Can You Win in This Easy Game of ZX81 Dice

Steven Reid — Fri, 31 Jul 2020 19:22:00 -0600

Lately, I've been reflecting on my programming journey. It is hard to believe that it has been over nine years since I started writing my monthly articles. I'm nearing the end of my printouts, and thought I'd write about my ZX81 Dice Game.

Walk down retro lane.

Although I'd shared the program on my original ZX81 site back in 1998, I'd never written about it. Back then, listings and screenshots were about as far as I went. It was a simple site, created before I started blogging.

Over the years, I went way beyond blogging about my programs. I made them a monthly column with listings and ways to play them. I even shared original programs, and recreations, and lots of bug fixes.

Funny enough, it also show cased how technology changes. My onsite emulator went from Java to Javascript, allowing any mobile device to run them. I shared an Android emulator for a few years, which still works on my old Toshiba tablet.

Over that same time, my site went from static, or generated, to dynamic rendering. It has been through a few redesigns, migrations, and remakes. Like the emulator I used, each element works on phones, tablets or computers. I never expected any of this when I started blogging in 2006.

Old doesn't mean old.

Will all that modernization and changes, the programs stayed consistent. The blocky graphics and quirky text fit well inside that modern chrome. For as modern and slick as things get, underneath they follow similar mechanics.

Dice Game, in theory, is based on analog dice. In this case the die doesn't roll, using a random number generator instead of physics. There are four dice, two for each player. After display each face, dice game tells you who won based on the highest value rolled. The only key in the game is when you press one to start again. There is no score or tally. The mechanics were all about the dice and a little math.

Now, I admit the game could use some game play. But even written in a modern language with fancy graphics, it would play pretty much the same. Dice are, well, dice. You could say the pseudorandom number generator isn't fair. But, loaded die aren't either.

Peeking inside the dice.

Okay, we aren't actually going to break dice open. But looking at the code for Dice Game, you get a sense of how simple it is. The program was one of my first, I still have hadn't written notes somewhere for it. The main focus was playing with graphics and, in this case, the dice.

That said, it is very well formed and flows well. Dice Game is an easy program to read, even if you don't know basic. It uses GOSUB to call each roll and display the dice. The rest of the program displays the results and who won.

Since ZX81 basic doesn't have a switch or case statement, I used a series of IF checks to mimic one. Dice themselves are PRINT statements using ZX81 graphics. To reuse case, I had a GOTO's on the five and six to display the last row of pips in the four.

As nice as the code looks, it could be more efficient. I could have simplified the throws to a single function. Yet, it would have required using another variable.

For the row of IF statements, an easy optimization would have been to use a variable GOTO instead. A simple GOTO 300+Z*40 would have worked. Although, I would have needed to adjust the lines numbers of the six. I didn't know this trick at the time, but did use it in later programs.

A more complex way to achieve this would be to use a string array with all the die faces in it. Then, all I would need is a single print routine using Z as an index or to slice the string. There are a couple of ways to do that, but at the expense of readability.

Improving the game itself.

The game isn't much of a game. I mean, there is no skill involved. As such, the program is a great demo, but has no replayability. To be a real game, it needs a mechanic for the player to keep playing.

An easy mechanic would have been to add a betting element of some sort. This is what I did on another game of my called STUD. That said, betting on dice rolls doesn't seem that popular, even now.

More fitting would be to collect patterns or matches. I know that I wanted the dice to print next to each other, instead of down. But I didn't know how to do that when I wrote the program. Fixing that, I can envision a couple of different matching or pattern games. Adding that with a dice substitution or tally mecahnism would add a strategy element.

Adding these changes would have made Dice Game more interesting. Yet, it would have lost its charm and simple nature. I'll leave this one as is, and let the rest be a future experiment.

Try to Be a Great Space Navigator Taking This Silly ZX81 Quiz

Steven Reid — Mon, 29 Jun 2020 23:38:00 -0600

Having a healthy imagination and perchance for sci-fi, Spaceship is a bit of both. I assume I conjured up the idea as part of some playtime activity. Written in 1983, it was one of my earlier programs and lacked graphics. Yet, it was still a bit of fun.

Navigating a spaceship is easy.

As a navigator for the spaceship lanes, you need to be tested. At least, that is what Spaceship requires you to do. Having watched Star Trek II by then, I was probably role playing my own Kobayashi Maru. Subtle terms like worp drive and impulse hint at Star Trek references.

Spaceship as a game is a bit light on play and heavy handed on words. Acting as a sort of computerized quiz. Set in a different context, I could have turned the program into a regular test. Of course, it isn't. Instead, it is an over wordy test set in a science fiction setting with little substance.

With two whole questions, the test is simplistic and it should be easy to pass it. Although the content is lacking, the presentation actually works well. The game uses a clean screen with standard positions for prompts and text. The text is well placed with boolean statements used to alter the story.

You are not determined and other fun text.

The results of the quiz, although wordy and difficult to read, are cleverly presented. The game asks for your name and age, using both to adjust the results. The next screen presents a full page of text related to how you answered the test and your age.

This is the heavy handed part, overly hammed up with a grade based on two whole questions. The grades and answers are, shall we say, different. I was young and the test reflected how I perceived grading. Using words like determined, awful and honor sound big but don't match the value.

What is more interesting is the code that underlies it. Spaceship determine your results based on your score and age. Yet, the game doesn't use numbers and math to determine the results. Instead, it uses a mix of logic to create and display your results.

Saying a little with a lot.

Spaceship first uses your age to set your ability. This is down with a single LET statement that uses a boolean check to determine what text to display. Other than text, there isn't much difference in results.

The quiz uses correct, worth 2 points, and partially correct answers, worth 1, to set a score variable. This allows a max possible score of four which is later translated into a grade. But, before using it, the game checks which age ability you are. Using the first letter of the ability string F$, the game then decides which text to display.

With two lines of code, the string G$is set to the appropriate grades based on your age ability. The grades, as noted before, are silly, but fit the feel of the game. There are five grades, based on scores from 0-4. Thus, the resulting text of the game has ten variations. Yet, it accomplishes this in three lines of code.

Finishing up the game.

As slick as that is, Spaceship is a rather long program because of all the extra text it prints. Unlike the quiz and results, the last screen of text of the game doesn't vary. It is a wordy letter about taking the test, signed by me of course. I have no clue what a spaceship AD is, but I expect it was a role I was playing.

While entering in the program I did run into few issues. The age checking code didn't match the text and could actually cause the game to crash. I fixed that error along with some spelling issues. Other than that, the game is as it was in 1983.

On the whole, and taken in context to the time it was written, Spaceship is a decent program. It uses some interesting coding tricks and presents well. Things I took to heart in my later life building web pages and user interfaces.

That aside, the game is too shallow and not well suited for any amount of replay. Saying that, I do recommend running through it a few times to see the different answers. But without some outside influence and story telling, Spaceship isn't much fun on its own. As my 13 year old self might say, "use your imagination!"