Back in the day I learned to program on school PDP-11 with a 6 teletypes and a CRT attached. I was still in computer club at the time, thinking the 8" floppies were pretty cool. To my despair, the poor thing died that Summer and, when I took my programming class, it was on an Atari 800. But the programs I wrote the previous year stuck with me. Printer Car harkens back to those days.
Typewriters and teletypes.
I grew up learning how to type. My dad brought home an old Royal manual when I was like 9 or 10. I spent that time learning to type, often creating D&D player sheets. But I also created pictures, or typewriter art. It was a fun way to pass the time.
Fast forwarding a couple of years. One of my friends, who was a year older, showed me some printouts of the computer programs he was writing. I was hooked. The yellow paper of printed text reminded me of earlier experiments on my typewriter. I couldn’t wait until I was in sixth grade to try it myself.
A year later, I had signed up for computer club and was playing on that PDP-11. My computer teacher provided me a BASIC manual and I started to write programs. Of course, I did what I knew. I created pictures!
It wasn’t long before I wrote real programs. Given this was on a teletype machine, the printouts were like the art I made on my typewriter. As the teletype printed each line, it advanced the paper, scrolling it up. I still have my medusa printout somewhere. It was a simple program, but it was a start.
And then there were printers.
Of course, a year or so later I had my own computer and was writing programs on it. It was a ton of fun and, at some point, I owned a printer. I’m not sure if it came with the computer, or was a later gift. Given I didn’t list old programs, I’m guessing the later.
In any case, it was a TS204 printer and used rolls of paper. Sound familiar? Yep, this printer didn't use paper sheets, but rolls like that old teletype. Yet, it wasn't quite the same given it was a spark printer instead of the ink of the teletype.
This leads to a different look and quality, but it works. Well, most of the time. My printer stopped printing two columns of information at some point. The printer has two heads and, given the other columns show, I’m guessing something came loose.
Now, I didn’t neglect my printer. Besides listings, I wrote many programs that printed to the screen. Some were art screenshots using the
COPY command. Others, such as Tabular, used sophisticated hacks. Yet, Printer Car, were a homage to those teletype days.
Games on printers.
Of course, the ZX81 isn’t a teletype machine. Like most home computers of the era, it was designed to work with a TV. In the ZX81’s case, it was a black and white television. Dot crawl and screen artifacts were normal and part of the experience.
Yet, the ZX81 could print lines of to the printer as well using
LPRINT. Unlike the display, I didn’t need to use
SCROLL since the printer advanced on its own, like the teletype did. Inspired, I wondered if I could write a game for it.
Printer Car isn’t unique, designed as a simple wall dodge game. I’d played many of other games written like it, along with writing my own. But this one was different. This one used the printer as a display, much like games I’d written for that PDP-11.
Of course, the printer isn’t very fast. Even as close as the walls are, the game isn’t hard. Yet, it does play very much like it would on the screen. Each line of data is printed and then, using the keyboard, you move to avoid the walls.
If you can survive a 100 lines, you win! If not, you crash and start over. To my surprise, it all works very well. I even tried it out using my emulators printer. Mimicking the old TS2040 or printer, it played pretty much like I remember it did. Fun times.
Printer Car, circa 1983, ZX81 Gameplay by Steven Reid
After the fact complexity.
The program’s code is short and sweet. Using a simple loop, Printer Car displays each line and then checks if you moved. If you hit a wall, the game ends. If you don’t, it keeps looping until you win or crash.
The original code could use a little optimization. It has some duplicate code in it that I could tidy up. Otherwise it is straightforward and readable program. Yet, the program stops when it ends, requiring you use
RUN to play it again.
The program here, then, allows you to choose which mode to run. By default, it will use the screen, but if you load it up it will ask you if you want to use a printer. If so, the game plays much like the original game.
If you decide to use the screen, it required a bit more work to emulate the printer. Usually, the ZX81 doesn’t automatically scroll the screen when full. Instead, you have to use the
SCROLL command to make text move from the bottom up.
Printer Car, circa 1983, ZX81 Screenshot by Steven Reid
Switching out the
SCROLL to each line. Even worse, the way
TAB works is a bit different. I kept getting memory errors playing the screen version of the game. After some testing I realized that the
TAB was causing the line to advance, even if it wasn’t printing anything.
To correct the problem, I used
PRINT AT to fix the memory issue. I thought it would slow things down, but I didn’t notice any difference. With all the errors gone, I now had a mirror copy of my game working on the screen.
That said, the program is now much larger and more complex. A good portion of the original version was dedicated to printing lines. Even with a few optimizations, the new code was still complex. The new program was almost twice as big.
For better or worse.
Even with the modification, the game didn’t need much tweaking. Outside of a few optimizations noted above, I don’t think I’d change much. I thought I could remove that extra
LPRINT that adds double spacing. I added it later given it has a a line number not ending in zero.
Thinking about why it was there, I’m sure I added it to advance the paper up enough to see it. The TS2040 printer head was below the case line. I’m assuming I needed to advance it a bit to make the game playable. Thus, it is an oddity that was practical at the time.
The only other thought would be to create a variable wall or add objects to dodge. That would make the game more playable, but given the medium, it wouldn’t make a lot of sense. Perhaps for a screen based game, but as written it works fine.
Plus, the program was meant to be simple. I designed it to emulate a typewriter, not a TV. The game isn’t quite the same as the teletype didn’t have an
INKEY$ function. You had to hit enter to get it to scroll. As such, Printer Car is an experiment—a “what if” game. As that, it does an exceptional job.