ZX81 Computer – Reid’s For Fun

Can You Keep Up with Lift, My ZX81 Elevator Game

Steven Reid — Mon, 06 Apr 2026 21:15:00 -0600

This week I received a new ZX81 book I purchased on eBay called "Timex Sinclair 1000 Programs, Games, and Graphics." A little graphic program in the back of the book inspired me to create a game called Lift. Can you catch the items before they fall? Let’s dig in.

# Moving around the floors.

Before we dive into the program, let's talk about the game. As a lift operator, it is your job to move between floors and catch the items that move along it. Simple enough, right?

Of course, the items move pretty quickly, making the game somewhat challenging. You use the 1-4 keys to travel between each floor. Like a hotel, the first floor is at the bottom and the fourth at the top. Fortunately, you don't need to stop between floors. As a hint, I usually have my fingers on each number ready to react.

"Lift in motion. Lift, 2026 by Steven Reid"

For each caught item you get 10 points. Miss an item, and it goes splat, and the game displays your score. How high can you go?

# An old idea reused.

The original graphic program, called "Macy," was a short little elevator simulator. The intent was to show how to move objects on the ZX81 screen. Typing in the program, I liked the clever way it moved the lift between floors. It wasn't fast, but it did convey the movement quite elegantly.

Designed for 1K (even though the Timex Sinclair 1000 was sold with 2K of RAM), the graphic program was quite simple. It used a repeating for loop to PLOT the floors. Although it looked decent, it was slow to watch.

The movement of the lift was better, using a simple print routine with a variable to shift between floors. Using a simple number input, you could move the elevator between the store's floors.

Overall, quite an intriguing simulation. I wanted more. Time to make a game.

# Printing instead of plotting.

Throwing out the old code, I started fresh. The first thing to go was how the floors were created, switching from PLOT to PRINT AT. With the new routine, not only could I display the floors faster, but I could use a different graphic as well.

"Lift game play. 2026 by Steven Reid"

With the display done, it was time to add in some movement.

# Making the game move.

With the display now done, it was time to add in some motion. I remembered another game using alternating block characters to convey motion. Using the same concept here, I wrote a little display routine for the item. It moves along a randomly chosen floor for you to catch.

"Lining up the catch. Lift, 2026 by Steven Reid"

The item moves smoothly using a very simple array. Using the ZX81’s true/false logic, I used the NOT command to flip between the two frames of the animation. The code below is a decent approximation of the logic.

 120 LET N=NOT N
 130 PRINT AT Q,W;" ";"/\"(N+1)

If you select a floor, the item will pause to allow the elevator to shift between floors. I like it when the items are polite. If you play enough, you may realize you can move the lift at the last possible moment and still win.

# Catch it or splat.

One thing I tried to do with the code is logically organize it. Since I was using 16K of memory, I could be a bit verbose and add in some REM lines to explain what each routine does. Although they are quite simple, it does help manage the flow of the program. By glancing at the code, it becomes clear how it is laid out.

Of course, the biggest challenge is catching that item. When you select the right floor, the game adds some points and repeats. If you miss, the item becomes an asterisk and the ending screen is displayed.

"That didn't end well. Lift, 2026 by Steven Reid"

It’s simple, but it works. The timing feels just tight enough to keep you paying attention. On a real TS1000, you'll be fighting the membrane keyboard as well.

# A proper intro screen.

I couldn’t resist adding a small intro screen to set the stage. I added it to the SAVE routine to make things easier. It’s a small touch, but it helps the program feel more complete right from the start. Plus, it tells you how to play. This avoids the objects from just rolling off the screen to start.

"Lift intro screen"

As a side note, I did use the ZX81 comma to format the text. This avoided adding in additional PRINT lines.

# Same idea, very different game.

At its core, this is still the same idea I found in that 1982 listing. Although I started by fixing the input routines and speeding up the graphics, the biggest improvement is how much cleaner the program structure became. It didn’t hurt that the game glitched when I was almost finished, forcing me to rewrite it from scratch.

But between the rewritten structure, updated input handling, and character-based graphics, it feels like a completely different program. Faster, cleaner, and honestly just more fun to play.

It’s always interesting how far you can take a simple idea with a fresh pass.

Want to try it out? You can run the program, or view the code if you’d like to see how it works.

Building a ZX81 Intro Screen for Wolf, Goat, Cabbage

Steven Reid — Tue, 31 Mar 2026 23:23:00 -0600

When I first converted Wolf, Goat, Cabbage to the ZX81, I wanted to include an intro screen. Sadly, I didn’t get around to it at the time. This month, I finally circled back and it turned into quite the journey.

# Where I ended up.
The final result works. I had a few different ideas in mind, but this one fits the limits of the ZX81’s graphics pretty well. It has a large title, a wolf, a goat, and a very simple cabbage. I’m happy with how it turned out.

“Final ZX81 intro screen”

# Where the journey started.
As much as I like the final version, I originally planned to build it using generative AI. Back in 2024, when I was updating the puzzle, I spent a lot of time experimenting with different GenAI tools. I had a clear vision and turned it into a prompt… and the result was a complete failure.

