RetroPie forum home
    • Recent
    • Tags
    • Popular
    • Home
    • Docs
    • Register
    • Login
    Please do not post a support request without first reading and following the advice in https://retropie.org.uk/forum/topic/3/read-this-first

    Configuring <CODE_NOT> Control Mapping in lr-MAME2003?

    Scheduled Pinned Locked Moved Help and Support
    45 Posts 3 Posters 23.6k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • caver01C
      caver01 @Riverstorm
      last edited by

      @Riverstorm What you are describing is how MAME does <CODE_OR> mapping. Waiting for it to register, then, without leaving the line, hitting enter and doing another keymap will <OR> them together (either one will register the input). I can't get it to recognize an intentional double-tap under any circumstance--only the ones done in error, and I can't tell what causes that (I suspect a flakey microswitch).

      The thing is, I can do these mappings just fine in AdvanceMAME, so it's not like I am inept with this process.

      Hearing your success with this makes me think I have something going on with my configuration. By that, I mean, something could be amiss with my base retroarch.cfg. I shouldn't be seeing "LEFT RetroPad Left" when I map to the left arrow on a keyboard. That just reads like two separate inputs. It makes sense that it won't allow me to do a <CODE_NOT> because it thinks I am pressing two keys at once (the raw keyboard key and the RetroPad virtual).

      It makes me wonder what might happen if I try mapping all of my player controls to "nul" in retroarch.cfg. MAME should then just see the raw keyboard inputs. But I am curious how your IPAC is setup.

      One thing I will say is that I haven't been getting double inputs. Dropping a coin, for example, doesn't give me two credits.

      My 4-player cocktail style cabinet built as a custom "roadcase"

      RiverstormR 1 Reply Last reply Reply Quote 0
      • RiverstormR
        Riverstorm @caver01
        last edited by

        @caver01 said in Configuring <CODE_NOT> Control Mapping in lr-MAME2003?:

        But I am curious how your IPAC is setup.

        No I never thought you to be inept at all. If there's any files or information I can pass along just let me know. I will test it out tonight. I have a Pi but not the IPAC with me as it's in the case. :)

        caver01C 1 Reply Last reply Reply Quote 0
        • caver01C
          caver01 @Riverstorm
          last edited by

          @Riverstorm Tests with an external keyboard interest me. Thinking this through, I suspect anyone who uses handheld controllers and hooks up a USB keyboard to do this test does NOT have the keyboard setup in retroarch.cfg (lines with inputs mapped to keyboard keys). Maybe I am wrong, but I am still thinking mame2003 is recognizing both the virtual retropad and the raw key being pressed, as revealed by the resulting line displayed (compare mine to @dankcushions notes).

          My 4-player cocktail style cabinet built as a custom "roadcase"

          1 Reply Last reply Reply Quote 0
          • caver01C
            caver01
            last edited by caver01

            @dankcushions @Riverstorm Ok, PROGRESS HAS BEEN MADE! Yippee!

            Here's what I discovered:

            If I remove all of my player input bindings from retroarch.cfg, I can do some <CODE_NOT> bindings in MAME2003 GUI. However, it fails when I try to map the Player1 joystick and buttons. For those, it is still recognizing double-inputs. For example, LEFT on the player 1 joystick (which the IPAC sends as the left arrow key) is coming in as LEFT RetroPad1 Left. Whereas, outside of Player one controls, keys come as they are. For example, LEFT on the Player 2 joystick registers as d and has none of this RetroPad2 Left virtual input attached.

            If I re-edit retroarch.cfg and force-bind all of my Player1 inputs to "nul" I can do <CODE_NOT> bindings in MAME2003 GUI and even regular bindings show up as only the key inputs (i.e. pushing LEFT on the P1 joystick binds in the GUI as LEFT and doesn't include the virtual RetroPad Left.

            So, here are my initial conclusions about what is going on:

            1. RetroArch sends the virtual inputs (via RetroPads) to MAME2003, as it should, but when the RetroPads happen to be KEYBOARD keys, MAME2003 "hears" both the RetroPad input and the raw key input. This is why TAB works, even though I don't have it bound anywhere in retroarch.cfg. It's also why the inputs I DO have setup in retroarch.cfg show up as both the raw key and the RetroPad input TOGETHER which prevents issuing a <CODE_NOT> (because it is already capturing a <CODE_AND>. Finally, it explains why folks who use handheld controllers don't have this problem. Their virtual inputs aren't raw keypresses, so MAME only sees the RetroPad.

            2. Even if I remove the Player1 bindings in retroarch.cfg, MAME still sees a RetroPad on Player 1 controls. I am thinking there's some kind of EmulationStation-to-RetroArch thing happening here where the initial setup in ES is automatically configured in the cores. The only recourse is to force-bind "nul" to the same.

            So. . . I think I have uncovered a bit of a mess. MAME should not be allowed to see both the RAW input and the virtual one at the same time IF THEY ARE BOTH THE SAME RAW KEY. I don't know how one would correct for this programatically. Maybe it has been dealt with in other cores. The only folks affected are those of us who use keyboard controllers as these create raw inputs that MAME sees by default.

            We don't want to block the RAW keyboard inputs since not everything has an equivalent input on the RetroArch side. I could just bind everything to "nul" but this seems messy. Moreover, how would I handle that configuration when I want to keep the bindings for FBA (it looks like the lr-mame2003 uses the retroarch.cfg in the Arcade folder--what about FBA?) Does anyone know about a way to BLOCK the Virtual RetroPad inputs for one emulator core? That would be preferred approach.

            My 4-player cocktail style cabinet built as a custom "roadcase"

            dankcushionsD 1 Reply Last reply Reply Quote 0
            • dankcushionsD
              dankcushions Global Moderator @caver01
              last edited by

              @caver01 nice job! sounds like my theory earlier was right.

              Does anyone know about a way to BLOCK the Virtual RetroPad inputs for one emulator core? That would be preferred approach.

              my plan before was to block the raw keyboard inputs IF they match the RetroPad inputs. i need to break through the code i linked to earlier to see if that's viable.. maybe this could be logged as an issue against lr-mame2003?

              caver01C 1 Reply Last reply Reply Quote 0
              • caver01C
                caver01 @dankcushions
                last edited by caver01

                @dankcushions Yes. That would do the trick! Sorry, I completely missed your reply, but your interpretation is proving to be correct. And, because two inputs are detected, the double-taps are ignored--each attempt looks like two buttons pressed simultaneously.

                Would you like me to try to post the issue against lr-mame2003? I've never done that.

                My 4-player cocktail style cabinet built as a custom "roadcase"

                dankcushionsD caver01C 2 Replies Last reply Reply Quote 0
                • dankcushionsD
                  dankcushions Global Moderator @caver01
                  last edited by

                  @caver01 please do! it's https://github.com/libretro/mame2003-libretro/issues - you could link to this thread if you don't want to repeat your findings there. i'll have a play over the weekend hopefully

                  caver01C 1 Reply Last reply Reply Quote 0
                  • caver01C
                    caver01 @caver01
                    last edited by

                    In the mean time, I can't really tell if the current state is having an affect on gameplay. I suspect it creates unnecessary overhead--with every input generated the emulator process simultaneous inputs--but I don't get a sense that there is a timing issue or delay.But now that I know what is happening, I tried a workaround on a single ROM using a per-rom config vindictr.zip.cfg where I force-bind every input represented configs/all/retroarch.cfg to "nul". This, temporarily, at least, lets me build single joystick "tank stick" configurations with the <CODE_NOT> key maps described in the original post. Lo and behold. . .I can play Vindicators with lr-mame2003 in all of its CRT-PI shader glory!

                    I consider this workaround temporary, as it will become unnecessary if double-inputs gets resolved the way you describe.

                    My 4-player cocktail style cabinet built as a custom "roadcase"

                    1 Reply Last reply Reply Quote 0
                    • caver01C
                      caver01 @dankcushions
                      last edited by

                      @dankcushions Issue added.

                      My 4-player cocktail style cabinet built as a custom "roadcase"

                      1 Reply Last reply Reply Quote 0
                      • RiverstormR
                        Riverstorm
                        last edited by Riverstorm

                        @caver01 @dankcushions

                        It looks like the same here. I have an IPAC 2 and my global retroarch.cfg configured exactly as you do which looks like the MAME defaults using the A&B swap?

                        input_player1_a = alt
                        input_player1_b = ctrl
                        input_player1_y = shift
                        input_player1_x = space
                        input_player1_start = num1
                        input_player1_select = num5
                        input_player1_l = z
                        input_player1_r = x
                        input_player1_left = left
                        input_player1_right = right
                        input_player1_up = up
                        input_player1_down = down
                        

                        Input lr-mame2003 (Keyboard):
                        "Up Arrow - Right Arrow - Right Arrow"

                        Output:
                        UP Retropad1 Up RIGHT RetroPad1 Right RIGHT RetroPad1 Right

                        Input lr-mame2003 (IPAC 2):
                        "Up Arrow - Right Arrow - Right Arrow"

                        Output:
                        UP Retropad1 Up RIGHT RetroPad1 Right RIGHT RetroPad1 Right

                        Input lr-mame2003 (XBOX 360 Joystick):
                        "Up Arrow - Right Arrow - Right Arrow"

                        Output:
                        RetroPad3 Up not RetroPad3 Right

                        If you break it down it looks like it's not recording the NOT but sees it as 6 keys pressed when in actuality only 3 were used whereas the joystick combines them as a NOT.

                        Is there two issues here? One being the double output (RAW and virtual) and other being not combining NOT statements?

                        Keyboard & IPAC:

                        1. UP
                        2. Retropad1 Up
                        3. RIGHT
                        4. RetroPad1 Right
                        5. RIGHT
                        6. RetroPad1 Right

                        Joystick:

                        1. RetroPad3 Up
                        2. not RetroPad3 Right
                        caver01C 1 Reply Last reply Reply Quote 0
                        • caver01C
                          caver01 @Riverstorm
                          last edited by

                          @Riverstorm said in Configuring <CODE_NOT> Control Mapping in lr-MAME2003?:

                          Input lr-mame2003 (Keyboard):
                          "Up Arrow - Right Arrow - Right Arrow"

                          Output:
                          UP Retropad1 Up RIGHT RetroPad1 Right RIGHT RetroPad1 Right

                          If you break it down it looks like it's not recording the NOT but see it as 3 key-presses for that one action whereas the joystick combines them as a NOT.

                          I would contend that it's actually seeing six (6) keypresses not three (3):

                          1. UP (raw)
                          2. RetroPad1 Up (virtual)
                          3. RIGHT (raw)
                          4. RetroPad1 Right (virtual)
                          5. RIGHT (raw)
                          6. RetroPad1 Right (virtual)

                          which are all <AND>ed together. Also, because they come in pairs (raw+virtual at the same time) it prevents <CODE_NOT> from working--already seeing two different inputs not the same one in succession.

                          My 4-player cocktail style cabinet built as a custom "roadcase"

                          RiverstormR 2 Replies Last reply Reply Quote 0
                          • RiverstormR
                            Riverstorm @caver01
                            last edited by

                            @caver01 said in Configuring <CODE_NOT> Control Mapping in lr-MAME2003?:

                            I would contend that it's actually seeing six (6) keypresses not three (3):

                            You beat me to it! ;) I revised my post after reading the issue.

                            1 Reply Last reply Reply Quote 0
                            • RiverstormR
                              Riverstorm @caver01
                              last edited by Riverstorm

                              @caver01 said in Configuring <CODE_NOT> Control Mapping in lr-MAME2003?:

                              which are all <AND>ed together. Also, because they come in pairs (raw+virtual at the same time) it prevents <CODE_NOT> from working--already seeing two different inputs not the same one in succession.

                              Right, would it be considered two issues going on or do you think correcting one will fix both? It also exhibits the same behavior when pressing buttons too such as CTRL, ALT, etc.

                              caver01C 1 Reply Last reply Reply Quote 0
                              • caver01C
                                caver01 @Riverstorm
                                last edited by caver01

                                @Riverstorm I think this is a single problem with the core implementation.

                                The fact that we can block the RetroPad inputs with "nul" bindings allowing MAME to just receive raw double keypresses that it correctly interprets as <CODE_NOT>, combined with the fact that non-keyboard inputs (RetroPads defined by joypads/handheld controllers) are also able to generate <CODE_NOT> mapping makes me think that MAME is behaving exactly like it should. It's the Libretro implementation of inputs that seems to be the problem. It's uniquely affecting KEYBOARD input since that is the only way a RAW input gets to the emulator outside of the RetroPads.

                                The most desirable fix would be the one @dankcushions suggests--filter out the RAW inputs if they match an existing key mapped in RetroArch. I hope the most practical way to fix it isn't an "all or nothing" proposition. In other words, I'd hate shut off RAW inputs completely, as we would lose the ability to press tab and bring up the MAME GUI (which is needed to define <CODE_NOT> in the first place!).

                                I'd like to check other LR-emulators to see if they behave the same way. For instance, I haven't checked, but I wonder if lr-mame2010 does the same thing.

                                My 4-player cocktail style cabinet built as a custom "roadcase"

                                RiverstormR 1 Reply Last reply Reply Quote 0
                                • RiverstormR
                                  Riverstorm @caver01
                                  last edited by Riverstorm

                                  @caver01 said in Configuring <CODE_NOT> Control Mapping in lr-MAME2003?:

                                  makes me think that MAME is behaving exactly like it should. It's the Libretro implementation of inputs that seems to be the problem. It's uniquely affecting KEYBOARD input since that is the only way a RAW input gets to the emulator outside of the RetroPads.

                                  I don't know if it helps but I did test mame4all-pi and it does work as it should with both keyboard and joystick so that does make sense that it's the Libretro core.

                                  caver01C 1 Reply Last reply Reply Quote 0
                                  • caver01C
                                    caver01 @Riverstorm
                                    last edited by caver01

                                    @Riverstorm Yeah, I think we are only dealing with a RetroArch/Libretro core issue here.

                                    I tested lr-mame2010 and I could create <CODE_NOT> mappings in the MAME GUI whether I have P1 controls mapped in retroarch.cfg or bound to "nul". It works both ways. However, I cannot map ANYTHING in 2010 besides Player1 inputs (in both cases). I don't know if that's an issue with 2010 or what (I don't use it), but I could not setup coins, start, or any joystick/buttons from other player locations on my control panel.

                                    Still, there may be something to learn from how inputs are captured in lr-mame2010. I don't see double entries like I do in 2003. Instead, a key mapped in the GUI to Player 1 left, for example, shows up as Kbd P1 JoyL
                                    I am not sure what the logic is there, but it doesn't read like two inputs captured, and it does pickup the AND, OR and NOT mapping just fine, so something inside there is working like it should.

                                    My 4-player cocktail style cabinet built as a custom "roadcase"

                                    1 Reply Last reply Reply Quote 0
                                    • caver01C
                                      caver01
                                      last edited by

                                      An interesting observation worth mentioning here is that while it took a complete set of "nul" bindings in lr-mame2003 to setup Vindicators (using <CODE_NOT> mappings for RAW keyboard inputs), once MAME has the inputs mapped for the game, you can remove the custom retroarch.cfg (vindictr.zip.cfg). It was only needed to do the mapping. The game plays fine because it is configured to only watch for the RAW inputs. When the regular RetroArch bindings are restored, the game still works. This is further evidence that the keyboard inputs are sending both RAW and RetroPad to MAME.

                                      My 4-player cocktail style cabinet built as a custom "roadcase"

                                      1 Reply Last reply Reply Quote 0
                                      • dankcushionsD
                                        dankcushions Global Moderator
                                        last edited by

                                        i've been going through this and i'm not sure i can think of a nice way to resolve it. the problem is, mame is reading from the abstracted retropad and retrokeyboard. it doesn't know that they are the same key, because they are already abstracted at that point. i don't believe there's a point where you can do a comparison to see if they're the same key.

                                        this seems like something that's best solved through configuration - if you want to avoid the double presses you should change the default binding of (for example) LEFT ARROW from RetroPad1 Left, or change it to 'null'.

                                        caver01C 1 Reply Last reply Reply Quote 0
                                        • caver01C
                                          caver01 @dankcushions
                                          last edited by

                                          @dankcushions I can appreciate that, but it seems lr-mame2010 has it figured out. Maybe apples and oranges, but the double keys aren't showing up there.

                                          My 4-player cocktail style cabinet built as a custom "roadcase"

                                          dankcushionsD 1 Reply Last reply Reply Quote 0
                                          • dankcushionsD
                                            dankcushions Global Moderator @caver01
                                            last edited by

                                            @caver01 said in Configuring <CODE_NOT> Control Mapping in lr-MAME2003?:

                                            @dankcushions I can appreciate that, but it seems lr-mame2010 has it figured out. Maybe apples and oranges, but the double keys aren't showing up there.

                                            i think 2010 gets around it by making mame think a connected gamepad is a keyboard, so it never actually detects gamepads as gamepads, but as the virtual keyboard (i think in the tab menu it will always show up as "Kbd PX...". player 2 SHOULD work (the code is there.. possibly bugged), but player 3 and up won't work i believe, because it only maps 2 virtual keyboards. so this isn't a good solution, but a hack that happens to help in this specific situation.

                                            that's my theory from the code, but i can't test it because i can't connect pads to my mac and can't be bothered to compile it on the pi :)

                                            interestingly, i just found out that mame2010 runs killer instinct 2... at least on my mac.

                                            1 Reply Last reply Reply Quote 0
                                            • First post
                                              Last post

                                            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.