MAME tools to mass change controllers configuration ?


Forum Addict!
Jun 20, 2011
Hi, I have multiple gamepads, and most of them are also recognized as different devices when I connect them in a different way.


PS2 (normal USB only gamepad) -> Only one device

MD (could be connected with USB or BlueTooth, as an X-Input device or as a D-Input device) -> this creates like 3 different devices in the system

Returning to MAME, the gamepads are recognized with a number, and this could be dynamic following the order they where connected to the system.

If I have a MAME configuration for "Joy1 Button1", and then I start the system with a different gamepad connected, or even the same gamepad but connected via BT instead of USB, it is not anymore the "original" "Joy1", so it could happen both that the new "Joy1" gamepad has "Button1" wrongly placed, or the gamepad you want to use is now "Joy2" so a total remapping is needed.

Now, there are two different issues there:

1. The gamepad is totally different from the original, so the "Buttons/Controls" should be all remapped
2. The gamepad is THE SAME, so the "Buttons/Controls" should be just associated to the right Joy number.

Do you know if there's a tool around that can manage with some kind of smartness this situation ?

Or I just need to make my personal modifier script for mame.ini files ?



Seems like that RetroArch manages joysticks in a smarter way than plain MAME (or Windows), I'm still doing some config editing, but I'm pretty sure that the controllers are referenced by their Unique ID, so this theoretically should solve my issues.
Last edited:
So, seems like that almost a years have passed and I'm still struggling to find a working configuration for my use cases:
1) A menu that works with every gamepad
2) An emulator that works with a specific gamepad, if it's there, else with the first it find. So every emulator (or CORE in Retroarch) should work by default with it's specific gamepad (and associated configuration).

But, at least, after reading a lot of bugfixing requests for RetroArch, I'm pretty sure that these issues will never be solved, because the programmers can't reproduce these issues.

Anyway, after A LOT of fiddling with config files, to understand how everything works, I'm pretty sure to be near a somehow working solution, so I'll list here some of the important passages I found out (it's not step to step but if you have issues just ask):

1) Save a default configuration: to do that just start RetroArch WITHOUT A CORE LOADED, set all the options you want, put both input joypad and input driver as SDL2, deselect automatic gamepad configuration, deselect the automatic config save at exit, select to use different cores configurations, and select that every player can use the menu. Then save this global config, backup it, and never touch it again.

