INTRODUCING PROJECT KAJITSU: USB-JAMMA CONTROLLER BASED ON RASPBERRY PI... OH, AND ITS FRE

Jasen Hicks

Hardened Shock Trooper
Joined
Jan 3, 2010
Posts
448
Thanks for posting that up Mike, and please correct me if I am wrong...

Lemony Vengeance,

With some tinkering with the source on your own, you could use all of the outputs of one of the joysticks and map them to the pins as you desired, everything is controlled in software for which button maps to which GPIO pin. When we started we agreed that the goal was to make it as plug and play as possible for the masses; once it was out the technophiles/experimenters could tweak it or change it and see what else they could do with it. Granted, changes to the code in this manner wouldn't be supported and Mike and I don't plan on providing tutorials on how to change the software to do this.

Jasen
 

Lemony Vengeance

Mitt Romney's Hairdresser,
Joined
Jan 30, 2012
Posts
4,204
Thanks for posting that up Mike, and please correct me if I am wrong...

Lemony Vengeance,

With some tinkering with the source on your own, you could use all of the outputs of one of the joysticks and map them to the pins as you desired, everything is controlled in software for which button maps to which GPIO pin. When we started we agreed that the goal was to make it as plug and play as possible for the masses; once it was out the technophiles/experimenters could tweak it or change it and see what else they could do with it. Granted, changes to the code in this manner wouldn't be supported and Mike and I don't plan on providing tutorials on how to change the software to do this.

Jasen

Gotcha. I know what it's like with the whole non support beyond stock thing. I think I'm going to take mike's offer of a bare board and build one out :)
 

Jasen Hicks

Hardened Shock Trooper
Joined
Jan 3, 2010
Posts
448
How will the ground line be connected to the edge, or through the DB15 for each player? I personally don't anticipate modding the OS, unless the serial inputs are needed to upgrade the OS.

In my test, I wired the boards up to a DB15 breakout to connect to my SuperGun. I just tied the two ground pins from the DB15 together and attached to the terminals with the +5V and GND lines. I hooked it up to one of my SuperGuns for testing which uses the common DB15 pinouts.

You could hook the terminal board version up any way you needed to for your application since there is a lot of flexibility there. Using DB15s was just the easiest interface in my case.

Upgrading the OS is simple, just reflash the card. I think mine took about 10 seconds yesterday.
 

undamned

Pleasure Goal
Joined
Jul 28, 2006
Posts
146
Cool project!

What makes this different/better than undamned's board?
Differences:

- Two Controller support
- This hardware hat allows inputs as well opening the aperture for other projects that require inputs into the Pi
- it's all provided free. You can make your own using all of the files provided and contribute to the project with tweaks to code (which we will be providing) to suit your needs. I want to look at the best way to allow people to do this via the freecade site.

Is it better?
- I think it's an alternative. Not better, nor worse. It's using an amazingly fast linux image and a super cheap platform to do something cool.
- I have on if UDs micro controllers and it's a good piece of gear. He did great work with it.
I can agree with this summary, save the free part. The information is free (which is awesome) but the hardware/setup cost will be a wash (comparing to two UD-USB decoders @ $35 ea.) after the cost of the Pi, add-on board, memory card, and time getting that whole setup programmed and running proper.

Also of note, the 2 player "brick" is a blessing and a curse. If you've got a nice big supergun, it shouldn't be hard to find a spot for it. If someone has tight constraints, UD-USB decoders can be distributed wherever they fit best in your system (also great for single controller pad hacks).

What controllers are supported, and is there lag?

In the first release, RC12, Wired XBOX 360 and Wired PS3 Controllers are working with no lag.

How was lag tested?
I can't notice any.

Please, for the love of science, do not claim zero lag based on the fact that you personally can't notice any. At best you could change your description to "no perceivable lag" (which is still very weak because your senses may not be as keen as those of others).

Also, the thinking that just being under 16 ms is good enough only works on paper. The USB inputs/Pi outputs are not part of the game system itself so the game is sampling at a different rate than the Pi which means, you are highly likely to be straddling frames, which means your moves come out at least 1 frame later than they were read. But more noteworthy is the fact that the controllers themselves have lag. You'd be shocked at some of the numbers (I have a Madcatz X360 stick with upwards of 14ms of lag).
-ud
 

