Setting up a Ipac2

[battlecat]

@caver01 And what do you set them too? :)

[caver01]

@battlecat To the keys you want to use them for.

But this is where it becomes different strokes for different folks. For example,
I set input_exit_emulator = escape and input_enable_hotkey = nul because I used WinIPAC utility to specify a switch on my IPAC4 (I think it was probably Player 3, switch5) to send the ESCAPE key. That is wired to my dedicated exit pushbutton. I don't use hotkeys.

However, for many people, they may not want to dedicate a button at extra expense (and inputs used). For them, the hotkeys are great because they allow you to do stuff in RetroArch like save states and so on. So the default would be to have input_exit_emulator = num1 and input_enable_hotkey = num5 to correspond with the Player 1 Start and Select (coin) inputs. These keys are the MAME defaults.

Just make sure you don't specify the same line twice in the retroarch.cfg, as one would override the other

[Riverstorm]

@caver01 said in Setting up a Ipac2:

So the default would be to have input_exit_emulator = num1 and input_enable_hotkey = num5 to correspond with the Player 1 Start and Select (coin) inputs.

It's exactly like @caver01 was saying. Here's where everyone starts tailoring for their specific setup needs. For mine after going through the initial input which defaults to num1 & num5I change my hotkey to num1 and my exit key to num2. Pressing Escape on your keyboard exits the game but also when using an iPAC pressing 1 & 2 simultaneously sends the Escape key and exits. By configuring the Retroarch settings to 1 & 2 I am able to exit non-Libretro cores (i.e. mame4all-pi or AdvMAME) by pressing 1 & 2 together which sends escape (their defaults) and to exit Libretro cores (i.e. mame2003, lr-fbalpha or NES) I also press 1 & 2 together. This allows me to exit all emulators by pressing 1 & 2 together.

The iPAC has a "shift key" which is similar to Retroarch's hotkey. The default is 1. So pressing 1 plus another key (within a specific time--a second or so) together sends a shifted key sequence (like 1+2 sends Escape). The neat thing about the iPAC is the shift key, normal keys and codes with shifted keys may all be set to whatever you want.

When I built my box I added a player 2 start key for player 2 start but also to exit. When I configure RetroPie on first bootup and it asks me to press a key for select I press 5 (the button I wired to my iPAC for player 1 coins--it's default--MAME defaults). I then can use 5 to add coins in MAME but also for changing from a one player to a two player game in Mario Bros. and hit player 1 start to begin playing.

Normally to exit it would be 1+5 (Libretro cores) but I go and modify the all/retroarch.cfg to make 1+2 my exit keys so it matches non-Libretro cores. This leaves 5 as my select key just not my hotkey then I move my hotkey to 1 and my exit key to 2. It's just a preference but you could also make your hotkey 2 and exit 1. It's mainly to match the iPAC escape sequence to simulate the Escape key for MAME. You may also have a dedicated exit key like @caver01 and disable the Retroarch hotkey but you loose the Retroarch hotkeys for save states, pause, etc. which I do use for some longer arcades games to save and restore if I die to often...which is the case! ;)

Another thing I can't quite remember if it's the iPAC or emulator right now. When exiting some emulators it doesn't seem to register hotkey+exit. So I press them in reverse exit+hotkey. So instead of 1+2 immediately in sequence I press 2+1. Subtle difference.

There are a lot of cool refinements and tweaks for streamlining things once you have this down. They kind of go on and on and they makes things work that much cooler but on the other hand they really aren't needed if you don't want to invest to much time and just get playing.

I get the turn key solution. I remember ripping my music CD's with EAC and using CUETools to verify the pressing offset for an exact bit perfect copy (well as close as you can get--miles of reading the nuances). I didn't want to know the whys or hows in the beginning just the steps to get it done but in the end I ended up learning way more than I cared to know on how to make bit perfect copies of CD's. ;)

[battlecat]

@caver01 Okay. SO you just said that you are deviating from the standard setup by not using hotkeys. There is no way to predict every possible variation. That is true enough. I somehow doubt that the majority of people who would be seeking this type of basic answer would be as advanced a configuration as you are.

;)

[battlecat]

@riverstorm Thanks for that detail.
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. I know I seem to be advocating this for those who just want to plug and play and not learn to edit files or remap keys. I understand that there are a lot of hardcore user out there of RetroPie. They may be the majority and yet I do not understand what the big deal is with including default setups for iPac users along side the heavily supported xbox controller user is.

[dankcushions]

it’s not simple. first up, what are the default bindings you want to use? what keyboard > retropad binding gives a sensible ipac mapping for all cores? including arcade (fighting game layouts, etc). such a binding doesn’t exist for any controller as the cores aren’t unified in that way. this is a general problem.

“xbox controllers” do not have default mappings. the user has to bind them themselves. i don’t know why an ipac would be special, here.

[battlecat]

@dankcushions I think that the standard keyboard or keyboard interface user has been left out of the list of controllers on https://retropie.org.uk/docs/

I guess what I want is to be able to have something up there that says hey iPAC users here are your instructions. Here is what you need to do if you are not deviating from the historical keyboard setup for the iPac. Here is what you should do if your iPac has not been changed from its defaults.

[dankcushions]

ok, i'm kind of interested in getting ipac to work with mame2003 by default :) some questions:

1. is this an accurate list of the defaults? https://www.arcadeworlduk.com/pages/IPAC-2-Code-Table.html
2. is it the same layout for ipac 1 and 2?
3. what do things like '1 SW 1' and '1 A', mean? Which one of these would be 'Button 1' in MAME, for example?

i think the first problem i would have to solve is to ignore the 'double press' scenario that @caver01 is very familiar with - if a keyboard key is also a retropad key, we need to somehow stop mame from reading that as two inputs.

[Riverstorm]

@battlecat said in Setting up a Ipac2:

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.

1. Yes that list is accurate and it's MAME's official default keys.

2. 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.

3. @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.