Transcription

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

Welcome to 8-Blit, a channel covering all the tips, tricks, and everything in between to program your own games for the Atari 2600 from 1977.

In this episode we discuss the Paddle Controllers, what they are, how to use them in your game, and their surprising complexity despite their simplistic implementation. We’ll also cover a clever branching technique that’s easy to implement and can save you a couple of bytes with each use.

That’s all coming up on this episode of 8Blit.

This channel is supported by viewers like you.

A huge thanks to all our patrons that help keep the intrepid spirit of ATARI alive by donating a few dollars each month. You can help me produce more episodes like this one, where we dive deep into the inner workings of the ATARI 2600 hardware, the 6502 processor, and assembly language programming.

All contributions are greatly appreciated.

The Atari VCS (later rebranded as the 2600), was released on September 11, 1977. Included within the packaging… along with two iconic CX10 joysticks, were the equally iconic CX30 paddle controllers.

Featuring a light and comfortable form factor, the controller fits easily in your hand with a nice firm grip. The label clearly identified them as paddle controllers with a double racket. This helped to distinguish them from the almost identical CX20 Driving controllers, which were packaged along with the game Indy 500, but totally incompatible with the paddle controllers.

The paddle controllers came in pairs, where both paddles were connected together to plug into a single port, allowing two sets of paddle controllers to be plugged into your console, enabling the ability for 4 players to play at the same time… right in your living room!

Aside from rebranded Sears versions of atari games, there were around 35 original titles featuring the paddle controllers. These included games such as Kaboom, Night Driver, Solar Storm, Circus, Guardian, and Super Breakout.

The paddle movement is controlled using the circular dial, which tops off a one megohm potentiometer. The power passing through the potentiometer charges up a capacitor located within the Atari 2600 console. There’s one capacitor per controller. The speed at which the capacitor gets fully charged is determined by the variable resistance of the potentiometer based on how much the paddle has been rotated. The farther it’s rotated clockwise, the less variable resistance there is, and the faster the capacitor will charge.

The fire button is located on the left side of the paddle. Not the best placement for lefties, to be honest… but that’s really no different than the placement of the fire button on the joystick.

The button itself is just a normal switch that completes a simple circuit when pressed.

Each set of controllers used a single female DE-9 connector to plug into the ports on the back of the console.

These days you can commonly find them marketed as DB-9 connectors due to a long running misunderstanding of the difference between D-Sub electrical connector form factors. Technically, DB-9… just doesn’t exist. But… I’d like to hear if you have an opinion on this, so let me know in the comments.

The Atari DE-9 port uses 6 of the 9 available pins to handle both paddles.

For movement, pin five is the Left Paddle, while pin nine is the Right paddle. Pin five is hot supplying 5v. This provides current to the potentiometers within both paddles before sending it back to the console to charge the capacitors. This affects the Input zero through Input Three ports which are used for reading the status of the capacitor.

The buttons on the controllers work in the opposite way. Pin 4 is the left button, while pin 3 is the right button. When pressing a button, the internal switch will connect that button’s pin to ground, providing a low signal to the console. This is why the Input 4 and Input 5 registers which are used for reading the status of the buttons, are usually high, and when pressed they go Low.

Using the paddle controllers to position a graphic on the screen is not immediately intuitive. It’s not like reading input from the joystick controller, where pressing RIGHT means that you’re going to move your player one unit to the RIGHT on each read until you stop pressing RIGHT.

With the paddle controllers you can determine how FAR to move RIGHT. This is great because instead of iterating the player’s position in one direction over many frames, you’re getting the final position to place your player.

This is what makes the paddle controllers incredibly useful for games like breakout. Once the player is used to the movement of the dial, compared to where the paddle is visually on the screen, they can quickly rotate back and forth, with the paddle on one side of the screen in one frame, and in the next it can be all the way on the opposite side.

While reading the paddle controller only takes a few machine cycles, that one read doesn’t provide the true context. Reading from the input zero through input three registers will only tell us if the capacitor is charged or not. We need to determine how long it took the capacitor to charge, and despite what the Stella Programmer’s Guide, and countless other websites will confidently tell you… the Atari 2600 console cannot tell us, and does not know, how long that took.

Reading from the paddles and determining where to place your player graphic can be broken down into these 4 steps.

Step One is to discharge the capacitor. In order to measure the time it takes for the capacitor to charge, we need to dump it to ground and start with zero volts.

Step Two is to start charging the capacitor. In this step we stop dumping to ground and allow the voltage to accumulate.

Step Three is to start reading the input pin… but not just once. We’re going to read this pin over and over again, and keep track of how many times we had to read the pin before it goes Hi. The tricky part is that it takes a long time for the capacitor to fully charge with maximum resistance. So much so that we don’t count this in machine cycles. We usually count them in scanlines.

A higher variable resistance will require a lot of scan lines, while a lower resistance could be a single scanline. It’s best to read the input at a regular interval, such as once per scanline. Otherwise the physical rotation of the dial on the paddle controller will be out of sync with your scanline count and could make your on screen movement seem unnatural or jerky to the player.