The problem wasn’t just the tools—it was the ZX81. Its low resolution and black-and-white graphics make it hard to translate modern AI output into something usable. I could generate 8-bit-style images, but the scale was always off. The wolf, goat, and cabbage never matched, and trying to recombine elements didn’t help.

I still have those attempts, but they’re not worth sharing. The title looked off, and the overall composition just didn’t work. Even revisiting this in 2026 didn’t improve things much. The AI tried, but it couldn’t quite grasp how to work within the ZX81’s character-based graphics.

# Building it myself.
So I went back to basics and built everything by hand. I found a simple online pixel editor and started sketching out the title screen.

I began with the lettering, roughing out shapes and then refining them until they were readable but still chunky enough to fit the system. From there, I built out the scene: two shores, a river, a boat, and the puzzle elements. I redrew parts several times to get the proportions right and experimented with the ZX81’s checkered and gray characters to add a bit of texture.

# Displaying the image.
As a teenager, I probably would have just used a giant PRINT AT and called it good. In fact, I’ve done exactly that in other programs.

This time, I wanted to try something a little different. I built a simple compressed data structure where each letter represents a graphic, followed by a number that repeats it.

“Compressed DATA for screen”

From there, I wrote a decode routine that walks through the data and renders the screen. It works, but it’s very simplistic and very slow.

“Decode routine”

# Working around the speed.
Since the decode routine is so slow, I took a different approach. Because the screen only needs to be built once, I can generate it and then SAVE the program.

“Saving the generated screen”

The routine uses FAST to help speed things up, but fair warning—it’s still slow. If you want to see it in action, try RUN 7000. If you remove line 7010 or comment out FAST, you can watch it build the screen step by step. It’s not pretty, but it gets the job done.

# And that is it.
I enjoyed building the screen and experimenting with the decode routine, but honestly, the teenage approach might have been better. A big PRINT AT block would probably use less memory and be much faster.

An even better solution would be to poke directly into the display file or use machine code. Maybe that’s a project for another day.

“Gameplay screen”

Outside of the new intro screen, not much else has changed. The puzzle plays the same as before. I considered cleaning up the code, but it didn’t feel worth the effort. Adding variables helps readability a bit, but sometimes it’s easier to just strip things down and leave a few comments.

I’ll leave that part to you—or your code generator—to improve.

Enjoy!

Want to try it out? You can run the program, or view the code if you’d like to see how it works.

Trap or Gold Is a Simple ZX81 Game of Chance With a Twist

Steven Reid — Sun, 01 Mar 2026 22:39:00 -0600

I was pursuing ideas for a simple role-playing or fighting game. The one I landed on was the concept of a single treasure chest. It fit the retro-computing theme perfectly. Trap or Gold is a simple game that doesn't need fancy graphics, speed, or memory — yet it’s still fun.

# From idea to fun.

Working on the game, I realized that simplicity was its strength. My ideas tend to be grand, graphic-heavy games that don’t always play well on the ZX81. To be honest, they don’t always look great either. Lately, I haven’t had the time to work on larger projects, so the idea of a single treasure chest that you either open — or don’t — felt right. It works.

Thinking about the game during a recent run, I realized how much it echoes the programs I wrote as a teenager. Once I figured out random numbers, my first games were usually dice or card games. Those are probably the simplest forms of chance you can create.

Trap or Gold, Starting screenshot, 2026 by Steven Reid

What makes Trap or Gold interesting is that it isn’t just about winning or losing money. Most gambling-style games revolve around a single value — money. Here, you’re gambling with two: gold and health. You want gold, but you don’t want to get hurt. That extra layer adds tension and fits nicely with the fantasy theme.

# A little strategy.

Adding health makes Trap or Gold feel more like a survival game. Opening the chest offers risk or reward — wealth or pain. Under the hood, the game picks a random number using the line LET R=RND. The odds don’t change, but you are given a choice: open the chest or not.

Trap or Gold, Opening the Chest, 2026 by Steven Reid

To make this more interesting, I intentionally generate the random number before you open the chest. This gives the player the opportunity to “burn” a number if they feel the chest might be a trap. Rationally, it changes nothing. Emotionally, it feels like control.

It’s a small trick, but it adds a surprising amount of tension. It turns a simple random number into something that feels personal.

# Making it a bit more random.

The ZX81 uses a pseudorandom number generator. By default, the sequence is the same each time the machine starts, which makes outcomes predictable. To avoid this, you can use RAND 0 to seed the generator from the FRAMES counter — a value that updates as the screen refreshes.

Trap or Gold, Deciding not to open the chest, 2026 by Steven Reid

On a real ZX81, this works well. The delay between turning on the machine, loading a program, and running it is usually enough to produce different results.

On an emulator, however, everything happens almost instantly. The machine state is consistent, and the random sequence can repeat each time you start the program. That’s not ideal for a game of chance.

Trap or Gold, Finding treasure, 2026 by Steven Reid

While designing the game, I added a simple title screen that waits for a key press. This gave me an opportunity. I moved the RAND 0 call to after the input. Since human timing is unpredictable, it helps make the results feel truly random.

# Making the game visually appealing.

