Setting up a Ipac2

[caver01]

@riverstorm Yeah, this is why it doesn't make sense to set all inputs to NUL. If all you ever do is run lr-mame2003, it would be similar to a stand-alone input strategy. MAME defaults would work as RAW keypresses and you could remap everything in the GUI (but you would not need to). I have considered this approach, but I want other lr-emus to work too (arcade folder). You can do it per-rom as needed. For example, I have a Vindicators zip.cfg file that does just this. I remapped that game's controls to work as a tankstick which was only possible by dropping virtual retropad and relying entirely on MAME raw keypresses.

One thing that I wonder about is this: How does the retropad inputs (A, B, X, Y, L, R) map to MAME inputs. Is RetroPad A -> MAME Button 1? In ES, I basically guessed and got close, but I find I need to remap a few games for my button layout. That's another variable, of course, as everyone builds their panel differently. Some go for a staggered button layout but mine is setup like Street Fighter, with my panel that looks like this:

     UP         SW1   SW2   SW3
LEFT    RIGHT
    DOWN        SW4   SW5   SW6

which for me corresponds to:

     UP         LCTL   LALT   SPAC
LEFT    RIGHT
    DOWN        LSH    X      C

But I am only guessing that this matches the retropad inputs:

     UP         A     B     X
LEFT    RIGT
    DOWN        Y     L     R

SO, if I looked at the MAME GUI menu at the mapping for Button 1, I would see "LCTL or Retropad A" but I don't know if that is what is mapped. The question is, does A from Retropad map to button1, B to 2, X to 3, Y to 4, L to 5 and R to 6? Furthermore, is that scheme consistent across all arcade emus? I just don't know.

[caver01]

@caver01 I expect there are some criss-crossing for some of the inputs. Mine is further complicated by the fact that Players 3 and 4 are sideways on my system, so up is left if you are sitting on the left vertical position facing the screen. This is just too hard to describe, but on my control panel, the players on the vertical ends are rotated clockwise 90 degrees for player 3 (on the left side) and counter-clockwise for player 4 on the right.

In vertical games, these side positions are remapped to player 1 and 2 respectively so vertical games fill the screen, but in 4-player games like Gauntlet, they get remapped again with the rotation accounted for.

I realize, my panel is unique, and it's one of the reasons why I love the flexibility of these layers (but why my example is not well-suited for the basis of a wiki config).

[Riverstorm]

@caver01 said in Setting up a Ipac2:

SO, if I looked at the MAME GUI menu at the mapping for Button 1, I would see "LCTL or Retropad A" but I don't know if that is what is mapped.

I am not sure I fully understand. It seems like it would be a 1 to 1 mapping or even if they are independent does it matter? If you set MAME GUI inputs to "NONE" and press a button to see what the Virtualpad is set to?

My mame2003 default button "P1 Button 1" would be "LCTRL or RetroPad1 B or RetroMouse1 Left Click".

• LCTRL is my keyboard input separate from the joystick or virtualpad.

• RetroPad1 B IS the the virtualpad button B and to MAME it's joystick physical button B?

• RetroMouse1 Left Click is the virtual mouse I guess. :)

When you press the physical button B it sends RetroPad1 B and also physical button B to MAME but you're thinking physical button B might be mapped to virtualpad A or some other virtualpad? What would that help knowing? It seems like it could be figured out with elimination disabling MAME GUI and/or Retroarch inputs? Sorry I think I am completely missing it here.

[caver01]

@riverstorm Look, MAME doesn't have A, B, X, Y etc. It has Button 1, Button 2, etc which, depending on the game, might be represented in the GUI as FIRE, and THRUST, and so on. The A B X Y stuff is layered over the top of MAME so that people with hand-held controllers can look at what they are holding and try to make sense of their buttons.

So, my question was: How is lr-mame2003 configured by default for inputs from Retroarch's virtual retropads? What retropad button (A, B, X, Y, etc) maps to each MAME input (Button1, 2, 3, 4)? Knowing this would help ensure a standardized keyboard mapping that uses MAME defaults as the basis for it. If RetroPad A is programmed to trigger MAME Button1, well then our retroarch.cfg file should have input_player1_a = ctrl if we want it to match MAME defaults. Our control key would be the same input to the emulator, whether RAW or from the virtual gamepad. Same key. I'd just like to see how they each map. Maybe it's in the docs somewhere.

