NEW I-PAC Ultimate I/O Arcade Interface

[AndyWarne]

We are proud to announce the latest arrival to the long-established I-PAC family of arcade interfaces.

This one is our most advanced ever.

This board has so many features its difficult to list them all here but highlights are:

• 48 switch inputs
• 96 RGB constant-current LED outputs
• 6 of the above with 1 amp drivers
• Inputs can be assigned to any keycode, gamepad button, plus mouse buttons, power, volume up/down,
  sleep or wake.
• Wiring harness supplied for 32 input connections. Additional harness options for the other 16 inputs
• Trackball and spinner interface. When enabled these use a total of 6 of the available 48 inputs. Our trackball and spinner simply plug in.
• Example configurations include: 2 player with trackball/spinner. 4 player without trackball/spinner
• Shift functions as on all I-PAC boards
• Our RGB pushbutton LED connections simply plug in.
• 128-command flash storage for configurable attract-mode or test LED sequences.
• Comes with LED power cable for plugging into a PC disk drive power connector
• SDK and LEDBlinky support.
• Brand new fully interactive configuration utility.
• Expansion interface which will support a new range of console adaptors.
• ALL WIRING for 2 player controls is included in the $99 price. Choice of harnesses with pre-crimped connectors.
• An entire illuminated panel with trackball & spinner can be built without having to strip/crimp a single wire.

Available now for immediate delivery from stock.

http://www.ultimarc.com/ipacuio.html

[chopperthedog]

Nice work! Support for 2 analog pots would have been badass.


good day.

[AndyWarne]

Nice work! Support for 2 analog pots would have been badass.


good day.

Can do. Analog capability is already in there, its not visible in the config utility but I can add it if there is a demand.

[yotsuya]

I want to go to there. 

[chopperthedog]

Can do. Analog capability is already in there, its not visible in the config utility but I can add it if there is a demand.

Oh snap! count my vote for that.


good day.

[yotsuya]

I second that. I might convert my JAMMA racer to MAME, and if this supports pots, I'll all in!

[chopperthedog]

I second that. I might convert my JAMMA racer to MAME, and if this supports pots, I'll all in!

Yeah. I've got a pole position panel and pedal burnin a hole in my head. Would gladly pay for all in one control interface.


good day.

[AndyWarne]

I second that. I might convert my JAMMA racer to MAME, and if this supports pots, I'll all in!

Yeah. I've got a pole position panel and pedal burnin a hole in my head. Would gladly pay for all in one control interface.


good day.

Our existing U-HID interface has support for 8 analog axes with calibration and optional dead-zone and auto-center. Also supports pulse mode for gearshift etc. This board does not support RGB LEDs though: www.u-hid.com

This board will continue to be the preferred one for driving and flight sims and was designed for that purpose.

[yotsuya]

I second that. I might convert my JAMMA racer to MAME, and if this supports pots, I'll all in!

Yeah. I've got a pole position panel and pedal burnin a hole in my head. Would gladly pay for all in one control interface.


good day.

Our existing U-HID interface has support for 8 analog axes with calibration and optional dead-zone and auto-center. Also supports pulse mode for gearshift etc. This board does not support RGB LEDs though: www.u-hid.com

This board will continue to be the preferred one for driving and flight sims and was designed for that purpose.

Yes, but COULD the IPIO board work for racers? I like all the additional functionality.

[Lucky S.O.B.]

Very cool board... I really like that all the wiring can be done for you. Unfortunately I am doing a big pedestal control panel with 4 players + Trackball.

Any plans to support us frankenpanel lovers?

[AndyWarne]

Very cool board... I really like that all the wiring can be done for you. Unfortunately I am doing a big pedestal control panel with 4 players + Trackball.

Any plans to support us frankenpanel lovers?

It will support large panels, the harnesses for players 3 and 4 are longer than the main harness. I will add more info on these to the website in the next few days. We also have packs of wires which can be used to lengthen any wire.

[pbj]

How's this different than the Howler?

[Generic Eric]

• ALL WIRING for 2 player controls is included in the $99 price. Choice of harnesses with pre-crimped connectors.
  
• An entire illuminated panel with trackball & spinner can be built without having to strip/crimp a single wire.

That and less screw down terminals.

[BlueGhost]

Can the player 4/spinner inputs handle two spinners?

