Setting up a Ipac2

[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! :)

[caver01]

@riverstorm said in Setting up a Ipac2:

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! :)

I go back and forth about this. I rather like the raw inputs at times. As a keyboard controller user, I think it affords me additional opportunities for mapping controls.

[Riverstorm]

@caver01 said in Setting up a Ipac2:

I go back and forth about this. I rather like the raw inputs at times. As a keyboard controller user, I think it affords me additional opportunities for mapping controls.

I agree. It provides better input configuration globally as well as per game. The other options in the TAB menu are handy like game settings for grabbing the resolution, history settings for an overview, dip switch settings for adding lives, cheats, etc.

When lr-mame2000 had no TAB menu I didn't find much value in using it. It only had a few controls. I don't think you had the ability to start 2, 3 or 4 player games even but you had shaders! :) Thanks to those guys they have improved it significantly.

There's still some input issues like when pressing "button 1" it automatically adds "joystick button 1" into the configuration. Not a deal breaker but you're locked into a 1 to 1 button mapping between keyboard & controller so you would need to choose which is your primary input to get a proper configuration. The other input device might not be ideal depending on your preference.

Also when pressing escape while in game locks it up but the Retroarch exit sequence works still. It has the same <NOT> mapping issues. I keep a few 0.37b5 ROMs installed for testing between mame4all and lr-mame2000 as they update it.

I was thinking more along the lines of fixing the double inputs and NOT mapping would be the win. It's probably not coincidental that the same issues in lr-mame2003 are cropping up in lr-mame2000 as they fix it. Probably similar MAME source and Retroarch code. The thought being if they fix one emulator the other should be a similar fix to the inputs.

Also I am not sure why the emulators accept raw input for almost everything except exiting the game with "UI Cancel". It's the standard key to exit the TAB menu and while in game it should be used for exiting the game. Allowing a single key exit (escape) vs. dual keys (Retroarch hotkeys) it would allow getting rid of a dedicated escape/exit button and just use the IPAC shift sequence. Being able to exit with "UI Cancel" as well as Retroarch hotkeys. Handy.

As it stands now I disabled the IPAC shift keys and re purposed my joystick directionals for saving and loading games. I did loose escape, enter & TAB shift functionality but I have dedicated buttons on the sides.

I think mame4all doesn't have those issues simply because it doesn't have "virtual inputs" or Retroarch complexities. It just needs to handle the raw inputs so it's pretty straight forward.

[caver01]

@riverstorm I honestly have not been messing around much with lr-mame2000. I know there may be performance gains, but the romset seems better for 2003. What roms are you keeping around for testing?

I think you are right about the inputs though. It makes sense that the same duality issue would appear there too as they enable raw keyboard commands like TAB. I seem to recall that moving forward in time, like to mame2010 solves the dual input problem.

The thing is, this issue with <CODE_NOT> represents such a small population that it may not get fixed. It only affects keyboard controller users and only those who care about uncommon mapping. And for those of us in this small group, we have the ability to do per-rom workarounds by setting relevant inputs to 'nul' in retroarch to effectively disable the virtual retropad.

At one point, I had half a mind to do that for ALL of my 2003 ROMs, but it seemed like a lot of extra work to manage this in the Arcade folder. It also meant that as I try other libretro cores I would have to be mindful of this workaround each time. So, I just leave it alone. It is not hurting anything, as far as I can tell. Vindicators, Vindicators 2, Toobin, benefit from a tankstick mapping. I think I also used <CODE_NOT> with AND and OR to get a 45 degree mapping for Q-bert. Battlezone comes to mind, but since it is horizontal and single player, and I have two sticks on the horzontal side, I can make that work without mapping to a single joystick. Besides, it is vector, so I use AdvanceMAME!

I see all of this as, the more options the better. Once you get into this hobby, you start to spread the love around each emulator, picking the right one for each ROM. And as always, what works for my hardware may be different for yours.

[Riverstorm]

@caver01 said in Setting up a Ipac2:

What roms are you keeping around for testing?

I completely migrated over to lr-mame2003, AdvMAME & FBA. I've been keeping a few "random" ROMs in the mame4all folder strictly for testing not production play. ;) When lr-mame2000 gets updated Mark sends a message out to download from source for testing. I test and provide detailed feedback on what's working and what's not. I sometimes flip over to mame4all to compare as they both load from the same console.

I have to run WinMerge against my ROM folders but I think I have identical ROM's between mame4all and mame2003 except for 6 additions and roughly 6 differences like the World vs. US versions. Same game just a different version. The differences between the sets are negligible but pertinent unfortunately.

The thing is, this issue with <CODE_NOT> represents such a small population that it may not get fixed.

That's true but mame2010 solves the issue? I didn't know that. The last I read it still had quite a few issues and I've haven't really tried it. Is it worth upgrading or is there performance issues? I think all the enhancements Dank has implemented on 2003 has made it pretty viable. I do prefer shaders and also the analog stick setting but I would guess those work in the newer versions.

At one point, I had half a mind to do that for ALL of my 2003 ROMs, but it seemed like a lot of extra work to manage this in the Arcade folder.

