USB "Gamepad" encoder questions

[tetsujin]

Hey,

I'm aware of some of the reasons why people use keyboard encoders when creating control panels, but I find the whole idea of wiring up a game controller as a (PS/2 or USB) keyboard (when there's a perfectly good USB game controller protocol) extremely distasteful.  It seems like a solution straight out of 1992, something I'd have used to play X-Wing or Falcon 3.0.  I'm willing to muddle through the sometimes-lackluster USB gamepad support in some emulators in order to avoid connecting a non-keyboard as though it were a keyboard.  So I have some questions.

First, are there any pre-made USB game controller encoders readily available?  I'm aware of a few options:

- Legacy gameport to USB adaptors (workable, though a bit cheesy and they only support 4 buttons)
- Expensive CH Products encoders supporting not enough buttons (only up to five...)
- USB Gamepad hacks (also workable, if a bit cheesy)
- Console Gamepad hacks with console->USB adaptor (I'd be worried about the extra latency from the protocol translator in the middle...  I'd swear I've been bitten by latency with one of my adaptors...)
- Roll-your-own interface using a PIC (examples here and also on Microchip's website - I may take this route.)

My main interest in finding a pre-made encoder is in skipping the work in building my own and in ensuring that latency in the controls is kept low.  I imagine responsiveness would be good with the roll-my-own solution, but I haven't tested that.  This brings me to the second question:

Are there any significant performance disadvantages to a USB gamepad as compared to a keyboard encoder on a PS/2 or USB interface?  In terms of latency, mainly.  Clearly there are solutions along both routes that give support for the proper number of buttons, etc...

I imagine not, but again I have no idea.  Along similar lines, would the difference in latency between using low-speed USB controllers on a high-speed hub vs. using full-speed USB controllers on a high-speed hub be significant in terms of gameplay?  Or would it even be better to use a USB 1.1 hub with low-speed or full-speed devices, to avoid the intermediate step that high-speed hubs take with slower devices (buffering the data in each direction and re-transmitting it at a different speed)?  Or does it even matter in practical gaming terms?

[krick]

I believe that the latency on a PS/2 keyboard port is always better than a USB port.

I made a post in this thread where I lay out the advantages of PS/2 vs USB in this respect...
http://forum.arcadecontrols.com/index.php/topic,20387.msg164683.html#msg164683

As for the USB 2.0 hub high-speed/full-speed issue, you should definitely read this article...
http://www.tomshardware.com/consumer/20030909/index.html

[NoOne=NBA=]

As far as PRACTICAL differences go, the only ones likely to show their head are:

1) Ease of setup.
Keyboard encoders are alot quicker to hook up than gamepad hacks.

2) If you choose a gamepad hack, the software may not fully support keyswitching by app.
With a keyboard encoder, you can tell P-1 UP to be any key you need for a given app that doesn't support input switching itself.

3) You may find some apps in your desired playlist which will not allow multiple players on the keyboard, but will allow multiple gamepads.

That said, there is not alot of PRACTICAL difference between how most apps handle input on a keyboard vs. a digital gamepad.
You have switches on the device that are either closed, or not closed, and those switches send data via the USB line to let the computer know that you are pressing the switch.
The "perfectly good USB game controller protocol" you mention sends the same TYPE of signals as the keyboard protocol--it just doesn't support as many keys.

I think your aversion to a keyboard encoder is very misplaced, unless you have specific apps that won't support it.
I don't see any reason to reinvent the wheel, as you seem inclined to do, unless there is a way to make it BETTER.

As far as the USB speeds go, I haven't seen any difference between 1.1 devices on a 1.1 port, and 1.1 devices on a 2.0 port.
I don't have any high speed devices to see if there's a practical improvement or not, but I haven't seen any PROBLEMS with the slower devices, so my guess would be that they are sending data fast enough for the processor.
Sending data any faster would likely yield no improvement, from what I can tell.

[tetsujin]

That said, there is not alot of PRACTICAL difference between how most apps handle input on a keyboard vs. a digital gamepad.
You have switches on the device that are either closed, or not closed, and those switches send data via the USB line to let the computer know that you are pressing the switch.

I think your aversion to a keyboard encoder is very misplaced, unless you have specific apps that won't support it.
I don't see any reason to reinvent the wheel, as you seem inclined to do, unless there is a way to make it BETTER.

As I said, I'm aware of the "advantages" of keyboard hacks.  I'm not particularly interested in hearing more about that, unless you wanted to give me some kind of compelling example of a game I'd want to play that won't work with a proper game controller.  If you just want to tell me you feel differently about keyboard encoders, that's fine.  Opinion noted.  But it doesn't answer my questions about whether there's a practical difference.

Reinventing the wheel?  Not really.  I didn't write the USB standard.  I just want to use it.  But what's wrong with doing things differently now and then, huh?

If USB gamepads support fewer keys than a keyboard, that's news to me.  I'd be interested to hear specific details about that.  It seems like even in low-speed the protocol should be able to handle 50-odd buttons...

The one that I suspect may cause me problems is the fact that there will be several USB devices on the bus.  USB has to time-slice between each device on the bus - which is why I thought that using full-speed devices might be a good idea, they'll transfer the same data in less time.  That could be an advantage of a PS/2 keyboard connection, since it's dedicated and all controls will be on it.  Or even a USB keyboard encoder, if it's the only device on the bus, may get polled more frequently by the system.  Or not, I don't know.

But the thing is, I know some of the numbers involved in this equation, and I have a certain level of understanding of the USB protocol and how it works and how that impacts things, but what I don't have is a practical knowledge of how much latency there has to be to cause a problem in the game.  I can't put it in perspective, which is why I'm asking for perspective.

krick: thanks for the info.

[NoOne=NBA=]

I'm going to try to be as nice as possible here.

As I said, I'm aware of the "advantages" of keyboard hacks.

Apparently not because keyboard hacks SUCK!!!
There are NO advantages to a keyboard hack.