To make the game a bit more interesting visually, I added a simple animation for opening the chest. This is done using a sequence of PRINT statements. To slow things down, I took advantage of the ZX81’s quirks — using small delays to create the illusion of motion.

Here’s the code with simplified graphics:

2500 REM **OPEN CHEST**
2510 PRINT
2520 PRINT AT 9,14;"_____";AT 10
,14;"&lt;pipe&gt;___&lt;pipe&gt;"
2530 LET L=SIN PI**PI
2540 PRINT AT 9,14;"&lt;pipe&gt;---&lt;pipe&gt;";AT 10
,14;"&lt;pipe&gt;---&lt;pipe&gt;"
2550 LET L=SIN PI**PI
2560 PRINT AT 9,14;"&lt;pipe&gt;---&lt;pipe&gt;";AT 10
,14;"&lt;pipe&gt;   &lt;pipe&gt;"
2570 LET L=SIN PI**PI

I use a similar approach for the trap and treasure animations. With just two frames and a simple loop, you can create a flicker effect that works surprisingly well:

2640 PRINT AT 21,6;"   TRAP/ -";
D;" HEALTH   "
2650 FOR P=1 TO 10
2660 PRINT AT 10,15;"***"
2670 LET L=SIN PI
2680 PRINT AT 10,15;"---"
2690 LET L=SIN PI
2700 NEXT P

Trap or Gold, Finding a trap, 2026 by Steven Reid

# Open the chest?

In the end, Trap or Gold is an adventure wrapped in a game of chance. I enjoyed developing it, and I’m happy with how it turned out. It feels like something I might have written back in the eighties.

Trap or Gold, Finding enough gold, 2026 by Steven Reid

I played through it multiple times to capture screenshots, and along the way, I found myself developing strategies — or at least convincing myself that I had one. Trusting instinct, second-guessing outcomes, and hoping for gold instead of traps made each decision feel meaningful.

As your health drops and your gold creeps toward 100, the tension builds. In the end, it isn’t really about the numbers — it’s about the feeling that maybe, just maybe, this time you’ll get lucky.

So… do you open the chest?

---

Want to try it out? You can run the program, or view the code if you’d like to see how it works.

Are You Fast Enough to Beat My ZX81 Duck, Duck, Goose Game?

Steven Reid — Fri, 30 Jan 2026 22:14:00 -0600

Every once in a while, a small, silly idea turns into a surprisingly fun little project. That’s exactly what happened with my latest ZX81 experiment, a reaction-based game inspired by the old nursery rhyme: Duck, Duck, Goose.

The rhyme always felt like a game waiting to happen. Someone walks around, calmly tapping heads, saying “duck… duck… duck…” and then suddenly — goose! Everything changes in an instant. That moment of surprise is perfect for a computer game, especially on a machine like the ZX81 where timing and simplicity are part of the charm.

I started with the story in my head: the computer steps through the ducks, and at some random point it shouts goose. Your job is simple — react fast enough and hit the right key before it’s too late.

Simple idea. Tricky execution.

# From rhyme to reaction.

At first, I built it in the most obvious way. The program runs through the ducks, waits, and when it hits goose you press a key to win. While testing, I immediately found a problem. I could beat it every single time by just holding the winning key down.

Not being any fun, I added a check to make sure you weren’t already pressing the key. Although it helped a little, it didn’t fix the problem. I could still cheat by holding the key, letting the program pause before the reaction window, and then hitting it again to win.

Back to the drawing board.

# Making it harder to cheat.

The real fix turned out to be simple and much more interesting: don’t tell the player which key will win.

Instead of waiting for one predictable input, the program now picks a random key when goose happens. That means you can’t camp on a button anymore — you actually have to react, see what’s being asked, and respond in time.

The side effect?

It’s harder. Sometimes really hard.

But that’s what made it fun.

Suddenly Duck, Duck, Goose stopped being a timing trick and turned into a proper reaction test. You have to be fast enough to win. I adjusted the timing a bit to ensure the game felt fair, yet challenging. On a ZX81, that kind of tension feels great. The machine isn’t rushing you with graphics or sound; it’s just quietly waiting to see if you’re quicker than it is.

Duck Duck Goose Win Screen, ZX81 Screenshot, 2026 by Steven Reid

# Programming a game.

Under the hood Duck, Duck, Goose is classic ZX81 BASIC. The program flow is as follows:

It steps through the ducks.
Randomly decides when goose appears.
Chooses a random winning key.
Opens a short reaction window.
Checks if the correct key is pressed in time.
Then decides your fate.

Nothing fancy, just timing, randomness, and keeping the player honest. Because of the randomness, I used SCROLL to avoid filling up the display.

# Can you beat it?

Of course, the real question isn’t how it works — it’s whether you’re fast enough. No save states. No rewinds. Just you, the ZX81, and a surprise goose waiting to ruin your day.

Sometimes you’ll win.
Sometimes you’ll swear you pressed the key in time.
And sometimes the goose just gets you.

Which feels pretty accurate to the playground version, honestly.

Duck Duck Goose Lose Screen, ZX81 Screenshot, 2026 by Steven Reid

# Final thoughts.