How are the trackball and spinner inputs seen?  Do they share one mouse input like a mini-pac or do they show up as mouse 1 and mouse 2?

[DeLuSioNal29]

Does this thing work with Steam games that exclusively use the Xbox360 controller?  That seems to be a thorn in our side right now with developers supporting PC keyboard encoders less and less.

Also, can it simultaneously use keyboard and joystick inputs?

D

[AndyWarne]

Can the player 4/spinner inputs handle two spinners?

How are the trackball and spinner inputs seen?  Do they share one mouse input like a mini-pac or do they show up as mouse 1 and mouse 2?

They are seen as one mouse device. Is there a need for two devices, are there games which use a trackball and spinner at the same time? If there is a requirement for this I could easily make a firmware change.

[AndyWarne]

Does this thing work with Steam games that exclusively use the Xbox360 controller?  That seems to be a thorn in our side right now with developers supporting PC keyboard encoders less and less.

Also, can it simultaneously use keyboard and joystick inputs?

D

It can simultaneously send keyboard and joystick inputs.

I am not sure on your other question. If there is a requirement to emulate a real Xbox 360 controller at the USB level, this would be virtually impossible as the connection is heavily encrypted.
But maybe there is no need to emulate it at the USB level. If there is a driver which accepts non-encrypted input available then I could look into it. I need to understand the issue.

[DeLuSioNal29]

Hi Andy,

I believe what I meant to say was does it support Xinput?  One game in particular requires it to function halfway decent on an arcade cabinet:  Injustice:  Gods Among Us (IGAU).

It's been well documented here:
http://forum.arcadecontrols.com/index.php/topic,135996.msg1407123.html#msg1407123

DeLuSioNaL29

[BlueGhost]

Can the player 4/spinner inputs handle two spinners?

How are the trackball and spinner inputs seen?  Do they share one mouse input like a mini-pac or do they show up as mouse 1 and mouse 2?

They are seen as one mouse device. Is there a need for two devices, are there games which use a trackball and spinner at the same time? If there is a requirement for this I could easily make a firmware change.

I was more concerned with bumping the trackball while using the spinner or vice versa.

Will it support one trackball and two spinners?  I'm guessing the spinner inputs allow two axis like the track ball. 

I'm planning to use two spinners for Atari 2600 paddle games.

[pbj]

Running inputs and LED voltage through the same PCB seems like an extraordinarily bad idea to me.  Think I'll sit this one out awhile and see how many of you manage to blow these things up.

 

[AndyWarne]

Running inputs and LED voltage through the same PCB seems like an extraordinarily bad idea to me.  Think I'll sit this one out awhile and see how many of you manage to blow these things up.

 

Strange comment. There are thousands of USB devices which also have external power. In fact in this case the external power is not really external, it comes from the same source, the PC power supply. Its the same 5 volt source. Even if you were to connect the LED voltage directly to the controls no damage would occur.

[AndyWarne]

Will it support one trackball and two spinners?  I'm guessing the spinner inputs allow two axis like the track ball. 

Yes it would.

[rCadeGaming]

Andy, does this use the same debouncing logic as the I-PAC?  You explained the I-PAC's debouncing logic previously in another thread, but when I asked a question about a potential problem, you left the thread without addressing it.  I guess you missed my response.  Can you take a look?  I'm interested in your encoders, but need some more info on this.

http://forum.arcadecontrols.com/index.php/topic,134531.msg1389408.html#msg1389408

Andy, thanks for stopping by.  I'm looking forward to switching to an I-Pac as it seems to be agreed upon as the best encoder for MAME in terms of input lag.

As I understand it, the frequency and duration of contact bounce varies widely among different types of switches, so creating one debounce routine that would work perfectly for all cases would be very difficult.  Being able tweak this when updating our firmware would be amazing.

Could you explain a little bit how the I-Pac's debounce logic works?

On switch closure, there is a trigger and then a second check around 0.5 milliseconds later, to eliminate false triggering from ESD etc, then the input is registered. (note this is a shorter delay than any keyboard). Then, no further transitions of the SAME switch are reported for another 40 milliseconds or so. Different switches are registered during this time.
On switch open there is another delay of around 1 ms to filter out transients then if still open it is confirmed as open on the interface. So you will see that there is a much shorter wait on open than closed, before another transition can be detected. This is because switches don't generally bounce on open to any extent.

