Wondering if anyone has encountered this. My machine has a coin mech which sends a very brief input through when a coin is dropped. It's working "fine" meaning arcade PCBs recognize the coins with no problem and when I hook up my j-PAC it works as expected if I press down on the coin trigger with my finger and raise it again slowly. If I flip it very fast or drop an actual coin through, the input seems to be too brief for mame (windows?) to notice and it's like no coin was added. Anything I can do?

I have experienced something similar using an early version of Ultimarc's rotary encoder that I bought from eBay: Windows apps (e.g. Noyepad) would recognise the key presses but not MAME! I read that Ultimarc released a revision with longer "key down" times.

In my case, I solved the problem by creating an AutoHotkey that catches the key presses from the encoder and resends to MAME with a longer key press time (maybe 20 ms from memory?) This solved the issue in my case.

Yotsuya, not sure what you mean? The switch works fine, it works with my finger thru the j-pac and adds a credit in mame when I push the wire down. It also works with a PCB either with my finger or a coin dropped through. It doesn't work with the j-pac/mame with a coin drop (it seems to be flipping too fast/brief).

It's a large number of games that don't seem to like the brief coin switch input. What can I do? Is this a MAME issue, driver issue with all those games, or just my coin switch has an unusually brief action? When I use the coin shortcut with p1 start and p1 button 1, it also needs a slightly longer press to work on many games. Longer than just a quick tap.

There are two things I can think of/ have been suggested:

1. Use autohotkey to "catch" when "5" is entered and send a longer input (as suggested above by Paradroid)

2. Andy suggested I attach a 10uf capacitor to the switch + and - terminals which should enlongate the pulse.

I like the autohotkey idea, but my concern is that if I install the PCBs of the games that have the issue in MAME, the coin input may not work. What do you think?

This is to ensure the pulse is actually a true signal.Likewise if you HOLD the coin button for a long period - Many games will report a "Coin Error" - Thinking the switch is shorted.

Obviously some games expect slightly different coin pulse periods - But generally you are safe between 50ms~100ms.

In the past, Most mechanical coin mechs would be connected to a credit pcb which would catch the trigger and output a signal pulse.

So your true solution would be to get a Credit PCB or preferably create a small circuit that holds the signal for a small time (50ms-100ms).It's also worth ensuring the circuit acts as a debounce as many people report issues of multiple credits on a coin trigger.

The cap should just be attached to the metal spades that the wiring plugs into right? Near the top so the plugs can still slide on. So it will just stick out.

That's a standard coin mech switch - And it should work ok.

You have three simple options to try first.1. The switch might be worn out or faulty. They are cheap - But one online at ebay or an online Arcade supplier.2. See the slight angle in the wire, You could bend it some more to give the rotation more action when a coin drops.3. Try the capacitor between the spade connectors as a last resort (From option 1 & 2).

If this coin mech is second hand (Not new) then it is more likely 1 or 2.

<Added>Also, Check the emulation speed of the games that cause this. If your PC is not up to speed - Then the game might see the coin input as a shorter pulse that it actually is.

Update: I tried the cap on the switch and it didn't seem to do anything at all. I also tried another coin microswitch and got same result. It seems a wide variety of games just don't take coin inputs easily. Maybe it's a general MAME problem. Too bad.

Update: I tried the cap on the switch and it didn't seem to do anything at all. I also tried another coin microswitch and got same result. It seems a wide variety of games just don't take coin inputs easily. Maybe it's a general MAME problem. Too bad.

Update: I tried the cap on the switch and it didn't seem to do anything at all. I also tried another coin microswitch and got same result. It seems a wide variety of games just don't take coin inputs easily. Maybe it's a general MAME problem. Too bad.

I played a game of Ketsui (ket)

Looks like what @krick and @yotsuya have mentioned is more than likely the case.ie. Some real games like Ms. Pac-Man has issues with coins falling too fast to trigger a pulse.

The game seems to run fast enough on moderate hardware (Benchmarks @400% on my old machine here).The coin trigger is consistent in it's operation - So it's not emulation slowdowns.

The easiest solution would be to buy a cheap electronic coin mech from ebay ($20).You can then set the coin drop pulse to 100ms - Which should be enough to trigger games like this.

I guess I should be more specific. I want to keep my coin validation and drop etc because they take 100yen coins and are part of my Blast City cabinet. It's just the microswitch part I would like to replace or change to a longer pulse. Is there something I could just replace the little switch with that is programmable?

I guess I should be more specific. I want to keep my coin validation and drop etc because they take 100yen coins and are part of my Blast City cabinet. It's just the microswitch part I would like to replace or change to a longer pulse. Is there something I could just replace the little switch with that is programmable?