mikew

Krauser's Shoe Shiner
10 Year Member
Joined
Mar 28, 2012
Posts
245
I can agree with this summary, save the free part. The information is free (which is awesome) but the hardware/setup cost will be a wash (comparing to two UD-USB decoders @ $35 ea.)

It's actually must less than "two UD-USB decoders @ $35 ea". That's $70! One Pi costs $35, even in small quantities the add-on board could easily be less then $20. If you already own a Pi this costs next to nothing. Since we are comparing numbers here that's about $35 cheaper than UD-USB decoders.

Please, for the love of science, do not claim zero lag based on the fact that you personally can't notice any. At best you could change your description to "no perceivable lag"

Thanks, I love both science and English. Regarding my statement on lag, there's really no difference between saying "I can't notice any" and "no perceivable lag".


Also, the thinking that just being under 16 ms is good enough only works on paper.

It reads and responds much faster than 16ms. The likelyhood of straddling frames decreases as the response time increases. In this case consider it a non-issue but if it turns out to be a problem I certainly can push the input stage harder with all the headroom on these devices.

You'd be shocked at some of the numbers (I have a Madcatz X360 stick with upwards of 14ms of lag).

I'm not shocked there. I don't plan on supporting devices which perform poorly but since it's open source an end user can easily add 3rd party support to the system.
 

ForeverSublime

6400|!!|Kyo Clone
20 Year Member
Joined
Oct 23, 2001
Posts
6,416
Thanks, I love both science and English. Regarding my statement on lag, there's really no difference between saying "I can't notice any" and "no perceivable lag".

The customer doesn't care what you perceive. They're the ones using it.

Your product page actually says "no lag".

The original question was not whether there is or isn't lag, but how it was tested.
 

Jasen Hicks

Hardened Shock Trooper
Joined
Jan 3, 2010
Posts
448
The customer doesn't care what you perceive. They're the ones using it.

Your product page actually says "no lag".

The original question was not whether there is or isn't lag, but how it was tested.

This is a valid point, precision of language matters. We'll make sure to update it.
 

Viewpoint

Art of Typing Wiz, , ,
20 Year Member
Joined
Aug 15, 2000
Posts
6,274
This is a valid point, precision of language matters. We'll make sure to update it.

All I can say is I like this idea. Just don't turn into christoph and you guys will have people seriously interested.
 

mikew

Krauser's Shoe Shiner
10 Year Member
Joined
Mar 28, 2012
Posts
245
The customer doesn't care what you perceive. They're the ones using it.

This project is completely free. To me that means there are no customers, just potential end-users and collaborators. I also didn't want people to argue over what it does, what it doesn't do, is it better than [x,y,z], is the verbiage strange on the website, etc, etc, etc. I really just wanted folks to have inexpensive options for connecting joysticks to their supergun. It was extremely simple to do and when I heard there that similar commercial products existed it made me even more motivated to give it away for $0.00.
 

fluxcore

Another Striker
Joined
Nov 4, 2013
Posts
324
Interesting project, but without some more concrete evidence towards the no-lag situation, it's not all that appealing from a fighting game perspective, I guess. People are often very poor at perceiving lag, especially if there's confirmation bias :)
 

mikew

Krauser's Shoe Shiner
10 Year Member
Joined
Mar 28, 2012
Posts
245
Interesting project, but without some more concrete evidence towards the no-lag situation, it's not all that appealing from a fighting game perspective, I guess. People are often very poor at perceiving lag, especially if there's confirmation bias :)

We've updated our statement, it no longer states "no lag" and now reads "no perceivable lag" . I guess we'll just need to wait and see what others perceive. Is there some kind of lag standard we can test it against? Like a lag test suite of sorts?
 
Last edited:

Xian Xi

JammaNationX,
15 Year Member
Joined
Dec 1, 2005
Posts
27,748
Aren't leg tests a catch-22 anyway since it relies on the user's reaction time? You can't think your way to a faster reaction time.
 

mikew

Krauser's Shoe Shiner
10 Year Member
Joined
Mar 28, 2012
Posts
245
Aren't leg tests a catch-22 anyway since it relies on the user's reaction time? You can't think your way to a faster reaction time.