Keyboard encoders are NOT keyboard hacks.
They are USB devices--JUST LIKE GAMEPADS.
That's the point I was making.
They send data that says "Hey, this button is pressed".
There is no difference between a button on a virtual keyboard, and a button on a virtual gamepad.

I'm not particularly interested in hearing more about that, unless you wanted to give me some kind of compelling example of a game I'd want to play that won't work with a proper game controller.

I don't KNOW what you want to play.
Unless a particular game you WANT to play won't accept multiple player inputs from a KEYBOARD, you're wasting your time trying to make a bunch of gamepad controllers.

But it doesn't answer my questions about whether there's a practical difference.

There is not alot of PRACTICAL difference between how most apps handle input on a keyboard vs. a digital gamepad.

I thought THAT answered the exact question asked.

Reinventing the wheel?  Not really.  I didn't write the USB standard.  I just want to use it.  But what's wrong with doing things differently now and then, huh?

DIFFERENTLY is one thing, DIFFICULTY is another.
You are planning on making MULTIPLE gamepad encoders, to do what can be done with a SCREWDRIVER on an I-pac.
THAT'S reinventing the wheel in my book.

If USB gamepads support fewer keys than a keyboard, that's news to me.  I'd be interested to hear specific details about that.  It seems like even in low-speed the protocol should be able to handle 50-odd buttons...

You know of an EXISTING gamepad driver with 50 button input?
If so, why are you worried about MULTIPLE gamepads?
Just wire ALL your controls up to ONE, and be done with it.

Wait....that sounds alot like a KEYBOARD encoder, doesn't it?

The one that I suspect may cause me problems is the fact that there will be several USB devices on the bus.  USB has to time-slice between each device on the bus - which is why I thought that using full-speed devices might be a good idea, they'll transfer the same data in less time.  That could be an advantage of a PS/2 keyboard connection, since it's dedicated and all controls will be on it.  Or even a USB keyboard encoder, if it's the only device on the bus, may get polled more frequently by the system.  Or not, I don't know.

Again, why worry about multiple devices if you can hook EVERYBODY up to a 50 button virtual gamepad controller?
And why worry about a 50 key virtual gamepad controller, when you can buy an I-pac4 and be DONE with it?

But the thing is, I know some of the numbers involved in this equation, and I have a certain level of understanding of the USB protocol and how it works and how that impacts things, but what I don't have is a practical knowledge of how much latency there has to be to cause a problem in the game.  I can't put it in perspective, which is why I'm asking for perspective.

That's what I'm saying.
Can you work a screwdriver?
Get an I-pac, or a PS/2 Keywiz if you think the USB latency might be an issue, and FORGET about all that stuff.
Screw the WIRE to the TERMINAL, play the GAME!
No learning, no problems, it just WORKS.

[Tiger-Heli]

I'm not particularly interested in hearing more about that, unless you wanted to give me some kind of compelling example of a game I'd want to play that won't work with a proper game controller.

Microsoft Train Simulator, Auran TRS2004, probably MS Flight Simulator, any host of other PC games will not work very well with a gamepad, but will work with a keyboard.

In general, there are more games that use the keyboard and not the gamepad, and a few - Virtua Tennis (multiplayer) that want a gamepad and not the keyboard.  Sure you can use Joy2Key or other programs to convert the outputs, but it's an extra step.

Having said my piece, the closest think to a pre-made gamepad emulator (and a very good and reasonable one) is DaveB's AKI - http://dave.bit2000.com/

[tetsujin]

Again, why worry about multiple devices if you can hook EVERYBODY up to a 50 button virtual gamepad controller?
And why worry about a 50 key virtual gamepad controller, when you can buy an I-pac4 and be DONE with it?

No learning, no problems, it just WORKS.

I was referring to keyboard encoders when I said "keyboard hacks", because I consider them a hack.  I am familiar with the established definition of "keyboard hack", meaning busting open an off-the-shelf keyboard and rewiring it to game controls.  Poor choice of words on my part.

I think I'm losing focus here.  It's clear to me now that my little rant about them was self-defeating to the point of being flamebait.  I'm sorry, let's put my personal distaste for keyboard encoders aside.  They work, they're a good, practical solution for a lot of people.  I just don't want one.  Can we leave it at that?  Then nobody needs to convince me to stop trying to build a gamepad encoder and buy an I-Pac.

There is not alot of PRACTICAL difference between how most apps handle input on a keyboard vs. a digital gamepad.

I thought THAT answered the exact question asked.

It did, I just have no confidence in your ability to make that statement.  If you are confident in your ability to make that claim, please tell me how you know that there is no significant difference in latency between the two systems.  Similarly, I can't imagine any game I'd want to play that doesn't support USB gamepads.  But maybe I forgot something, who knows?  That's why I was asking for suggestions there.

In terms of numbers, the PS/2 interface uses a 16Khz clock and transmits 11 bits per event - about 2/3 of a milisecond for each event (key pressed or key raised.).  It'll be a bit higher if the PC runs the keyboard bus at the slower speed of 10Khz.  So I would expect that for small numbers of simultaneous events the keyboard interface would have interface-to-host latency of around 1-2ms, with interface-to-program latency somewhat higher.

USB time-slices between the different devices, but each device is able to submit its complete state in a single report.  I'm not entirely sure of the timing - but I think it happens in 1ms slices.  So I'd guess with five USB devices the device-to-host latency would presumably be between 5ms-10ms for any events.

I don't know how much latency there is getting the data from the respective interfaces to the running program, or how these delays compare with software-level delays, and whether these delays are significant in terms of gameplay.  I would guess that the latency might become noticable as it approaches the framerate - so around 20-50ms depending on the game?

