IPB

Welcome Guest ( Log In | Register )

2 Pages V  < 1 2  
Reply to this topicStart new topic
> Joypads, teamtaps and other controllers
Fadest
post 12 Sep 2009, 11:20
Post #21


Super sprint
**

Group: Level1
Posts: 407
Joined: 1-2 06
From: Disconnected...
Member No.: 32



Nice and cool game...
Go to the top of the page
 
+Quote Post
SebRmv
post 26 Oct 2009, 10:46
Post #22


Rick dangerous
***

Group: Level1
Posts: 1.544
Joined: 23-1 06
From: Paris, France
Member No.: 31



QUOTE (Fadest @ 8 Sep 2009, 10:04) *
CODE
// First, interrupts must be initialized via call of function. Basically, put this call in main()
init_interrupts();

// Then, somewhere when we want interrupt to start, we need to use the set_timer firunction, in order to program an automatic call of rotary() :
set_timer(200<<16 | 360,rotary);


Great post Fadest flowers.gif
(better late than never for me to comment this thread wink.gif)

The magic values correspond to PIT0 and PIT1 values

The frequency of the interrupt is computed as follows:

Frq = (Clock / (PIT0+1)) / (PIT1+1)

The set_timer function takes thus as first parameter the long word equal to (PIT0<<16)|(PIT1)

The system clock is approximately 26.5 MHz (SCPCD or Zerosquare, could you please recall us the exact value?)

Thus, in your case, you generate an interruption at a frequency of about 26500000/201/361 = 365,209961 Hz ie about every 2 ms
(compare to a VBL which is every 20 ms for 50 Hz display)

Maybe I should add some words about this in the documentation of my library whistling.gif


--------------------
Go to the top of the page
 
+Quote Post
Zerosquare
post 26 Oct 2009, 20:48
Post #23


Rick dangerous
***

Group: Administrators
Posts: 2.076
Joined: 4-1 06
Member No.: 30



CITATION(SebRmv @ 26 Oct 2009, 10:46) *
The system clock is approximately 26.5 MHz (SCPCD or Zerosquare, could you please recall us the exact value?)
26.593900 MHz for PAL models, 26.590906 MHz for NTSC models smile.gif


--------------------
« Mon PC on dirait un Amiga tellement c'est instable » – GT Turbo
« Soit A un niveau d'absurdité, il existe un post N tel que... » – Azrael et al., 2006
Go to the top of the page
 
+Quote Post
SebRmv
post 26 Oct 2009, 23:02
Post #24


Rick dangerous
***

Group: Level1
Posts: 1.544
Joined: 23-1 06
From: Paris, France
Member No.: 31



Thanks!


--------------------
Go to the top of the page
 
+Quote Post
ggn
post 24 Jul 2010, 19:05
Post #25


"Can I hear you say YEAH?"
*

Group: Members
Posts: 167
Joined: 11-8 08
Member No.: 207



I also posted this on the D-Bug forum a few minutes back, but I thought I'd mention it here, since I don't think there'll be anything different for the Jaguar smile.gif. Original text follows in verbatim.


Recently I've been messing around with Jagpad input and while I sorted it out easily, I wanted to add support for the teamtap as well. Not wanting to reinvent the wheel, I asked around for some advice on the matter. Zerosquare of CVSD pointed me to two solutions for this.

One was to use heuristics (i.e. make the user press a jagpad button and see if the button press is shadowed on other pads on the same port - if yes, the user most certainly doesn't have one installed), and the other was in fact a method by Matthias Domin, which reads a seemingly unused bit on the jagpad matrix on jagpad #4. Matthias claimed that if this bit (C1 on the jaguar docs) is inactive (at least on Falcon, jagpad bits are all set to 1 when the user doesn't press any button on the pad), then there's a teamtap installed.

