Transcription

Your support is greatly appreciated! https://www.patreon.com/8blit

introduction Long before gaming consoles had cheap, micro-sized Bluetooth keyboards with RGB lighting, the Atari VCS brought us the Keyboard Controller, Video Touch Pad, and the Kid’s Controller. In this episode, we’ll explore its origins and technical design, then show you how to bring all these to life in your own homebrew game.

patreon This channel is supported by viewers like you. Make a real difference, today. Our patrons’ monthly contributions, even just a few dollars,fuel the time, energy, and resources it takes to create quality episodes like this one. Join them now and be part of making the next episode possible. You’ll find the link waiting in this episode’s description. Thank-you for being part of this journey!

origin Ten months before the Atari VCS was released in 1977, the RCA Studio II beat it to market. It was pretty terrible, but it did feature two built-in 10 button key pads. Possibly the first of its kind on a console game system.

In hindsight, they may have been ahead of their time — just a year later, the Magnavox Odyssey 2 debuted a built-in keyboard, and Atari took things a step further with the CX-50 detachable wired Keyboard Controllers.

Soon after, Mattel’s Intellivision included key pads directly on their hardwired joystick controllers in 1979, and a couple years later the ColecoVision basically directly copied Intellivision with their implementation of the combination joystick-keypad controllers in 1982. With the release of the bundled pair of CX-50 keyboard controllers in 1978, came three new games specifically created for the controller. Brain Games – a collection of memory games where you need to remember the order of things, or button presses like the game of Simon. Code Breaker – up to two players where one creates a secret code, the other has 12 chances to crack it. And finally Hunt & Score, which was strangely renamed two years later and sold as “A Game of Concentration.” You’re given a field of squares, and each turn you select two to see what’s underneath. If you find the most matching pairs then you win.

In 1980, Atari released a version of “Basic Programming” for the VCS. Presumably to better position the VCS as a competitor to computers, like the Apple II.

Despite its utter terrible-ness, the “Basic Programming” box included the first button overlays for keyboard controllers. They featured visual markings for buttons, or combinations of buttons to perform basic instruction input, cursor movement, and menu navigation.

The controllers could also slide together to form a single 24 button keyboard allowing you to see all the functions in one place. To my knowledge, there’s no other carts that benefit from the controllers sliding together.

Additionally, Basic Programming would be the ONLY game to use button overlays for the CX-50 Keyboard controllers on the Atari VCS. Through 1982, a total of eight games were compatible with the Keyboard Controllers. One of them being Star Raiders.

Star Raiders was first created for the Atari 8-bit line of computers in 1979, and later ported to the Atari VCS (now referred to as the Atari 2600) in 1982.

While the game is fully compatible with the CX-50 Keyboard Controller, it was actually bundled with the CX-24 Video Touch Pad—a peripheral that was electronically exactly the same as a Keyboard Controller, with the only difference being the design of the outer shell.

The Video Touch Pad was created and marketed in 1979, but was never sold until it was included along with Star Raiders. In fact, it was never sold separately, and no additional button overlays were ever made for it, other than those included with Star Raiders.

In 1983, Atari wanted to make the Atari 2600 more accessible to preschoolers, so in partnership with Sesame Street’s parent company, the Children’s Television Workshop, they released four games, along with yet another Key Pad controller, the CX-23 Kid’s Controller.

This controller was much larger, with larger key pads for kids’ smaller hands, and each of the games came packaged with a brightly colored overlay featuring Sesame Street characters on them.

These games were Alpha Beam with Ernie, Big Bird’s Egg Catch, Cookie Monster Munch, and Oscar’s Trash Race.

Like the CX-50 Keyboard Controllers and the CX-24 Video Touch Pad, the CX-23 Kid’s Controllers are electronically the same as the other two inside the shell, and all are interchangeable. As long as you remember what each button does because the overlays are not.

