Setting up a Ipac2

Riverstorm

Once more I am suggesting that there should be a baseline default setup for the iPac users that should require no remapping of keys or changes to any text files.

When you first boot RetroPie you're asked to configure your input device. If you hold down a button connected to an iPAC it is identified as a keyboard. At this point you're presented with the input configuration (this is configuring Retroarch). All you need to do is press the button you wish to assign to each input. It's straight forward with minimal interaction to get you up and running but gives you the flexibility to choose your keys. You don't need to remap or modify text files. It should work just fine with MAME and consoles too.

Note P1+P2 will most likely not be your exit emulator keys because choosing P1 or P2 for select which will in turn become the hotkey doesn't make sense. P1 and P2 need to be left as is to start games and need to be assigned as such.

If I am understanding you correctly you want this part skipped and the Retroarch default keys to be the iPAC default keys which are in turn the MAME default keys?

I think the iPAC is identified as a keyboard which could actually be many different devices from an actual keyboard, IPAC, GPIO, Xin-Mo, etc. but you want to settle on the IPAC default keys for Retroarch?

One example where this may not work is MAME player 1 button 1 is l-ctrl but assigning l-ctrl to GPIO doesn't work the best as it causes issues in some emulators. It's better to stick to letter keys with GPIO. I am sure there are many others examples why allowing the user to configure the input might be a better option.

I do believe Retroarch does have a set of default keys that you're more than welcome to change. Looking at it in reverse Retroarch already setup default keys and you need to modify the IPAC to match.

d-pad up - up arrow
d-pad down - down arrow
d-pad left - left arrow
d-pad right - right arrow
start - enter
select - rshift
A - x
B - z
X - a
Y - s
left bottom - q
right bottom - w

You either need to convince the Retorarch developers to reassign the default keyboard keys in retroarch.cfg to use the MAME defaults is a better idea or convince the RetroPie developers to identify the IPAC on bootup and modify the retroarch.cfg keyboard input keys to use MAME defaults. Also they will need to configure the hotkey and hotkey functions to what is best for all users. All this because you don't like the idea of pressing a dozen buttons to setup the IPAC on first bootup.

I do see your point where this might have merit but you're going to need to make some assumptions that everyone wants to use the IPAC default keys, a hotkey button and also all the hotkey function keys like reset, save, load, exit, etc. need a key designation.

It doesn't seem like a priority item because you truly want a turn key solution but on the other hand you want flexibility and to make P1+P2 to be your combo exit keys. If you want something different then the defaults during setup you're probably going to need to learn to modify one text file or buy one of the ready made consoles.

I never thought that RetroPie promised a turn key solution that you want but slowly it is getting closer and closer over time. Patience Danielson! I am not sure what to say except maybe make large donations and hope your idea gets moved to the top but no promises it will! ;)

caver01

@dankcushions said in Setting up a Ipac2:

what do things like '1 SW 1' and '1 A', mean? Which one of these would be 'Button 1' in MAME, for example?

The first number is player. So '1 SW 1' is Player 1, Switch 1. On the older IPAC hardware, there was no '1 A' but it looks like Ultimarc saw fit to use it to better align with gamepad/console emulators.

