Setting up a Ipac2

Riverstorm

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

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

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

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

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

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

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

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

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

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

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

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

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

caver01

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

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

Riverstorm

@caver01 said in Setting up a Ipac2:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

caver01

@riverstorm

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

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

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

Riverstorm

@caver01 said in Setting up a Ipac2:

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

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

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

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

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

caver01

@riverstorm said in Setting up a Ipac2:

Basically Retroarch Select is unused in a MAME environment.

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

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

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

battlecat

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

caver01

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

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

Riverstorm

@caver01 said in Setting up a Ipac2:

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

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

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

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

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

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

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

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

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

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

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

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

caver01

@riverstorm

When you wrote:

Basically Retroarch Select is unused in a MAME environment.

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

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

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

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

So you can disable Retroarch SELECT without affecting ES functionality.

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

Riverstorm

@caver01 said in Setting up a Ipac2:

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

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

Help me understand why you would disable SELECT in RetroArch?

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

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

caver01

@riverstorm said in Setting up a Ipac2:

@caver01 said

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

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

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

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

;-)

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

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

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

Riverstorm

@caver01 said in Setting up a Ipac2:

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

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

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

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

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

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

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

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

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.