I like projects like this. They start with something small — a nursery rhyme, a silly idea — and turn into a little experiment in game design. Even on a 40-year-old machine, you still run into modern problems like cheating, fairness, and player feedback.

Duck, Duck, Goose ended up being more than a joke program. It’s a tiny reaction challenge wrapped in a bit of childhood nostalgia, running on hardware that still surprises me with what it can do.

So… are you fast enough to beat it?

---

Want to try it out? You can run the program, or view the code if you’d like to see how it works.

Building a Flip-Style Digital Clock on the ZX81

Steven Reid — Mon, 22 Dec 2025 20:28:00 -0600

I’d been thinking about writing a better clock program for the ZX81 for some time but never acted on it. That is, until yesterday when I saw a flip-style digital clock program on the C64. The result is a sort of digital flip clock program for the ZX81 that ended up being quite a fun journey.

# Programming a clock without a clock.
First off, I should note that the ZX81 doesn’t have a clock. It does have a crystal oscillator in the ULA chip, but don’t expect miracles. It works, but it will drift. The irony isn’t lost on me that Timex sold a number of these in the US and these things don’t keep on ticking. Marketing aside, you aren’t going to get a great clock.

Thus, the way to do this is by counting frames, which the ZX81 makes easy through a system variable. This isn’t a new concept and is used by other games as well. But that was where my brain was stuck, as I don’t use it much in BASIC. I decided to focus my attention there. At this point, I started to build a very basic digital clock with a few input statements. The prototype worked, but it was boring.

One thing I did early on was to make sure the clock worked on both the PAL and NTSC versions. The ZX81 has a system variable I could read to adjust the frames per second. As a note, the clocks are highly imprecise, so you might need to nudge it a bit. I originally had some routines built in to do that manually. They proved too slow and I decided to drop them from the final version.

# Sprucing up the clock.
The goal was to build a more interesting clock with larger digits. This required a lot of trial and error to see what worked fast enough. Given the frame counter only gives me about 4–5 seconds, I needed a fast print routine. The first version required breaking apart digits and printing each number using simple print routines. This worked, but wasn’t very fast.

My next version used arrays to hold strings. There are multiple ways to do this. You can use flat arrays and split them, which is easy to enter but proved slower. Or you can create a multidimensional array and print each row of the digit. This was marginally faster, so I stuck with it.

As a note, during development I displayed the seconds. Although this worked, it tended to skip seconds—something I adjusted for in the routine. It still looked awkward, so I dropped it later. I also played around with blinking colons, leaving that in the final version to give some visual feedback that things were working.

Flip Clock, Running, ZX81 Screenshot, 2025 by Steven Reid

The final version made a couple of minor changes. I didn’t like the slow incremental printing, so I built the display in another variable and printed it all at once. This still drags a bit, but looks smoother. To keep things as fast as possible, I don’t print anything until the minute changes.

# Setting the clock.
Although INPUT worked in the prototype, I wanted a better user experience. To accomplish that, I ended up using the print routine itself to let the user enter digits to set the time. When done, you use the D key and, if the time is valid, the clock starts.

Flip Clock, Setting, ZX81 Screenshot, 2025 by Steven Reid

This is actually a pretty slick program, but it also shows how slow the print routine is. It takes almost a second to display the digits. Be patient! I really like it, but I do wish the display was a bit faster. If I were to make any changes, I’d probably move the digit display into machine code. The goal was to keep this in BASIC, and this is probably as good as it gets.

# A lot of work.
Although a simple program, I spent a lot of time building and testing different versions. I ran through probably sixteen iterations as I tried different ways of accomplishing the same thing. I used GenAI to help research ideas, but I spent much of the time explaining the ZX81’s constraints.

If I were to make changes, I’d reduce the character size and try to speed up the display. Adding an alarm would be cool. There are sound cards out there that would be neat to use. I also found a project during my research that used an external clock. That would be a fun project for another day.

---

Want to try it out? You can run the program, or view the code if you’d like to see how it works.

Experimenting with Binary Space Partitioning on the ZX81

Steven Reid — Fri, 28 Nov 2025 20:11:00 -0600

I thought I’d try something a bit different this month. I’d been looking at different ways to build maps for years but never really did much with them. After watching a video on binary partitioning, I decided to see if I could build a simple map builder on the ZX81.
This is the result.

# Watching It Run.
Rooms started as a way to build a map of rooms. Simple enough. But as I worked on the program, I added a few debugging lines to help me watch what it was doing. This made the demo a bit more interesting to watch. I could have easily run it in FAST mode and printed the final output, but where’s the fun in that?

In a departure from what I normally do, I left the debugging routines in the version I’m sharing. It may not be obvious at first, but there are two debugging routines. The first shows vertical (SV) and horizontal (SH) splits for each room.

The second is after Rooms clears the screen and displays room numbers. For each room, it prints its screen position, width, and height. Following that, the rooms are drawn on the screen. More on that later.

Rooms, Building, ZX81 Screenshot, 2025 by Steven Reid

# Getting Ready.
With the premise complete, let’s dive into the program. The general idea is that you start with a room and divide it. That division could be vertical or horizontal. Easy, right? Not quite. First, you need a little math—and a data structure.