Some of us reverse A and B so on console emulators they positionally match the original controllers, but I want to know the hard-coded defaults from retropad to mame button.

[Riverstorm]

@caver01 said in Setting up a Ipac2:

Look, MAME doesn't have A, B, X, Y etc. It has Button 1, Button 2, etc which, depending on the game, might be represented in the GUI as FIRE, and THRUST, and so on. The A B X Y stuff is layered over the top of MAME so that people with hand-held controllers can look at what they are holding and try to make sense of their buttons.

Some of us reverse A and B so on console emulators they positionally match the original controllers, but I want to know the hard-coded defaults from retropad to mame button.

I wonder if that diagram you were speaking of might come in handy. :) I also reverse my A and B buttons in NES so for example A is on the right and B is on the left. I also do the same for my XBOX joysticks but I never put much though into it as layers or mappings between 1,2,3 and a,b,c.

I can't help to think that lr-mame2003 is not coded from scratch. Basically I think they took the original MAME 0.78 source code and wrapped it in Libretro code.

What I defined as RAW input is the original MAME 0.78 source code. Then there's Retroarch which interfaces with Libretro. I view these two input methods separately and they can also use multiple input devices such as a keyboard, joystick, mouse, etc.

You can completely NUL the Retroarch keyboard inputs and still fully configure and use lr-mame2003 with a keyboard through the MAME GUI. I don't know if this was a side effect (maybe the second/double input?) or intentional so that Retroarch could be disabled and MAME would still be fully playable. To me that shows Libretro is accepting input from another source (the original source) or maybe Libretro isn't aware it's being "bypassed" with RAW inputs.

You can also still use the joystick even though the keyboard inputs are completely disabled. (I would be curious if you could completely NUL the Retroarch joystick inputs and use a joystick exclusively through the MAME GUI too).

This thought for me negates the idea that there's layered mappings/dependencies but inputs are independent of each other from both the MAME source embedded in Libretro and Retroarch passing parameters to Libretro.

When I think of button 1 and 2 in the MAME GUI. I think of fire and jump. When I want to configure the fire or jump button I can choose any key on the keyboard, any button on the joystick or any button on the mouse. I may also use any combination of the 3 input devices at the same time or just two or even just one.

For sure we know we can completely disable (NUL) Retroarch keyboard inputs and lr-mame2003 is still fully functional. Which removes Retroarch from the picture completely and leaves Libretro which is just MAME at the core.

Anyway I am just throwing thoughts out there trying to grasp what you're saying. I look at your diagrams and they make perfect sense but I just don't see any correlation between keyboard (LCTL) and joystick (A) or keyboard (LALT) and joystick (B) or keyboard (SPAC) and joystick (X), etc. They perform the same function such as fire or jump but I don't see them as mapped or tied together but as independent input sources (keyboard and joystick) that can also be NUL or disabled and the other source still functions fine.

[dankcushions]

@riverstorm said in Setting up a Ipac2:

I can't help to think that lr-mame2003 is not coded from scratch. Basically I think they took the original MAME 0.78 source code and wrapped it in Libretro code.
What I defined as RAW input is the original MAME 0.78 source code. Then there's Retroarch which interfaces with Libretro. I view these two input methods separately and they can also use multiple input devices such as a keyboard, joystick, mouse, etc.
You can completely NUL the Retroarch keyboard inputs and still fully configure and use lr-mame2003 with a keyboard through the MAME GUI. I don't know if this was a side effect (maybe the second/double input?) or intentional so that Retroarch could be disabled and MAME would still be fully playable. To me that shows Libretro is accepting input from another source (the original source) or maybe Libretro isn't aware it's being "bypassed" with RAW inputs.

yeah this is correct :)

it's difficult to visualise how both libretro keyboard and libretro joystick can co-exist. there's no elegant solution. i believe recent libretro control changes may accommodate us, though. i need to give it some thought.

[Riverstorm]

@dankcushions said in Setting up a Ipac2:

i believe recent libretro control changes may accommodate us, though. i need to give it some thought.

Nice, that would be great! I know lr-mame2003 is my main game emulator. By the way thanks for the tip on modifying the joystick reset button. It has saved loads of resets while gaming. :)

[caver01]

@riverstorm said in Setting up a Ipac2:

I just don't see any correlation between keyboard (LCTL) and joystick (A) or keyboard (LALT) and joystick (B) or keyboard (SPAC) and joystick (X), etc.

