"These people have taken a supreme vow of celibacy. Like their
fathers and their fathers before them."
"Hot Shots! Part Deux" - Topper Harley (Charlie Sheen)
PROGRAMMING THE JAGUAR POWER PAD
(WHICH CAN ALSO BE CONNECTED TO THE FALCON!)
by Leon O'Reilly
(a.k.a. Mr Pink of Reservoir Gods)
This article was originally published in a recent issue of
"Maggie". Kind permission was given by both the original author
and the "Maggie" editorial staff to reuse it here. Cheers!
If you have an STE or Falcon and are writing games software,
it is a good idea to support the Jaguar Powerpads which can be
plugged in via the extended controller ports. Not only are
these easier to access than the fiddly joystick ports, it means
you can have a more complex control method with 3 fire buttons
and numerous other keys at your disposal.
If you have written some keyboard stuff for the ST before,
try to forget them as soon as possible. The extended controller
ports work in a very different way from the rest of the keyboard.
They are not in any way linked to the keyboard or the IKBD
processor. They do no generate any interrupts (unlike a
conventional keypress/ mouse/joystick movement which will
generate a keyboard interrupt). Because of this, you cannot put
this routine on vector address $118 and expect it to work.
You have to physically interrogate the ports at every
vertical blank (i.e. every time the screen is refreshed) to get
the current state of the powerpads plugged in.
Enquiring about the powerpad state is done via two hardware
addresses: $ffff9200 and $ffff9202. A write mask is written to
address $ffff9202 and then both addresses can be read as they
will contain the selected powerpad data.
There are a total of 8 different write masks (4 for each
powerpad) which have to be written to get every piece of
powerpad data.
The data for Fire A, B & C, Pause and Option is returned in
$ffff9200 whilst the other data (directional + keypad) is
returned at $ffff9202.
When inquiring about powerpad A only bits 0-1 of $ffff9200 and
bits 8-11 of $ffff9202 are relevant. When examining powerpad B
only bits 2-3 of $ffff9200 and bits 12-15 of $ffff9202 are
required.
As the routine accesses hardware addresses you must be in
supervisor mode when you call, so ensure you have set into this
mode (GEMDOS function $20) or use a supexec call (XBIOS $26)
My routine gleans all the information about the current state
of the powerpads and creates two data packets from it.
The first is a byte packet which contains directional data and
fire information. The bit structure is:
--------------------
| Bit | Represents |
--------------------
| 0 | Up |
| 1 | Down |
| 2 | Left |
| 3 | Right |
| 4 | (not used) |
| 5 | Fire C |
| 6 | Fire B |
| 7 | Fire A |
--------------------
The second variable is a word that contains information about
all the Powerpad keypad key as well as Pause and Option.
--------------------
| Bit | Represents |
--------------------
| 0 | * |
| 1 | 7 |
| 2 | 4 |
| 3 | 1 |
| 4 | 0 |
| 5 | 8 |
| 6 | 5 |
| 7 | 2 |
| 8 | # |
| 9 | 9 |
| 10 | 6 |
| 11 | 3 |
| 12 | Option |
| 13 | Pause |
--------------------
When reading from the extended controller ports, the flagging
is different from other keyboard reports. A bit of 0 means the
flagged key is on, a bit of 1 means it is off. I inverse this
for my packets so a bit of 1 means a key is pressed whilst 0
means it is off. I find this a lot easier to remember!
An example:
move.w jp1_key,d0 ;get powerpad a key info
btst #13,d0 ;check pause flag
bne do_pause_routine ;pause pressed - do sub-
routine
You may be wondering about the strange order of the "key"
packet. This is the order in which the keypad bits are
returned. You could sort them out into numerical order in your
powerpad handler but this is really an unnecessary waste of
processor time. You can still easily check for each keypress, it
is just a question of remembering which bit represents what.
I hope these routines may be of use in your future games and
productions!
Thanks to the author and "Maggie" for this small but very useful
article!
Disclaimer
The text of the articles is identical to the originals like they appeared
in old ST NEWS issues. Please take into consideration that the author(s)
was (were) a lot younger and less responsible back then. So bad jokes,
bad English, youthful arrogance, insults, bravura, over-crediting and
tastelessness should be taken with at least a grain of salt. Any contact
and/or payment information, as well as deadlines/release dates of any
kind should be regarded as outdated. Due to the fact that these pages are
not actually contained in an Atari executable here, references to scroll
texts, featured demo screens and hidden articles may also be irrelevant.