Main > Main Forum

Sanwa JFL / I-Pac USB

Pages: << < (4/5) > >>

rCadeGaming:

In a lot of fighting games, holding something down or tapping something quickly can make a big difference, so it's very important that the game engine can tell the difference.

It is possible that the I-PAC's software debouncing could be better.  I'm guessing it doesn't have any hardware debouncing, as I can only see on capacitor on the board, and it's probably the decoupling capacitor on the 5v line.

BUT, the arcade PCB's that MAME is emulating read button presses directly, without any encoder in between.  They must have had some debouncing, at least the more advanced games.  The question is if it's in hardware or software, and if MAME would do anything to emulate it if it was in hardware.

It could also be possible that the I-PAC's polling rate just doesn't line well with the way some of the game's software debouncing works.  Have you guys tried overclocking your USB polling rates?

To really get to the bottom of this we'd have to set something up to definitively test the I-PAC's debouncing versus other encoders, and also test suspect games in MAME versus other software.

ahofle:


--- Quote from: fleskebacon on September 18, 2013, 10:29:34 am ---The stick is now still behaving properly after the electronic cleaner job. :)

--- End quote ---

Can you elaborate a little on how you cleaned them?  Did you open up the switches and spray them inside?

AndyWarne:


--- Quote from: ahofle on September 17, 2013, 04:13:52 pm ---Yeah I emailed back and forth with Andy from Ultimarc and he said there is debouncing logic, but it's difficult to make it perfect.  My IPAC is really old (like 2002-2003 timeframe) so I was hoping newer ones would work much better, but it sounds like there are still issues.
I do see the same in game, although it's not as noticeable in most circumstances.  Entering initials as the OP stated is when you can really see it happen.

--- End quote ---
There is nothing wrong with the debounce logic on the I-PAC. If a switch is breaking the contact and making it again when it is being released there is something wrong with the switch. It would be easy to greatly increase the debounce delay but this is not the right way to address a problem with switches. But if anyone wants firmware with a longer delay I can supply it. Not for a 2002 board though unfortunately which don't have upgradeable firmware.

rCadeGaming:

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?

AndyWarne:


--- Quote from: rCadeGaming on September 21, 2013, 04:24:41 pm ---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?

--- End quote ---

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. Adding a debounce delay on open would be possible but might cause correct state changes to be missed.
A very long time ago there were a batch of Cherry switches on the market which, if you looked at the output on an oscilloscope, the contact would make and break very rapidly when the button was held in the close position and simply vibrated, rather than being let go. There were clearly faulty switches and I suspect these switches are also faulty, they likely have tarnished contacts, or possibly the secondary contact at the pivot point of the lever inside is flaky.
Note there are a lot of Sanwa copies out there which may have sub-standard switches.

Pages: << < (4/5) > >>

Go to full version