2) Load RetroArch with a CORE, set all the options you want for that CORE,like shaders, borders, select the gamepad you want, set the remappings, etc..., and save every one of them as a CORE config. Now you should have some new folders called as the CORE in the "config" directory.
Ok, now save everthying as a new global config (don't overwrite the global config). A new CFG file named as the core DLL you are running should appear in the "config" folder, now rename it as the one in the core folder and paste it in the core folder, overwriting the other one.
Now you have a FULL configuration that will be used only when that core is loaded.

This solved most of my issues with gamepad associations.

Just an explanation about the input configuration "bugs" that are present in Retroarch:
the issues seems to be related to the fact that RetroArch most of the time will save the "selected" gamepad configuration, in the "default" gamepad configuration, where "default" is the actual joystick with ID 1 (that could change at every boot in windows).
So this will lead to broken configurations even for the gamepads that were working great at the previous run...

Using the entire configuration for every core, and the SDL2 driver, seems to bypass this wrong behaviour.
Dunno if this this what you are searching for, but it's the only joystick tools I know.
Good to know, but I wasn't speaking about that.

I have different gamepads that I want to use for different emulators (most of those are just RetroArch Cores), but still I want to launch all the emulators from the same frontend menu.

So, If I launch a Sega Mega Drive game, the gamepad with 6 face buttons should work by default, with the right mapping.
If instead I launch a SNES game, the gamepad for the snes should work by default with the right mapping.

But both of them should be able to control the menu at the same way.

I use EmulationStation as a launcher frontend, and it has absolutely no issues at all to recognise gamepads, but instead RetroArch always do a mess with them...
it sets as the default the first gamepad, that could also be disconnected (in case of X-Input bluetooth devices, because the drivers remains loaded even if the device is turned off...), it doesn't recognise the difference between different models of bluetooth d-input controllers, so everytime I map one of them, the others will have all the buttons with the wrong functions...
Most of the time if you remap and save a new gamepad configuration, it will be saved for the WRONG controller (almost always the one that has ID 1)...
and these are just few examples...

My little guide was just a start to understand how to actually configure them, evading the issue of RetroArch.
I rarely use a joypad on PC.
Can't it be fixed with a udev rule ? (if udev is usable on you system)
I also always just played with keyboard+mouse in PC... but lately, at least for emulators I started to appreciate the original way those games were meant to be played.
(I'm still angry with proper PC games that are only optimized for a gamepad anyway... if something is made for PC it should be M+K stuff too !!)

I'm on Windows, there are no rules for controllers, only auto assigned IDs at every start, in the order of how them were plugged in, and the only one that really count is the ID 1, if you set a gamepad as DEFAULT, it becomes ID 1, and the other ones changes their IDs...
Some programs, like STEAM, can recognise controllers by other means, maybe name or product id and can maintain also a modified configuration associated.
Some others, like 90% of the latest games around, just asks to "press a key" at the beginning, so they can catch what controller you will use. EmulationStation works like this.

RetroArch does some of this and some of that in a messy way... that's why it works so bad with controllers associations... it saves in the configuration the windows ID of the device (that could change), but then searches the custom mapping by name... so you not only can start with the wrong controller, but it can also get the wrong configuration for it too...
Last edited:
Personally when I use mednafen on my PC or various emulators on my Pandora, I spend a couple of minutes at the start redefining my controls every time. Proving I play for at least half an hour that's not too bad. I guess that's bad form for a standalone emulation box though, if that's what you're building.
Personally when I use mednafen on my PC or various emulators on my Pandora, I spend a couple of minutes at the start redefining my controls every time. Proving I play for at least half an hour that's not too bad. I guess that's bad form for a standalone emulation box though, if that's what you're building.

Yeah, I want to obtain something stable and configured as I wanted it. With the easy of use of a console, but with better and more stuff.
For too many years I configured and tested a lot of different types of emulators, all different from each others... and everytime I wanted to just play something I always had to remember where were the functions and what were the limits of the program I was using...
now that the Libretro project is on the right path, creating a standard for all the emulators, it is really close to what I want to obtain.

I never had issues with emulators until I got more then one controller, then the hell broke loose... and finding on the internet solutions as "just unplug the one you don't use" or "unplug and plug them in the right order" or again "remove the device then change the default then add again the device"...
I have a LightGun that is recognized as a joystick, and I don't know how many times I had to unplug it to make the other controller be recognized... and still it wasn't just so simple every time... WTF !!!

I wonder why Microsoft never did something about that department... it is pretty known that the definitive gaming PC is still a Windows PC... but they just put up a driver for their shiny controller and that's it...
I post here some new findings in the gamepads configurations of RetroArch, because seems like the things I told in one of the previous post were somehow working for pure luck... now I'm continuing to understand what is actually happening...

Some info about RetroArch:
1) Every "Joypad driver" (to be selected in the configuration) has a folder with its configuration files, and most of them, are already set up for the most common controllers, BUT, not all drivers covers the same gamepads by default !!
2) A gamepad can also be recognized by its HARDWARE ID, and this will really make the gamepad-type unique for the emulator (so it will work with 2 similar BT gamepads, but I'm not sure what could happen with 2 identical gamepads anyway).
3) There is an option to make every gamepad be able to use the MENU, but seems broken... it at least should work for every controller mapped in one of the player ports, but still, it seems that only the "DEFAULT" gamepad will work in the MENU at the start.