The correlation exists because of retroarch. You define the keys on your keyboard (IPAC) that you want to map to VIRTUAL gamepad inputs. Retroarch passes these virtual inputs (ABXY) to the emulator. So, that's your connection. It is a configured mapping. Sure, you still press a key (or a pushbutton) that triggers a LCONTROL, but then two things happen: 1. That keypress gets interpreted by Retroarch and mapped to button A on an imaginary "joystick/gamepad" controller (RetroPad) and sent to MAME. 2. Meanwhile, the RAW input is also picked up as a keyboard keypress by MAME. So, MAME "hears" two inputs simultaneously--the retroarch button you have configured (that traces all the way back to your keyboard controller) and the raw key that MAME picks up directly.

It's as if pressing a key on the keyboard (button on IPAC) gets split, like a laser can be split into two beams. One beam goes directly into MAME, the other makes its way through Retroarch, changes into Button A, and then a virtual button A goes to MAME.

This is why the MAME GUI shows TWO inputs when you try to map buttons. MAME actually thinks you are pressing two things at the same time.

[Riverstorm]

@caver01 said in Setting up a Ipac2:

@riverstorm said in Setting up a Ipac2:

I just don't see any correlation between keyboard (LCTL) and joystick (A) or keyboard (LALT) and joystick (B) or keyboard (SPAC) and joystick (X), etc.

The correlation exists because of retroarch. You define the keys on your keyboard (IPAC) that you want to map to VIRTUAL gamepad inputs. Retroarch passes these virtual inputs (ABXY) to the emulator. So, that's your connection. It is a configured mapping. Sure, you still press a key (or a pushbutton) that triggers a LCONTROL, but then two things happen: 1. That keypress gets interpreted by Retroarch and mapped to button A on an imaginary "joystick/gamepad" controller (RetroPad) and sent to MAME. 2. Meanwhile, the RAW input is also picked up as a keyboard keypress by MAME. So, MAME "hears" two inputs simultaneously--the retroarch button you have configured (that traces all the way back to your keyboard controller) and the raw key that MAME picks up directly.

It's as if pressing a key on the keyboard (button on IPAC) gets split, like a laser can be split into two beams. One beam goes directly into MAME, the other makes its way through Retroarch, changes into Button A, and then a virtual button A goes to MAME.

This is why the MAME GUI shows TWO inputs when you try to map buttons. MAME actually thinks you are pressing two things at the same time.

I agree with most of this as it's mostly the same as what I have written and I can work with the laser beam analogy to programming! :) Here's where I am confused. These statements below seem like some unnecessary complicated layer or something that just doesn't exist.

How does the retropad inputs (A, B, X, Y, L, R) map to MAME inputs. Is RetroPad A -> MAME Button 1?

MAME doesn't have A, B, X, Y etc. It has Button 1, Button 2, etc

How is lr-mame2003 configured by default for inputs from Retroarch's virtual retropads? What retropad button (A, B, X, Y, etc) maps to each MAME input (Button1, 2, 3, 4)?

Taking an XBOX controller as an example. Assuming there's a driver running that assigns each button a raw value.

Now when you look at the controller config in the Wiki docs. Retroarch Button A is physical button B (red button), etc. Also in this case I think of "Retroarch A" as a variable holding a raw value assigned by the driver. Basically each button has a raw joystick value.

• Retroarch A = (B-red button)
• Retroarch B = (A-green button)
• Retroarch X = (Y-yellow button)
• Retroarch Y = (X-blue button)

Say "Retroarch A" is jump (assigned as default). I press the (B-red button) it passes "Retroarch A" and my character jumps.

Now let's say I want make the (Y-yellow button) the jump button. I go into Retroarch (through the menu) and assign Retroarch A = X. Assignment is based on Retroarch assignments and not the physical button. Now when I press the (Y-yellow button) my character jumps.

X above is not (X-blue button) but (Y-yellow button) it's variable1 = variable2 and not variable1 = raw1 even though variable2 will translate to a raw joystick value.

In both scenarios lr-mame2003 sees "Retroarch A" as the jump button.

The thought being is any button can be remapped to any other button via Retroarch but "Button A" is always the jump button as far as lr-mame2003 is concerned. I don't think it's cross-mapping "button A" to "button 1" but uses the same variable for the entire process. If that makes sense.

As for raw input in MAME that's the driver sending values to MAME directly without intervention from Retroarch.

[caver01]