The Player 1-4, Switches 1-SW8 on the IPAC4, for example (a 4-player, max # of inputs board) were originally supposed to map to MAME defaults. MAME was the only significant emulator going, so it made sense to setup the board defaults to keys that match the MAME inputs. Since MAME maps to Button 1 Button 2, etc, and not ABXYLR like gamepads, this was a good plan. So the basic rule was that, depending on which IPAC model you bought, you were really just picking the number of player inputs you needed. IPAC4 has inputs for 4 players, IPAC2 has inputs for 2. The basic inputs were:

Up, Down, Left, Right.
SW1, SW2, SW3, SW4, SW5, SW6, SW7, SW8
Coin, Start

for each player.

Later, A and B were added (I don't even know what the defaults are for these) and they also added the ability to connect as a game controller or a keyboard--configureable using the WinIPAC utility.

These days, the abstraction layers don't perfectly line up the way they used to. If all we ever used was MAME, it would be OK, but folks like to emulate consoles now (and sometimes more than arcade), so we have to consider how the MAME keys map to a virtual game controller with ABXYLR. So, choices have to be made. Do you go with AB = Sw1 and Sw2, or do you reverse these because of how most controllers are built? It's confusing to say the least, and everyone will have their own idea about what switches map to controller buttons (not to mention the fact that you CAN reconfigure the actual keypresses sent by the board using the WinIPAC utility).

That's why I tend to think about IPAC users as traditional MAME-based cabinet builders that want to use Arcade buttons and joysticks. But the moment they say they want to play consoles, it gets sticky.

i think the first problem i would have to solve is to ignore the 'double press' scenario

As for the double-mapping, you COULD set all retroarch inputs to NUL but this would break any libretro core that does not see RAW keypresses. The fact that it maps two keys at once doesn't really matter unless you are trying to get <CODE_NOT> remapping to work in the MAME GUI. Otherwise, it functions fine.

Oh, and of course, the MAME Coin input can be used as SELECT and Start is Start on console emulators, so at least that works OK. However, the default retroarch mapping for these is RSHIFT and ENTER, which is different than MAME Player 1 Coin and Start (num5, num1).

Riverstorm

@caver01 said in Setting up a Ipac2:

Later, A and B were added (I don't even know what the defaults are for these)

They are tailored toward MAME also. I do use all 4 of them when I wired my IPAC. There's your dedicated exit button but it doesn't look like they have them on the IPAC4 only the 2! ;)

1A = P
1B = Enter
2A = Tab
2B = Escape

As for the double-mapping, you COULD set all retroarch inputs to NUL but this would break any libretro core that does not see RAW keypresses.

Are you aware of any as to keep this in mind might be helpful.

The fact that it maps two keys at once doesn't really matter

Right it just looks a bit funny when configuring TAB input and it has double inputs displayed but it still works except <CODE NOT>.

Do you go with AB = Sw1 and Sw2, or do you reverse these because of how most controllers are built?

I use the "Swap A&B buttons in ES" feature even with the IPAC. I reconfigure the keyboard and joystick after. This doesn't affect standalone MAME emulators like mame4all or AdvMAME.

However, the default retroarch mapping for these is RSHIFT and ENTER, which is different than MAME Player 1 Coin and Start (num5, num1).

At the first bootup if you configure the IPAC or keyboard they will be changed to num5 & num1 if shooting for MAME keys. I suppose if you just configure a joystick only they will stay at defaults.

@dankcushions Sorry Dank I thought your questions on IPAC setup were rhetorical in regards to making a point in the discussion with @battlecat and not actually doing it.

Yes that list is accurate and it's MAME's official default keys.
Yes I think all the input/button designations are the same for the IPAC2 and 4. The 4 has inputs for up to 4 players. MAME's default keys are 100% on the keyboard for all 4 players, even the directional keys. So it's pretty much a 1 to 1 mapping from IPAC to official MAME keys.

I believe Andy from Ultimarc designed the board with MAME specifically in mind. He's easy to talk to and will answer any question you ask him. I even requested an Autocad diagram with the dimensions to do some laser cutting and he was able to create one. The mini and ultimate are more like dupont/jumper type connectors for the budget minded and the mother of all models respectively.

@caver01 pretty much explained the button scheme. If you wire 1SW1 to button 1, 2SW2 to button 2, 1STRT to player 1 start and 1COIN to player 1 coin, etc. MAME emulators will work right of the box with no modifications due to the IPAC making it's default keys align with official MAME default keys that most MAME emulators use too but the IPAC inputs can be changed to any key you want even mouse clicks or joystick simulated button presses, etc. It's incredibly flexible.

caver01

@riverstorm An interesting point here, I was never able to get mouse clicks to work when I configured my IPAC using the WinIPAC utility. Of course, mine is a very early model. It was not a big deal, as my U-Trak has a mouse button interface too, so I used that--not that it really comes into play.

Are you aware of any as to keep this in mind might be helpful.

So, I don't really know if lr-fbalpha sees raw keypresses. It is quite likely that nothing in that emulator would work without mapping in retroarch.cfg. And this could apply to console emulators too. I would expect most libretro cores are built around the retropad abstraction for inputs--in fact I think that is by design in order to bring consistency to the framework (to keep users out of the business of configuring controls to every single core).

Depending on what cores you plan to run, I would expect that you would NEED to have the keystrokes mapped in retroarch to support most of them. I think we are, in fact, lucky to be able to press TAB and have that raw key recognized by MAME. There are MAME emulator features that work because they are accessible through the MAME GUI menu that simply don't map to core options.

Riverstorm

@battlecat - I missed this but it looks like you can configure the hotkey when configuring input vs. select being the default hotkey but I would imagine you would still need to modify all/retroarch.cfg or go into the Retroarch menu to modify the hotkey functions (save, load, etc.) if the defaults aren't what you want.

"The ability to configure your own RetroArch hotkey enable button when setting up your gamepad."

One step closer! :)

Riverstorm

@caver01 said in Setting up a Ipac2:

And this could apply to console emulators too.

Those are some good points when it comes to console emulators. I keep thinking from a MAME point of view as it's my main type also.

If the emulator was built from the ground up as a Libretro core it's sole input might be Retroarch vs. MAME which seems to handle both ways fine hence the double inputs. :) Someone would need to nul the Retroarch inputs and run a console game to know, unless you're the guy that programmed it. It's been a while since I fired mine up when I do I might have to try it.

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