That was just what I needed! So I quickly wrote a test program in GFA Basic and sent it to SH3 (I forgot to mention that I don't own a teamtap wink.gif). And that didn't work 100%. It turns out that this bit can change if there's no teamtap installed and the user presses the pause button. Fortunately we noticed that only bit C1 changes when you insert the teamtap in the port. So Matthias' claim was partly correct. The check that works 100% is:

  • if (bit c1 in jagpad #4)=set and (bit c2 in jagpad #4)=set then the user is using a single jagpad without teamtap and pressing pause
  • if (bit c1 in jagpad #4)=unset and (bit c2 in jagpad #4)=set then we have a teamtap! (the trick here is that when a teamtap is installed, then if jagpad #1 pause is set, you don't have any shadowing to the other pads)
  • if (bit c1 in jagpad #4)=unset and (bit c2 in jagpad #4)=unset then we have a normal jagpad, pause is not pressed


(note: "unset" means that the bit is in it's natural state and "set" means it's changed. As I mentioned, on the Falcon it's 1 for unset and 0 for set smile.gif)
(note #2: there's a 4th combination of bits, but I don't think it's possible to achieve this with a normal teamtap, so it's left out)

I hope I didn't screw anything up - after all, I tested at blind (sh3 was my eyes smile.gif). If you find any inaccuracies, please mention them to me so I'll fix the text smile.gif


Addendum: The shitty GFA program I used to test all of the above. It's not anything brainblasting, but at least it works (it's for port #1 btw) and it displays all ports' pad bits in the same screen.

CODE
DO
  PRINT AT(0,1)
  PRINT "teamtap port a"
  SDPOKE &HFFFF9202,&HFFFE
  PRINT BIN$(DPEEK(&HFFFF9200),16)'BIN$(DPEEK(&HFFFF9202),16)
  SDPOKE &HFFFF9202,&HFFFD
  PRINT BIN$(DPEEK(&HFFFF9200),16)'BIN$(DPEEK(&HFFFF9202),16)
  SDPOKE &HFFFF9202,&HFFFB
  PRINT BIN$(DPEEK(&HFFFF9200),16)'BIN$(DPEEK(&HFFFF9202),16)
  SDPOKE &HFFFF9202,&HFFF7
  PRINT BIN$(DPEEK(&HFFFF9200),16)'BIN$(DPEEK(&HFFFF9202),16)
  '
  PRINT "teamtap port b"
  SDPOKE &HFFFF9202,&HFFF0
  PRINT BIN$(DPEEK(&HFFFF9200),16)'BIN$(DPEEK(&HFFFF9202),16)
  SDPOKE &HFFFF9202,&HFFF1
  PRINT BIN$(x1%,16)'BIN$(DPEEK(&HFFFF9202),16)
  SDPOKE &HFFFF9202,&HFFF2
  PRINT BIN$(x2%,16)'BIN$(DPEEK(&HFFFF9202),16)
  SDPOKE &HFFFF9202,&HFFF3
  PRINT BIN$(x3%,16)'BIN$(DPEEK(&HFFFF9202),16)
  '
  PRINT "teamtap port c"
  SDPOKE &HFFFF9202,&HFFF4
  PRINT BIN$(DPEEK(&HFFFF9200),16)'BIN$(DPEEK(&HFFFF9202),16)
  SDPOKE &HFFFF9202,&HFFF5
  PRINT BIN$(x1%,16)'BIN$(DPEEK(&HFFFF9202),16)
  SDPOKE &HFFFF9202,&HFFF6
  PRINT BIN$(x2%,16)'BIN$(DPEEK(&HFFFF9202),16)
  SDPOKE &HFFFF9202,&HFFF8
  PRINT BIN$(x3%,16)'BIN$(DPEEK(&HFFFF9202),16)
  '
  PRINT "teamtap port d"
  SDPOKE &HFFFF9202,&HFFF9
  PRINT BIN$(DPEEK(&HFFFF9200),16)'BIN$(DPEEK(&HFFFF9202),16)
  SDPOKE &HFFFF9202,&HFFFA
  x1%=DPEEK(&HFFFF9200)
  PRINT BIN$(x1%,16)'BIN$(DPEEK(&HFFFF9202),16)
  SDPOKE &HFFFF9202,&HFFFC
  x2%=DPEEK(&HFFFF9200)
  PRINT BIN$(x2%,16)'BIN$(DPEEK(&HFFFF9202),16)
  SDPOKE &HFFFF9202,&HFFFF
  x3%=DPEEK(&HFFFF9200)
  PRINT BIN$(x3%,16)'BIN$(DPEEK(&HFFFF9202),16)
  '
  PRINT
  PRINT "C1=";BTST(x1%,0);", C2=";BTST(x2%,0);", C3=";BTST(x3%,0)
  PRINT "So..."'
  IF BTST(x1%,0)=1 AND BTST(x2%,0)=0
    PRINT "you have a teamtap installed!"
  ELSE
    PRINT "you DO NOT have a teamtap installed!"
  ENDIF
LOOP UNTIL INKEY$<>""
Go to the top of the page
 
+Quote Post
sh3-rg
post 25 Jul 2010, 00:52
Post #26


Super sprint
**

Group: Members
Posts: 338
Joined: 3-6 09
From: bolton, england
Member No.: 227



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

poulpe.gif


--------------------
Would you Push The Button?
"Do not trust people who offer incense" - zerosquare offering some important advice via google translate
Go to the top of the page
 
+Quote Post
Tyrant
post 25 Jul 2010, 11:49
Post #27


Great giana sister
*

Group: Members
Posts: 73
Joined: 17-8 06
From: UK
Member No.: 77



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.


--------------------
Tyr of the Arcana
Aka Tyrant
Go to the top of the page
 
+Quote Post
sh3-rg
post 25 Jul 2010, 13:23
Post #28


Super sprint
**

Group: Members
Posts: 338
Joined: 3-6 09
From: bolton, england
Member No.: 227



wow, thanks for all the infos Tyrant smile.gif


--------------------
Would you Push The Button?
"Do not trust people who offer incense" - zerosquare offering some important advice via google translate
Go to the top of the page
 
+Quote Post
ggn
post 25 Jul 2010, 17:46
Post #29


"Can I hear you say YEAH?"
*

Group: Members
Posts: 167
Joined: 11-8 08
Member No.: 207



QUOTE (Tyr of the Arcana @ 25 Jul 2010, 13:49) *
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 wink.gif

QUOTE (Tyr of the Arcana @ 25 Jul 2010, 13:49) *
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.

QUOTE (Tyr of the Arcana @ 25 Jul 2010, 13:49) *
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 biggrin.gif


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?
Go to the top of the page
 
+Quote Post
Zerosquare
post 25 Jul 2010, 18:15
Post #30


Rick dangerous
***

Group: Administrators
Posts: 2.076
Joined: 4-1 06
Member No.: 30



Great and informative post, Tyrant smile.gif

CITATION(Tyr of the Arcana @ 25 Jul 2010, 12:49) *
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 biggrin.gif

CITATION(Tyr of the Arcana @ 25 Jul 2010, 12:49) *
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.

CITATION(Tyr of the Arcana @ 25 Jul 2010, 12:49) *
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.

CITATION(ggn @ 25 Jul 2010, 18:46) *
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.

CITATION
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 smile.gif
I've also merged Fadest's topic about rotary controllers, and an old topic by GT Turbo about detecting teamtaps.


--------------------
« Mon PC on dirait un Amiga tellement c'est instable » – GT Turbo
« Soit A un niveau d'absurdité, il existe un post N tel que... » – Azrael et al., 2006
Go to the top of the page
 
+Quote Post
ggn
post 19 Dec 2011, 22:21
Post #31


"Can I hear you say YEAH?"
*

Group: Members
Posts: 167
Joined: 11-8 08
Member No.: 207



QUOTE (Zerosquare @ 8 Sep 2009, 19:49) *
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 :

CODE
{
    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 smile.gif). 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 smile.gif.
Go to the top of the page
 
+Quote Post
Zerosquare
post 19 Dec 2011, 23:45
Post #32


Rick dangerous
***

Group: Administrators
Posts: 2.076
Joined: 4-1 06
Member No.: 30



!X in C is X <> 0 in BASIC.
~X in C is NOT X in BASIC.

That's a classic mistake wink.gif


--------------------
« Mon PC on dirait un Amiga tellement c'est instable » – GT Turbo
« Soit A un niveau d'absurdité, il existe un post N tel que... » – Azrael et al., 2006
Go to the top of the page
 
+Quote Post
ggn
post 20 Dec 2011, 07:25
Post #33


"Can I hear you say YEAH?"
*

Group: Members
Posts: 167
Joined: 11-8 08
Member No.: 207



Blah! So if I wanted to understand the code better I should have compiled it and then disassembled it tongue.gif. Why couldn't languages have standard prefixes and stuff? smile.gif
Go to the top of the page
 
+Quote Post

2 Pages V  < 1 2
Fast ReplyReply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



Lo-Fi Version Time is now: 21-4-2014 / 05:33