To keep things simple, I used an array to hold the rooms. I start with a single room. The routine looks like this:

1000 REM **INIT
1010 LET NR=1
1020 LET NM=10
1030 LET RM=5
1040 DIM R(NM,4)
1050 LET R(1,1)=0
1060 LET R(1,2)=0
1070 LET R(1,3)=63
1080 LET R(1,4)=43

The variable NR tracks the number of rooms. R holds each room’s position and dimensions. Two constants give me flexibility in adjusting the map creation. The NM variable holds the maximum number of rooms to create. The RM variable contains the minimum room size. With that in place, I can start building the map.

# Building Rooms.
The next step is to walk through each room and try to split it. Using a FOR loop, I pick a split direction. I used a little trick to do that in a single line:

2060 GOSUB 3000+100*INT (RND*2)

This lets me jump to one of two routines—vertical split or horizontal split—without extra conditionals.

The general algorithm:

Divide the room randomly.
Calculate the new room’s screen coordinates.
Adjust the original room’s width and height.
Calculate the new room’s width and height.

After the split, the main routine performs two checks:

Is each room big enough?
Are we still below the room limit?

If either fails, it skips the update and moves on. If both pass, the original room is updated, NR increases, and the new room is inserted at the end of the array.

Rooms, Finding, ZX81 Screenshot, 2025 by Steven Reid

# Building a Map.
There’s a larger loop that keeps dividing rooms until we reach our target count. Ten seemed like a good start. Inside this loop, the program prints out the rooms created so far and then draws them to the screen.

I originally planned to turn off debugging and just show the final rooms, but I ended up liking the look, so it stayed.

You may notice that rooms print in a strange order. That’s because new rooms are appended to the array and aren’t always next to the room that generated them. I could have created a tree structure, linking parent to child. I didn’t need that for this demo, but maybe in the future.

Rooms, Final, ZX81 Screenshot, 2025 by Steven Reid

# What’s Next.
The rooms generated here work fine, but they could use more variety. For the next version, I plan to add connections and vary the room sizes. That should give the map more personality—especially for dungeons or caves.

I’ll likely convert the whole thing to machine code as well, since speed becomes an issue as complexity grows.

Once I have the core engine working, the real challenge begins: what do I use it for? I have some old game ideas from my teenage years that would fit nicely. I had monsters and such built out in earlier projects, but everything was quite static. This system would give me a proper world to drop them into.

Looking forward to sharing more as it grows.

---

Want to try it out? You can run the program, or view the code if you’d like to see how it works.

Drawing a Twisted Cylinder on the ZX81

Steven Reid — Fri, 31 Oct 2025 23:09:00 -0600

I wrote this back in August and I’m finally getting around to publishing it. It was first shared in my BASIC group, but the ZX81 lacks a lot of the functionality needed for it to run well. Undeterred, I hacked at the program to not only display the twisted cylinder, but also add a bit of randomness to the demo.

# Needing a line.
The first hurdle to overcome was adding a line-drawing routine. Fortunately, I’ve done this a few times in other programs, so I grabbed the routine from my old drawing program. With that in place, I could replicate the math of the original program and see how it behaved.

I got to work formatting the program. As a teenager I usually didn’t bother, but these days I try to make things a bit more logical. It’s easy enough to use a GOSUB to organize logic. Doesn’t hurt to add a comment or two using REM either. The result is a program that’s a little easier to read.

Cylinder, ZX81 Screenshot #1 by Steven Reid, 2025

# Plotting is so hard.
Although I couldn’t do much about the slowness of the program, I could fix another issue I ran into. The ZX81 plots from the bottom-left corner, which caused the cylinder to appear inverted. Not quite what I planned.

To get around that, I inverted the plots. Fortunately, that only required a bit of math. Instead of LET X1=X1/4.4 I did this: LET X1=64-X1/4.4. Not too difficult, but it looks a lot better. I also mirrored the Y-axis, although I probably didn’t need to.

Cylinder, ZX81 Screenshot #2 by Steven Reid, 2025

This got me to the point where I could test. Although the program worked, it was too big for the screen. To size the cylinder properly, I scaled down the plot points. Thus, the /4.4 in the code above. It fixed the display and kept the cylinder on screen.

# Adding a bit more interest.
Although the program looked decent, it was a bit dull. To spice things up, I added some randomness to the cylinder’s shape. This ensures that each new cylinder looks a bit different, turning the program into something closer to a screen saver.

To make the cylinder more interesting, I added a touch of randomness to a few variables:

1000 REM **SET VARS**
1010 LET D=1.95
1020 LET S=PI/10
1030 RAND 0
1040 LET UR=30+RND*70
1050 LET LR=40+RND*60

The UR and LR determine the twist of the cylinder and make it easier to see on screen.

Cylinder, ZX81 Screenshot #3 by Steven Reid, 2025

And with that, I wrap up this month's program.

---

Want to try it out? You can run the program, or view the code if you’d like to see how it works.

Fun with DATA — Building a Blocky World Map on the ZX81

Steven Reid — Sun, 28 Sep 2025 11:09:00 -0600

