Configuring <CODE_NOT> Control Mapping in lr-MAME2003?
-
In the past, I have been able to setup special control mapping in MAME using the MAME GUI. Specifically, I am trying to configure single joystick to be used as a tank-stick. Games like Vindicators or Toobin that have two sticks per player (UP and DOWN) work in tandem, like driving a tank. You can simulate this with a single 8-way joystick, provided you can exclude certain combinations with a "<not>" function.
The way it is usually done in the MAME menu is you select the control you want to map, and you enter the combos one at a time. To enter a <NOT> key, you press that key twice (or in the case of a joystick, you press the direction twice) before it accepts the complete input.
Problem: I can't seem to configure <NOT> controls in lr-MAME2003. I have seen them appear accidentally, but I don't know how it happened.
Here's a mapping for a single 8-way joystick to control two tank sticks:
Game Control Mapped to Right/Up Up <not> Right or Left <not> Down Right/Down Down <not> Right or Right <not> Up <not> Down Left/Up Up <not> Left or Right <not> Down Left/Down Down <not> Left or Left <not> Up <not> Down
So, for the first one, you would select Right/Up in the MAME menu, then push your joystick up and immediately right twice, and let it accept that. Then add another for Left and immediately Down twice.
Only--it doesn't seem to work. Any ideas how to get NOT controls mapped?
I am running RetroPie 3.6 built from image, updated 2003 binaries just before 3.7 came out, and I use an iPAC-4 controls interface (keyboard) connected to a Pi3.
-
Wondering if anyone (@dankcushions) has thought about this.
For an example, take a look at mapping controls in AdvanceMAME (TAB) and using the double-press to denote NOT in this case.
-
here is the bit of code that handles 'Input (this game)' in mame2003: https://github.com/libretro/mame2003-libretro/blob/dfea13cbb7a3ece51e84e8e02b87a486ab181beb/src/usrintrf.c#L1855
i've only recently started messing with C but i can't see anything there that would handle 'not' type bindings, but maybe someone else can? if you can recreate it (by accident!) and paste the subsequent .cfg file, maybe we can track it down?
-
Wow Nothing like having a peek directly into code! I haven't written C since college and that was almost 25 years ago. I can't wrap my brain around the boolean logic there to tell if it is accepting repeat inputs as NOTs. I don't understand the variables, but I know from other versions of MAME there is a time limit on entering a double keypress for it to be detected as a NOT.
I was wondering if maybe the concept of NOT keys came after this version of MAME. In fact, I might have simply rested on that assumption if I hadn't spotted some mistakes in my mapping for certain ROMs that contained NOT entries by accident. I will see if I can find (create) an example. I know a couple of my microswitches are aging (corroding?) and sending multiple keypresses occasionally. I wonder if the timing is just really really short for accepting a NOT. When I saw them, they were not intentional, so I fixed them when it happened, but I may not be able to reproduce the effect (since I don't know how it happened to begin with). If I can, I will paste a .cfg.
Thanks for looking into it! It's really making MAME2003 the best first choice, and it just keeps getting better thanks to your efforts.
-
@dankcushions Well, I did a little snooping around the mame2003-libretro repository and found some references to the control mapping I am describing above. In MAME jargon, it's referred to as "CODE_NOT" key sequence mapping. It goes hand-in-hand with "CODE_OR" but also logical "AND" combinations when defining key sequences. Here's the reference:
https://github.com/libretro/mame2003-libretro/blob/dfea13cbb7a3ece51e84e8e02b87a486ab181beb/docs/ctrlr.txtThat doc describes how it is possible to construct a controller input key-remapping file. I'd be willing to play with this if I knew where I might be able to drop such a file and have lr-mame2003 find it for a given rom. It does look like this MAME supports it, I just don't know how to build a controller file outside of using the GUI. Thoughts?
-
@caver01 said in Configuring <CODE_NOT> Control Mapping in lr-MAME2003?:
@dankcushions Well, I did a little snooping around the mame2003-libretro repository and found some references to the control mapping I am describing above. In MAME jargon, it's referred to as "CODE_NOT" key sequence mapping. It goes hand-in-hand with "CODE_OR" but also logical "AND" combinations when defining key sequences. Here's the reference:
https://github.com/libretro/mame2003-libretro/blob/dfea13cbb7a3ece51e84e8e02b87a486ab181beb/docs/ctrlr.txtThat doc describes how it is possible to construct a controller input key-remapping file. I'd be willing to play with this if I knew where I might be able to drop such a file and have lr-mame2003 find it for a given rom. It does look like this MAME supports it, I just don't know how to build a controller file outside of using the GUI. Thoughts?
interesting! well, the /ctrlr/ folder should be
/home/pi/RetroPie/BIOS/mame2003/ctrlr/
(you may need to create this). i found what seems to be the default std.ini here: http://shiningmoon.com.pl/PL/Gry/Gry/Emulatory/Mame32/ctrlr/std.iniperhaps that points you in the right direction?
-
@dankcushions YES. That's the idea! Those examples are precisely where I want to go with this. All of the "!" and "|" in that std.ini are exactly what I was expecting to see. I guess we won't know if it works until I try it, but my hope is that it could be a way to build MAME key-mapping files per ROM to override the defaults. I will see where I can go with it. Thanks!
-
@dankcushions
Well, that didn't work. I created the folder in the location described and added a .ini file for Vindicators (vindictr.ini) with:P1_JOYSTICKRIGHT_UP "KEYCODE_UP ! KEYCODE_RIGHT | KEYCODE_LEFT ! KEYCODE_DOWN" P1_JOYSTICKRIGHT_DOWN "KEYCODE_DOWN ! KEYCODE_RIGHT | KEYCODE_RIGHT ! KEYCODE_UP ! KEYCODE_DOWN" P1_JOYSTICKLEFT_UP "KEYCODE_UP ! KEYCODE_LEFT | KEYCODE_RIGHT ! KEYCODE_DOWN" P1_JOYSTICKLEFT_DOWN "KEYCODE_DOWN ! KEYCODE_LEFT | KEYCODE_LEFT ! KEYCODE_UP ! KEYCODE_DOWN"
This should have bestowed tankstick control to the P1 joystick. No luck. Near as I can tell, it didn't do anything. Player 1 tank control has not changed due to this file. I also made sure there wasn't a .cfg for this rom, nor anything saved in NV memory.
Perhaps the command line parameter needs to be specified for -ctrlr_directory? not sure where I would do that with the lr core.
-
@caver01 said in Configuring <CODE_NOT> Control Mapping in lr-MAME2003?:
@dankcushions
Well, that didn't work. I created the folder in the location described and added a .ini file for Vindicators (vindictr.ini) with:P1_JOYSTICKRIGHT_UP "KEYCODE_UP ! KEYCODE_RIGHT | KEYCODE_LEFT ! KEYCODE_DOWN" P1_JOYSTICKRIGHT_DOWN "KEYCODE_DOWN ! KEYCODE_RIGHT | KEYCODE_RIGHT ! KEYCODE_UP ! KEYCODE_DOWN" P1_JOYSTICKLEFT_UP "KEYCODE_UP ! KEYCODE_LEFT | KEYCODE_RIGHT ! KEYCODE_DOWN" P1_JOYSTICKLEFT_DOWN "KEYCODE_DOWN ! KEYCODE_LEFT | KEYCODE_LEFT ! KEYCODE_UP ! KEYCODE_DOWN"
This should have bestowed tankstick control to the P1 joystick. No luck. Near as I can tell, it didn't do anything. Player 1 tank control has not changed due to this file. I also made sure there wasn't a .cfg for this rom, nor anything saved in NV memory.
Perhaps the command line parameter needs to be specified for -ctrlr_directory? not sure where I would do that with the lr core.
hmm, i will have a look at this soon in my development environment and see what's happening.
-
@dankcushions I was doing some remapping for vertical games (cocktail mode) and ran across some accidental <CODE_NOT> maps in the MAME gui. I exited and made a copy of the config file:
It only happens when I remap Button 1 for my rotated vertical games. On my cabinet, Player 1 vertical controls are on the left side of the cabinet. These controls normally correspond to Player 3 on a 4-player game. If you follow me, I am basically remapping Button 1 to my Player 3 pushbutton. On the IPAC4 this corresponds to "R.CONTROL".
So, I am in the MAME GUI mapping buttons, and I get to Button 1, press ENTER and it is ready to receive my input. I press R.CONTROL and it registers as "NOT R.CONTROL". I usually don't notice this as I am going through until I try to test play. Of course, the "not" doesn't work at all and I have to remap that key again.
Here's what I think is happening--that button is on an old cherry microswitch. it sometimes bounces and registers a double-key press. This makes sense, as MAME is supposed to allow double-presses to register as a <CODE_NOT>, but here's the rub--I can't make it register a <CODE_NOT> which makes we wonder if maybe the time allotment is too short. It should be around 1-second. It's definitely detecting multiples with <CODE_AND> with a proper timer, as I can setup Q-bert on an 8-way by mapping to the corners.
-
And, by the way, can you launch Sarge with 2003? All I get is the MAME VOLUME control on the screen--as if it's defaulting to some Service mode.
-
@caver01 said in Configuring <CODE_NOT> Control Mapping in lr-MAME2003?:
Here's what I think is happening--that button is on an old cherry microswitch. it sometimes bounces and registers a double-key press. This makes sense, as MAME is supposed to allow double-presses to register as a <CODE_NOT>, but here's the rub--I can't make it register a <CODE_NOT> which makes we wonder if maybe the time allotment is too short. It should be around 1-second. It's definitely detecting multiples with <CODE_AND> with a proper timer, as I can setup Q-bert on an 8-way by mapping to the corners.
Hey Caver, wouldn't the <NOT> need to be registered with another key first? I mean to register only a NOT command alone is basically saying you can press anything but right-ctrl but it seems more like it wouldn't register any working key and would only test the NOT condition which would make the key do nothing.
Are you using a SuzoHapp button? If you have a spare cherry switch you could switch them out for testing? I didn't think you could press it to fast but I know you can register it to slow. I never seem to have much luck with the NOT command in MAME.
-
@Riverstorm I have had great success in AdvanceMAME. It registers a not when you press the same key in rapid succession. If you press two different keys in succession, they <AND> together. And if you pause long enough for MAME to accept the key and print it on the screen, pressing enter again without moving to another control will have you entering a second key mapping and this will be <OR> with the existing.
Try mapping a TankStick configuration in AdvanceMAME. It works great. For Right/UP you can hit Enter, then use the joystick to tap out UP-RIGHT-RIGHT in rapid succession. Wait for it to accept, then enter again and do LEFT-DOWN-DOWN. This gives you the combination of ORs, ANDs and NOTs to map Right/Up on a single joystick, and you can move on to the others (see my notes above). That's what I do in AdvanceMAME, but in 2003, the double-taps fail.
I have spare microswitches--I was merely trying to understand why/how I could accidentally get a "not" to show up in a mame2003 config. The fact that it shows up occasionally for me by accident proves that 2003 can handle <CODE_NOT> mapping. I am thinking that it's just interface timing that is messed up for this.
-
i just tried it on my osx install of lr-mame2003, and NOT and AND worked as you'd expect - not particularly fast on the button timings, either. will test pi install in a sec...
-
@dankcushions Interesting! I am particularly curious about setting up Toobin, Sarge (if it would launch correctly) and Vindicators. I would say Battlezone for single-joysitck cabinets, but that one being vector is probably better in AdvanceMAME anyway.
-
@caver01 said in Configuring <CODE_NOT> Control Mapping in lr-MAME2003?:
I have spare microswitches--I was merely trying to understand why/how I could accidentally get a "not" to show up in a mame2003 config. The fact that it shows up occasionally for me by accident proves that 2003 can handle <CODE_NOT> mapping. I am thinking that it's just interface timing that is messed up for this.
Sorry I was building off previous posts/conversations. I know you have pretty much mastered AdvMAME! ;) I was referring to "regular" MAME.
I haven't tried 2003 and I was taking it for granted it was fully working in 2003 as I believe it does in mame4all fine. The only reason I was asking about the cherry switches is they make such a clean click. When you look at the innards they seem to be magnetic when they "click" together. Hence a double click seems almost faulty but I suppose it's a good indicator that the program could be faulty too.
If you have a moment can you explain what you do with the tank stick? You're trying to say up but not right and down but not left with a regular joystick?
-
yeah... this works absolutely fine on my pi :) i'm using a normal UDEV controller (joystick, although i'm sure it would work on my gamepads also), and what i do is:
- TAB on keyboard to enter mame menu
- Input (This game) ... press ENTER on kb to select
- UP/DOWN ARROW on kb to select whatever input
- A button on stick (pause of about half a second), double tap B button)
- wait a few seconds
- result: "RetroPad1 A not RetroPad1 B"
if i repeat the same but instead tap them both at the same time:
- result: "RetroPad1 A RetroPad1 B" (i guess this means AND)
so.. this doesn't work for others?
-
@dankcushions said in Configuring <CODE_NOT> Control Mapping in lr-MAME2003?:
so.. this doesn't work for others?
It works ok in mame4all-pi & lr-imame4all.
-
@Riverstorm and lr-mame2003.. at least in my test above.
-
@dankcushions said in Configuring <CODE_NOT> Control Mapping in lr-MAME2003?:
@Riverstorm and lr-mame2003.. at least in my test above.
Ok, I am using an XBOX controller so we'll have to wait and see what Caver comes back with for input as it seems to be working software wise for both of us.
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.