@riverstorm I don’t know about all of that, but I do know arcade games don’t have ABXY buttons. However, that’s how retroarch maps inputs, so ultimately a retro arch virtual button has to connect to a MAME button. I am just curious how th evirtual lettered buttons map to MAME by default.

[Riverstorm]

@caver01 said in Setting up a Ipac2:

I do know arcade games don’t have ABXY buttons. However, that’s how retroarch maps inputs, so ultimately a retro arch virtual button has to connect to a MAME button.

I always considered A-B-X-Y as labels and nothing more really. It probably started as an A-B joystick (like NES) and then X-Y was added later (like SNES). I imagine a Wiki has the history behind the ABXY naming convention.

It could have just as well been 1-2-3-4. I know 1 is a numeric value but in this context it's just a label as in press button 1 or fire or jump or thrust or whatever label that may be tied to button 1.

The post above was meant to illustrate how the Retroarch buttons are dynamic and may be changed to any button assignment. Inside the GUI it show "User 1 Button 1", etc. Again just to illustrate even Retroarch uses button 1 labels.

Also when looking inside the MAME GUI at button 1 it literally reads "RetroPad1 A" to me that seems to be the map/connect to the ABXY buttons from a joystick and it's assigned by the user.

Looking at it from the other way the MAME GUI button 1 may be mapped to A or B or X or Y from a joystick. Also assigned by the user.

One step further is you may assign button 1 with joystick or mouse input in addition to keyboard.

I am guessing your not talking at a code level like mame_button1=retropad1a or something along those lines.

All these assignments or mappings are dynamic and may be assigned by the user but I still don't think that's going to satisfy your question but it just might be miscommunication in understanding the question. I guess if you do find the answer you're looking for maybe post it here for clarification.

[caver01]

@riverstorm said in Setting up a Ipac2:

I am guessing your not talking at a code level like mame_button1=retropad1a or something along those lines

I am talking about the code level. I realize it is all dynamic, but Button 1 in MAME is coded, whether it represents Jump or Fire is ROM dependent, but in the General Settings, there is a universal default. On the retroarch side, the same applies for Button A for example. When a MAME Libretro core is built, some coder has to make a choice about what button A in retroarch maps to in MAME, regardless of how a user actually choses to configure their controls. It sounds like A --> Button 1, but I'd like to see the list of all of them. That way, if we build a retroarch.cfg file for IPAC users, assuming they leave the keystrokes for their IPAC default, we can ensure that those MAME mappings actually do lead through retroarch and into the correct MAME buttons.

[markwkidd]

@riverstorm said in Setting up a Ipac2:

I always considered A-B-X-Y as labels and nothing more really. It probably started as an A-B joystick (like NES) and then X-Y was added later (like SNES). I imagine a Wiki has the history behind the ABXY naming convention.

Here's the story on the RetroPad abstraction: https://buildbot.libretro.com/docs/specs/retropad/

[markwkidd]

@caver01 said in Setting up a Ipac2:

I am talking about the code level. I realize it is all dynamic, but Button 1 in MAME is coded, whether it represents Jump or Fire is ROM dependent, but in the General Settings, there is a universal default. On the retroarch side, the same applies for Button A for example. When a MAME Libretro core is built, some coder has to make a choice about what button A in retroarch maps to in MAME, regardless of how a user actually choses to configure their controls. It sounds like A --> Button 1, but I'd like to see the list of all of them. That way, if we build a retroarch.cfg file for IPAC users, assuming they leave the keystrokes for their IPAC default, we can ensure that those MAME mappings actually do lead through retroarch and into the correct MAME buttons.

There is a very active discussion about this topic among libretro developers on github right now. I know you have a lot of experience with controls, you may have something to contribute: https://github.com/libretro/fbalpha/issues/141

[caver01]

@markwkidd said in Setting up a Ipac2:

Here's the story on the RetroPad abstraction: https://buildbot.libretro.com/docs/specs/retropad/

Good info. Do you know if there is a reference to how the abstracted RetroPad controls were mapped to the MAME buttons in lr-mame2003? If I knew where to look I suppose it is probably in one of the source files. Having that, I think we really could build a standard reference .cfg for IPAC owners, at least where defaults are used.

[markwkidd]

@caver01 said in Setting up a Ipac2:

@markwkidd said in Setting up a Ipac2:

Here's the story on the RetroPad abstraction: https://buildbot.libretro.com/docs/specs/retropad/

