Setting up a Ipac2

battlecat

it's more say probably for cons

A lot of times we have guests over with kids. I like to have it on so that they get an idea of what it was like back in my childhood. Funny enough you can set up all the flashiest game systems you want and at the end of the night they are all fighting over who gets to play the last game of Frogger or Ms Pacman.

caver01

@battlecat said in Setting up a Ipac2:

I do not have a coin button. :(
I have a coin door that takes tokens. :)

So I do not have a "MAME player 1 coin button".

How does this affect things?

Do you have a select button? If so, pressing it will drop coins in MAME.

I think it is cool that you have a coin mech. All MAME is trying to do is accommodate in emulation the inputs that come from a coin mech on a real arcade cabinet. Since many of us don't have the mechanism, we use a pushbutton for dropping coins. That button also serves as SELECT in other emulators (NES, etc), or depending on how you look at it, the SELECT button on gamepads is used to drop coins.

I can see how you might not want to reach down and add a coin just to press a virtual SELECT button, but as @Riverstorm said, there is no "select" function in MAME even though that button does exist on most consoles.

I have seen some interesting ideas from cabinet builders: You could do two wires to the same IPAC input. Wire a P1SELECT button on the control panel AND the coin mechanism to the same IPAC input (two wires from P1COIN, one goes to each). Another idea that I thought was brilliant (this is what I would do with a cabinet build project with a coin mech) was a guy that wired COIN on his IPAC to the REJECT COIN button in his mech, AND the coin drop trigger. In other words, you could put in a real coin and that would trigger the COIN input, or you could push in the red, backlit REJECT COIN part of the mechanism (Coin Return), and this too would trigger the COIN input. I don't know if he had to add a little microswitch to do it, but I loved that because his coin mech would accept tokens or, if you knew about it, you could secretly just push the mech like a button. Very clever.

In any case, COIN=SELECT. Something to keep in mind.

Riverstorm

@battlecat said in Setting up a Ipac2:

@riverstorm said in Setting up a Ipac2:

it's more say probably for cons

A lot of times we have guests over with kids. I like to have it on so that they get an idea of what it was like back in my childhood. Funny enough you can set up all the flashiest game systems you want and at the end of the night they are all fighting over who gets to play the last game of Frogger or Ms Pacman.

I wish but I don't quite have that issue as I can never rally enough interest most days except for my youngest whose always on board. I am hoping on Thanksgiving I might get a few takers. If I had a real arcade size cabinet it might have more appeal too.

It would probably be a downstairs deal as the wife wouldn't allow it upstairs but right now I have stacks and stacks of music CD's (100's and 100's) pulled out and laying all over that I've ripped with EAC/AccurateRip and verified with CUETools for 100% accuracy. I'm ready to just dump the whole shebang now and redesign the space for gaming. That would probably include Kinect as we have a lot of fun with it and possibly darts as it's something I do miss playing. We used to do a lot of bar league playing in the late 80s early 90s that made for an interesting and fun combo when half popped. The good ol' days. :)

@caver01 - thanks for those tips. If a full sized cabinet ever presents itself my way the hidden coin button is truly clever! :)

battlecat

@caver01 said in Setting up a Ipac2:

Do you have a select button? If so, pressing it will drop coins in MAME.

A select button? Hmm no I do not have one of those.

I have two joysticks each with 6 buttons.
I have a P1 and a P2 button.
I have a coin 1 mech and a coin 2 mech.

That is a standard arcade setup.

battlecat

@caver01 said in Setting up a Ipac2:

Another idea that I thought was brilliant (this is what I would do with a cabinet build project with a coin mech) was a guy that wired COIN on his IPAC to the REJECT COIN button in his mech, AND the coin drop trigger. In other words, you could put in a real coin and that would trigger the COIN input, or you could push in the red, backlit REJECT COIN part of the mechanism (Coin Return), and this too would trigger the COIN input. I don't know if he had to add a little microswitch to do it, but I loved that because his coin mech would accept tokens or, if you knew about it, you could secretly just push the mech like a button. Very clever.

