Are all joysticks 60fps?

Tech Talk
#1

and if not, which ones are and aren’t.

In trying to build a programmable stick (arduino x Hori Wireless stick), I ran in to a lot of problems with garbled outputs. If I did
1,2,3,1,2,3,1,2,3 (1F for each input) with Paul in T6, I got lots of variations

http://img834.imageshack.us/img834/328/16667b.png

Simplifying things, I wrote a simple arduino sketch



int pins[10]={22,23,24,25,26,27,28,29,30,31}; //Wireless Hori
//int pins[10]={15,16,17,18,19,3,4,5,6,7}; RAP V3
int i;
void setup()
{  for(i=0;i<10;i++){pinMode(pins*,OUTPUT);}
  //for (i=0;i<10;i++){digitalWrite(pins*,HIGH);}}

void loop()
{digitalWrite(pins[0],HIGH);digitalWrite(pins[4],LOW);
delay(1000/60);
digitalWrite(pins[0],LOW);digitalWrite(pins[4],HIGH);
delay(1000/60);
}

which presses one button for a frame, then releases and presses the other button for a frame, and repeats.

On the Hori wireless this gives
http://img593.imageshack.us/img593/6886/streetfighteriv20110910.png

whereas on the HRAP V3 it gives
http://img718.imageshack.us/img718/6886/streetfighteriv20110910.png
(ignore the fact that the buttons pressed are not the same, the point is one gives a consistent on/off pattern whereas the other is very inconsistent.

So is the wireless jumbling up the commands? I have a strong feeling that on doing something with the Hori Fighting Stick 3 two years ago I suspected something similar.

Are other sticks known to have problems like this?

#2

Uh, didn’t you do that already, a long time ago?

Console and arcade cabinet PCBs will run at the monitor frequency more often than not. . The frequency the controllers are polled at is entirely different. PC versions, I frankly don’t know but I’d expect an even 60Hz. If I were in your place, I’d make sure to have the frequency somewhat easily configurable in your code, with 60Hz and 59.94 Hz being your big ones (59.94 Hz being the refesh rate on NTSC TVs.)

Next, DO NOT USE DELAY! Evar. The time period before each cycle will vary that way. The flow of your code should be something like this.

interupt function ()
{
reset timer count;
set INTERUPT_HIT flag;
}

setup()
{
normal pin setup stuff
setup timer for desired frequency and interrupt.
clear INTERUPT_HIT flag
}

loop()
{
if(INTERUPT_HIT flag is set)
{
(do normal stuff to write to the pins as it should for this new frame.)
clear INTERUPT_HIT flag.
}

}

Lastly, is the wireless Hori common ground? Even if it is, it may not like the way you’re changing the pins, with ‘low output’ for pressed and ‘high output’ for unpressed. You may want to change the unpressed state to ‘input’ using pinMode instead.

#3

I did make a programmable setup a few years ago, I’ve been trying to find a way to make it accessible to other people.

I had used a interrupt function in my main sketch, which did not fix the problem. I used delay in this sketch mainly because I wanted to keep the sketch as simple as possible. Also given that it’s working on the HRAP but not the wireless makes me think that the timing is robust enough for a simple comparison. The main difference to me is that there are no simultaneous presses for the HRAP, but lots with the wireless. I’d also tried direct port manipulation but didn’t manage to get it working.

The wireless seems common ground to me, but the point about setting mode INPUT/OUTPUT is an interesting one.

[Figured it would either be toodles or rufus or both who would set me straight]

#4 


#include "TimerOne.h"
int pins[10]={22,23,24,25,26,27,28,29,30,31}; //Wireless Hori
int frame_advance=0;
unsigned long time;
int i;int pm;
int F=16667;
void setup()
{
  Timer1.initialize(F);
  Timer1.pwm(9,900);
  Timer1.attachInterrupt(FrameAdv);
  digitalWrite(pins[0],1);
  digitalWrite(pins[4],1);

}
void FrameAdv(){frame_advance=1;}

void loop(){if(frame_advance==1){
{pinMode(pins[0],pm);
pinMode(pins[4],abs(pm-1));}
frame_advance=0;
pm=(abs(pm-1));
}}

http://img263.imageshack.us/img263/6886/streetfighteriv20110910.png

Similar result.

#5

HRAP V3 with the same code.
http://img824.imageshack.us/img824/6886/streetfighteriv20110910.png

#6

Sorry it didn’t help, but that code should be much more reliable.
The only other thing I could see as a possibility that isn’t ‘Dont use that wireless pcb’ is the power going to the arduino. Are you powering it via the batteries? If so, try it out with the arduino powered by a reliable 5v power source. If that doesnt help or it already is, then I dont know what to suggest except to not use that controller pcb.

#7

One other thing you can do is to hit stuff for 1/3 of a frame (or some other fraction) rather than a full frame. Then you should be able to see whether you’re getting drift.

I’ve found that the game’s frame rate can vary by whether buttons are pressed or not, and by whether I’m running on the composite or VGA display cable, so having it change because of the sticks doesn’t seem so far fetched. I know that Maj has had timing issues on longer combos with his sticks.

Another option is to just keep checking the clocuallyk.
It has some clunkiness due to roll-over, and can be much less efficient than interrupts.



/*Frame time.  Defaulting to nominal 59.94 Hz. */
unsigned long frame_ticks=16683;
unsigned long frame_ticks_num=22938;
unsigned long frame_ticks_den=65535;

...
void runmacro {
...
  Next_Frame=micros();
...
  do {
...
      Next_Frame+=frame_ticks;
      Fractional_Ticks+=frame_ticks_num;
      if(Fractional_Ticks>=frame_ticks_den) {
         NextFrame+=int(FractionalTicks/frame_ticks_den);
         FractionalTicks%=frame_ticks_den;
      }
...
      while(micros()<NextFrame)
         ;
      setpins(next|held);
...
   } (...)