Right. I'm thinking the best I could do is an end-to-end test with a mixed mode scope. I can trigger on a button press then have the other channel on the output pin of the Kajitsu interface. The difference between the trigger and the falling edge of the output pin would be the total latency.
 

ForeverSublime

6400|!!|Kyo Clone
20 Year Member
Joined
Oct 23, 2001
Posts
6,416
@Xian: Ip Man disagrees. Isn't lag a measurable thing? There's a difference between a delay in milliseconds on an action and opinion of when you should have reacted.

I'm not familiar with the Pi. Could you:

1) Start a timer on the button press and stop the timer when the signal is done running through the Pi?

2) Use an oscilloscope on each end of the Pi to measure at what time the signal enters and exits the Pi? Then compare this with the unit not there at all.

That would get you the numbers. The second part is what is perceivable. You could do something like the "filtered vodka" classification test. You'd have a game people play and there would be a device in between the controls and screen that delays the signal a discreet amount of milliseconds. You'd test perhaps 10 different delay times and ask the gamer to put those 10 plays in order of how much lag they perceived (in the vodka study, this was "put the vodka in order by how many times you think the vodka was filtered - professional tasters actually got this 100% right, while average joes had a breaking point). You could then be able to determine A) a threshold for when people perceive lag or B) a likelihood they will perceive lag depending on a certain amount of actual lag time.

Something I'm currently working on is making me think out loud about this. If anyone is actually interested in this, feel free. The amount of actual measured lag time may be a nail in the coffin, anyway. It may not matter what we perceive if the time is so small.

@Jasen and Mike: I'm not familiar with Pi. I've read that time sensitive projects are usually done with Arduino - since linux inherently adds a layer of processing time on the Pi. What made that different here?
 
Last edited:

Xian Xi

JammaNationX,
15 Year Member
Joined
Dec 1, 2005
Posts
27,748
@Xian: Ip Man disagrees. Isn't lag a measurable thing? There's a difference between a delay in milliseconds on an action and opinion of when you should have reacted.

Since I used to study Kaji Kenpo I can tell you that there is a difference between reaction and anticipation. If you keep doing the same test over and over again you will anticipate a response rather than truly reacting to something.
 

mikew

Krauser's Shoe Shiner
10 Year Member
Joined
Mar 28, 2012
Posts
245
@Jasen and Mike: I'm not familiar with Pi. I've read that time sensitive projects are usually done with Arduino - since linux inherently adds a layer of processing time on the Pi. What made that different here?

Sure, Linux or any multitasking OS will have overhead. These threads run at realtime priorities so I've done some work to minimize that. The lag from the OS would be overshadowed by the lag in USB however. If this sort of inherent lag wasn't acceptable you wouldn't be able to play games in Windows or Linux.
 

Jasen Hicks

Hardened Shock Trooper
Joined
Jan 3, 2010
Posts
448
@Xian: Ip Man disagrees. Isn't lag a measurable thing? There's a difference between a delay in milliseconds on an action and opinion of when you should have reacted.

I'm not familiar with the Pi. Could you:

1) Start a timer on the button press and stop the timer when the signal is done running through the Pi?

2) Use an oscilloscope on each end of the Pi to measure at what time the signal enters and exits the Pi? Then compare this with the unit not there at all.