Good info. Do you know if there is a reference to how the abstracted RetroPad controls were mapped to the MAME buttons in lr-mame2003? If I knew where to look I suppose it is probably in one of the source files. Having that, I think we really could build a standard reference .cfg for IPAC owners, at least where defaults are used.

I think it's somewhere in here: https://github.com/libretro/mame2003-libretro/blob/master/src/input.c

You may need to refer to this: https://github.com/libretro/mame2003-libretro/blob/master/src/input.h

I will try to look for the specific place in the code once I have some time. @dankcushions might know that answer right off the bat though.

[caver01]

@markwkidd said in Setting up a Ipac2:

There is a very active discussion about this topic among libretro developers

Thanks for that link. I think my voice would be drowning in hand-held gamepad users, as that seems to align with the way the abstraction was conceived which is fine, but when the dust settles, there can be a standard MAME mapping for folks who use keyboard controllers and organize their buttons as one might expect on an arcade control panel: first button 1, then button 2, and so on. A typical arcade layout won't resemble the most common gamepad button positions, which is why there is so much discussion.

[markwkidd]

@caver01 said in Setting up a Ipac2:

@markwkidd said in Setting up a Ipac2:

There is a very active discussion about this topic among libretro developers

Thanks for that link. I think my voice would be drowning in hand-held gamepad users, as that seems to align with the way the abstraction was conceived which is fine, but when the dust settles, there can be a standard MAME mapping for folks who use keyboard controllers and organize their buttons as one might expect on an arcade control panel: first button 1, then button 2, and so on. A typical arcade layout won't resemble the most common gamepad button positions, which is why there is so much discussion.

As someone who regularly uses mame 2003 with SNES controllers and an X-Arcade control panel, I can only sigh. :) 'Oh, the huge manatee'

Edit: But to be more serious @caver01 , I think there is consensus developing that the libretro arcade cores should provide an option to switch between two layouts: the SNES retropad mapping and a standardized arcade control panel layout with certain coded exceptions for games/arcade drivers where that is not appropriate.

I think you are right that there is more expertise in that crowd with the SNES format than the arcade buttons.

[Riverstorm]

@markwkidd said in Setting up a Ipac2:

There is a very active discussion about this topic among libretro developers on github right now. I know you have a lot of experience with controls, you may have something to contribute: https://github.com/libretro/fbalpha/issues/141

Uff-da, the that looks like it's going to take some programming skills and know how of the internal workings. I think that would be incredibly handy for the casual user that mainly focuses on gaming vs. the group that heavily modifies everything manually. Honestly I spend more tinkering than actually playing...like a 70/30...kind of sad! ;)

[battlecat]

WOW this thread got so long and a little hard to decipher.

I greatly appreciate all the discussion here. I still feel confused and dumb.

So, I still am unsure what to do when it comes to NON-MAME4ALL and NON-ADVMAME emulators such as NEOGEO or FBA.

I am using a Raspberry Pi 3, 32 gig SD class 10 card
When I first installed Retropie I did go through the initial setup which says "No Gamepads Detected" "Hold a button on your device to configure it."

I hold down the button P1 which is wired to the iPac2's player1 button. This is a keyboard command of the number 1. This triggers the setup sequence for the key mappings for Emulation Station Front End.

My button layout is very rudimentary.

I have two joysticks each with 6 buttons like this:
UP SW1 SW2 SW3
LEFT RIGHT
DOWN SW4 SW5 SW6

I have a Player One and a Player Two button
Button P1 - Button P2

I have a working coin door wired to the area labeled 1coin. The iPac2 translates this to 5.

When going through the initial startup configuration RetroPie setup asks for NON-Keyboard items such as Left Analog Stick. Of course the whole setup is designed to be used with a gamepad not a keyboard or keyboard encoder I do realize.

The problem is then what button on the setup should be pressed to correlate to what button press on the setup screen?

QUESTION 01
I get that up on Player 1 joystick is up and down on Player 1 joystick is down. What should each of the 6 Player one action buttons be mapped to when it starts asking for A, B, X, Y, L1 ETC?

QUESTION 02
How do you get non MAME4ALL / ADVMAME emulators to accept P1+P2 (keyboard ESC) to exit the game? I found that with my current setup I can get into FBA just not out of it without rebooting.

QUESTION 03
How do you get Player 2's Joystick and buttons to work? This is something I think that gamepad users have had issues with as well.

Thanks again for putting up with this. I am sure that these questions may have been answered in some way and I just didn't see it.
BC