By Mikey Walters / September 6, 2016

This is the first in a series of articles about programming in Atari BASIC. Space Assault source code and references can be found here.

10 PRINT “Introduction”

When someone chooses a computer to purchase today, they usually consider only what the computer can do based on available software. They’re thinking about what games they can play, what kinds of entertainment media they can enjoy, and how fast they can access the web. But in the 8-bit home computer boom of the late 1970s and early 1980s, choosing a new computer was based largely on what kind of software you wanted to create yourself. Kids who grew up in that era were part of a DIY software revolution that we may never see again, a time when nearly everyone with a PC at least dabbled in programming. We selected our computers based on what programming languages were available, based on graphics and sound capabilities, and worried if we needed to spring for 48K of RAM. I thoroughly enjoyed being part of that time, and it paved the way for my 25-plus-year career in software development.

My pride and joy computer of childhood was the Atari 800, and, after learning how to accomplish a few things in Atari BASIC (the programming language provided by Atari via cartridge), I decided to write my own games. I wrote quite a few, using techniques I learned from the many programming magazines and books of the time. All of my programs have been lost to time except one, because I was lucky enough to have the source code for my game Space Assault published in ANALOG Computing magazine in September 1983, which was quite exciting! In 2013 I was able to resurrect the game by using an Atari 800 emulator on my MacBook Air, which meant typing in the entire source code line by line, just like anyone who bought the magazine over 30 years ago had to do.

I recently realized, while talking shop with my younger coworkers, that most of them had no concept of what programming was like at that time. Even my boss didn’t realize that people would diligently type in source code from a magazine to try out someone else’s software masterpiece. Being a web developer now and relying on the browser to handle so much user interaction, I can certainly understand how my coworkers would be baffled by concepts like reading joystick positions in a main loop or drawing a game playfield by plotting it one pixel and line at a time. It made me think that a series of articles on “ancient programming” would be interesting to write and, hopefully, interesting for others to read.

In each segment of “Adventures in Atari BASIC,” I’ll dissect the source code of Space Assault to demonstrate what amateur game programming was like in the early 1980s. I’ll try to remember what I was thinking and what decisions I made while I was developing the game, and along the way we’ll learn about fun things like graphics modes, player sprites, and sound generation. I won’t actually be covering the fundamentals of the BASIC language or how to get an emulator running on today’s hardware platforms, but I’ll provide some references to some of the materials that helped me learn as a teenager. (A link to both the references and the Space Assault source code will appear at the beginning of each article.)

20 PRINT “About Space Assault”

Before we get started, it might be helpful to know a little about the game. You can read the backstory I came up with in the ANALOG article, but here’s a quick overview. The object is to protect several bases from enemies that fly horizontally across the playfield. You move a crosshair with the joystick, and fire a laser weapon to fight three kinds of ships. Enemies fire down on your bases, and when all of the bases are destroyed, the game is over.

Obviously I was a fan of Missile Command (1980), so I borrowed the city protection and crosshair aiming aspects, but I swapped out ICBMs for enemy ships since I wanted to create player sprites. I enjoyed the “tedious” work of drawing the playfield (stars, bases, and laser tower), designing sounds for lasers and explosions, and I even added a title screen with a snippet of music borrowed from Disney’s The Black Hole (1979). When the game was finished, I think I was most proud of the earthquake effect when a base is destroyed, which I’ll cover in a future article.

I think most amateur game designers at the time had similar goals in mind. First, create something you actually want to play. Second, keep the design simple but add a few technical challenges to improve your programming skills. And third, take advantage of shared techniques to make something better than you could on your own. Because I could play Missile Command at any time by popping in a cartridge, I wanted to try out my own unique variations on Space Assault to see if I could do it. I had a little experience with player sprites, so I knew I could make them work, but I wanted to make them faster using a routine I had read about in ANALOG Computing #10 (just a few issues before my game was published). Despite not having the internet, the amount of available reference material to teach and inspire was amazing. It did require, however, a healthy allowance and multiple trips to the local computer store!

30 PRINT “Random Stars”

Now, let’s actually look at some code. Before the action begins, the playfield must be created. Space Assault’s playfield is mostly black with a few purple stars. Today you might Google for a photograph taken by the Hubble telescope and reference that in your code, but in Atari BASIC, everything is drawn from scratch. Here’s the code that draws the stars:

First, the GRAPHICS command sets a display mode for the game, which gives us 160 by 96 pixels to work with (quite different from the fairly minimal 1024 by 768 average today). Next, the SETCOLOR commands set up three colors (gray, purple, green) for us to work with later, and the COLOR command selects a color (purple).

Now we use a FOR loop to do something 50 times. In this case, the PLOT command says to fill in a single pixel at an X,Y coordinate, and we use the RND command to select random horizontal (X) values from 0 to 159 (the full width of the playfield) and random vertical (Y) values from 40 to 95. Since 0,0 is the top left of the screen, we are avoiding putting stars in the upper half of the playfield. I originally had stars filling the entire screen, but, as we’ll see eventually, we’re going to be drawing and erasing a laser beam in the top half of the screen, which accidentally erased stars and looked funny. This is a great example of a design decision made during development in which “good enough” was fine with me.

So far the playfield isn’t very impressive, but we did manage to draw 50 stars with only a couple of lines of code. In my next article, we’ll flesh out the playfield with our bases and some terrain.

Mikey Walters lives in Austin, Texas, and has an entire room devoted to toys, including Mego figures, Japanese kaiju, and over 1,000 PEZ dispensers. He spends his time thinking about how great it is to be a geek who grew up in the 1970s.