That is a neat idea. Of course I don't think that the coin reject button would be a good solution given how much it costs to replace the parts when they wear out and given how many times you need to press it to get a coin it will wear out quickly or just break.

Good idea though.

Riverstorm

@battlecat said in Setting up a Ipac2:

I have a coin 1 mech and a coin 2 mech

I guess I am not even sure how a real coin op door works. Is it an open relay wired to coin-in and common ground?

That is a neat idea. Of course I don't think that the coin reject button would be a good solution given how much it costs to replace the parts when they wear out and given how many times you need to press it to get a coin it will wear out quickly or just break.

I suppose coin doors probably don't have rep specs like buttons but I don't think Caver meant it as a substitution but more of a supplement it in the way of an Easter egg. Definitely wire your coin door and use that primarily but if you're ever jonesing for a game and you scoured the house to no avail for the last remaining quarter you'll be glad you did it.

caver01

@riverstorm There are certainly more sophisticated models available now, but in the early arcade days, the coin mechanism was just at tricky piece of mechanical levers that compare a deposited coin to a reference by size and weight, sometimes with a magnet to reject counterfeit slugs. When the proper coin made it through the mechanism with gravity, it landed on a wire which triggered a microswitch before falling into a collection bin. The microswitch was simply a Normally Open switch with poles wired to the COIN input pin on the arcade motherboard and ground. Functionally, this is just like any other digital input. I suppose the switch itself may not have been interchangeable with the switches used for joysticks or buttons, but electronically, they are equivalent.

So, in MAME, emulating COIN insert was no different then a pushbutton input.

I think the challenge @battlecat (and anyone building a true arcade cabinet) is figuring out how to handle the SELECT input. Sure, it is COIN while inside MAME and FBA, but what about navigating Emulation Station menus--not to mention, using SELECT in console emulators. You certainly don't want to deposit a coin so that ES brings up a particular menu. Or worse, to use default hotkey functions to exit a Libretro emulator, you would have to press P1Start with SELECT, which means you would be pressing start AND depositing a coin--just to exit the emulator!

This is messy business, all so you can have that coin mech working like it would in an arcade without an additional COIN/SELECT button. I didn't fully appreciate the problem until @battlecat explained his cabinet controls. It shouldn't be so complicated, but imagine not having a button setup for SELECT. It makes a lot more sense to me now why one might NEED to change the defaults.

However, this is where IPAC shift can be very handy. You can setup Retroarch for EXIT with ESCAPE, and use IPAC Shift functionality to send that keystroke (P1Start+P2Start). You can also drop a coin using IPAC Shift function by pressing P1Start and Button 1. This sends the "5" key by default. Using this, you would probably need to disable the RetroArch hotkeys with "nul" or move it to another input since you would conflict with P1Start.

Thinking out loud, I would probably recommend that people building a true arcade cabinet should think about what they plan to use to trigger SELECT in ES and other emulators, Using the coin mech is fine for triggering real tokens in MAME, but in ES and others, you would have to use IPAC shift function, assuming you are using an IPAC.

Riverstorm

@caver01 said in Setting up a Ipac2:

You certainly don't want to deposit a coin so that ES brings up a particular menu. Or worse, to use default hotkey functions to exit a Libretro emulator, you would have to press P1Start with SELECT, which means you would be pressing start AND depositing a coin--just to exit the emulator!

That's funny! I thought about a scenario like that last night. If playing Mario Bros. on NES you would need to deposit a coin to select 2 players.

I remember we used to try and tie string around the quarter to see if we could get some free credits but it never worked of course. :)

You can also drop a coin using IPAC Shift function by pressing P1Start and Button 1. This sends the "5" key by default. Using this, you would probably need to disable the RetroArch hotkeys with "nul" or move it to another input since you would conflict with P1Start.

I don't really see a way to utilize the IPAC shift coin-in. Even moving the shift function to another input isn't going to help. I think you would need to disable it altogether.