No.But you CAN install a Credit PCB - Which should condition the signal to be more acceptable.

Otherwise - Just pull the existing coin mech out (Store it - Don't throw it out) - And install the electronic coin mech.If you get a 5 coin type acceptor - You can program each coin type to signal a credit.eg. 20c, 100yen, Quarter etc.

Just wanted to chime in because I ran into this problem with my coin door as well on my machine with MAME, Specifically with the Cave games. One of the later DoDonpachi games and mmpork is very finicky with coin drops. With mmpork if it's not right it'll spill out a coin mech error and the game will need to be reset.

Iirc, I think I made individual ini files for problem games and screwed with the coin impulse options for those?

Another option is use a directinput enabled version of mame for these games and write an autohotkey script that runs that would keep your coin button held down a little longer. For example if your coin door is mapped to 5 in your encoder you could do:

Setting coin_impulse to 10000 fixed it. Hah! I'm still confused a bit though, does this mean people who own espgaluda and ketsui pcbs can't get credits working with a normal Japanese coin mech? Or are the mame drivers incorrect for those two games?

Setting coin_impulse to 10000 fixed it. Hah! I'm still confused a bit though, does this mean people who own espgaluda and ketsui pcbs can't get credits working with a normal Japanese coin mech? Or are the mame drivers incorrect for those two games?

After some investigation, I now understand how it works - And the value of 10000 is WRONG.

coin_impulse is calculated by the number of frames per second the game runs at (Refresh rate)The game Ketsui (ket) runs at refresh="59.170000" (Lets just say 60fps to make it easy).

So for a 1 second coin pulse, The value of 60 should be used.1 second coin_impulse 602 seconds coin_impulse 1204 seconds coin_impulse 240

WARNING - The coin impulse is a "BYTE" meaning it has a range of 0-255.Any values over this may be either cycling 256 or unpredictable.(Example the value of 256 gives NO coin_impulse and increments up the same as starting from 0)

How did you figure it out? I searched a lot for info on it and found none. I also tried 1, 2, 100, 1000, before landing on 10000 which worked for all games except muchi muchi pork so I made a separate ini for that game with impulse set back to zero.

How did you figure it out? I searched a lot for info on it and found none. I also tried 1, 2, 100, 1000, before landing on 10000 which worked for all games except muchi muchi pork so I made a separate ini for that game with impulse set back to zero.

I'll try 60 I guess and see how it goes.

The first thing I noticed was altering 10000 did not change the impulse time as expected.ie. 20000 didn't make it twice as long.

Then I loaded a game (1944), Entered Service mode (F2) then selected Input test and observed the coin trigger duration.Exit the game, Alter the coin_impulse then checked it again.After a little trial and error, I figured it was cycling 0-255 (Hence 1 byte).

40 works fine for me so I suspect you are right. I just figured that when 100 and 1000 didn't work I needed to go higher.

I gave Ketsui (ket) a check and found the upper and lower values it can accept (Probably a slight variance between machines).# coin_impulse 77 Fails.coin_impulse 7~8 Should be a safe value (~120 to ~135 milliseconds).# coin_impulse 5 Fails.

The lower the value, the faster coins can be accepted.eg. Value of 40 is just over half a second per coin drop.(ie. 60 frames per second, 30 being half)

I still don't get why this is a thing. I know espgaluda and ketsui both ran in Japanese arcades with the same coin drop and cab that I have. Maybe it's a mistake with the mame driver for PGM.

Anyway glad to have a fix.

Perhaps (probably) the coin mech 1st went to a Credit PCB (Very common), Which then signaled the Main game board with a specific coin pulse (~100ms+).

It could be mistake in the driver (I'm not skilled enough to confirm or deny the driver integrity).However - It appears to me that it's the actual game code that is determining what is too short or too long a pulse.

Either way - Something new learned is good and something to keep in mind when other coin issues arise.

I still don't get why this is a thing. I know espgaluda and ketsui both ran in Japanese arcades with the same coin drop and cab that I have. Maybe it's a mistake with the mame driver for PGM.

Anyway glad to have a fix.

There does appear to be a bug in the coin_impulse code, In that the doc say if value is smaller than 0 then disable the impulse.(n<0 disable impulse, n==0 obey driver, 0<n set time n).

However when setting the value to -1 or smaller, The coin_impulse still fires (As if the value was 0 == obey driver which usually means for as long as the key is held down).

<Added>On second thought,It may be that some drivers force a "coin_impulse n" - And the disabling option might be for those specific cases.But generally (most drivers?) would simply make the pulse the length of the key press when obeying the driver.