The keyboard controller is a marvel of 1972 engineering, built around an electronic switch-scanning matrix, a technology that has remained the foundation of virtually every keyboard ever since. Earlier keyboards used direct-wired keys, where each key was individually connected to its own circuit. This design required a separate pin on the connector for every key, an impractical setup when you consider that a standard full-size keyboard has 104 keys. While modern keyboards typically connect via USB or wirelessly, their internal circuitry remains a complex web of circuit traces.

A switch-scanning matrix keyboard uses a wired grid of rows and columns.

This is an example showing a single electronic switch to represent one key, and using one row and one column. We can add another switch, inline on the first row by adding another column. Now if switch 1 is pressed, column 1 is energized. Likewise, if switch 2 is pressed, column 2 is energized. We can easily expand our matrix to four switches by adding in a second row. Now if we energize the second row, and close switch 4, the second column is energized.

Each row and column are wired directly to a corresponding pin on the DE-9 connector that you plug into the back of the console. Pin 1 on the connector provides power to the first row, while pins 2, 3, and 4 are wired to the 2nd, 3rd, and 4th pin. The 1st column is pin 5, 2nd pin 9, and the 3rd pin 6. The trick to determining in your code which of the buttons is pressed is by scanning through each row one at a time. When you detect an energized column, you use that column, along with the currently energized row to determine which button was pressed.

When we press Button 1, we can see that Pin 1 and Pin 5 are energized. This is Button 2, Three, Four, Five, Six, Seven, Eight, Nine, Star, Zero … and finally Pound, Hash, Hashtag, Sharp, or Number sign. Depending on the context or how old you are.

Now that we know the hardware switches and pins, let’s have a look at which registers handle each.

Port-A on the console is the left connector on the back of the Atari console. Player One… or player zero if you want to be technical… which I guess is why we’re here. Let’s go ahead and be nerds. Player zero’s controller uses the first four most significant bits, D4 to D7 on SWCHA for each row. Interestingly enough, you might assume you set the bit to 1 in order to energize a row, but you actually need to set it to 0, and all the other bits need to be 1. We read each column by checking bit D7 of the INPUT ZERO register for the 1st column, INPUT ONE for the 2nd, and INPUT FOUR for the 3rd. The column is energized if bit D7 is set, or in other words 1.

On Port-B, player 1’s controller uses the four least significant bits, D0 to D3 on SWCHA for each row. Each column is read by checking bit D7 again, but on the INPUT TWO register for the 1st column, INPUT THREE for the 2nd, and INPUT FIVE for the 3rd.

At this point, we need to piece all this together in the right order or we’re going to have a really bad day.

The first step is setting the pins on the controller as output so the console will supply power to them. This is done by writing to the SWITCH A CONTROL register and setting the first four most significant bits to ONE for player 0’s keyboard, and the least significant bits on ONE for player 1’s keyboard. You could also just set all bits to ONE since there’s literally no downside when we’re using the keyboard controllers. However, for learning purposes, the first example included in this episode specifically sets the bits depending on which controller we’re checking. Now that we have our pins set for output, we can energize one of the rows using SWITCH A. After which we need to wait for approximately 400 microseconds for the row to charge. If you don’t then you’re not going to be able to read anything from the input registers. 400 microseconds is about 477 machine cycles, or just over 6 scanlines on the Atari 2600. Once the row is charged, we read the input registers one at a time to check if they are energized and bit D7 is set to one. If we don’t detect any keypresses then we start the sequence again by charging the next row, waiting 400 microseconds, and checking the inputs… and so on, and so on. Until we’ve checked all the buttons we’re interested in.

Realistically, you don’t need to check every button. If you’re only interested in a few—say, the middle column with 2, 5, 8, and 0… then just check that column. Or maybe you only care about the first two rows. It’s your game. Do what makes sense for you

Code Now that we know the hardware, registers and theory, let’s have a look at the code. The example we’re going to look at in this episode scans over both keyboard controllers and displays a graphic of the button you pressed… but first, we need to know how to configure the emulator to treat the input as the keyboard controllers.

The following information will use a standard English 104-key PC keyboard. Your layout may be different depending on your computer type, location, and language. So please refer to your emulator software for more information on key binding.

