Jump to content
Jagware
RaZ

Joypads, teamtaps and other controllers

Recommended Posts

sh3-rg    6

Testing GGN stuff is the most fun I have on Ataris - it's like the crazy old days somehow - love it! :D

 

:poulpe:

Share this post


Link to post
Share on other sites
Tyrant    0

You see, now this kind of thing is EXACTLY why Atari needed another 6 months of testing on the Jaguar. For the sake of A SINGLE DIODE! they made the C1-3 bits be all locked into the pause button (push pause and C1, C2 and C3 all go low too).

 

There should be a diode connecting pin 6 to the pause button, but someone forgot to include it (or decided it wasn't necessary) and it was never spotted in testing, because how many people hold pause when games start and do their TeamTap/Controller detection?

As you found out, assuming nobody is holding pause, the state of C1 should be that normally it's high, and the only time it is ever low is on socket 3 (player 4) of a TeamTap, which sets it low as an identifier. Seems a terrible waste of a bit to me, but it's not really significant I guess.

 

Btw, on the subject of the C2/C3 bits, everything Atari says about their use can safely be ignored. They should be used for controller-type identification. In other words, different combinations of C2/C3 indicate different controllers. The normal pad has them both high all the time (except when pause is pressed it seems), the Rotary was meant to have one high and one low, but nobody who made rotaries has ever implemented that (we leave them high like normal pads), and on top of that Tempest 2000 does not appear to support auto-detection of them using C2/C3 anyway. The ONLY advanced controller Atari ever made that actually (we assume) follows the spec is the VR head-mounted tracker, and there are precisely two of them, so it doesn't seem worth supporting them (especially since most of it is still undocumented).

 

Incidentally, on the subject of controllers: There are precisely three Jaguar games* which support non-standard controllers. One is the aforementioned Missile Command VR, supporting the head-tracker. The next is Tempest 2000, supporting Rotary Controllers, but not following the spec on them. The last is BattleSphere Gold, which supports Analog Joysticks, but only on early models of the Jaguar which still have the ADC chips onboard. Atari wrote a nice spec for how to interface them digitally, but it's not been implemented in BSG, which just reads variable voltages off two pins directly. They presumably don't check for C2/C3 either. I believe STe's and Falcons have the ADC chips for Analog Joysticks too.

*I believe Starcats point-and-click will have support for bus (Atari) mice, when it comes out. Also there is the Balloons light gun demo, but guns read differently again.

 

On the subject of Rotary Controllers, the Atari spec is awkward and has never been implemented in full. It requires the knob-movement to be encoded on the left and right pins of socket 1 (i.e. player 2 on a TeamTap). No buttons are on socket 1, and a "pass-thru connector" should be used, which will respond to socket 0 codes and have an ordinary controller plugged in. This is ugly as all hell, and thankfully was never made that way. EVERY controller anyone ever made responds simply on socket 0 codes, and just has the left and right buttons replaced with the rotary encoder (usually losing up and down at the same time). The encoders produce a 2-bit grey code, which consists of a pair of square waves, 90' offset from each other. Each "step" of revolution changes an edge on one of the lines, enabling you to tell direction, and naturally the rate of change lets you know speed. In this they are identical to how Atari mice work (although I'm not sure how bus mice appear to the system, there might be a processor on the keyboard to help with them).

 

The best, and only reliable way to detect a Rotary is to watch for the situation where both left and right are simultaneously depressed. You can add that check to your standard controller-reading routines, and need not have an actual "detection" phase before launching the main menu. As people try to navigate the menu, or launch the game, they will rotate the knob, and you will see both buttons depressed at once (it happens 1/4 of the time), at which point you can adjust for a Rotary input. It helps to update the speed at which you poll the controller, to up the sample rate and avoid the situation where the user twists the knob more than 1 position in between the times you're reading it. Yak does it under interrupt from Jerry's PIT signal, and reads rotaries 8 times as often as normal pads. From what I can see of reading/searching through his source, he never once looks at socket 1 (player 2 on TT) and thus cannot be following the spec. He reads them just as we've been building them, which does beg the question of why Atari wrote the spec in the arse-backwards way they did.

 

Mouse detection is another anomaly, in that the only mouse adaptors people have hooked up are simple wire-crossing affairs which take no account of the 4 different common wires the Jaguar uses, and thus always output x1, x2, y1, y2, left and right, regardless of which row you're reading. They can be detected that way, or by the same method as Rotary detection, only you can check for up and down both being depressed at the same time as well as left and right, thus doubling your chances of detecting the controller quickly, before the aberrant signals cause unwanted button pushes.

 

If you don't have the dev docs, I'd be happy to upload them for you, they're an invaluable tool, although not exactly the most complete or intuitive docs to read.

 

P.s. Sorry for the wall of text, I like to be complete where I can be.

P.p.s. Feel free to copy/pasta this elsewhere if it is useful to people.

 

Share this post


Link to post
Share on other sites
ggn    0
You see, now this kind of thing is EXACTLY why Atari needed another 6 months of testing on the Jaguar.

 

More like 6 YEARS really, but let's not split hairs here ;)

 

