Please do not post a support request without first reading and following the advice in

Some games giving two credits despite DIP switch coinage set for one credit per coin

  • Mame2003.

    As the title states, seeing this in a few games Moon Patrol (mpatrolw), 194X series, and a few others, but not all of the games.

    Went into the DIP settings for all games, and to a game they show one coin = one credit in the coinage configuration. Confirmed coin mech is sending a single key (IPAC) when a coin drops.

    This only happens in mame2003, and not FBA (the only cores I'm using).

    Would welcome suggestions on where to debug this...

    Edit: Adding some detail per read-this-first instructions... And NO, this is NOT solving an issue for commercial use or monetary gain!

    Pi 3b w/official power supply.
    New clean install of RetroPie 4.2 official image.
    USB devices, single IPAC2 (and generic keyboard when isolating IPAC2/coin mech as root cause).
    No error messages from Retroarch's log, or debug.
    Replicating the problem covered in thread.

  • Blew away the cfg file for the questions exhibiting this behavior and things worked correctly. Odd given the coinage configuration. Is there a way to human-read these cfg files?

    Edit: Take that back... same issue started happening again. In 1943 a moment ago I dropped a coin in, the game showed one credit, then after a very brief moment it acted as if another coin was drooped!

  • @mbert0
    I'm not sure why it is importent, I mean, your are not loosing any money with this 'cause someone gets 2 credits out of, idk, one dollar.

  • administrators

    @DarkWolf I don't have any sympathy if he's using this to make money. He did not receive a license for it and therefore I see no need to enable such behaviour.

  • @herb_fargus That is exactly what I thought.. I think I wasn't clear enough
    I mean, why would you care about that if not for that reason...
    I understand why you don't like such things :-)
    Would be a shame if this project gets shut down because of something like this

  • @DarkWolf your assumption couldn't be more wrong, but no offense taken. I've read plenty of threads here and there from asshats trying to make a buck off MAME machines. That said, this cabinet is in my home, for my families use.

    I wouldn't say this is "importent" per-se, but rather more of a curious thing I just can't figure out. Thought it was an electrical fubar on the coin mech, but nope, software. Brass tacks, one coin should give one credit, so it goes on the list of things to fix.

    Additionally, when the kid and I play to beat each others high scores we're rather attentive to the amount of credits we have :)

    So, now that I've defended myself and post, I'd appreciate some help...

  • @herb_fargus while I couldn't agree more with what you said perhaps postpone judgement? :)

  • Global Moderator

    @mbert0 things that happen 'sometimes' definitely don't sound like software problems. ipacs and coin mechs seem much more likely to be causing the problem.

    Confirmed coin mech is sending a single key (IPAC) when a coin drops.

    if it's only sometimes, i don't know how you can confirm this?

    i think the best way to debug this would be to play the same games on your setup without your ipac/coin mech disconnected entirely. use a joypad or whatever.

    i've played a lot of 1942 in mame2003 and never had this issue.

  • @dankcushions Indeed. Aforementioned behavior has been very consistent across games since blowing away the cfg files (e.g. always happens on some games, never on others). List of games is small, roughly ~12 so will do some tests and look for any correlations. Will try and go through the list later a few times and build a list of results.

    Regarding the IPAC, I failed to mention removing it completely and testing using a regular ol' keyboard. Same behavior. I really wish it was an IPAC/coin mech issue, probably be much easier to sort.

    Appreciate the reply.

  • Global Moderator

    @mbert0 ah, i know this issue now. it IS software, but it's not really fixable.

    the problem is this: mame2003 reads the keyboard and the 'joystick' state every frame. the 'joystick' in this case is the retropad abstraction.

    so, when you press your bound 'select' (insert coin) button on your keyboard, mame2003 sees both retropad select AND that keyboard key as well. i guess in this case, when you insert coin it sends two inputs:

    1. retropad select button (insert coin)
    2. the keyboard insert coin key

    so that's two insert coins in the same frame. evidently some games will ignore that, but others might take that as two credits.

    the same issue applies when you use the ipac, as it appears as a keyboard to the system.

    i believe the only way to fix this is to make all the retropad buttons 'null' in your config so it only sees the keyboard keys. or vice versa. i think @caver01 has hit this same issue, and probably explains it better :)

  • @dankcushions hah, that makes sense! Thanks for your insight.

    If there is value to devs I'd be more than happy to open an issue in GitHub and be debug monkey.

    In the meantime for the games the kid and I compete at most often (Frogger, Moon Patrol, and 19XX) I suppose our playtime just doubled before bedtime. I believe this is a win for the kid :)

    Edit: Dumped main and mame-libretro retroarch.cfg files to a Gist ( These are the only configurations in play, no other mapping, remapping, etc. files/configs.

  • @mbert0 I think @dankcushions explained this problem better than I could have. Another workaround might be to remap the coin key using the MAME GUI menu <TAB>. You could just map it to the same key, but when you do, MAME will see BOTH keys at the same time (your raw keyboard/ipac key + the Retropad virtual button). When MAME sees both keys at the same time, it saves the mapping as a <CODE_AND> type of key press. It is effectively saving coin input so that BOTH keys have to be pressed at the same time, as opposed to the default which may allow either to be pressed.

    Remapping is a very easy thing to do that might be a quick way to test. Otherwise, @dankcushions suggestion about setting all retroarch inputs to "nul" would be even better. Or, simply set the SELECT to "nul" as this doubles as the coin button. That way, when you press your coin button/key it only comes from the ipac.

    I ran into a related issue that dank is remembering with this dual key press issue with respect to my early attempts to map <CODE_NOT> key combos to make a single joystick work to control a game that uses dual tanksticks. There is a complicated mapping formula you can use (stuff like, "Left but NOT DOWN" and so on) by pressing one key, they quickly pressing another key twice. It would fail when I tried because MAME thought I was already pressing two keys at the same time (raw keyboard + retropad virtual button). Setting the retroarch inputs to "nul" in the retroarch.cfg allowed me to map only my ipac keys.

    Anyway, didn't think there were other use cases. This is interesting.

  • I have recently been considering, when in the future I do build a cabinet at home, to add such coin mechanisms and buy tokens to reward the kids every now and then, so that they also learn the value of money to some extent, and control their game time. Right now it's just in the living room, with two PS 3 controllers, which is hard to take away :)

    I didn't think someone would have done such a thing already though, though I suppose if at times a second credit would come up I'd more likely tell them that they got lucky rather than worry :) Either way, glad you solved it.

    If you'd want to share the specs/build for your cabinet, would love to hear about it - the more ideas and feedback on what works, the merrier.

  • @mbert0 Ok, apologies for that...
    That was the first thing that comes to my mind first, never thought of something like that...
    I should think about it more next time, sry

  • @DarkWolf no worries, and no offense taken. Join the foot-in-mouth club... I'm a member myself ;)

  • @caver01 @dankcushions thanks very much for the insight and advice. I followed the suggestion to nul-out things in the retroarch config and re-bind MAME itself. Worked, like, a, champ!

  • @pjft Absolutely. PM me and I'd be happy to share. Don't want to hijack this thread.

  • @mbert0
    You could open a new topic in the "Projects and Themes" section so everyone can look at it and maybe find something usefull for them in it

  • @mbert0 said in Some games giving two credits despite DIP switch coinage set for one credit per coin:

    @pjft Absolutely. PM me and I'd be happy to share. Don't want to hijack this thread.

    If only there were PMs here :)

    @DarkWolf 's suggestion is definitely the best!


  • Global Moderator

    @mbert0 i just had a little brain-wave about this, and thought i'd share:

    i tested frogger with my retropad select button (insert player 1 coin) bound to my keyboard button 5, which is the same as the insert player 1 coin keyboard button in frogger. one button doing insert player 1 coin in two different ways.

    i tested, and only 1 credit appeared every time i pressed, and it only seemed to hit the keyboard part of the code. curious...

    in your .cfg:
    input_player1_select = "num6"
    so your retropad select button (insert player 1 coin) is '6' on the keyboard. however, in frogger in mame2003, this is also the default player 2 insert coin. keyboard button so, every time you press this button, you insert a coin for player 1 AND player 2. 2 credits!

    the mame core itself seems to be clever enough to ignore two presses of one button, but it (correctly) registers two separate (as far as it knows) buttons.

    so hopefully this explains the issue a bit better :) i don't think i can fix this. one thing i could do is remove all the default keyboard bindings in mame, which isn't a bad idea, actually.

Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.

Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.