I’d seen a few different BASIC programs that print out a map of the world. Generally blocky, they still looked decent, but much of the data was too big for the ZX81—until I ran across a C64 version based on a Spectrum program. Examples in hand, I built a version for the ZX81.

# Beginnings.
When I first saw the Commodore 64 version of the block world map, I got the thought that it might fit on the ZX81 screen. I realized why when I dug into the listing. It was based on a Sinclair Spectrum program by Luboš Janku's which shares the same screen size as the ZX81. I was intrigued as other versions tended to be for larger resolutions.

On the positive side, the program was relatively short. Most of the length was in the DATA routines toward the end. I originally thought the program would be a series of data points that would be plotted. While converting, I realized it was instead a compressed screen image. Although not quite what I was looking for, it offered a challenge: how would I deal with the ZX81 BASIC not having DATA and READ commands?

World, Map Expanding, ZX81 Screenshot, 2025 by Steven Reid

# Approaching the lack of data—strings.
The lack of DATA is a long standing problem for the ZX81, even back in the eighties. Many of my books offered tips for converting other programs. The easiest, and partially the way I dealt with it, was to use strings.

Strings are a good choice overall. They offer flexibility since there are different ways to read the data out of them. The challenge is often understanding how the program will read and use the data. With a string, you can either read it in parts using slicing or as a whole. If you’re feeling particularly ambitious, you can even create string arrays. Although, that might waste a good amount of memory since all the string arrays have to be the same size.

The problem with strings is you basically store the data twice. Once in the program itself, and a second time when the data is read and loaded into the variable. This isn’t a huge problem on machines with more memory, but with the ZX81 it can be a challenge.

# Inputing into your variables.
To get around that, another way to handle data is to read it directly into variables. A text adventure interpreter I used to play with from a book used this trick. Basically, it had a loader program where it read the data through a series of INPUT commands. The data was stored directly in the variables for the program.

In addition to saving memory, it also meant you couldn’t list the program and see what the data was. A good choice if you are obfuscating your program. Just don’t forget where you placed your notes—it makes it hard to share anything other than the binary.

One other word of caution: you have to remember never to RUN or CLEAR your program. Doing so erases the variables. On the positive side, using SAVE on the ZX81 always stores the variables as well. Thus, this was often a good choice for large games that needed to save on memory.

# Peeking around the program.
Another way you can approach this problem is to store the code in a REM statement and use PEEK to read the data. I used this approach in an early version of Gem Quest where each REM held the tile graphics. It’s a bit trickier since you need to calculate the memory location. However, it has the advantage of saving memory and retaining the ability to list the program.

The disadvantage to this method is that you have to get each entry one byte at a time. This isn’t particularly fast. I was using some compiled BASIC with MCODER to get around the problem. You could also use a small machine language routine to speed things up. But if you’re going to do that, you might as well just write the whole thing in assembly. Kind of defeats the purpose.

# Reading strings.
The original program had data strings that were variable in length. It would read a line of data each time into a string array. Since the program was relatively small, I decided to just concatenate each of the data lines together into D$. Example below without the inverted characters:

1000 REM **DATA**
1010 LET D$="EEEDDNPPLCIBJBCIH."
1020 LET D$=D$+"DGEADABPPKBBCJBP
EMAEE."

The data itself is a compressed screen image. The structure is straightforward: a number displays a series of spaces, a letter displays a graphic block, and an inverted letter displays a number of inverted spaces. I’ve used similar compression routines myself, and this isn’t a bad approach. For the most part, I didn’t want to change the data. However, I did add a period to the end of each data string so the read would work.

To mimic the read, I wrote a small routine that basically copies each character into a new string, A$. I used a string index in variable L to know what to read next. That string would then be decompressed and displayed on screen. It isn’t super fast, but it works well enough:

 500 REM **READ**
 510 LET A$=""
 520 IF D$(L)="." THEN GOTO 560
 530 LET A$=A$+D$(L)
 540 LET L=L+1
 550 GOTO 520
 560 LET L=L+1
 570 RETURN

# Running the program.
After tweaking the print routine, the final program generated a decent world map. I think it looks pretty good on the ZX81, even if a bit slow. The program will pause for a bit before clearing the screen and starting over.

World, Map Done, ZX81 Screenshot, 2025 by Steven Reid

# Other thoughts.
There are a multitude of ways to approach the DATA command. Specific to this one, a better method would have been to place each line of the program as a string pointing to A$. Instead of tracking the string position, I would have tracked which line it was on. In this case, F from the FOR loop could be used to calculate which line to read from. Thus, the program would have looked like this:

500 REM **ALT READ**
510  GOTO 10*F+990
1000 REM **ALT DATA**
1010 LET A$="EEEDDNPPLCIBJBCIH"
1015 RETURN
1020 LET A$="DGEADABPPKBBCJBPEMA
EE"
1025 RETURN

This is much tighter, faster, and more memory efficient. Sadly, I thought of this after I understood how the program worked. Same goes for the compression algorithm. Now that I understand how it works, I’d probably tighten up the code a bit. In fact, I could probably remove the outer FOR loop and skip the READ altogether.

Overall, this was a fun program to convert and dissect. There is no right or wrong in programming as there are always trade-offs and compromises. I look forward to seeing the different ways people solve the same problems. Until next time!