Some facts about 8Bitdo gamepads:
1) When connected via BT as d-input device, EVERY MODEL (at least SN30, M30, N30 Arcade...) is recognized as "Bluetooth Wireless Controller"
2) When connected via BT as x-input device, EVERY MODEL (at least SN30, M30, N30 Arcade...) is recognized as "Xbox Bluetooth Gamepad", BUT in this case, the gamepad is recognized ALWAYS present, even when the gamepad is turned off !!
3) Firmware updates can change the HARDWARE ID of the devices

So, what did I found regarding my situation ?

1) The driver "xinput", with the first gamepad it worked ok, but after the second one, it was always a trouble to use them, the one I wanted to use was always not working... at least now I know why !! In the xinput folder, there are actually configurations (with HARDWARE IDS) for all my gamepads, so all of them were recognised as unique types... the problem is that if the first one connected to the system (that become "Default") is turned off, as "Xbox device" it doesn't disappear, and remain still the "default device"... so when RetroArch is started, the MENU will work ONLY with that default device, that is anyway turned off... and to change the active controller you have to use the mouse and select manually the controller that only you know it is currently turned on...
2) The driver "dinput" never worked out of the box for me... because I didn't know, that the "Xbox devices" I created before, were still giving the same issues as explained before... them were considered default even if turned off... so I actually weren't never able to understand why no one of my controllers were working at the start in d-input mode... Also, when I was selecting them by hand, I wasn't able to set different buttons configurations for every type of gamepad, and it was always a mess... In the dinput folder anyway I see already configurations with HARDWARE IDs set, but I had to correct them because weren't right after the firmware update... so before, without a corresponding HARDWARE ID, RetroArch was thinking that all my "Bluetooth Wireless Controller" were the same device, using the same button configuration for all of them...
3) The driver "sdl2" was working out of the box for 2 reasons, the first is that it doesn't recognize Xbox devices, so the previously problematic ones were excluded from the scan, and also in its folder, the "Bluetooth Wireless Controller" configuration didn't had a HARDWARE ID set... so it was recognising whoever 8bitdo gamepad was turned on in that moment as the default... and I was able to switch between them, and use the MENU with all of them, just because turning OFF one and turning ON the other, for RetroArch was always the same gamepad... but I found out that this way I can't use BOTH of them at the same time... I didn't found out the issues early, because I remapped gamepad buttons in a different way for every CORE, and was working... I didn't recognized that the M30 was using the same gamepad base configuration of the SN30, because I never used the SN30 to play Sega Genesis games, and never used the M30 to play Super Nintendo ones...

Now I understand better what is going on under the hood... but the main issue still stay, the MENU does work only with the default gamepad, and if it is turned off, you'll have every time to use the mouse to select the one you need...
launching RetroArch from EmulationStation means that for EVERY GAME YOU LAUNCH, you'll need to open RetroArch MENU to set, with the mouse, the actual gamepad to use...

So, right now, I have only 2 options:
1) Make RetroArch correctly recognise every type of gamepad, and having a correct button configuration for every one of them... but with the issue that if I'm not using the default gamepad, I'll have to select the right one at every launch, with the mouse
2) Make RetroArch consider that all my 8BitDo gamepads are the same one, and having a shared (wrong) button configuration for all of them... this could works if it is somehow corrected with a CORE level remap, considering that only the gamepad whose remap was made for will work correctly

This covers anyway only 8Bitdo devices... if I'll take into consideration all my other NOT-8BitDo gamepads the issue still stands...


I'm not sure about what it does, but even if it's already configured that every player could use the MENU, if this option is active only the gamepad of "Player 1" will work:
Input -> Menu Controls -> Unified Menu Controls -> [OFF] !!!

So, now I can use the MENU with ALL my gamepads/controllers (not only 8BitDo, all of them !!) that are associated to a Player port... (the ones not associated to a port will just not work)...
A good thing is that RetroArch can manage A LOT of Player ports...
The drawback could be that if a specific game does differences from port numbers, like port 2 is always player 2 (maybe linked to a specific character in game), or only port 1 can start the game, then you are stuck probably with the wrong type of gamepad for that core... but at least you can interact with the game or the RetroArch MENU, instead of having to search for the keyboard and mouse to set up the gamepad every time...