Then, no further transitions of the SAME switch are reported for another 40 milliseconds or so.

Andy, I've been lookingn closer into this, and.. is this a typo!?  Do you mean 40 microseconds here?

I wrote something up with an Arduino that reads a single button at high speed and reports state changes back over the serial monitor on the computer.  I've been using it to measure bouncing, as well as trying different debouncing methods and timings.  It runs at around 58kHz polling rate, so it's pretty accurate.  Anyhow, some of my findings agree with the article I linked to.  No quality microswitch bounces for more than a few milliseconds. 

Anyhow, ignoring state changes for 40 milliseconds means ignoring new states for two and a half frames of video at 60Hz.  There are plenty of games in MAME which will accept new states every single frame, and in fact it's needed for certain things, like achieving the maximum firing in rate in some shmups.  This is easy to do with a turbo function triggered by the vertical sync pulse, so long as the encoder will allow it.

[AndyWarne]

Andy, does this use the same debouncing logic as the I-PAC?  You explained the I-PAC's debouncing logic previously in another thread, but when I asked a question about a potential problem, you left the thread without addressing it.  I guess you missed my response.  Can you take a look?  I'm interested in your encoders, but need some more info on this.

http://forum.arcadecontrols.com/index.php/topic,134531.msg1389408.html#msg1389408

Andy, thanks for stopping by.  I'm looking forward to switching to an I-Pac as it seems to be agreed upon as the best encoder for MAME in terms of input lag.

As I understand it, the frequency and duration of contact bounce varies widely among different types of switches, so creating one debounce routine that would work perfectly for all cases would be very difficult.  Being able tweak this when updating our firmware would be amazing.

Could you explain a little bit how the I-Pac's debounce logic works?

On switch closure, there is a trigger and then a second check around 0.5 milliseconds later, to eliminate false triggering from ESD etc, then the input is registered. (note this is a shorter delay than any keyboard). Then, no further transitions of the SAME switch are reported for another 40 milliseconds or so. Different switches are registered during this time.
On switch open there is another delay of around 1 ms to filter out transients then if still open it is confirmed as open on the interface. So you will see that there is a much shorter wait on open than closed, before another transition can be detected. This is because switches don't generally bounce on open to any extent.

Then, no further transitions of the SAME switch are reported for another 40 milliseconds or so.

Andy, I've been lookingn closer into this, and.. is this a typo!?  Do you mean 40 microseconds here?

I wrote something up with an Arduino that reads a single button at high speed and reports state changes back over the serial monitor on the computer.  I've been using it to measure bouncing, as well as trying different debouncing methods and timings.  It runs at around 58kHz polling rate, so it's pretty accurate.  Anyhow, some of my findings agree with the article I linked to.  No quality microswitch bounces for more than a few milliseconds. 

Anyhow, ignoring state changes for 40 milliseconds means ignoring new states for two and a half frames of video at 60Hz.  There are plenty of games in MAME which will accept new states every single frame, and in fact it's needed for certain things, like achieving the maximum firing in rate in some shmups.  This is easy to do with a turbo function triggered by the vertical sync pulse, so long as the encoder will allow it.

I looked onto this in the very early days of the I-PAC many years ago. I found bounce time was between 20 and 60 ms for standard microswitches. Switches made by Cherry, which used to be supplied by Happ were on the high side. I do get the occasional email about visible switch bounce which generally shows up as control problems when moving through game menus etc. My reply is usually to replace the switch but this does not always cure the problem.
The current settings have been determined my years of experience but there is no reason I could not shorten this time, its just a parameter in the firmware.
I am not sure how rapidly its possible to actually press the same button repeatedly. Did you determine this?

[rCadeGaming]

I am not sure how rapidly its possible to actually press the same button repeatedly. Did you determine this?

Yes.  It is easily provable using the shift-pause frame advance method in MAME that many games will accept a new button state each frame.  As I said, this is necessary to achieve the maximum fire rate in some shmups.  Based on your debounce timings, you are ignoring new state changes for about two and half frames.  If the user is able to exceed 24 press and release cycles per second, which is certainly possible, the I-PAC will ignore it, even the though game would have responded favorably if the inputs were passed on to it.  More practically, it is easily possible to provide a change of state exactly every frame by using a turbo-fire circuit triggered by the vertical sync pulse, but the I-PAC will ignore it.