It is a fact that there will be multiple USB devices on my MAME box.  Probably between five and ten.  This is a necessary consequence of one of my other design goals.  (Can you guess which one?  It's not that hard...)

But as for the difficulty involved in making a USB encoder, it's really going to be pretty minimal.  The source code is already out there on Microchip's website.  I have a PIC programmer and I know how to use it.  And the USB HID drivers are built in to any OS I would ever consider running.  It really doesn't bother me that I'm going to be putting in a little extra effort: what I'm going to learn from this project is going to be well worth the effort, and my finished control panel will stand as a demonstration of those new skills.  And I won't have had to compromise on matters of taste, or resort to buying and hacking up anything to build the controller.  That's really exciting.

[Tiger-Heli]

tetsujin,

Did you see my comments above?

[Hoagie_one]

That AKI interface is sexsay

[tetsujin]

Did you see my comments above?

Yes I did, thank you.  I know when I say something like "What games would I want to play that expect keyboard controls?" it's all guesswork on anybody else's part, but I appreciate the guesses.  Really, I don't know what's out there that might be worth playing besides MAME and maybe the odd console game.  I suppose I'd enjoy having some of my old PC games on there (maybe X-Wing or Wing Commander) but I think flight simulators and the like are out of the question until I build a panel with flight controls.  I haven't heard of the other games.

Thanks for the link to those encoders, too.  I'm not doing analog or 49-way controls on this panel but it's good to see what's out there.  I'm curious about how these encoders were made (i.e., what kind of microcontroller, etc...)

(EDIT): Ah, I can just make it out in the product photo...  he used the PIC16C745...  On the AKI at least.  I can't tell with the SJC.

[Tiger-Heli]

Thanks for the link to those encoders, too.  I'm not doing analog or 49-way controls on this panel but it's good to see what's out there.

You must not have seen that in addition to five analog axes, the AKI has fourteen pushbutton inputs that register as Gamepad One 1-7 and Gamepad 2 1-7, thus basically acting as a USB gamepad encoder.   

[tetsujin]

Thanks for the link to those encoders, too.  I'm not doing analog or 49-way controls on this panel but it's good to see what's out there.

You must not have seen that in addition to five analog axes, the AKI has fourteen pushbutton inputs that register as Gamepad One 1-7 and Gamepad 2 1-7, thus basically acting as a USB gamepad encoder.   

Yeah, but to make the joystick control the joystick axes I'd need to hook up a resistor network to the switches, and seven buttons per player might not be enough for my control panel.  Plus I could build the same circuit (or a better one) for less money.

But it's still really great to know there's a joystick encoder board out there.  I'd like to try one of Dave's boards sometime.

[NoOne=NBA=]

Tetsujin,

Just so that you know from the start, I'm not trying to be a jerk here, or start a flame war.
You seem to be at least reasonably informed about this, so I am truly interested in your reasoning about the following:

I was referring to keyboard encoders when I said "keyboard hacks", because I consider them a hack.

Why?

A true keyboard HACK will have problems with ghosting, etc...
The encoders are designed to eliminate the matrix issues involved in TRUE keyboards, and send digital signals down the USB, or PS/2 line, so are essentially NOT a keyboard, from a design standpoint--despite being resolved as such by the HID drivers.

Following your definition of a hack to its logical conclusion, if you design a gamepad encoder, to interface your controls to, will it not be a GAMEPAD hack?

I play all kinds of games that will accept input from keyboards, joysticks, gamepads, etc.... and have never seen a PRACTICAL difference in input between them.

The big question I have here is what difference does it make, from a gaming standpoint, whether the device you are planning to design/use sends a "keyboard A key" signal, or a "Joystick Button 1" signal--as long as the RESULTING action, in the game, is the same?

I'm sorry, let's put my personal distaste for keyboard encoders aside.  I just don't want one.

Why?
Again, what LOGICAL reason have you found to opt for SEVERAL gamepad hacks, and the possible difficulties involved, as opposed to a single keyboard encoder?

You even went so far as to say the following, in your original post:

I'm willing to muddle through the sometimes-lackluster USB gamepad support in some emulators in order to avoid connecting a non-keyboard as though it were a keyboard.

That makes absolutely no sense to me.
Why would you INTENTIONALLY opt for a format, that you KNOW has spotty support, just to avoid using a VIABLE, and more importantly FULLY FUNCTIONAL, alternative?

Similarly, I can't imagine any game I'd want to play that doesn't support USB gamepads.  But maybe I forgot something, who knows?  That's why I was asking for suggestions there.

You apparently forgot that you originally DID imagine playing "some emulators with lack-luster gamepad support".

But as for the difficulty involved in making a USB encoder, it's really going to be pretty minimal.  The source code is already out there on Microchip's website.  I have a PIC programmer and I know how to use it.

You have all the tools you need to TRY this, and see how it works.
Why don't you just DO it, and let us know how it worked?
If it doesn't work, you'll be out a few bucks on chips, but you'll KNOW it doesn't work.

what I'm going to learn from this project is going to be well worth the effort, and my finished control panel will stand as a demonstration of those new skills. And I won't have had to compromise on matters of taste, or resort to buying and hacking up anything to build the controller.  That's really exciting.

You seem set on building this the way you want it anyway, so just build it.
The worst that can happen is that you may have to come behind yourself, and wire the controls to a keyboard encoder.
That will leave you out the money for the chips themselves, and time, but not bring the project to a complete halt.

An even better solution would be to pop the money for a keyboard encoder and wire it up BOTH ways, to see if one actually outperforms the other.

If you do learn something useful, please make sure to post back what you learned.
Information sharing is the primary function of this board.


As a side note, the AKI and SJC both use the same components, chips, and circuit board.
The functional difference is in the encoder chip itself.
My guess, not having investigated it fully, is that you could design a fully digital gamepad from the same circuit, replacing the inputs from the 49-way with discreet button inputs.
That was Dave's ORIGINAL plan, until the demand for analog and 49-way support drove him away from it.

[tetsujin]

Just so that you know from the start, I'm not trying to be a jerk here, or start a flame war.

I know you're not.  I just think I started off on the wrong foot, and I wanted to put this to rest.  A lot of people here use keyboard encoders because, like you're saying, they get the job done.  So starting this thread with my tirade about why I hate the whole concept of keyboard encoding game controls was just asking for trouble.

Nevertheless, I am not at all interested in this debate about why you think I should use a keyboard encoder.  I'm a bit of a tech-head and a tech-purist and I want my joysticks to be encoded as joysticks.  That's pretty much it.  I think it's awesome that I can buy a $20 controller that's decked out like a PSX controller, rig up hubs and plug in 50 of the buggers if I want.  All without special drivers.  I just think it's really cool that it's no longer necessary to resort to measures like putting game controller data onto the keyboard bus, like it was 10-15 years ago.

The one emulator that comes to mind that I did have serious problems with USB gamepads is MacMAME.  USB input works in MacMAME but the configuration doesn't.  But my cabinet's not going to have a Mac in it.  Other than that, I'd heard that this was a reason why people use keyboard encoders.  So I think I'll be perfectly content treating ill-behaved software as the exception rather than the rule.

The situation I'm trying to avoid is one where I build the controls and set up the software, and play a bunch of games, and then a few months down the road I or someone else plays a game and realizes, "hey, this is a little laggy, isn't it?"  Or what if it's a problem I'll only see once I've got a four-player console going?  Not something I can easily test on my own.  Plus it's my knee-jerk reaction: if so many people are resorting to putting their game controls onto a keyboard port in this day and age I had to wonder if there was something wrong with the alternative.  I suppose there's probably not.

If you want to continue discussing why I want to encode my joysticks as joysticks, PM me and we can talk all day.  I don't want this thread gunked up any more.  There's actually been some useful information posted.

[krick]

The situation I'm trying to avoid is one where I build the controls and set up the software, and play a bunch of games, and then a few months down the road I or someone else plays a game and realizes, "hey, this is a little laggy, isn't it?"

[tetsujin]

Ultimately, at the BIOS level, they all need to get the attention of the CPU for data transfers by using the IRQ system.  Now with that in mind, consider the fact that the motherboard keyboard controller uses IRQ#1, the second highest priority IRQ and this is a dedicated IRQ that is NEVER shared with any other device.

I read about that in another thread here, but I don't know how significant it really is that the keyboard IRQ has higher priority than the other device IRQs.  The priority only comes into play (I believe) when multiple requests are received simultaneously.  But more to the point, I have a real hard time believing this makes any practical difference.  Because of the nature of USB and the keyboard port we're already talking about latencies on the order of milliseconds.  The interrupt system's latency on a 1Ghz+ processor is probably in the microseconds.  I guess If my USB controller were on IRQ 10 or 11, and some interrupty device on IRQ 9 took a hell of a lot of the CPU's attention, then maybe it would have a measurable impact...  The only other higher-priority IRQs would be 8 (real-time clock, used to set alarms and such) and IRQ 0 and IRQ 1.

Though if anybody more educated than myself on the subject of modern PC internals would like to speak, I'll listen and take notes.

[NoOne=NBA=]

Nevertheless, I am not at all interested in this debate about why you think I should use a keyboard encoder.

That was NEVER the debate here.
I was trying to find out if you had any relevant information on the keyboard vs. gamepad front, that the rest of us should know.
It was never about what YOU should do, but rather about what the REST of us should do.

I'm a bit of a tech-head and a tech-purist and I want my joysticks to be encoded as joysticks. That's pretty much it.

Most of us here are tech-heads, and are always searching for more knowledge about things that interest us.
That's why we were pumping you for information about why you wanted gamepads.
Now we know WHY.
There is no technical reason for it, you just "want to".
THAT is what we were trying to find out.
We don't really care what you hook up, that is your business.
What we want to know is if there was a reason that WE shouldn't be using keyboard encoders.

I think it's awesome that I can buy a $20 controller that's decked out like a PSX controller, rig up hubs and plug in 50 of the buggers if I want.

So are you still planning to make custom encoders, and use arcade controls; or are you just going to plug in a bunch of iShocks, and use them as-is now?

The one emulator that comes to mind that I did have serious problems with USB gamepads is MacMAME.

[tetsujin]

Nevertheless, I am not at all interested in this debate about why you think I should use a keyboard encoder.

That was NEVER the debate here.

The situation I'm trying to avoid is one where I build the controls and set up the software, and play a bunch of games, and then a few months down the road I or someone else plays a game and realizes, "hey, this is a little laggy, isn't it?"  Or what if it's a problem I'll only see once I've got a four-player console going?  Not something I can easily test on my own.

Why not go for the PROVEN method then, and use a PS/2 keyboard encoder for P-1/P-2, and external USB gamepads for P-3/P-4?

Dude, seriously.  I've explained my feelings on this issue.  Enough.

[NoOne=NBA=]

DUDE, this STILL isn't about YOU.
That's the part I'm trying to get you to grasp.
This is about the next guy that comes BEHIND you, wanting to know the same thing.

I offered that solution because it is PROVEN, and you are worried about putting something together that you KNOW will work from the start.
That WILL work for you.

Knowing that, if you want to go put something together that MIGHT work, go for it.
That's what most of us here do anyway.
We buy stuff, we hook it up, we report back to the next guy here, so that HE doesn't have to buy the SAME stuff, and try it himself.
The next guy coming along wanting to know about gamepads may be of a more conservative bent, and want to play it safe.
This information is for HIM.

[crashwg]

Or her! 

[krick]

I guess If my USB controller were on IRQ 10 or 11, and some interrupty device on IRQ 9 took a hell of a lot of the CPU's attention, then maybe it would have a measurable impact...

I don't know what the real world diffence is but keep in mind that in every motherboard I've seen in the last 2 years, the USB controllers share IRQs with PCI slots and/or other onboard devices. Either of these could be something that is very needy like a sound card.  Then add to that the fact that each controller can have a device in each of its two ports, both competing for attention. And then throw USB hubs into the equation.

Though, In the end, like you said, it might not make any noticable difference at all.

[tetsujin]

I guess If my USB controller were on IRQ 10 or 11, and some interrupty device on IRQ 9 took a hell of a lot of the CPU's attention, then maybe it would have a measurable impact...

I don't know what the real world diffence is but keep in mind that in every motherboard I've seen in the last 2 years, the USB controllers share IRQs with PCI slots and/or other onboard devices. Either of these could be something that is very needy like a sound card.  Then add to that the fact that each controller can have a device in each of its two ports, both competing for attention. And then throw USB hubs into the equation.

Yeah, I mean I'm thinking out loud in the forum about what I expect to see in terms of USB performance, but I don't know how much of it is true from a practical standpoint, or what the real implications are.  The "IRQ 1" argument does have some merit, I'll admit...  I just don't know how much.  IRQ conflict issues I can negotiate through the BIOS - I can put devices where I want them. But probably I really won't have a real answer about performance until I've built my devices, unless someone really knowledgable about PC hardware wants to chime in.  I need to read up more on USB, too.

[NoOne=NBA=]

The one caution I can think of is that any STATIC controls are going to need hardwired ID's, like what is included on Dave's boards.

You don't want a beautifully designed panel loading up the controllers in whatever order it feels like THIS time.

[tetsujin]

The one caution I can think of is that any STATIC controls are going to need hardwired ID's, like what is included on Dave's boards.

You don't want a beautifully designed panel loading up the controllers in whatever order it feels like THIS time.

Yeah, I read his FAQs.  Thanks for the heads-up though.

I'm interested in looking at other possible solutions to that.    One that did occur to me is that, if the boards need to have distinct IDs to control how they're assigned by the system, it'd be possible to multiplex some of the control I/O lines to a BCD rotary dial or a set of DIP switches so the ID could be changed.  It'd be possible to add that feature by using one additional I/O line without any impact on the performance of the controls: the additional I/O line (let's call it "DIP Enable") could be an output, set "high" when the controls are in use, and "low" when the controller wants to check the DIP switches.  All the control inputs would be pulled-high, and each switch would connect to an input line and also to the output on a NOT gate attached to "DIP Enable" - so when DIP Enable is high, closed control switches can pull the inputs low, and when DIP enable is low, only the DIP switches can pull the inputs low.

Another option would be to connect all my controls to a single microcontroller.  For my current panel design this is certainly possible.  (two 8-ways, sixteen action buttons and maybe another 8 administrative buttons = 32 inputs.  The planned future four-player panel could pose a problem for this approach, though: four 8-ways, as few as twelve action buttons, 8 admin = 36 inputs, where the 18F4550 only has 34 available I/O lines if I don't multiplex.)  Putting both controllers on a single USB device would give me control over the order in which they're enumerated, which is the main factor determining how they are recognized by the system.

Really, though, I'd like a better software solution to this.  I don't know if it's possible to address a USB device according to where it is connected - like on X-Box where there are four USB ports for the controllers, but it knows which port is which.  If I could get that kind of control at the hub-level, that could do the trick.

Of course, I want my front-end to have some intelligence when it comes to USB device IDs, too: I'd like to be able to use USB device IDs to enable the front-end to enable and disable games according to whether the controller is compatible, and assign mappings in a sensible way.  That brings me back to hard-coding device IDs for the controllers, but for the purpose of identifying a control panel rather than simply establishing an ordinality.  That could prove a very flexible solution, as if I chose to supplement the main panel with some off-the-shelf gamepads, I could create layouts based on those IDs, too.  (But to really work nicely that would still need to rely on being able to determine where the device was plugged in...)

I know all this is possible with keyboard encoders.  I've seen (online) some fine examples of this, using various types of high-density connectors to connect a whole group of controls to an encoder in a modular fashion.  And certainly such setups would be able to use an input or two to identify which CP is connected, allowing the front-end to adapt its behavior accordingly...  I'll more likely give each control panel its own built-in controller so a swapped-out control panel could also be used on a computer, and only require one USB connection and one power connection.

There's also something called a "physical descriptor" that a USB game device can define...  I'm very curious about that, and what it could do for me.

[NoOne=NBA=]

Can you give a quick rundown of what you are envisioning the end product to be here?

Is it a cabinet, with a fixed two player panel on it, that may or may not support add-on gamepads in the future?
A cabinet with swappable control panels?
Separate control boxes that will plug directly into the computer--like gamepads?

You have mentioned several possibilities, so I'm trying to pin it down a bit.

[tetsujin]

Can you give a quick rundown of what you are envisioning the end product to be here?

My plan in a nutshell:

Upright cabinet around 26"-28" wide with swappable panels.  The first will be a two-player fighter configuration with a trackball, possibly a spinner or two added later.  The second (to be built sometime after the cabinet is completed) will be a four-player sticks-and-buttons configuration for Gauntlet, TMNT, Bomberman, etc.

I'm considering options for making USB ports accessible so that I can expand with regular peripherals if I want to quickly (sub-optimally) support other games or more players using gamepads and such.

[NoOne=NBA=]

I think you are trying to make this alot more complicated than it needs to be.

If you approach this in a one encoder/one control set manner, that will leave lots of room on the encoders for admin functions, would still allow for future growth (such as adding a second stick for each player, etc...), and will circumvent alot of the problems you mentioned above regarding controller ID's, etc...

Unless you are planning on having portable controllers, there shouldn't be any need for ID swapping, changability, etc...
The ONLY way that could ever be an issue is if you built an identical set of controllers for a friend, and he brought them to your house to use them.

Do you have plans for any 4-player games that use more than three buttons.
The list you mentioned doesn't include any.
If that list is typical of the games you plan to play, your concerns over latency are pretty unfounded.

[tetsujin]

I think you are trying to make this alot more complicated than it needs to be.

If you approach this in a one encoder/one control set manner, that will leave lots of room on the encoders for admin functions, would still allow for future growth (such as adding a second stick for each player, etc...), and will circumvent alot of the problems you mentioned above regarding controller ID's, etc...

....

Do you have plans for any 4-player games that use more than three buttons.
The list you mentioned doesn't include any.
If that list is typical of the games you plan to play, your concerns over latency are pretty unfounded.

There won't be physical space on the panel for two-player dual-stick on the first panel.  We don't want the panel to be that cluttered anyway.  So I don't need to plan for that.  But I believe I already mentioned wiring my whole 2-player console to one PIC as a possibility.  The nice thing about USB is that a single controller can represent multiple devices - and since they're all one device their enumeration order will be deterministic.  But rest assured, I'm choosing technical challenges that interest me, so nothing is "more complicated than it needs to be".  It's complicated enough to be fun and very, very rewarding.

I don't know of any four-player games that use more than three buttons - not arcade games at least.  (Console games are another matter...)  It's actually more likely the four-player panel would have four buttons per player, but I was saying that "even with as few as three buttons" it couldn't all be done on a single PIC.

Really there's a lot of MAME I haven't played.  I don't know what I'll end up playing.  What would be a good example of a game that's more timing-critical?

[NoOne=NBA=]

But I believe I already mentioned wiring my whole 2-player console to one PIC as a possibility.

Yes.
You weren't SURE that you wanted to do though.
I was pointing out the safe path again--mostly for other's sake.

A single encoder doesn't leave ANY room to grow if you change your mind.
That's the point I was making.
You get two sticks, eight buttons each, two coinups, and two players starts--that leaves you with 4 admin inputs (exit/pause/tab/enter, most likely) provided your design allows you to USE all 32 inputs.

You haven't mentioned any plans for a shift function (which I'm not sure is even possible using gamepad drivers).
That is how the keyboard encoders have been able to overcome this shortfall.

I don't know of any four-player games that use more than three buttons - not arcade games at least.  (Console games are another matter...)

That was the question I was asking.
Are you planning to use this as a console controller as well?
If so, there are ALOT of issues to keep in mind while designing for that.
Alot of the console emulators have SET keymaps; and, if you don't adhere to those, you're out of luck.
Many PC games have that limitation as well.
They expect you to hook up "Gamepad X", or "Gamepad Y".
If your gamepad mapping doesn't match that, it may be poorly supported--if "supported" at all.
If you don't know going in what you HAVE to do for this game, or that one, you could box yourself in with a bad, or completely useless, control set.
Truthfully, MAME is the least of your worries because of how configurable it is.

Something else for you to investigate, while we are on the subject is keymapping.
Dynamic keymapping has been THE reason that the keyboard encoders have been able to overcome the issue of non-adjustable controls on several emulators/games.
They can swap keysets at the push of a button, (or by opening the control panel and telling them to change).
I don't know if you're going to have that option, when designing a gamepad encoder.
Joystick 1 Button 1 is going to BE Joystick 1 Button 1 in the driver--unless you have a method planned out to overcome that.
The drivers themselves just read what is on the "joystick" they see, they don't interpret it, or dynamically alter it.
The I-pac is using an EEPROM, and can thus CHANGE "Input 1" to be whatever key you'd like it to be, with a simple flashing.

It's actually more likely the four-player panel would have four buttons per player, but I was saying that "even with as few as three buttons" it couldn't all be done on a single PIC.

4-p CAN be done on a single encoder, given limited buttons (3/player being max.).
People are doing it all the time with a KeyWiz.
The Shazaam function is the key piece to doing it though.
On the good side, you won't need to worry about that because you're leaving the encoders IN the CP, so you can just use two on the 4-p CP.

Really there's a lot of MAME I haven't played.  I don't know what I'll end up playing.  What would be a good example of a game that's more timing-critical?

I'm not sure what you mean by timing-critical in this question.

[u_rebelscum]

I know most of this has already has been touched, but I thought I'd put my 2 cents in.

First, are there any pre-made USB game controller encoders readily available?

Well, there's always happs interface  If you don't mind $$$.

Are there any significant performance disadvantages to a USB gamepad as compared to a keyboard encoder on a PS/2 or USB interface?  In terms of latency, mainly.

Well, most practical differences were already mentioned, but I'll list the main ones (AFAI care):

keyboard (and "gamepad"): many directX 7+ games only let the keyboard (and each "gamepad") represent one player (can't be split between players).

keyboard: windows only sees "one" keyboard, IOW even if you connected two different keyboards, all apps sees only one unified keyboard.

gamepad: if ID'ed the same, they may switch players on computer reboot.

keyboard: 256 max different "keys" (in windows directX directInput, at least).
joystick: 128 max buttons, 6 axes per joystick device (in windows directX directInput, at least).  (IE: If you have one chip telling the computer it's two joysticks, double that, if three joyticks: triple, ect.)

AFA USB protocols, true there are standard USB keyboard, mouse, and joystick protocols ("protocol" might be too strong a word, though).  However, these do not have to be followed as long as the device driver decodes the non-standard one.  The most commonly not used standard protocol is the mouse one: if you have a 4+ button mouse, or a "two scroll" or "scroll+sideways" or "trackball scroll" mouse (for examples) the standard USB mouse protocol doesn't work, and a different protocol is used.  It's so common, the drivers are standard in XP.

Along similar lines, would the difference in latency between using low-speed USB controllers on a high-speed hub vs. using full-speed USB controllers on a high-speed hub be significant in terms of gameplay?  Or would it even be better to use a USB 1.1 hub with low-speed or full-speed devices, to avoid the intermediate step that high-speed hubs take with slower devices (buffering the data in each direction and re-transmitting it at a different speed)?  Or does it even matter in practical gaming terms?

Does not matter in gaming, usually.  A more likely noticable problem is when you have too many devices on the same root hub (even 4 gamepads + mouse might be too much).  Of course, this really depends on the quality of the external USB hub you use, as some are much worse than others.

[tetsujin]

I know most of this has already has been touched, but I thought I'd put my 2 cents in.

First, are there any pre-made USB game controller encoders readily available?

Well, there's always happs interface  If you don't mind $$$.

Ah, I thought that one was mainly a keyboard encoder.  I guess it encodes with the joystick protocol, too, huh?  I think so, anyway, it's not really clear in the case of the fighting encoder.  That is crazy expensive, though.  I mean, it's probably a good-quality thing, what with the non-volatile coin counter and watchdog timer, but I don't think I'm gonna need that. 

I don't think six axes and 128 buttons is going to be much of a limitation.    I like not having to have special drivers, too.

NBA: I know you can wire four player controls to any encoder with a sufficient number of inputs.  What I was saying is that the PIC I'll be using doesn't have that many inputs.

As for remapping to support games that aren't configurable...  The ideal situation would be for the front-end to handle that.  I launch a game, it sets up the right controls for me.  No button-pressing, no control-panel opening...  And there shouldn't be a need to re-flash an EEPROM to do it either.  Those things can't be re-flashed indefinitely, after all.  I don't see an automated keyboard encoder re-programmer as significantly less complicated a solution than using a software driver to translate the joystick to keycodes for the purpose of running old or otherwise backward software that doesn't support USB joysticks or an adequate level of configurability.  There is the situation you cited where a particular game may support USB game controllers but not have a configurable button mapping...  If I determine that I need to address that at the hardware level I could provide a way for the software to instruct the encoder to change its mapping at runtime.  Hopefully I just won't have to bother with that at all.

And then if I decided to play something like X-Wing with flight controls (I am planning a flight-control panel in the future, but not for a while), the keyboard encoding would have to be fairly sophisticated to handle things like the throttle anyway (repeated +/- throttle keystrokes along with (possibly) zero throttle/half throttle/full throttle to dead-reckon the throttle to match the analog throttle) - something like that could be done in firmware, but it's such a specialized thing it's really better done at the PC level.  That's how I feel, anyway.

That said, though, I think my NES and SNES emulators both support USB joysticks.

"Timing-critical": You said for the games I listed I wouldn't have to worry about control latency.  This means they must not be particularly timing-sensitive games.  So in what games would I have to worry?

[NoOne=NBA=]

"Timing-critical": You said for the games I listed I wouldn't have to worry about control latency.  This means they must not be particularly timing-sensitive games.  So in what games would I have to worry?

I don't think you're going to have timing related problems, which is why that question threw me.
The problem you will most likely run into, with USB on an arcade cabinet, is when too many keys are pressed simultaneously, on a device that doesn't support it.
The potential for that problem increases with the number of players.

When you reach that point, the signs you see will appear similar to packet loss, rather than lag, on a network connection.
You'll hit jump, but the computer will never see that keypress because it filled the packet with other commands.
IIRC, the I-pac2 will only allow 16 simultaneous commands.
(This may have been increased, or could be different)

Two players would be very hard pressed to hit 16 inputs at any given moment.
FOUR players could all be hitting a diagonal, and BOTH action buttons at the same time though.
If someone tries to coinup at that exact moment in time (a difficult feat if you are also hitting both action buttons), a keypress will be dropped somewhere on those packets.
Multiple encoders should reduce this effect because they will be polled independently, and will be able to send their full state on each poll.

I have seen reports of specific devices, and/or hubs, creating problems.
These were easy fixes in most cases, by either removing the device, updating drivers, or in extreme cases, switching one of the devices to the PS/2 port.

[tetsujin]

"Timing-critical": You said for the games I listed I wouldn't have to worry about control latency.  This means they must not be particularly timing-sensitive games.  So in what games would I have to worry?

I don't think you're going to have timing related problems, which is why that question threw me.
The problem you will most likely run into, with USB on an arcade cabinet, is when too many keys are pressed simultaneously, on a device that doesn't support it.
The potential for that problem increases with the number of players.

I see.

For USB Joystick encoders, the encoder could send the entire controller state with each interrupt.  The tradeoff, as best I understand it, relative to a PS/2 keyboard encoder is that a keyboard encoder can send updates every millisecond (unless the host decides to send output to the encoder, in which case the encoder has to wait), but each update is just one state change: one button pressed/released, etc.  But with multiple USB devices being serviced a USB joystick may have to wait 10ms before it can update anything.  So in the same time it takes a USB joystick encoder to update its entire state (including the latency as it waits for its interrupt) a PS/2 keyboard encoder could update between 10-15 buttons (depending on the speed of the PS/2 bus on the host).

A low-speed USB HID device can send I think 8 bytes of payload per interrupt...  that'd be two axes plus 48 buttons.

I don't know how a USB keyboard encoder would behave.  Presumably it'd be the only device on the bus (and therefore get its interrupt every millisecond, or close to it) - I don't know if the commercial encoders are set up this way, but I'd assume that if too many state-changes appear at the same time, some of them may be delayed a millisecond to appear on the next interrupt.  That's how I'd do it.  Since the game is (I imagine) waiting at least 10ms between updating its internal notion of what buttons are being pressed, barring any complications I'd imagine the entire control panel on such a thing could change state and still get there "on-time"...

[Tiger-Heli]

I don't know of any four-player games that use more than three buttons - not arcade games at least. 

Dungeons and Dragons series in MAME . . .

[Lilwolf]

Hate to say it... but...

you still should really look at a keyboard encoder.  Everything you have said is SCREAMING keyboard encoder.

sure... if someone came up with a good usb joystick encoder that would be great... but nobody has yet (Dave??  How many connections can that chip of yours handle?  Consider creating one?)...  But you would find more problems with them. 

But until then... you will not find anything off the shelf work for you.  You could find the fanciest joystick on the market and pull it apart to get its 20 connections...

The speed issues your talking about is bunk though.  The ps2 is fast enough for anything your tlaking about it.   only about 1000 examples are here that are successful.

[Trimoor]

Some things to consider:
Why not use PS/2 for your interface?  No, PS/2 is not just for keyboards.  It's a nice low-latency port that can be configured as a game devide with the proper drivers.

You could take a USB keyboard encoder, and rewrite the program to use the game controller protocol.  This would be almost exactly what you wanted.  With a couple of extra parts, it could even support analog.

You could write new drivers for a standard keyboard encoder, and have the system see it as a game device.

I see your reasons for wanting this.  I have a flight sim that refuses to use anything but a joystick device, even though it would work fine with a digital stick.

[tetsujin]

you still should really look at a keyboard encoder.  Everything you have said is SCREAMING keyboard encoder.

sure... if someone came up with a good usb joystick encoder that would be great... but nobody has yet (Dave??  How many connections can that chip of yours handle?  Consider creating one?)...  But you would find more problems with them. 

The speed issues your talking about is bunk though.  The ps2 is fast enough for anything your tlaking about it.   only about 1000 examples are here that are successful.

Perhaps I can put this very plainly.  Please, no one take offense.

It will be a cold day in hell before I attach a keyboard encoder to my controls.

It's just the way I feel.  It's not like I think any less of people who use keyboard encoders, I simply have my own preferences.  I really don't feel like any of my needs are crying out for a keyboard encoder to save the day, either.  Really, I think keyboard encoders have their limits, too.

And I never said the AT Keyboard interface wasn't fast enough.  Quite the opposite.  All the numbers I've tossed about indicate to me that the AT Keyboard interface will have a best-case latency USB can't match, at least when there's more than one device on the USB bus.  And an average-case and even worst-case performance (assuming the keyboard encoders are designed well - which I assume they are) that's more than adequate for any game.  Speed of keyboard encoders was never a concern for me, though.  The question of speed has always been whether USB gamepads would perform adequately - and based on the reckoning I've done and the feedback I've gotten, I'm satisfied that they will be.

As for Dave's USB Joystick encoder, the reason it doesn't support a lot of inputs is because it uses the 16c745, a 28-pin USB PIC with 22 inputs.  The 40-pin devices support 33-34 inputs total - still not up to the level of some keyboard encoders but it's easy enough to use two...  At this point I've committed to making my own USB joystick encoders, probably with the PIC18F4550.  The exact configuration, however, I've not yet determined.

Tiger-Heli:
Ah, never played it.  There's a lot I haven't played, but because I'm not familiar with a game definitely does not mean I'm not interested in playing it!  Thanks for the tip.  I guess my 4-player panel will have 4 buttons per player, unless I determine that there's a great need for more...

Trimoor: I don't really have any interest in writing (or using) a driver to make a keyboard look like a joystick.  I feel like that's going backwards.

[NoOne=NBA=]

Perhaps I can put this very plainly.  Please, no one take offense.

Why would I take offense, you're yelling at somebody else this time?

[tetsujin]

Perhaps I can put this very plainly.  Please, no one take offense.

Why would I take offense, you're yelling at somebody else this time?

I didn't mean you or anyone else specifically.

It's just that I'm at the polar opposite end of the spectrum from most people on this issue, and sometimes that gets people angry.  Practically everybody uses them, so if I come along with a statement like that some people have a tendency to get defensive.  That's OK, I'm like that sometimes, too.  I don't want anybody to feel that I'm putting their work down.  Different strokes for different folks, you know?

[Trimoor]

If you complete this, will you release the source for the PIC?  That would really help those of us who want to build it ourselves.

Let me try this idea again:  Take a USB keyboard encoder and flash the PIC.  It is now a blank USB device with inputs.  Now write code for the PIC so it sends the inputs through USB using the game controller protocol.  It is no longer a keyboard controller, but a game device.  It's only purpose was a cheap piece of assembled hardware.

[NoOne=NBA=]

I didn't mean you or anyone else specifically.

You did too.
I saw it, right there in black and white.
You said

Please, NoOne take offense.

You didn't single anyone ELSE out, so that comment must have been aimed at ME!

--------------------------------------------------------------------

I don't think you'll run into much anger here, at least from the people who've been here awhile.

Most of the people are genuinely curious, and are still trying to figure out why you would CHOOSE to go a more difficult route, given all the obstacles YOU are presenting, in addition to the ones presented by others.

Trimoor is a great example of this.
He didn't get offended at your post.
He elaborated on his original post.

[tetsujin]

I don't think you'll run into much anger here, at least from the people who've been here awhile.

Most of the people are genuinely curious, and are still trying to figure out why you would CHOOSE to go a more difficult route, given all the obstacles YOU are presenting, in addition to the ones presented by others.

That's good.  It's easy for disagreement to turn into conflict on-line.  I guess I'm a fine example of that.    I should have more faith in you guys!

Trimoor: Sorry I jumped the gun, I guess I didn't understand what you were saying.  I don't know the technical details of the existing keyboard encoders.  I don't know if they are on PICs (and if they are on PICs, they'd probably be the older, one-time programmable ones, which were the only USB PICs until recently.)  If they're not PICs (but rather some other kind of microcontroller) then I currently have neither the hardware nor expertise to re-program them.  Plus if the circuit weren't set up for in-circuit serial programming I'd need to pull the chip to re-flash it, and that would be a pain.

But in any case, it just wouldn't be worth the cost.  It'd cost at least $30-$40 to get the pre-made USB keyboard encoder, and for that much money I could buy all the parts myself and then some.  In terms of wiring it's a very simple circuit: hook up a USB connector, a crystal, and 20-30 screw-in terminals on a general-purpose board and it's good to go.  It won't be as pretty as a custom-printed or custom-etched circuit board, but cheaper and probably easier to work with.

I do generally share my source code.  I don't know how much I'll have to write for the encoder itself, unless I decide to make it support re-mapping the buttons.

[Tiger-Heli]

I didn't mean you or anyone else specifically.

You did too.
I saw it, right there in black and white.
You said

Please, NoOne take offense.

Why does Tetsujin want NoOne to be mad about this - "Please, NoOne take offense".

Sorry . . .

[Hoagie_one]

RAndy just released something you may be interested in

http://forum.arcadecontrols.com/index.php/topic,31677.0.html

[tetsujin]

RAndy just released something you may be interested in

Thanks for the heads-up!