The first press (P1 Start + Button 1) is fine, the 2nd press is going to start the game, the 3rd is going to have other side effects depending on what's assigned to the shift function.

If you moved the shift key to player 2 start you'd have the same issue as player 1 where a game may start when you don't want it to start. Another side effect is your character is going to be "shooting" or "hopping" while in game due to pressing button 1.

If you move it to the player buttons like "button 1 + button 3" to add coins your character is going to be "shooting" and "hopping" at the same time as your pressing 2 game buttons now.

Move it to the joystick you'll be moving left, right, up or down while entering coins. All these scenarios might get you killed unless you play 1 quarter at a time.

It's not the IPAC as it's aware of itself but Retorarch will immediately enter the first key you press not waiting for the 2nd key press.

You would need a "non-control" button so you might as well add a coin-in button if you have the Retroarch layer in there intercepting keystrokes. I like the idea of wiring it to the coin door to utilize both.

Thinking out loud, I would probably recommend that people building a true arcade cabinet should think about what they plan to use to trigger SELECT in ES and other emulators,

Do you need a shift key if you don't use consoles in a dedicated cabinet? I don't think I ever use it for just MAME. I use button 1 to enter platforms, button 2 to exit back to ES and button 1 to pull up the menu for shutting down, etc. Once in MAME I don't think I use the shift function for anything but I do use the button assigned to it.

caver01

@riverstorm One thing you are forgetting is that IPAC knows you don't want to send P1Start when using shift function. SO, it does not send the "num1" until you release the button. That way, if you do happen to also press Button1, it sends "Num5" (it is the shift function coin drop). Retroarch will only see "5". This is why you sometimes have to press your retroarch hotkeys in reverse order because while you hold P1Start, nothing is getting sent.

It is fair to say that you probably cannot leverage an IPAC-shifted SELECT as a retroharch hotkey. You would need to dedicate some other input to the hotkey, and using the shift key itself can be problematic because of how the IPAC holds back the input until you let go.

Riverstorm

@caver01 said in Setting up a Ipac2:

Using this, you would probably need to disable the RetroArch hotkeys with "nul" or move it to another input since you would conflict with P1Start.

Thinking out loud, I would probably recommend that people building a true arcade cabinet should think about what they plan to use to trigger SELECT in ES and other emulators,

Right, as soon as I left for lunch I knew I made a mistake on the input but had to drive across town to install a VMWare server before the end of the day so I couldn't correct it. Following that logic what is the issue with this statement above? That's what had me thinking a different way. I am already doing exactly what you're describing above with the defaults.

My setup is more of a controller with power, HDMI, Ethernet & USB ports on the back with (P1 Start, P2 Start, Coin-in, 6 buttons & joystick) that you connect to a TV or monitor but no different than a full arcade cab.

Retroarch P1 Start & Select should be fine. It seems like you could even remove your dedicated coin-in (5 button) too! I'll test tonight using the IPAC shift key.

Pressing 1 would send "num1" to start a game. Pressing 1+1SW1 would send "num5" for a credit as the IPAC is holding the shift key until a 2nd key is pressed.

You could then assign input_player1_select = "num5" and you have the select ability without the physical button. This allows your coin door to operate fully but also retain shift functionality without comprising or adding buttons.

This is why you sometimes have to press your retroarch hotkeys in reverse order because while you hold P1Start, nothing is getting sent.

Here's whats happening. If you remove the IPAC (or disabling the IPAC shift keys would probably have the same effect) Retroarch doesn't care if you press 1+2 or 2+1. I would guess some type of polling is happening because you can hold either as long as you like then press the other to exit.

Pressing 1+2 sends escape which is fine if you disabled Retroarch hotkeys and set input_exit_emulator = "escape".

But with the IPAC shift enabled you have to press 2+1 in Retorarch to exit due to 1+2 is sending escape or you could just disable the IPAC shift keys.