I understand that you've tested a much larger variety of buttons than I have, and that you have to release a single product that will work for a variety of users, but as far as my own buttons and joysticks go I've found from testing that a debounce period of even a whole frame is excessive.

The current settings have been determined my years of experience but there is no reason I could not shorten this time, its just a parameter in the firmware.

This would certainly be the solution for advanced users, but when I emailed you about an IPAC-4 with adjusted or removed debounce periods you told me it would be a $300 custom job with a 6-week wait time.  After that, you didn't respond to any further emails.

[Slippyblade]

If the user is able to exceed 24 press and release cycles per second, which is certainly possible, the I-PAC will ignore it, even the though game would have responded favorably if the inputs were passed on to it.  More practically, it is easily possible to provide a change of state exactly every frame by using a turbo-fire circuit triggered by the vertical sync pulse, but the I-PAC will ignore it.

The only way a person is going to be able to do what you are suggesting is by hacking extra circuits into their buttons.  Just because a game CAN accept those kinds of inputs doesn't mean it was meant to.  I'm all for the ability to cheat and use auto fire buttons and such, but really?  Complaining that you can't turbo fire faster than 24 times per second?  Seems a bit much to me.

[adder]

here's someone who does 32 presses per second...

[rCadeGaming]

If the user is able to exceed 24 press and release cycles per second, which is certainly possible, the I-PAC will ignore it, even the though game would have responded favorably if the inputs were passed on to it.  More practically, it is easily possible to provide a change of state exactly every frame by using a turbo-fire circuit triggered by the vertical sync pulse, but the I-PAC will ignore it.

The only way a person is going to be able to do what you are suggesting is by hacking extra circuits into their buttons.  Just because a game CAN accept those kinds of inputs doesn't mean it was meant to.  I'm all for the ability to cheat and use auto fire buttons and such, but really?  Complaining that you can't turbo fire faster than 24 times per second?  Seems a bit much to me.

It's easily done with an Arduino, I've set it up.  You could also do it cheaper with some logic circuits, but I'm using an Arduino for some other tricks as well.

If you don't wish to get that technical that's fine, but that's no reason to tell others they shouldn't.  The point is that it's a potential issue for advanced users that could be addressed.  The makers of other encoders have been very accommodating in terms of firmware changes.  It's a reasonable request.

here's someone who does 32 presses per second...

There you go.  Is his technique is a little much?  Maybe, but is it right to say that his niche use is in the minority so it doesn't matter?

[adder]

...Is his technique is a little much?  Maybe, but is it right to say that his niche use is in the minority so it doesn't matter?

yep im with u on this,  if i was inspired by that guy in the video and wanted to learn how to do that, it would be nice to have kit which could cope with this kind of onslaught

[AndyWarne]

Yes.  It is easily provable using the shift-pause frame advance method in MAME that many games will accept a new button state each frame.  As I said, this is necessary to achieve the maximum fire rate in some shmups.  Based on your debounce timings, you are ignoring new state changes for about two and half frames.  If the user is able to exceed 24 press and release cycles per second, which is certainly possible, the I-PAC will ignore it,

I recall that your request some time ago was for the debounce to be removed completely. I would not want to do this but if you have an I-PAC 4 with current hardware I can supply firmware with a reduced value. If you consider 32 presses per second is a correct value instead of 24, I will implement this in all our products.

[rCadeGaming]

I understand the reason for using a conservative timing for the general release.  I didn't say it should be exactly 32 presses per second, nor am I presuming to know exactly what it should be as I've only tested the buttons I'm using.  I think it might be good to reduce the 40ms period to something under a frame though (16.67ms assuming 60Hz), but maybe that's too low for some users with lower quality microswitches.  Why not allow the user to adjust it in the U-HID configuration program so that advanced users can tweak it to their own needs, or at least release alternate firmwares on your website with different timings?

The reason I wanted debouncing removed is that I'm running my inputs through an Arduino as kind of a pre-encoder that can remap buttons for console games lacking the appropriate settings, handle turbo-fire, monitor button states for other cabinet functions, etc.  I could handle the debouncing in the Arduino, and in some cases I'll have to, so I didn't want redundant debouncing further down the line.

