Hoo boy. Building this one was a doozy.

This is probably the game in the book that intrigued me most as a nine year old when I first borrowed this book from the LaGrange Public Library. It’s the one that most resembled a game I was familiar with, in this case, Space Invaders. An interesting note about that, is that this book was first published in April 1978, and Space Invaders wouldn’t see release for several more months in North America. This game though, as you’ll find out, is much more primitive than Taito’s masterpiece.

As you might gather from a cursory glance at the above diagram from the book, the “stormtroopers” descend slowly towards the player square and the player must clear the screen of the enemies before they reach the bottom, and avoid being shot all the while. The stormtroopers fire after a brief interval, initiated by the player square crossing their line of sight. A potentiometer controls the player square, giving brisk movement, and the shots are instantaneous for both the player and the stormtroopers.

A simple game such as this could probably be programmed in less than an hour on a modern computer by someone with even modest coding skills. But in the world of discrete transistor-transistor logic? Just look at this mess:

And if you’ve read the other parts of this little series, you’ll know that this wasn’t built without A LOT of trail and error, troubleshooting, and conspicuous bodge work. One thing I made sure to check this time as I was plugging in the schematic into EasyEDA was to check the pinouts labeled in the schematic against the datasheets for the ICs. The author seems to have had a nasty habit particularly with getting the pinouts confused on 7402s. Checking to make sure the pinouts were labeled right saved me hours of nonsense that would have been created if I just had the PCBs printed based strictly on what was listed in the book.

HOWEVER – as I’m sure you can guess – there were still lots of other problems that merely checking the pinouts couldn’t solve. The first problem I noticed was in regards to the descent of the Stormtroopers. They were moving far too fast down the screen. This was supposed to have been controlled by way of the VRST signal driving a couple of binary counters. The book clocks the time it takes the stormtroopers to reach the player at roughly 60 seconds. With the design given in the schematics, however, this descent only takes 6 seconds. My solution was to bodge in an extra 555 timer with a potentiometer so the rate of descent could be controlled, lasting anywhere from 6 to 60 seconds.

The second problem that gave me quite a headache was an issue with the player laser. When the fire button was pressed, the entire screen would flash white for the duration of the laser. This problem proved to be much more complicated than any issue I had previously worked with in these projects. This wasn’t an issue that could be solved by changing a single variable (as in the descent timer) or just fixing up some confused pinouts. This was a problem with the design of the logic itself. A daunting task for a self-taught electronics hobbyist, and one that definitely required taking a break from the project in order to collect thoughts and think of ways to work towards solutions (you know, other than just going on r/AskElectronics and asking “Hey uh, why doesn’t this work?”).

What I did first was to narrow down where the laser display signal was coming from. This was done fairly easily, since the write-ups describing the circuits are fairly well done in the book, and indispensable for a novice like me. The player laser display signal was being OR’ed together with the stormtrooper display signals through IC 7 on the control board (a 74LS02). I lifted the output pin, and wired the signals to jumper wires so I could mess around with them on breadboards. It turned out these signals needed to AND’ed together, not OR’ed. I also added in a timer to keep the laser onscreen for a few extra microseconds.

Last problem ended up being the easiest to solve, with just a single junction missing from the schematic. This had to do with the elimination of stormtroopers after being shot. When a stormtrooper was shot, another one would also disappear, as if the last four stormtroopers were a repeat of the first four. Just poking around on the board a bit uncovered that all that was missing was connecting pins 1 and 15 together on the 74155 multiplexer IC in the stormtrooper section.

And here’s me joyously showing off the progress I had made immediately following this fix:

BUUUUUUUT I wasn’t done yet! Soon after I posted this video, I signed up to show off my work at a Maker Faire local to me (Rochester, NY to be precise), and I just couldn’t have a video game without sound or scoring! These designs, luckily, were much simpler than the entirety of the Stormtrooper Attack game logic board. On the sound board, I couldn’t get the noise generator to operate as described in the text, but since the rest of the board worked just fine, I didn’t sweat it too much. You can use the V-counts from the video generator board to create simple tones of the same note in different octaves (which is pretty wild that it just…. works that way), but I wanted just a little variety, so I used a 556 timer to make a couple different tones. I also learned about voltage dividers in bringing the 9V tones created by the 556 down to a level that was workable with the 5V circuit controlling the timing of the sounds.

The scoreboard gave me a little bit of trouble, but compared to the game itself, I was able to figure out without too much trouble. Turns out one signal needed to be inverted (a mistake in the original schematics), and all was dandy after that. There’s still a little bit (well, ok, a lot) of ghosting around the boxy digits, but it’s legible, and at this point, it’s good enough for me.

I took this build and the tag game with me to the Rochester Maker Faire, and people seemed to like it! I struck up a lot of great conversations with brilliant and curious people. If you happen to have one of these in your area, go. It’s pure joy. Anyway, I noticed something about the Stormtrooper game as it was being played by folks at the Faire. First off – it was way too hard. I was so focused on the rate of descent of the bad guys, but not the rate of fire from the bad guys. The bad guys currently fire within 1/4 of a second after sensing you in their sights. Since I was the only one playtesting, I had thought nothing of it, and learned to whip the potentiometer pretty quickly to make my shots. Turns out that isn’t really an intuitive reflex to folks who haven’t played hours upon hours of Kaboom on the Atari 2600.

Another issue I noticed, is that there’s a lot of noise in the player’s laser signal, which can result in a sort of unintentional spray fire upgrade. While it certainly helps as a sort of handicap for less experienced players, it’s far from my intention for the game. I’ve yet to discover the source of this noise definitively, but my hunch is that it has to do with the rush job I did for the game controller, using wires that are too long, unshielded, and twisted together. I don’t remember the player’s laser suffering video noise before I added the custom controller. I’m sure I’ll eventually figure it out. For now, here’s a short demo of the game in its current state:

Oh, and here’s the little flyer I made for the game at the Maker Faire. Even though the controller may be interfering with performance, I’m pretty proud of the simplistic retro style of what I built:

Next time, I attempt the Pinball game. *cracks knuckles*….