I'll have to still try... but maybe I could find a way to even correct this (final ?) issue...

In the end seems like I'm getting closer to what I wanted to obtain, but there are really a lot of obscure options in RetroArch...
Last edited:
Cool, seems like that the libretro docs returned to life after the 404 doom I had to deal with for months :cool:
Now a LOT of my questions received a pretty clear answer, and I also found many new interesting things, like the difference from an "Input Driver" and an "Input Joypad" :cool:

It is really a well made manual

:confused: never heard of it... I'll do some research...

In the mean time I continued to test how RetroArch reacts to various gamepad configurations so I leave here also this is a little report.

I wanted to know how the Player 1 joystick is recognized when Autoconfig is on, now I have 2 configurations (.cfg) for 8BitDo devices, the first comprehend ID/VENDOR so it recognizes my "SN30 Pro", the other is a generic "Bluetooth Wireless Controller" without IDs...

If I turn OFF the M30 and turn ON the SN30pro, then start RetroArch, I can save as P1 the SN30pro.
If then (after saving the previous config) I turn ON also the M30, after starting RetroArch, it became the P1 gamepad !! And the SN30pro is not anymore associated to any player... (making also impossible to use the menu with it) so seems like the Autoconfig gives priority to the "generic" configurations...

I'm also still trying to find a solution to make P1/P2 switch gamepads when I start SNES instead of MEGADRIVE... especially in the second console, many games expects that only P1 is able to start the game... so the previously explained workaround to put all the gamepads to different players is not working so well...

Another issue is this: let's say you have 2 gamepads plugged in, one is recognized as joystick "0" and the other as joystick "1", then you save as Player 1 the joystick "1"... and unplug it... in the next start, RetroArch doesn't find the joystick "1", so, instead of using the first joystick available (the "0" that is still plugged in), it DISABLES the port 1 !!

ok, I had some readings about this "Recalbox" and found out it is almost exactly what I have achieved so far (EmulationStation+RetroArch), and this includes my RetroArch gamepad issues.
Also seems to me it is only for Linux, while I'm using Windows as a base (but maintaining compatibility for a possible port).
Last edited:
ahhh. that could be a problem... im using a raspberry pi 3+ i had. i have 1 microSD card with retropie and another one with recalbox. testing what worked better. retropie has the USB stick method to add roms but what i found brilliant was out of the box( no pun) recalbox had a windows share setup and it was a simple drag and drop on my PC. SOOOOO much easier than on retropie. another reason i think i will stay with recalbox is it is already setup to use GPIO pins for the joystick and game buttons. no need to buy a USB keyboard controller or hack an old USB keyboard like i planned to do ( about 15 years ago when i bought the joystick and arcade buttons) . project went on hold at that time because using a PC of the time was not going to be fun and emulators and MAME were not great.
Recalbox 6.1.1-Dragonblaze ( apt name) is available on PC both 32 bit and 64 bit..

Good to know, unluckily the issue with gamepads is always RetroArch.

I'm experimenting a bit with PowerShell and various command line Microsoft tools, to find out if I can make a Batch or some other type of script that can recognize my controllers in the order that I want, so it can modify the RetroArch configuration before the launch... but it's not so easy...

For now I saved for the Genesis and SNES two complete different configurations with swapped controllers... so, at least, I have the right gamepad as the first for each of them... it's not as dynamic as I wanted but works...
I need to do this for the other consoles with the other controllers... I'll leave the lightgun as the last...
I found this project called "Universal Control Remapper"... at a first read I thought it was just a buttons remapper as there are tons around...

...but then I stumbled in this two descriptions:

  • Remapping and device order persists through reboots and unplugging of devices
  • Profiles can be switched by external programs through Command line parameters (CLI)

And this could really be the thing I need !!
I could make profiles with a different order for controllers, for every emulator, and then start the right one before the emulator !!