When using a non-Libretro cores you need the IPAC shift keys or a dedicated escape key button due to pressing 1+2 is sending escape (MAME default exit). On the other hand pressing 2+1 well that's doing nothing except sending 2+1 in say mam4all or AdvMAME basically non-Libretro cores.

It is fair to say that you probably cannot leverage an IPAC-shifted SELECT as a retroharch hotkey. You would need to dedicate some other input to the hotkey, and using the shift key itself can be problematic because of how the IPAC holds back the input until you let go.

Agreed. Did you see any scenario where the Retroarch select is used in a dedicated MAME cab setting?

caver01

@riverstorm

Agreed. Did you see any scenario where the Retroarch select is used in a dedicated MAME cab setting?

Well, mine has dedicated select buttons because they are the same as COIN, and I have a coin for all four players.

I also have dedicated exit, pause, volume up/down. These are all very handy.

Riverstorm

@caver01 said in Setting up a Ipac2:

Well, mine has dedicated select buttons because they are the same as COIN, and I have a coin for all four players.

I think I see the confusion now. If you're building a dedicated arcade cab you could assign NUL to Select and everything will still work fine. Coin doors, etc. You need the button not the function. Basically Retroarch Select is unused in a MAME environment.

I run mame2003, Atari 2600, NES & SNES. If I set Select to NUL mame2003 is still going to function but what I will break is all the consoles. For example Super Mario Bros. on NES. I wouldn't be able to select between 1 & 2 players because there's no Select button assigned.

I think of Select as a Retroarch "secondary" function. In MAME I have input_save_state = "up" and input_load_state = "down". I can set them both to NUL and everything will still function as intended. I consider them secondary functions that can be disabled. It doesn't change it's primary function of moving up and down.

The same as Retroarch Select I can set it to input_player1_select = "nul" and the primary function of COIN is still working.

caver01

@riverstorm said in Setting up a Ipac2:

Basically Retroarch Select is unused in a MAME environment.

No, you have it wrong. Retroarch SELECT is COIN in MAME. It is arcade games that don’t have SELECT. But you can’t set it to nul in Retroarch because you need it to drop coins. That’s what I have been saying. They are the same input.

The problem is that if you build a cabinet with just a coin mechanism as this input you will have difficulty using the coin mech for when you need SELECT in ES and in console emus. That is why IPAC has a handy shift function. That, and for folks who don’t want to dedicate a button for exit etc.

And in addition, if you are in this situation you might not be able to use the Retroarch hot keys because they might conflict with IPAC shift function by default and it will be impossible to to hit select without using the shift function.

battlecat

WOW Much discussion and WOW now to figure out what it all means. LOL

caver01

I should add, that if you do set SELECT to 'nul' in your RetroArch config, you will break the ability for the system to use other libretro emulators that need SELECT to navigate, etc. The only reason MAME2003 would still let you drop coins is because you have a keyboard interface and MAME2003 sees raw keys alongside the retropad. So, assuming you have IPAC defaults where triggering COIN results in an IPAC "5", MAME2003 will see a coin drop.

However, this won't work in FBA. You need a RetroArch SELECT mapped.

Riverstorm

@caver01 said in Setting up a Ipac2:

No, you have it wrong. Retroarch SELECT is COIN in MAME. It is arcade games that don’t have SELECT. But you can’t set it to nul in Retroarch because you need it to drop coins.

I am not sure if you're just not understanding or guessing for some reason which seems unlike you. Everything is working as described in previous posts. I have this setup and tested both IPAC and keyboard.

Yes, you can say COIN=SELECT instead of SELECT=COIN. I figured for illustrative purposes it was ok as it doesn't interfere with the point. You can also say COIN=SELECT=IPAC=5 or COIN=5. The last statement is true due to lr-mame2003 direct TAB configuration not needing Retroarch SELECT input for COIN. You can spin it any way you want just like the chicken or egg coming first but either way you can set SELECT to NUL and still have COIN functionality in MAME.