Incidentally, on the subject of controllers: There are precisely three Jaguar games* which support non-standard controllers. One is the aforementioned Missile Command VR, supporting the head-tracker. The next is Tempest 2000, supporting Rotary Controllers, but not following the spec on them. The last is BattleSphere Gold, which supports Analog Joysticks, but only on early models of the Jaguar which still have the ADC chips onboard. Atari wrote a nice spec for how to interface them digitally, but it's not been implemented in BSG, which just reads variable voltages off two pins directly. They presumably don't check for C2/C3 either. I believe STe's and Falcons have the ADC chips for Analog Joysticks too.

 

Yes, the ADC chips do exist on STE/Falcon.

 

One question though: Does BSG support the same rotary controllers as those you build or are they different? I'd assume that the wiring and mode of operation is totally different.

 

If you don't have the dev docs, I'd be happy to upload them for you, they're an invaluable tool, although not exactly the most complete or intuitive docs to read.

 

No worries, the Falcon is my primary target anyway :D

 

 

P.S. Mods, there is another thread on the rotary in this forum. Maybe we should merge both threads into a bigger one that talks about all kinds of inputs on the Jaguar?

 

Share this post


Link to post
Share on other sites
Zerosquare    10

Great and informative post, Tyrant :)

 

You see, now this kind of thing is EXACTLY why Atari needed another 6 months of testing on the Jaguar. For the sake of A SINGLE DIODE! they made the C1-3 bits be all locked into the pause button (push pause and C1, C2 and C3 all go low too).
The Jaguar needed more testing for sure, but I'm willing to bet the reason why they removed that diode was to save a few cents on each controller :D

 

I believe Starcats point-and-click will have support for bus (Atari) mice, when it comes out. Also there is the Balloons light gun demo, but guns read differently again.
Matthias Domin's Impulse (which should be released soon) is going to support mice and rotaries controllers, too.

 

In this they are identical to how Atari mice work (although I'm not sure how bus mice appear to the system, there might be a processor on the keyboard to help with them).
Yes, on the ST(E)/TT/Falcon, the keyboard processor does count the pulses for you ; you can simply ask it how much the mouse has moved.

 

One question though: Does BSG support the same rotary controllers as those you build or are they different? I'd assume that the wiring and mode of operation is totally different.
Yes, they're totally different. The controllers supported in BSG are analog joysticks, and only work on early Jaguars that included the ADC chip. The rotary controllers supported by Tempest 2000 are, well, rotary things which you can rotate endlessly in both directions, and work on all Jaguars.

 

P.S. Mods, there is another thread on the rotary in this forum. Maybe we should merge both threads into a bigger one that talks about all kinds of inputs on the Jaguar?
Done :)

I've also merged Fadest's topic about rotary controllers, and an old topic by GT Turbo about detecting teamtaps.

Share this post


Link to post
Share on other sites
ggn    0
This documentation is wrong. Encoders don't have 3 different states, they have 4 different states, They behave like a Gray code counter, incrementing for one direction of rotation, and decrementing for the other (explanation on Wikipedia)

 

It's also explained in the Jaguar developer docs, in the section about controllers. According to this, the sequences are :

 

Clockwise rotation is : none, right, left AND right, left.

Anticlockwise rotation is : none, left, left AND right, right.

 

Personally, my code is similar to this :

 

{
    unsigned long dataJoypad;
    unsigned long ph0, ph1, ph0_old, ph1_old; // ph0_old and ph1_old must be initialized, and preserved between calls to the routine

    dataJoypad = joypads->j1;    // we only manage jagpad 1 for this demonstration routine

    ph0 = !(dataJoypad & JOYPAD_LEFT);
    ph1 = !(dataJoypad & JOYPAD_RIGHT);

    if (ph0 ^ ph0_old ^ ph1 ^  ph1_old)
    {
        if (ph0 ^ ph1_old)
        {
             // do whatever you need to move anticlockwise
        }
        else
        {
              // do whatever you need to move clockwise
        }
    }
  
    ph0_old = ph0; 
    ph1_old = ph1;
}

 

(I've not tested it on the Jaguar, it's possible both directions are swapped)

 

Okay, it took some time to verify this (actually I waited till I have a rotary on my hands!), but there's a small problem with the above code. Unless I'm really reading it wrong of course (some C specifics elude me).

 

Anyway, I transcribed the above code to GFA Basic on the Falcon for testing some time back and while it worked 100% for one of the two movements (anticlockwise IIRC), on the other one the code was alternating between clockwise and anticlockwise every two ticks (I think - not that it matters too much :)). I traced the problem to the way ph0 and ph1 are calculated; i.e. reading the jagpad, masking for specific bits and NOTting the result. What I did was to convert this to give me $ff for one state and $00 for the other state for both ph0 and ph1. After this it worked perfectly :).

Share this post


Link to post
Share on other sites
ggn    0

Blah! So if I wanted to understand the code better I should have compiled it and then disassembled it :P. Why couldn't languages have standard prefixes and stuff? :)

Share this post


Link to post
Share on other sites
Guest
You are commenting as a guest. If you have an account, please sign in.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoticons maximum are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×