Step Four is converting our scanline count into something that makes sense for placing your graphic on the screen. That will be based on what your game is and how your screen is set up. In the end you’ll establish a possible range of acceptable values, either using the actual scanline count as-is, or performing a calculation on it to transform it to a screen position. angle three

The paddle controllers are analogue mechanical devices, and many factors could introduce inconsistencies in how long the capacitor takes to charge. The manufacturing of the capacitor, the age, the temperature. All these can affect its performance. The same goes for the potentiometer. The manufacturing, age, wear and tear, and even dirt or other foreign material that finds its way into the protective case.

In addition to the analogue inconsistencies, most of the movement of the dial is unmeasurable. While the dial can rotate about 330 degrees, the actual usable arc is closer to around 90 to 100 degrees on a controller using a standard one megohm potentiometer. Typically this arc is closer to the stop point of the dials rotation.

Let’s take some measurements and determine what our usable arc might be. This rectangle will represent the total 330 degrees the dial is free to rotate. Keep in mind the paddle starts with the maximum resistance, and lowers the resistance as it’s rotated clockwise. This means the scan goes from the max number of scanlines, to the least.

On my Atari Heavy Sixer, using original Atari Paddle controllers, the Left paddle in Port A began to register a change in the number of scan lines around 190 degrees with 179 scanlines. It continues to change all the way to 320 degrees when it measures one scanline.

I then tested the Right paddle. Then both paddles again in Port B. Then did the same with the controllers that come with the Coleco Gemini. Then both sets of controllers on my Light Sixer. Then again on the Coleco Gemini.

After finding the average number of scan lines of all the tests, we arrive at a respectable 172 scanlines. Since the horizontal resolution of the Atari 2600 is 160 pixels, we can pretty easily adjust this number to place our player graphic anywhere horizontally on the screen. We’ll just need to remember to flip the number, or our graphic will move opposite to the rotation of the paddle controller!

I was able to perform these tests easily using some example code I created for this episode. With it, we can read the number of scan lines required for any dial rotation, as well as reading if the fire button was pressed. It can read both left and right paddles on both ports. You can use this for checking your own paddles. Are they different from mine? Make sure to post your findings in the comments. Now, Let’s have a look at how the code works.

For this example, we’re going to read from all four paddle controllers. So we’ve created a variable that’s 4 bytes in size. Then at the beginning of our frame we set all of those bytes to zero.

Now we need to dump all our paddle controller inputs to ground to set them low at ZERO volts. We do this by writing to VBLANK with D7 high. This can be done at any time, but since we need to turn off VBLANK anyway, we’ll reuse the write. During this time the internal paddle capacitors are discharged and will remain that way until we tell VBLANK to start charging them again.

Let’s check each of the paddle inputs to see if their capacitor has been fully charged. We do this by reading the Input zero through three registers. If the result is zero then it means the capacitor is still charging. In this case we branch down to update this paddles value with the current scanline. If the result was greater than zero, we continue execution with the next line, where we encounter an interesting value.

This has nothing to do with how the paddle controllers work, but it’s an interesting hack we can use to avoid some awkward branching. Since the capacitor is already charged, we don’t want to update the paddles value. We could add in a jump, but that takes 3 bytes for the opcode and operand. With this trick we’ll save two bytes.

First, allow me to explain what the .byte directive does. We’ve seen this previously in our example code when we define our graphics. We use this to tell our assembler to insert the byte after the directive into our code, exactly as is. Right at that point in our assembled ROM, will be the hex value of 2C.

In 6502 assembly, the hex 2C opcode is the BIT Test instruction. It’s an instruction that doesn’t alter the accumulator, or the index registers. Basically, it’s benign. Which is important. What’s also important is that the BIT instruction requires a 2 byte operand. When our code is executed, the operands address is the next one or two bytes after the opcode.

So when our BIT instruction is executed, the two bytes it will use for the operand, are the bytes for the Store X opcode and pValue address… and the result of the Bit instruction being executed, is of no importance. It didn’t affect anything we cared about. What it did do though was advance the program execution by two bytes, bringing us past the Store X function. We essentially hopped over that instruction!

This is an awesome trick, but let’s continue on reading the paddles.

So far we’ve only checked the left paddle. However, The other paddles are handled the exact same way. If it’s the first time checking the paddles, odds are that none of the capacitors are charged, so we jump back up the the top of this loop to start the next scanline and check the paddles again, until we’ve done enough scanline that suits the accuracy you want for your game.

In the previous episode we established the birth of a new game called Purrballs.

It was built to demonstrate asymmetrical playfields and how to create a scoreboard. At the time your onscreen paddle was controlled by the joystick controller. In this version the code has been amended to use the paddle controller. Now it works so much better, and you have fast and smooth movement. Giving you better control and reaction time.

Keep in mind, this is a work in progress.

The paddle controllers offer a unique control mechanism for your game. They provide a simple human interface that gives your players the ability to make lightning fast movements that are as quick as their reflexes allow. Best of all, it’s easy to implement once you get the hang of it. We’ll keep refining Purrballs with each new concept we introduce. More episodes will be coming soon so remember to subscribe if you haven’t already done so.

As always, all the example code used in our episode, including the full source code for Purrballs and the Paddle utility are available in our code repo located at the link in the episode description.

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

Back to top of page