As I said it's not needed in a MAME (Libretro or standalone) only environment except FBA which has a seperate config that you can update. It's only needed if you're running consoles in addition to MAME. I think most folks building full size arcade cabs with coin doors and Wells Gardner monitors aren't adding console emus so most should be ok.

If you disable select with input_player1_select = "nul" in /opt/retropie/configs/all/retroarch.cfg. You can start a game, enter coins, play and exit back to ES without the Retroarch SELECT key enabled.

What I think you're forgetting is lr-mame2003 has it's own inputs (TAB) and will accept "num5" for COIN with Retroarch SELECT disabled. So you're able to wire up those coin doors directly to the IPAC COIN input and shouldn't experience issues or need SELECT functionality.

Unless as I said you want to run older consoles in your arcade cab. Even then you'll have some controller input issues as a joystick can't replace every console controller out there properly.

You keep insisting SELECT is used in ES like it has something to do with Retroarch SELECT or COIN. Yes it is but ES has it's own SELECT key and Retroarch has it's own SELECT key. So you can disable Retroarch SELECT without affecting ES functionality.

If you feel more comfortable it's super easy to add an IPAC shift key that equals ES or Retroarch SELECT without adding additional buttons.

The only key I know that will conflict with the defaults is exit in Libretro cores but that's an easy work around without adding a dedicated escape key. I can explain if you want as it can get long but has a good reason. The rest of the hot keys are fine with no conflicts.

A few things that might help is enabling "UI Cancel" to exit as it's default is escape (currently doesn't work) or just disable IPAC shift keys and use Retroarch keys. My current setup.

I am running exactly what I am explaining to you. It seems like you're making this out to be more complicated then it is or it might help to experiment more with Retorarch hotkeys as it's not as complicated as you might think. IPAC shift and Retroarch hotkeys co-exist without much issue. All I can tell you is try what I just wrote if you don't believe me.

caver01

@riverstorm

When you wrote:

Basically Retroarch Select is unused in a MAME environment.

I had to jump in and clarify. What you wrote is just not true. Retroarch does use SELECT in lr-mame. As you know, it is mapped to the COIN input via the retroarch virtual gamepad. This is important because SELECT also gets used by lr-fbalpha for COIN and as Select for other libretro cores. BUT, you are going to tell me again that you are actually doing this and getting away with it in MAME. Right?

The difference in lr-mame2003 is that there is an input bug that only affects keyboard interface users. For us, lr-mame2003 sees dual inputs: one from the virtual retropad ('5' mapped in retroarch as SELECT which triggers COIN) and another from the raw keyboard (a raw '5' that also gets sent to MAME). These inputs come to MAME together at the same time. It is why you cannot do <CODE_NOT> mappings with a keyboard interface (MAME2003 is already seeing two simultaneous inputs). It is also the reason you can get away with setting SELECT to 'nul'. If you block the virtual retropad, the raw key still gets sent. In fact, this bug is also why keys like 'TAB' work in lr-mame2003 even though nothing is mapped in retroarch. You could actually set all player inputs to 'nul' and then <CODE_NOT> mappings like a virtual tankstick for Vindicators, or Toobin will work like they should.

Still, there is no real benefit to setting SELECT to 'nul'. I would not recommend it as part of a general IPAC setup because it prevents other libretro emulators from working. Not everyone using IPAC is going to be exclusive to lr-mame2003 and stand-alone. I'm not. And even if you are building a cabinet with arcade controls and a Wells Gardner CRT, there is no reason to assume you might not want to play NES or some other libretro core that needs SELECT. I certainly want to, and man, would I love to have the real CRT (too bad they are so big).

I get the fact that select still works in ES, but only because you map it on first boot. My notes above sound like I was confounding these settings. I guess I was.

So you can disable Retroarch SELECT without affecting ES functionality.

I guess I am asking, why would you want to disable Retroarch SELECT? All that does is break your ability to use SELECT/COIN in libretro emulators that need it. I would hate to lose lr-fbalpha for NeoGeo games and fighters. And I want to play NES, SNES and still have my Libretro shader. Help me understand why you would disable SELECT in RetroArch?