Is Arcade a lot of work? I would do the initial setup regardless of time if I was able to backup/restore from RetroPie version to version. I've never tried it.

I do change my ES system icons using some of Udb's artwork so it shows AdvMAME, lr-mame2003, lr-fbalpha which is handy for me but the casual player still asks where is... but most are found in mame2003.

I've recreated the ROM folder structure on USB and dump everything in one fell swoop. ROM's, snaps, configs, gamelist.xml, etc. for all emulators and ports. Then I do the same for the emulator directory for AdvMAME, mame4all, ports, etc. Also the BIOS directory. I can rebuild from scratch fairly quickly.

It definitely seems mame4all and AdvMAME have the most complete and flexible TAB input but also they don't have to contend with Retroarch. It seems like somewhat of challenge to solve the input issues without moving all the input options like pedal, paddle, dial, trackball, lightguns, etc. to Retroarch or something. Somehow they have to say use this input or that input. Retroarch or raw but it sounds like mame2010 finally did get a workaround in place.

I think I also used <CODE_NOT> with AND and OR to get a 45 degree mapping for Q-bert.

That sounds cool. I wouldn't mind trying that if you have the config settings or a link? So you're using a 4 way that equates to the original 45's? I find the <CODE NOT> can get complex real quick.

What are you doing with Toobin'? I use 4 of the 6 button layout. Bottom left and right for hands forward and top left and right for hands backward.

[rbaker]

@riverstorm said in Setting up a Ipac2:

Is Arcade a lot of work?

No. It's great. I have about 100 games in it. Each one perfectly configured. The majority are on lr-mame2003 but others are on FBA and Advmame. It presents a very neat and tidy list and the main advantage is that when people want to play the games on the cabinet they just play them. They do not care which emulator, why etc or have to even consider them. With the run command disabled, it's bullet proof! Well almost.

[Riverstorm]

@rbaker said in Setting up a Ipac2:

No. It's great. I have about 100 games in it. Each one perfectly configured.

Ah nice! That's really what I would prefer a single list of all arcade games. How do you disable the run command?

One thing I've seen asked a few times but don't remember if there's a definitive answer. Is it possible to boot directly to a console like Arcade? It's definitely more polish than needed but could be nice. I have all the parts for a Pi Zero W and was thinking of a simple project with some of the golden age classics.

[caver01]

@riverstorm said in Setting up a Ipac2:

but mame2010 solves the issue?

It may have been solved by accident because of the way inputs are programmed. According to this post from a while ago, Dank thinks the devs avoided the issue in 2010 by abstracting all inputs to a virtual keyboard instead of via virtual gamepads alongside raw keys. I have only done a few things in 2010 to test ROMs that fail in others. Performance is better in 2003 for sure.

Is Arcade a lot of work?

It can be at first, but for me the benefits far outweigh the config tracking. You need to keep a list somewhere of which ROMs come from which sets. Otherwise, you have a big mess on your hands. When I had ROMs in their separate folders I knew what sets were being used. I have my own version of one of the compatibility lists where I added columns for my own tracking. This helps me remember which romset I am using for each ROM in the Arcade folder.

Like you, the upgrade or rebuild process streamlined with a backup of the configs folder and roms folder, and maybe even easier because I only need to grab one arcade ROM folder.

It has been interesting to see which ROMs have changed from set to set. I will often just try a rom in another emulator before replacing it with one from the proper set. As a result of starting with Advmame a long while back, many of the live ROMs are .106 on my system. They work, but if I am ever troubleshooting, I get the right one. This is why you have to maintain a list.

With Toobin, I just setup a tankstick using <CODE_NOT> . I probably need to change to buttons though since that is what the orignal arcade machine used. Still, inside the GUI menu, the inputs are LEFT UP, LEFT DOWN, RIGHT UP, RIGHT DOWN just like a tank, so I just went with my tankstick mapping. But now I wonder what happens if you press both left buttons? Does the player move right? You cannot push both up and down on the same side at the same time with a joystick!

My Qbert mapping is perhaps different than most, since I play on the vertical ends of my cocktail cabinet so the joysticks are rotated. But, you can do it easily just by editing the inputs in the MAME GUI. On the original arcade machine, they simply mount the joystick rotated 45 degrees. So, you just need to know which way is UP for you, and use the diagonals to remap the inputs. This will create <CODE_AND> mappings because you will be using the diagonals, effectively mapping two inputs at once. This should not conflict with the virtual retropad like it does for doing <CODE_NOT>. In fact, you will probably see two sets of inputs for each as it should pickup the retropad and the raw keys at the same time. In practice, playing Qbert this way on a mapped joystick allows you to use the diagonals, but it always feels weird because you are using an 8-way stick without a restrictor plate and trying to hit the diagonals. It is not perfect.

[caver01]

@riverstorm said in Setting up a Ipac2:

Is it possible to boot directly to a console like Arcade?

I think you can set which emulator is first/default on the carousel, but you cannot boot directly to the games list.

[rbaker]