In the Stella emulator, which is the most common, you need to press the back-tick key. This will bring up the debugger. Load up the code in Stella, run the button-press animation, then press back-tick.

From there, click on Options → Game Properties, and then select the Controllers tab. Click the dropdown for Left Port and select Keyboard. Do the same for the Right Port if you want to try that side as well.

On your computer keyboard, the LEFT port uses the keys 1, 2, 3, Q, W, E, A, S, D, Z, X, and C. The RIGHT port uses 8, 9, 0, I, O, P, K, L, semicolon, comma, period, and forward slash.

Unfortunately, while Stella will remember your keyboard configuration after you save, it uses a signature of the ROM file to determine what configuration to use. When we’re modifying our code, that signature is constantly changing. So you’ll either have to keep setting it back to use the keyboard controllers each time, or use Stella’s command-line parameters to force it to use them.

That’s a little too heavy for this episode, but we will cover it in more detail in the future where I’ll show you some of the tricks and tools I use to make game development even easier. Be sure to subscribe to let me know if that’s something you’re interested in, but for now, let’s get back to the code.

First we’ll define which pins on each controller will be used as output. The first byte will set all the row pins on Port-A to output, and the second byte will set all the row pins on Port-B to input. While we’re scanning the controllers we’ll swap between the two.

This is where we select which byte to use, based on the Y register which holds the index of the current controller. We store the byte into the SWITCH A CONTROL register, which configures the pins on the PIA (Peripheral Interface Adapter).

Next, we need to configure which row we want to energize. In our data tables we’ve defined two tables to store the bytes for Port-A and Port-B. Each has four bytes—one for each row, with the first byte being the top row. As mentioned earlier, we energize a row by setting the corresponding bit to ZERO.

We then set up the tables for use with a pointer, allowing us to easily switch between which data table we’re reading without hard-coding the names. You can learn more about using pointers in our episode titled “Animating Graphics on the ATARI 2600.” I’ll leave a link in this episode’s description.

We use these data tables by selecting which table we’re going to read from—again using the Y register to represent the current controller—then reading the byte representing the row we want to scan. In this example, we start with row 3 (the bottom row) and work our way down to 0 (the top row). We usually decrement through a list because it’s faster to check if a number becomes zero or negative than to compare it to another number. Once we have our byte, we store it into SWITCH A and wait about 400 microseconds while it energizes our row. We do this by burning six scanlines with a WSYNC loop. However, if you have other tasks for your game, you can use those cycles for whatever you want.

After 400 microseconds we’re clear to start reading the input registers. In this code we check one controller at a time, so we determine which controller is current and then jump to the correct routines. Since we’re checking the controller on Port-A first, we carry on to the next instruction.

Checking the input registers is easy. We load the register and check if the D7 bit is set to 1. Luckily, we have a branch instruction (BMI, “Branch on Result Minus”) that tests the Processor Status Negative Flag. That flag is set when the result of the last operation was negative—specifically, when bit 7 of the last operation was 1. If it’s not set, we move on to the next input or controller; if it is set, we know a key was pressed.

We then use the row we’re currently on and the input detecting the key press to determine which graphic to display on the screen. The second example included with this episode performs the same function but finds cleaner ways to code the key-polling routines.

If you’re wondering how the graphics are encoded in both examples, that will be covered in a future episode, along with the tool I created to help me design and encode them. Be sure to subscribe to let me know if this is something you’re interested in.

Outro While keyboards are the preferred input device for many PC gamers today, the situation was quite different for consoles in the early 1980s. Back then, the keyboard wasn’t widely used in a meaningful way on systems like the Atari 2600. Most games didn’t take advantage of it in any interesting or effective manner, with Star Raiders being a notable exception.

What do you think would be an interesting way to incorporate the keyboard controllers in an Atari 2600 game? Let me know in the comments below.

As always, all the example code from our episodes is available in the repo—just follow the link in the episode description. Have you programmed Atari today?

That’s all for now, thanks for watching, and I’ll catch you later!

Back to top of page