** 1 page regular EJP Series Part 4/ 914 words **

Pros and cons

Xav looks at Atari's Procontroller, then discovers how an understanding of the joypad hardware can reveal some useful software tricks.

** Darryl, if you can salvage the joypad grab we used in AC3/4 **
** use it here - suggest stripping away dark background... **

Atari's standard joypad was a wonderful piece of design, giving programmers over a dozen buttons to assign to whatever functions they desired. Unfortunately not all of the buttons were easy to hit when attempting to master the "Power Death Throw" in "Street Scuffle 3". The answer was obvious - just add some more buttons. But add them how?
Atari's engineers engineered, and the result was the Procontroller joypad variant - which also addressed several niggles present in the original design. From our point of view the most important feature was the addition of five extra buttons: there are three more "fire" buttons (X, Y and Z) and a pair of fingertip operated buttons (L and R - not to be confused with those on the D-Pad). In hardware terms there were a variety of ways Atari could have added these extra buttons - and in my opinion they chose the worst! However, it's still better than no extra buttons at all isn't it?...
In my opinion the best way to add another three fire buttons would have been to put them in the "blank" positions on the Pause line. Instead, Atari fitted them in parallel with three of the numeric keypad buttons. When reading back a Procontroller, therefore, a press of X will appear the same as a press of 9, Y as 8 and Z as 7. Similarly the fingertip buttons are mapped with L appearing as 4 and R as 6.
So in fact we didn't actually get any "extra" buttons but if your program requires more than six fire buttons, or could be made easier by putting some functions literally at the user's fingertips, you can consider offering a Procontroller mode.

Tricks of the trade
It's all very well taking "expert" advice for granted, but often you can learn just as much by ignoring the rules and experimenting for yourself - which is what this series is all about! Take the joypad circuit - a section of which is shown in figure 1.
The "official" rules state you should test each group of switches individually, writing a low to each of the four control lines in turn. But have you considered what would happen if you were to take more than one line low at a time? Suppose, for example, pins 3 and 4 were both pulled low: the effect would be that pin 10 would also go low if either button A or button B were being pressed. The reason for this is that the negative logic system of a joypad has the effect of turning what we perceive as an "AND" function (pin 3 AND pin 4) into an "OR" function (button A OR button B).
So this is more than just a passing curiosity? Suppose your program only requires a single fire button - by pulling pins 2, 3 and 4 LOW (by writing a mask of 0xFFF8), you will get a LOW on pin 10 when any of the fire buttons are being pressed. The downside is that you can't differentiate between the D-Pad and some of the numeric keypad, but in a program with only one fire button you're unlikely to be terribly worried about the keypad. Clearly we've only made one read of the joypad, rather than the usual three, leaving more processor time for the rest of the game logic.
Why isn't this feature officially documented? Because there's a problem. Unfortunately this little cheat clashes with Atari's Team Tap (a multi-joypad adapter) but so long as you know the user doesn't have a Team Tap (ask them - don't assume) there's no problem.
Another trick, which does work with the Team Tap, is useful for multi-player games. Suppose you want to read from both of the enhanced joystick ports - presumably reading two joypads. With the code we used in the last issue, this would have to be done in two passes. Since reading the ports is more "costly" in processor usage than a little data manipulation, it would be nice if we could read both ports at once, then split the resultant information down if necessary.
The way to do this is actually quite easy. Let's say that you want to read group 1 from both joypads. Usually you would write a mask of 0xFFFE, then read for port A, followed by a write of 0xFFEF and a read for port B. Why not just write a mask of 0xFFEE? All this does is take one line LOW in each joypad simultaneously, and the data for both are returned in the bits of 0xFF9200 and 0xFF9202 as described last time.
Of course, you don't have to read the same group on each port, for example, a mask of 0xFFB7 returns the status of port A group 4, and of port B group 2 - you can even combine this with the previous tip, so long as you're sure there's no Team Tap connected: a mask of 0xFF88 will check to see if any of the fire buttons are being pressed on either joypad.

Next time
That pretty much concludes our coverage of the joypad as an isolated device. In the next issue we'll look at user friendly ways to implement joypads into your programs, and take a first look at the Team Tap.


** IMAGE **
pad_2.gem
** Caption **
Figure 1: Joypad fire button arrangement