In any case, is debouncing really necessary for everything in MAME?  It emulates PCB's that were looking at raw inputs.  Real cabinets didn't use encoders.  The buttons just connected directly to the PCB, so shouldn't there be some debouncing built into the game code that is emulated in MAME?  The only exception I can see is if capacitors were used for hardware debouncing, but I don't know how often that was used.

[AndyWarne]

The reason I wanted debouncing removed is that I'm running my inputs through an Arduino as kind of a pre-encoder that can remap buttons for console games lacking the appropriate settings, handle turbo-fire, monitor button states for other cabinet functions, etc.  I could handle the debouncing in the Arduino, and in some cases I'll have to, so I didn't want redundant debouncing further down the line.

In any case, is debouncing really necessary for everything in MAME?  It emulates PCB's that were looking at raw inputs.  Real cabinets didn't use encoders.  The buttons just connected directly to the PCB, so shouldn't there be some debouncing built into the game code that is emulated in MAME?  The only exception I can see is if capacitors were used for hardware debouncing, but I don't know how often that was used.

As I am sure you will understand, customising for one users specific requirements is not usually easy to cost-justify. But making it configurable is an option I will look at.

The feedback I get regarding bounce is specific to actions such as selecting games in a list in a front end, rather than in the actual games. The usual report is something like "I can move up and down the list with my keyboard with no problem but when doing it with the joystick it jumps up/down several lines, the board must be faulty".

[rCadeGaming]

As I am sure you will understand, customising for one users specific requirements is not usually easy to cost-justify. But making it configurable is an option I will look at.

Of course.  I just meant at the minimum you could release one or two alternate firmwares, like one for no debouncing, one for sub-1-frame debouncing, but if you want to make it configurable that is even better.

The feedback I get regarding bounce is specific to actions such as selecting games in a list in a front end, rather than in the actual games. The usual report is something like "I can move up and down the list with my keyboard with no problem but when doing it with the joystick it jumps up/down several lines, the board must be faulty".

That makes sense.  Unlike the game code, the UI in MAME assumes you're using a keyboard, joystick, encoder, etc., that has its own debouncing.

[Edit by DeLuSioNaL29 to correct the quote code so that they appear properly]
[Edit: Haha, thanks Delusional.  I'm usually good about that, but I hastily hit post as I was running out the door]

[SavannahLion]

here's someone who does 32 presses per second...

You know... I'm not trying to bump or debate the issue one way or the other but...

Can that video really be accepted as exemplar? I mean, to achieve 32 pps, he's using two hands. How does this apply to typical gameplay? Does he use his penis to navigate? Is there a shmup where you can go through an entire level without navigating but only if you can machine gun 32 shots per second? I'm really curious to know

[Paul Olson]

here's someone who does 32 presses per second...

You know... I'm not trying to bump or debate the issue one way or the other but...

Can that video really be accepted as exemplar? I mean, to achieve 32 pps, he's using two hands. How does this apply to typical gameplay? Does he use his penis to navigate? Is there a shmup where you can go through an entire level without navigating but only if you can machine gun 32 shots per second? I'm really curious to know

That is how he plays Track & Field, so it could definitely be used on a MAME cab someday. Enough people have seen him play and watched the videos that someone from this community will probably get fairly good at it at some point. I have watched him play and tried it, and it definitely won't be me. My fingers no worky like that. 

[rCadeGaming]

Even if you don't do it with your fingers, too long of a debouncing period will screw up a hardware-based turbo setup, as mentioned several times before.

[jimmer]

I was interested enough to go googling.
Found this http://www.eng.utah.edu/~cs5780/debouncing.pdf

[DeLuSioNal29]

I was interested enough to go googling.
Found this http://www.eng.utah.edu/~cs5780/debouncing.pdf

Thanks for the link.  I read this over coffee this morning and it was well written by the author.  Interesting read!

D

[rockyrocket]

I just noticed the addressable LED strip controller on your site andy - do you have any more info on that?.

[AndyWarne]

I just noticed the addressable LED strip controller on your site andy - do you have any more info on that?.

Just realised the "more info" link in the store was incorrect. I have corrected it. Here is the direct link:

http://www.ultimarc.com/nanoled.html

Let me know if any further questions.