Riverstorm

@caver01 said in Setting up a Ipac2:

BUT, you are going to tell me again that you are actually doing this and getting away with it in MAME. Right?

I am not sure what you're telling me and asking here.

Help me understand why you would disable SELECT in RetroArch?

How the conversation began. I believe @battlecat said he doesn't have a SELECT button. I added that he should be fine without it. I thought the whole point of the conversation was whether SELECT is needed when using coin doors. It wasn't a question of whether he should disable SELECT. I think it was more of a question of if it's needed if he didn't have it.

It's kind of splitting hairs here. Yes it's used/mapped/configured but no it's not needed in this scenario because of the MAME2003 raw inputs which I have been mentioning from the beginning should work for operating his coin doors without SELECT. I've tested and confirmed this (as long as lr-fbalpha isn't being used).

caver01

@riverstorm said in Setting up a Ipac2:

@caver01 said

BUT, you are going to tell me again that you are actually doing this and getting away with it in MAME. Right?

I am not sure what you're telling me and asking here.

I meant that you were about to reply with something like this:

I've tested and confirmed this (as long as lr-fbalpha isn't being used).

;-)

I don't think it is splitting hairs. It is good discussion. It is debate that will bring us to recommendations for people, possibly even enhanced documentation in the RetroPie Wiki.

This thread has long been referenced in other threads as a source of detail for IPAC users. I assert that as a generality, it is a mistake to conclude that IPAC users don't need SELECT mapped in RetroArch--whether you have coin doors or not--because you don't want to limit yourself to just lr-mame2003 and standalone arcade emulators. That will only generate new forum questions and misunderstanding. My argument for this configuration is that IPAC users who want the most flexibility across any/all emulators will lose functionality by mapping SELECT to 'nul'. It will break their ability to drop coins in lr-fbalpha and will break SELECT in any other libretro console emulators that need it.

Sure, you could say the same thing in the opposite way--that it does not hurt to map SELECT to 'nul' if all you use is standalone and lr-mame2003. But if we put this setting on a spectrum of functionality lost vs. functionality gained in RetroPie, I think we have to admit that mapping SELECT to 'nul' does more harm than good. I just don't think there is a reasonable argument for doing it, while there are several good arguments for mapping it to '5'. It certainly does not hurt anything to have it mapped, but it does create limitations having it set to 'nul'.

Riverstorm

@caver01 said in Setting up a Ipac2:

I don't think it is splitting hairs. It is good discussion. It is debate that will bring us to recommendations for people, possibly even enhanced documentation in the RetroPie Wiki.

Ah ok, I was really confused after reading that statement from the previous post more than once and thought I should ask what he's asking me. Here's his original statement from Battlecat:

A select button? Hmm no I do not have one of those.
I have two joysticks each with 6 buttons.
I have a P1 and a P2 button.
I have a coin 1 mech and a coin 2 mech.
That is a standard arcade setup.

I don't think it was a question of whether he should disable SELECT. I think it was more of a question of if it's needed if he didn't have it in the "standard" arcade setup above.

I was just pointing out that technically he should be ok if he left SELECT unconfigured or disabled. It still equates to the same as no SELECT button but his coin doors should still be hunky-dory wired to COIN except for lr-fbalpha. Looking at fba2x.cfg it seems there's no getting around it either.

I agree someone might be confused. I would leave it enabled as it's extra steps to disable it after initial config and it technically it doesn't hurt anything.

In the future if raw inputs are removed and SELECT is forced then you'll need to utilize the coin door for credits and console select or configure an IPAC shift function and/or wire up a dedicated button. Any of the scenarios should fit the bill.

I think @markwkidd and r-type have been working on lr-mame2000 and after testing it the other night it's neck and neck with lr-mame2003 TAB input now. If they could merge efforts to rid/merge the raw and virtual inputs it would be a huge win! :)