---

Want to try it out? You can run the program, or view the code if you’d like to see how it works.

Speeding Up Truchet Tiles on My ZX81 with Machine Code

Steven Reid — Sun, 31 Aug 2025 10:34:00 -0600

Having finished my last Truchet tiles program in BASIC, I wondered how fast it would run in machine code. Soon afterward, I gave it a try, writing a version that runs significantly faster than the BASIC one. Let’s dive in and see how it works.

# Setting things up.

Turning Truchet into a machine language program was straightforward enough. After copying in my standard template, I stuck with the same looping concept I had originally used. The main loop of the program does just that—setting up the display locations and using the BC register as the X and Y loops.

mainloop:

ld de,(d_file)          ; grab display file
inc de                  ; add one

ld b,12                 ; height x 2
y_loop:

ld c,16                 ; width x 2
x_loop:

With that done, I randomly print a tile—more on that in a bit. The rest of the X loop looks like this:

push bc                 ; save loop
call print_a_tile
pop bc                  ; restore loop

call delay

; done with x?
dec c
jp nz,x_loop

Before closing out the Y loop, I need to shift the display down a row. I could have optimized this a bit to remove the push and pop, but it keeps things more readable. Notice that I jump ahead 34. That’s because each tile is 2×2 and I have to move past the end-of-line return character on the first row, plus the row beneath it (33 with return).

push bc
ld bc,34                ; jump ahead
ex de,hl
add hl,bc               ; to next row
ex de,hl
pop bc
; de at start of next row

; done with y?
djnz y_loop

jp mainloop             ; start again!

Truchet ML, ZX81 Starting Screenshot, 2025 by Steven Reid

# Printing the tiles.

With the setup complete, now I need to print the tile. First, I have the tile patterns defined later in the program:

; Truchet tile patterns
tile_1: db $06,$00,$00,$06
tile_2: db $00,$86,$86,$00

The print_a_tile routine uses these locations to decide which tile to print. After setting HL to point to the first tile, the program calls a simple 8-bit random number generator. I then compare the result with 127 to decide if I’ll print a different tile.

print_a_tile:

; get tile
ld hl,tile_1            ; set to 1st tile data
call rnd                ; get which tile
cp 127                  ; compare to 50%
jp m, print_tile        ; print first tile
ld hl,tile_2            ; set to 2nd tile data

At this point, DE points at the screen location of the tile, while HL points at the tile data. This is important since I’m going to use the ldi instruction to copy the contents at HL directly to the screen.

print_tile:
        ; de = display file location
        ; hl = tile pattern data
        ld bc,33        ; next row

       ; print 1st row
        ldi             ; print 1st char
        ldi             ; print 2nd char

At this point, half the Truchet tile is displayed. To print the bottom half, I move the display pointer down a line. Before I do that, I save DE since it’s already pointing to the correct location for the next tile, thanks to how ldi works. This is also why I set BC to 33 instead of 31. Here’s the code for the second row:

        push de         ; save display location
        ex de,hl
        add hl,bc       ; move to print tile
        ex de,hl

        ; print 2nd row
        ldi             ; print 1st char
        ldi             ; print 2nd char

        pop de          ; restore location
        ret

Truchet ML, ZX81 Screenshot, 2025 by Steven Reid

# It’s so fast!

With the primary routines complete, running the program uncovered a bit of a problem. It was too fast! Odd to say on the ZX81, I know, but I needed to slow things down a bit. I added my default delay routine, along with a break check, to finish the program. The final version was still faster than the BASIC one and very pleasant to watch.

Now that it’s running smoothly, I’ve been thinking about ways to use it. With a less random routine—say, a memory pointer to ROM—I could make this into a scrolling background. That would fit nicely in a shooting or jumping game. Fun for another day.

---

Want to try it out? You can run the program, or view the code if you’d like to see how it works.

Exploring Truchet Tiles on the ZX81 with BASIC

Steven Reid — Sun, 13 Jul 2025 23:40:00 -0600

Sometimes ideas drop right into your lap. In the case of this month’s program, it was a mix of a post and a video that led me to this Truchet animation. A simple concept, but it worked way better on the ZX81 than I expected.

# So those diagonal lines were Truchet tiles.

I’d read and written here before about the single-line “10 PRINT” program. What I didn’t realize was that the diagonal lines used in the Commodore version were actually the Labyrinth variation of Truchet tiles. The video I watched opened my eyes, and I was intrigued to do something similar—but with my own twist!

Since the ZX81 doesn’t natively support user-defined graphics (UDGs), I took a different approach. This is where the BASIC program that was shared sparked an idea. Instead of a single character like before, I decided to use a 2x2 tile. This gave me a bit more flexibility… but only a little. The ZX81’s character set is still pretty limited.

# I kept the code simple and fast.

Using the quarter-circle form of Truchet decoration, I landed on using two different tiles. In real life, it would just be a single tile rotated. I thought of a couple different ways to print the design, but ultimately went with the straightforward approach: generate a random number and use a conditional. Here’s the rough code used:

