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.

Bringing My Atari 2600 Joysticks and Paddles Back to Life

Steven Reid — Mon, 16 Feb 2026 11:37:00 -0600

I recently got back into retro hardware. My starting point was gaming, as I ordered one of the new Atari 7800s that plays the old cartridges. In my haste to grab a few games, I inadvertently purchased a complete 2600 with controllers. I’ll blame travel and lack of sleep for missing that detail. But it gave me the opportunity to attempt something I’ve never done before: restore the controllers.# Assessing the condition.

The controllers that came with my purchase weren’t in the best shape. Both joysticks were missing their rubber grips. The fire buttons were okay, but not great. Most of the paint had worn away. These were well-used sticks.

On the positive side, I tested both and they worked well. That gave me hope.

Atari 2600 Controller Restoration by Steven Reid, on Flickr

The paddles, on the other hand, looked decent aside from a minor scratch on one of the labels. Unlike the joysticks, however, they worked horribly. I remember the paddles always being a bit fiddly—but not this bad. Trying out Warlords, neither paddle moved smoothly, making the game nearly impossible to play.

Atari 2600 Controller Restoration by Steven Reid, on Flickr

After watching a few restoration videos and finding replacement grips on eBay, I felt confident enough to tackle the project.

Atari 2600 Controller Restoration by Steven Reid, on Flickr

# Taking apart the joysticks.

I started with the joysticks. The first order of business was to disassemble them so I could wash the cases. Although not horrible, the cases and cables were grimy.

This turned out to be the easiest part. A few screws later, I had both joysticks broken down.

Atari 2600 Controller Restoration by Steven Reid, on Flickr

Atari 2600 Controller Restoration by Steven Reid, on Flickr

One thing I noticed while taking them apart was a plastic rim that the sticks come into contact with. On both controllers, the lip around the inner hole had broken. This was most likely from pushing the stick too hard in one direction—something not unusual if you’ve played Atari 2600 games. You can see the damage more clearly below.

Atari 2600 Controller Restoration by Steven Reid, on Flickr

Since I removed the cords from their shells, I took a picture of the connector layout so I would know the order when reattaching them.

Atari 2600 Controller Restoration by Steven Reid, on Flickr

This turned into a lesson. Although they came apart easily, I ran into connection issues after reassembly. If anything, don’t bother disconnecting the wires unless you absolutely need to. I could have easily cleaned everything with the boards still attached.

# Joystick cleaning incoming.

With them torn down, I cleaned each one with simple soap and water. I used a cloth to clean the cords and a toothbrush to get into the tighter spaces. Overall, it went really well. I ended up with two nice, clean sticks.

One thing I noticed was that each joystick had a number written on it. I was careful not to rub this off to preserve a little character. I’m sure millions of these were made and these are probably just inspection numbers, but to me it gives them some uniqueness.

Atari 2600 Controller Restoration by Steven Reid, on Flickr

The boards themselves were in good shape. I checked the contacts and the dome switches were all fine. I decided not to do anything further with them.

# Tackling the paddles.

While those dried, I worked on tearing down the paddles. This required a bit more effort, as they have a few more parts to them. Sadly, I didn’t grab a full teardown photo, but you can find videos online that walk through it.

Atari 2600 Controller Restoration by Steven Reid, on Flickr

Beyond cleaning, I also needed to refurbish the potentiometers. This meant carefully opening them up so I could access the internal contacts.

Atari 2600 Controller Restoration by Steven Reid, on Flickr

My next step was to clean the gunk out of them. I used cotton swabs and isopropyl alcohol to remove the grime from inside. There was quite a bit of buildup from years of friction and dust.

Once done, I focused on the cases, cleaning them the same way I did the joysticks with simple soap, water, and elbow grease. With that complete, I reassembled everything.

# Making the joysticks look new.

With everything back together, there was one final thing to do. The paint on the joysticks had completely worn off.

I pulled out my wife’s acrylic paints and went to work finding a match. To my surprise, she had a set of acrylic paint markers. I found a bright orange that worked perfectly. After shaking them up, I got to work—and they turned out great.

Atari 2600 Controller Restoration by Steven Reid, on Flickr

Atari 2600 Controller Restoration by Steven Reid, on Flickr

# A few problems before wrapping up.

As a first restoration project, I’m really happy with how everything turned out. They look fantastic, which was my primary concern. The paddles worked extremely well—better than I expected.

The joysticks, however, were a bit of an issue.

During reassembly, I discovered the internal connections are fairly fragile. They didn’t grip firmly when reattached. I ended up taking them apart multiple times trying to improve the connection. One attempt at crimping even broke a lead, so I decided not to push it further.

Lesson learned: if you don’t need to disconnect something, don’t.

Regardless, I’m extremely pleased with the restoration. They look good, work well, and fit nicely in my collection.

Atari 2600 Controller Restoration by Steven Reid, on Flickr

Hopefully the next hardware project goes just as well.

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.

My Retro Computing Binge, Falling Back in Love With Hardware

Steven Reid — Sat, 17 Jan 2026 09:53:00 -0600