That would get you the numbers. The second part is what is perceivable. You could do something like the "filtered vodka" classification test. You'd have a game people play and there would be a device in between the controls and screen that delays the signal a discreet amount of milliseconds. You'd test perhaps 10 different delay times and ask the gamer to put those 10 plays in order of how much lag they perceived (in the vodka study, this was "put the vodka in order by how many times you think the vodka was filtered - professional tasters actually got this 100% right, while average joes had a breaking point). You could then be able to determine A) a threshold for when people perceive lag or B) a likelihood they will perceive lag depending on a certain amount of actual lag time.

Something I'm currently working on is making me think out loud about this. If anyone is actually interested in this, feel free. The amount of actual measured lag time may be a nail in the coffin, anyway. It may not matter what we perceive if the time is so small.

@Jasen and Mike: I'm not familiar with Pi. I've read that time sensitive projects are usually done with Arduino - since linux inherently adds a layer of processing time on the Pi. What made that different here?

Mike can add his $.02 as well, but here are the things that make me like the new B+

- 40 GPIO
- i2C support
- 700Mhz processor vs. the 16Mhz processor of the Arduino
- C support vs. the Arduino Environment
- Arduino Shields are at least $15 plus the cost of the Arduino. Pi is $35 and has 4 USB ports on it
- Linux + C is more powerful than Arduino Code
- Since the decoding and encoding of the controllers requires software, the Pi seems like the better choice
- I had a couple on hand

The proper test to tell the overall system lag is what Mike said above, that's the math and technological answer. Naturally, each device you use will have its own value. The XBOX Pad may have more inherent delay or lag from button push to USB output than the PS3 controller, etc.

The second part of the experiment would be interesting because it adds the human factor into it.... fighting game people complain about lag in PCBs all the time and some try to blame the lag on their poor performance. I'm not 100% sold on the lag is causing my bad game theory but that doesn't mean it isn't a factor :-D
 

ForeverSublime

6400|!!|Kyo Clone
20 Year Member
Joined
Oct 23, 2001
Posts
6,416
Since I used to study Kaji Kenpo I can tell you that there is a difference between reaction and anticipation. If you keep doing the same test over and over again you will anticipate a response rather than truly reacting to something.

Good input. Pun intended. Luckily, there are many games that are not reaction based.

Edit: Thanks for the responses, Jasen and Mike.
 
Last edited:

SNKorSWM

So Many Posts
No Time
For Games.
10 Year Member
Joined
Feb 5, 2010
Posts
15,152
If the lag is below 1 frame, then there really is no difference anyways. Your tv can't possibly refresh faster than that.
 

ForeverSublime

6400|!!|Kyo Clone
20 Year Member
Joined
Oct 23, 2001
Posts
6,416
If the lag is below 1 frame, then there really is no difference anyways. Your tv can't possibly refresh faster than that.

But computers process collisions between frames.

Edit: To mean, this isn't a rendering issue, right? Moreover, a collision never had to actually be visible in order for it to register as happened.

Double edit: So, I wonder if people may perceive more lag in older JAMMA games than newer JAMMA games, since the newer hardware - I assume - would have more cycles between the rendered frames. I don't know shit. Just thinking and sharing my potentially embarrassingly wrong ideas.
 
Last edited:

mikew

Krauser's Shoe Shiner
10 Year Member
Joined
Mar 28, 2012
Posts
245
But computers process collisions between frames.

Edit: To mean, this isn't a rendering issue, right? Moreover, a collision never had to actually be visible in order for it to register as happened.

The Kajitsu interface has no reference to the frame rate of the Jamma board its connected to. To minimize the risk of missing the specific VBLANK intervals which are typically used to check joystick input Kajitsu oversamples the input many times faster than VBLANK and quickly represents the joystick status on its output.

We could sync the joystick output to VBLANK but that would introduce 1 frame of lag per output.
 

Razoola

Divine Hand of the UniBIOS,
Staff member
20 Year Member
Joined
Nov 12, 2002
Posts
4,662
I'm not fancy on electrical terms but I want to say something about lag so I hope you guys follow. This applies to the Neo Geo but most arcade games follow the same method of reading the joystick port (CPS-2 does also).

All Neo Geo games read the joystick port state once per frame. This means the joystick is read only 60 times a second. Providing the wireless device can receive and return data wirelessly more than 60 times a second then there will be no extra lag that will affect gameplay regardless of the time it takes the information to travel wirelessly.

To compare to a wired system the same lags apply. For example, the user presses a button just after the Neo Geo has read the joystick port. That joystick state is not going to apply to the game until the next time the joystick is read. In effect there is always lag depending on the time the button is pressed in relation to the next joystick port read so its variable.

When does lag apply? If the Joystick state in a wireless device is transmitted and presented to the target hardware less than 60 times a second (but more than 30 times a second) then there will certainly be lag but its questionable if it could be detected. If its less than 30 times a second then I feel a gamer could notice it.

I hope that makes sense in the case of most arcade games (at least the ones I know about).

Now there are games that may read the joystick port more than 60 times a second, these games may experience lag depending on the speed of the wireless device.

Raz
 
Last edited:
Top