LET R=INT (RND*2)
IF R=0 THEN PRINT AT X,Y;”/ “;AT X+1,Y;” /”;
IF R=1 THEN PRINT AT X,Y;” ";AT X+1,Y;”\ “;

I used the ZX81’s graphics characters instead of the slashes, but you get the idea. The rest of the program is a loop that fills the display with tiles. I would’ve preferred more circular graphics, but had to work with what was available. To my surprise, the patterns looked really good.

Truchet, ZX81 Screenshot, 2025 by Steven Reid

# Why those last two lines had to go.

Unlike some of my previous programs that scrolled the display, this one redraws the entire screen with new random tiles each time through the loop. The result is an ever-changing pattern, an idea I borrowed from the example I saw. I hadn’t tried that before, and it worked well with the simplicity of the design.

The two blank lines at the bottom of the screen bugged me. There is a way to remove them, but I usually don’t bother. This time, though, filling the screen felt important. I considered poking the display memory with tile characters, but discarded that idea—it would have required math that would slow things down.

Fortunately, there’s another way.

On the ZX81, there’s a system variable that controls how many lines are reserved at the bottom of the screen. Setting that variable to zero with POKE 16418,0 effectively expands the vertical display by two lines. I hardly ever use this trick in BASIC since it can cause issues with scrolling. But in this case, scrolling wasn’t a problem.

This solution was elegant: the only change I had to make was adjusting the FOR loop range. I ran a few tests to see if breaking out of the program would crash the system. It didn’t—and I decided it was worth using. This trick has been around since I was a teenager and shows up in a few of my old books.

# Wrapping up with more tile ideas.

And with that, I had a very simple tile program. I did try a few other designs just to see what worked. It’s not overly hard to add more tiles—I even made a version with four—but the ZX81’s limited character set didn’t play nicely with most of them. Feel free to try your own variations!

As mentioned earlier, I could’ve also used an array to avoid the IF conditionals. I didn’t go that route, but I’ll leave it as a challenge for someone else.

Now, something I might do is convert this into a machine language version. Not only would it run faster, but I could use it inside a larger, more complex game. Interestingly, I learned after the fact that a few strategy games have used these same quarter-circle Truchet tiles. The patterns also seem like they’d make great backgrounds for other games.

I’ll end this one with more ideas running through my head. Let me know what you’d like to see me build next!

Want to try it out? You can run the program, or view the code if you’d like to see how it works.

Recreating Font Art on the ZX81—With Some Limits

Steven Reid — Sun, 29 Jun 2025 11:06:00 -0600

It’s funny how a random video can spark an idea. One moment I’m watching someone play around with ASCII art, and the next I’m thinking, “Hey, I could make something like that on the ZX81.” That little spark turned into a weekend project: a simple banner program using different fonts. How fun!

# The Idea

I have fond memories of creating art using typewriters and characters. We had a typewriter in our house when I was around 8 or 9, and I remember spending hours just typing on it. Once I got into D&D, I used it extensively to write up character sheets and campaign ideas. But I also used it to generate doodles and art—TIE Fighters and cartoons were a staple.

It should be no surprise that some of my first computer programs were character art. I still have a Medusa head lying around somewhere from the PDP my school had. Terminals and consoles notoriously lacked graphics—or at least support from most programs for them. As such, ASCII art became a common way to create doodles and fun images.

# Fast Forward

In the ’90s, there was a resurgence—or perhaps an organization—of online ASCII art creation. During this time, entire fonts were created using basic characters and symbols. I came across a great example of these FIGlet Fonts, which got me thinking about using them in a program.

Fun Fonts: 3-D, 2025 by Steven Reid

The ZX81, with its blocky characters, was ripe for this kind of art—especially if you wanted to do anything visually interesting. Sadly, it lacks many of the standard characters that FIGlet fonts use, such as the backslash and apostrophe. Even the hash symbol (often called pound) and the exclamation mark are absent from the ZX81’s character set. Sad times.

# Making Do

Not to be deterred, I decided to give a few of the fonts a try. Creating a simple font display program, I was able to recreate a few using “ZX81” as the sample text. Some fit nicely on screen, but others required scrolling to get the full effect. To save space, I only reproduced the letters and numbers needed. Maybe a full-font program will be a future project.

Fun Fonts: Alligator 2, 2025 by Steven Reid

I tried to use fonts with characters already available. For a few, I adjusted the characters where needed—for example, swapping out the hash symbol for the literal pound symbol. I think the fonts worked pretty well and look decent overall. A few spacing issues popped up since the ZX81’s pixels are more square than rectangular. I adjusted a few fonts to make the letters cleaner.

# All Done

The program itself is modular. You could easily add more examples or swap in different display techniques. I used string slicing for much of the display. The effect is slow in BASIC—so slow that I moved from printing each line individually to using a buffer technique to avoid jarring lag during rendering.

Fun Fonts: USA Flag, 2025 by Steven Reid

A more practical use for this program might be as an intro screen for a game. That said, I’d probably redo it in assembly for better speed. Having a complete font set could be fun for a banner program, but memory constraints would be a challenge. Alternatively, you could use the ZX81’s graphic symbols to make something even more visually compelling.

What ideas do you have?