Lately I’ve been on a binge — a retro computing hardware binge. It started last year when I went searching for a working Timex Sinclair 1000. The idea was simple. Set it up and run my own programs on real hardware again. What began as a hunt for one machine quickly turned into something bigger.I have fond memories of programming my ZX81, and the thought of seeing my code run on real hardware stuck with me more than I expected. I’m not there yet. The Timex Sinclair is still sitting in its box in my office. But that’s the part I’m working toward. I want to plug things in, load my programs, and watch them behave the way they did when I was a kid. Showing them off to my parents and anyone else who wandered into the room.

Once that idea settled in, I started looking for ways to make it real. That’s where modern retro hardware and a certain familiar name pulled me in.

# I blame Commodore.

Well, probably not really. But it did kick-start things again. LEGO didn’t help either with their Atari and Nintendo sets. Seeing the new hardware Commodore had, I was very tempted to get one. It looked like my old C64 from my teenage years, but didn’t require me to figure out how to connect it to a modern TV — one of the reasons my Timex Sinclair was still in the box.

I was still working on finding the parts needed to get that other hardware running. I still have all my ZX81 tapes from when I was a kid. I bought a new cassette deck a few years back to play them into my Mac, replacing the bulky boom box I had been using. Loading those old programs from cassette was what started my ZX81 blogging. The high-pitched squeal of a program loading from tape was music to my ears. I wanted to find a way to recapture that moment.

First, I needed a way to connect it to a modern TV. I started looking for ways to convert old RF signals into HDMI. I found a few devices, now on order, to see if they work. Yes, I could do a composite modification, but my problem had grown — I had other machines I wanted to experiment with too.

With those thoughts still in my head, I finally pulled the trigger on a new Commodore. It arrived this week, but I’m traveling, so my experimentation will have to wait a little longer.

# More retro goodness with Atari.

Another console pushed me back toward the Atari VCS. I had bought a modern version of the VCS housed inside a joystick a few years back. It was fun to play the old games, but it lacked the nostalgia of the original hardware. I missed having physical cartridges to shove into the deck.

My original Atari was long gone, given away years ago. But a new FPGA version had shown up on the market that not only let you use original games, but also worked with modern TVs. I added it to my wish list months ago and, after the new year, finally pulled the trigger. I chose the modern 7800 mainly because I liked the more compact shell.

At the same time, I picked up a handful of untested games off eBay. They all arrived together, which led me down a small rabbit hole of plugging in the console, lightly cleaning the carts, and giving each game a try. It had been over thirty years since I last held an Atari cartridge, and it immediately transported me back to being a teenager in my parents’ basement, trying out the latest Activision release. I was hooked.

# Being young again.

Perhaps the thrill of getting that first cart to load helped, but I had a fun few hours. Just like I remembered, the games didn’t always fit right. I had to finagle a few to get them to open their dust doors. I made sure they engaged well, just like I would as a child. The 7800 console was easy to set up, and the wireless joystick was a real quality-of-life upgrade.

A big win was that almost all the games worked, with only one giving me trouble. I’ll work on cleaning it later. At that moment, it didn’t matter — I was having fun. I loaded up Donkey Kong and immediately started playing. More than forty years later, I still knew how to start the game and work through the levels.

After shaking off the rust, I was able to get the ladder timing right again and work my way through the first level. The timing of the jumps took a moment to return. I kept jumping too early and landing on barrels. As the rust fell away, I finally cleared the stage.

The second took more effort. I never had a single pattern, so remembering how to clear the bricks and evade the fireballs took longer. Muscle memory kicked in and, after a few playthroughs, the gameplay came back. It was like the decades melted away, and I started enjoying each game as I tested it.

# More nostalgia ahead.

Not content with just the few games I had, I ordered some more, not realizing the lot also included an original Atari. Apparently, you really should look at all the pictures when ordering off eBay. In any case, I soon had another set of games to try out. Included, to my delight, was Asteroids.

This may sound silly, but I love the original 2600 version. Yes, the sprites are simple and flicker, but I still remembered how to play. I selected game 17 — I prefer the fast flip instead of warping — and proceeded to play. Being one of the earliest games I remember, I have fond memories of sitting in my room playing Asteroids. Like my younger days, I quickly racked up points and flipped the score. The first time I did that, I remember running to tell my parents.

The Atari console itself looked good but needed some cleaning. Once I get my composite connector, I’ll see if it still works. I also need to fix the controllers — they were missing the rubber covers. I ordered a pair that arrived this week while I was traveling. The paddles work, but they’re a bit wonky at times. I’ll see if I can clean them up as well.

# A new idea formed.

With all this modern-retro fun, a bigger idea started to form. I wanted to collect a few different computers from the eighties. I fondly remember going to each of my friends’ houses and trying different machines. Everyone had something different. It was great fun to try each other’s games and see how they all worked.

I programmed on an Atari 800 at school, and my best friend owned an Atari 800XL. I learned on an Apple ][ in high school. I owned a Commodore 64, 64C, 128, and Amiga over the years. All of those are now long gone and high on my list to acquire and display. Each one adds to the memories I’ve collected along the way.

I hope to mount them behind me in my office as a reminder of where it all started. Not as museum pieces, but as working machines with stories still left in them. In the next article, I’ll start cleaning, restoring, and figuring out how to actually display this growing collection and, of course, see which of these old friends still power on.

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.