@riverstorm said in Setting up a Ipac2:

How do you disable the run command?

You can enable and disable different functions of the Runcommand Launch Menu. This is configured via RetroPie-Setup or via the runcommand configuration option in the RetroPie area of Emulation Station. The first option is Launchmenu. You just choose disable which means that a rom just launches.

Details here: https://github.com/RetroPie/RetroPie-Setup/wiki/Runcommand

[Riverstorm]

Nice thanks for the tips guys. I would like to give this a try at some point. I think after reading through I would definitely need some way to track ROM sets or at least build out a folder structure like arcade (mame2003), arcade (advmame), arcade (fba), etc. That way if I ever needed to start over I could reference the directory list when configuring. I have about 300 games across the 3 emulators.

I know this is a long shot but Caver I remember you pointing out some limitation on Arcade on configuration or something in a post a long, long time ago. Do you happen to remember what that was? Of all the things to remember I just remember you pointing out some limitation to be aware of or something along those lines.

Is there any documentation on Arcade or any posts you recommend reading. I see advmame has links under Arcade but mame2003 has folders. I think I can figure it out but is there any other folders to backup where Arcade specific config information would be stored?

[caver01]

@riverstorm said in Setting up a Ipac2:

I know this is a long shot but Caver I remember you pointing out some limitation on Arcade on configuration or something in a post a long, long time ago. Do you happen to remember what that was?

I do. It had to do with the single retroarch.cfg file in the configs/arcade folder. In the configs folders, you can have a retroarch.cfg per emulator folder, as you might already know, and one for "all". For example, the one in mame-libretro would cover the retroarch settings applied just to mame cores. That is already somewhat limiting because you cannot have a separate config for lr-mame2003 that is different than the one for lr-mame2000 because they both use the mame-libretro config folder. Now, apply that same limiation to the arcade folder and you see the potential problem. One retroarch.cfg file has to cover all libretro cores used. That means, if you map keys for lr-mame2003 differently than you do for lr-fbalpha, you only have one retroarch.cfg to work with. You might end up needing more per-rom config files.

Of course, you still have the ALL folder for your base/default, and retroarch combines them, but where they conflict, the config is superceded as you get more specific, ALL-->Cores-->Roms.

Anyway, that was the limitation. One cfg file for arcade. In practice, however, it has not been a big deal.

[caver01]

This was one reason why I am so passionate about keeping the SELECT key mapped. It has to work for both mame and FBA using the same retroarch.cfg file.

[Riverstorm]

@caver01 said in Setting up a Ipac2:

I do. It had to do with the single retroarch.cfg file in the configs/arcade folder.

Thanks Caver, that was it, good memory! :)

that is different than the one for lr-mame2000 because they both use the mame-libretro config folder.

Is lr-mame2000 lumped mame4all? When I go to the launch menu with ROMs placed in the mame4all folder I can choose between mame4all or lr-mame2000 but when using Arcade it lumps all lr-mame configs (i.e. - 2000, 2003, 2010, 2014 & 2016) to one folder being mame-libretro?

his was one reason why I am so passionate about keeping the SELECT key mapped. It has to work for both mame and FBA using the same retroarch.cfg file.

Yeah lr-fbalpha seems to be the only MAME Libretro core that doesn't accept raw input and relies solely on Select for credits.

[caver01]

@riverstorm said in Setting up a Ipac2:

Is lr-mame2000 lumped mame4all? When I go to the launch menu with ROMs placed in the mame4all folder I can choose between mame4all or lr-mame2000 but when using Arcade it lumps all lr-mame configs (i.e. - 2000, 2003, 2010, 2014 & 2016) to one folder being mame-libretro?

I believe lr-mame2000 is the better name for the libretro version of mame4all. It used to be lr-mame4all.

I think one reason why it is setup together is because lr-mame2000 and mame4all-pi are both built on the same mame code base and require the same romset.

Arcade combines all arcade emulators (except Daphne which is not really interchangeable with the others). The stand-alones like AdvanceMAME will use their own configs as always, but the libretro cores will share the same retroarch.cfg. Actually, they already shared the one in the all configs directory, but the emulator-specific config ends up coming from the arcade config folder and all libretro cores must share.

The benefit, even with this limitation, is that all arcade games (except laserdisc) are united under a single menu in ES. Before I started using it, I would show a friend the system, and they would be scrolling through the gamelist looking for their favorite, and I was like, "oh, that one is listed under the FBA emulator," or, "oh, that game is vector, so it is under AdvanceMAME," and they would ask, "what is a MAME?" That's when I knew that having multiple arcade choices in ES--especially multiple MAMEs to choose from--was really confusing the casual user. People would appreciate what I built more if they did not have to hunt for their games. The users don't understand why I would choose one emulator over another for a particular game. They also don't care, so the Arcade folder just cuts through all of that confusion.

Sure, I need a spreadsheet to keep track of what ROMs I have in there (what sets each one comes from) but it seems like the best option for me.

I might like to try to unify Arcade with Daphne at some point. I am not sure why that hasn't happened yet.