The program is not exactly so straightforward to use... I had a reading at the documentation, but it will require a bit for a fully working configuration...
the cool thing is that it is really malleable... you can set some combination of buttons in a gamepad, to act as switches, to actually change the output of the other buttons in the same gamepad in realtime !!
Like if you press Button A returns "pressed A", but if you keep pressed "L1" and then press "A", then it returns "pressed B" :cool: I can foresee a LOT of things I can use this function for !!

So, how I'm working with this in practice:
1) I made it to create different virtual controllers (that will be "connected" everytime the profile is run)
2) Associating my real controllers functions to each virtual controller... for now I'm trying with virtual XBOX controllers, but they seems lacking buttons that instead I can use in 8BitDo controllers... but maybe I could find a solution with filters...
3) In RetroArch bind to the ports the virtual controllers instead of the real ones
4) In EmulationStation change the configuration so that an UCR profile is launched before the emulator

I'm still at the step 2 for now, but if my theory is correct I can associate the virtual "Controller XBOX 1" to a different physical controller for every profile...
so in the case of SNES / GENESIS, I can create 2 profiles like this:

Controller 1 = SN30pro
Controller 2 = M30

Controller 1 = M30
Controller 2 = SN30pro

So that RetroArch will not switches the devices every time I turn them ON/OFF.


ok, this doesn't work either... the actual virtual devices stay in the proper order, but them are always created AFTER the real controllers...
so, if I set RetroArch to use the "virtual XBOX 1 controller", maybe in that moment it is ID 2 because there is only a gamepad plugged, and uses the first gamepad for player 1, but if I turn on the other gamepad, it becomes ID 3, and RetroArch starts using the second "real" gamepad (that became ID 2) for the player 1...
Last edited:
so close too.. a shame.
im currently using a logitech F710 wireless controller . i have a set of 6 buttons and player 1 and 2 buttons and a coin button as well as an arcade joystick . these will be built into the bartop cabinet . these will be default controls and either my 8bitdo NES30 pro gamepad or the F710 as second player. i want to make a small cabinet as i dont have the floor space for a full sized cabinet.
Look at what I have found !! :oops:

I still have to try it, but seems really promising...

As it was born using some code from the x360ce project, it works somehow in the same way...
you put the executable and the dll in the same directory of the program you want to run, along with a configuration file.
The program will use GUIDs to identify and order the controllers, and those are UNIQUE for any controller ever plugged in the system !!!
Also, it is able to HIDE from the program the controllers that you don't want to be seen by it !!
And I have some use for this too... there was a game, Advent Rising, that I was playing with Keyboard+Mouse, but the camera always pointing at the ceilings... it took me 2 days to find out that was the connected gamepad the one who was giving the issue... just by unplugging it the game started working ok... so, with this program I could just "patch" the game to not see the gamepad at all !! :happy:

I'll report what happens when it is used with RetroArch.
Last edited:
OMG OMG OMG !!! SEEMS WORKING !!! :confused:

I just did a pretty fast try, having 3 gamepads plugged in, and with "devreorder" I set visible only the second one... aaaaand... RetroArch detects only the second one, obviously as the default one !! :cool:
This is super cool !! Because while RetroArch is "blind" about the other gamepads, the rest of the system works as nothing was changed !!

There is no need of virtual devices or drivers installation at all !!! Just put the DLL and its textual configuration in the folder with the program !!

The configuration also permit to exclude some executables from using devreorder, if, like in the case of RetroArch, there is more then an EXE in the folder.

Tonight I'll do a complete configuration to see how it's working, because I want to check also the realtime disconnection/connection while RetroArch is open...
happens sometimes that the battery die while playing, so I have to plug the gamepad with cable, and everytime all the controllers shift position between players... because the wireless gamepad disappeared and a NEW gamepad appeared, becoming the last gamepad plugged in...
Last edited:
interesting to see if it recognises the wireless and the plugged versions of the same gamepad as the same gamepad and not reorder them...
wonder if it has some sort of OR wireless gamepad or wired gampad as controller 1 depending on which it detects?

i have some USB to PSX adaptors i would like to have plugged in ready to use if the PSX is picked in ES...