Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Request] Add MAME keyboard input options #135

Closed
Takohiko opened this issue Jul 17, 2021 · 26 comments
Closed

[Request] Add MAME keyboard input options #135

Takohiko opened this issue Jul 17, 2021 · 26 comments

Comments

@Takohiko
Copy link

Hello,
I am using a JVSpac2 with MiSTer on an New Net City arcade machine that uses JVS.
Unfortunately, due the way it works, I cannot play 2 player games with it (only single player if I configure custom inputs).
Changing this to the default MAME keyboard scheme enables users of the JVSPAC2 to play 2 players.
Could this please be looked into? As an option if not default?
Thank you!

More details:
https://github.com/jotego/jtcps1/issues/36
https://misterfpga.org/viewtopic.php?f=25&t=94

@sorgelig
Copy link
Member

MiSTer supports JammaSD/J-PAC/I-PAC standard.
i don't know what is JVSpac2. If it supports the same standard as above, then you can use options in MiSTer.ini: jamma_vid and jamma_pid
You can read comment in MiSTer.ini
I think MiSTer already supports enough jamma zoo, so can use one of supported input device.

@Takohiko
Copy link
Author

Thanks taking the time answering :) Not sure if was really cleat and I actually forgot to put on more link:
https://irkenlabs.com/jvs-pac2/introduction
https://irkenlabs.com/jvs-pac2/mister-for-jvs-crt-cabinets

The reason of my ask about supporting default Mame keyboard input (An it work fine with a lot of arcade cores):

The input system of MiSTer is a bit of a mess when it comes to arcade cores. MiSTer cores can consume gamepad and/or keyboard input from the Linux subsystem, which makes sense from a console/retro-computer perspective, but no so much for arcade, where you have one cabinet. It's not obvious where an arcade core should look for things like TEST, SERVICE, TILT etc, so naturally, it's either not implemented or varies from core to core.

Gamepad input
For a console/computer core, one physical USB device will be player 1, another physical device can be player 2. This is all strongly tied to low-level USB workings, so input from one USB device is constrained to one player.
Since gamepads are not equal, you will also have to remap your gamepad. To complicate matters further, MiSTer can take input from a physical USB keyboard and present it to a core as ONE gamepad, not two.. There is a hack to get around this, but I will not get into that.

Keyboard
To avoid the complexities of the MiSTer input system, arcade cores can also consume keyboard input where there is no artificial player1/player2/cabinet limitations. Most cores support this, and most cores use the standard MAME mapping.

Getting out of trouble / limitations
If you for whatever reason used the "Define joystick buttons" of MiSTer and and pressed something on your cab - you now have a virtual gamepad, which will cause issues with things that consume keyboard input, like arcade cores.

To fix this, have a look in the "config/input" directory on the MiSTer SD card, and delete the .map files you have there.
Unfortunately a keyboard device like the JVS-PAC 2 can't be both a "virtual gamepad" and a keyboard, unless you are super careful how you set up the mapping in MiSTer, so the JVS-PAC 2 is probably not a great option if you want to run retro-computers/consoles AND arcade cores in your cabinet - something you shouldn't try in the first place, as it's frowned upon by purists :)
In the absence of an arcade specific input system in MiSTer, I suspect MAME keyboard input will be the standard going forward.

@sorgelig
Copy link
Member

sorgelig commented Jul 18, 2021

The key point is that mentioned "JammaSD/J-PAC/I-PAC" presented as keyboard devices and MiSTer already know how to handle them and correctly splits between 2 players. More over, those input devices are using mame standard. That's why i've said if you will add vid/pid of your device to those INI options then it will be recognized as mame input. However you need to define system wide map for "JammaSD/J-PAC/I-PAC" once and then it will work as gamepad. Test/service/tilt are not gamepad related buttons - they are implemented as DIP switches (where it's implemented).

MiSTer is universal emulator which primarily focused on consoles and computers. It's supports arcades as well but it's not mame replacement, nor there is a goal to mimic mame. MAME is software emulator with many options not available in FPGA. And of course there is no target to be integrated into arcade cab. The target is like small console with USB input gamepad/keyboard and HDMI output. Other options are possible at some extents.

@Takohiko
Copy link
Author

No worries, again thanks for taking the time to answer this. I'll definitely give it a try. MiSTer is so amazing and versatile that it's just easy to get excited for things beyond its original purpose, a testament to all the hard work being put into it! Super thankful for it :)

@Takohiko
Copy link
Author

With everything said above understood, I just wanted to update the results of adding the jamma_vid and jamma_pid of the inpuit in Mister.ini:

  • Same as before, Arcade cores are working fine with 2p, but the Neogeo Core does not recognize the 2P controls (can only define 1P, and the 2P are not automatically defaulted to the correct ones like the arcade cores).
    It's ok, I can play 1p and switch to the original hardware for 2p sessions easily, but leaving it it here in case someone else in the future is looking into it.
    Thanks!

@sorgelig
Copy link
Member

is this issue a NeoGeo specific? How about other consoles with 2 player support?

@Takohiko
Copy link
Author

I checked with a few 2 players consoles cores (Nes, Snes, Genesis, TG16) and it's the same yes, while the arcade cores are fine.

@sorgelig
Copy link
Member

try this core:
https://github.com/MiSTer-devel/InputTest_MiSTer
Does it react on Joy2?

@sorgelig
Copy link
Member

I don't have any of these jamma inputs, but basically any keyboard can be used as jamma input if you assign jamma_vid and jamma_pid to that keyboard.
So i've tested on my keyboard with InputTest core. First (of course) i went to Menu core and defined joystick buttons just for player 1 (second player gets the same assignments).
Then in InputTest core i see reactions for both Joy1 and Joy2 using that keyboard.

I can give you a hint: You don't need any special jamma input device. You don't need to use jvs-pac.
Just get any USB keyboard which you would like to disassemble. Open it, then check what combinations of row/column are used for each key needed for jamma:

	{KEY_5,         1, 0x120}, // 1P coin
	{KEY_1,         1, 0x121}, // 1P start (shift key)
	{KEY_UP,        1, 0x122}, // 1P up
	{KEY_DOWN,      1, 0x123}, // 1P down
	{KEY_LEFT,      1, 0x124}, // 1P left
	{KEY_RIGHT,     1, 0x125}, // 1P right
	{KEY_LEFTCTRL,  1, 0x126}, // 1P 1
	{KEY_LEFTALT,   1, 0x127}, // 1P 2
	{KEY_SPACE,     1, 0x128}, // 1P 3
	{KEY_LEFTSHIFT, 1, 0x129}, // 1P 4
	{KEY_Z,         1, 0x12A}, // 1P 5
	{KEY_X,         1, 0x12B}, // 1P 6
	{KEY_C,         1, 0x12C}, // 1P 7
	{KEY_V,         1, 0x12D}, // 1P 8

	{KEY_9,         1, 0x12E}, // Test
	{KEY_TAB,       1, 0x12F}, // Tab (shift + 1P right)
	{KEY_ENTER,     1, 0x130}, // Enter (shift + 1P left)
	// ~ Tidle supportted?
	{KEY_P,         1, 0x131}, // P (pause) (shift + 1P down)
	{KEY_F1,        1, 0x132}, // Service
	{KEY_F2,        1, 0x133}, // Test
	{KEY_F3,        1, 0x134}, // Tilt

	{KEY_6,         2, 0x120}, // 2P coin
	{KEY_2,         2, 0x121}, // 2P start
	{KEY_R,         2, 0x122}, // 2P up
	{KEY_F,         2, 0x123}, // 2P down
	{KEY_D,         2, 0x124}, // 2P left
	{KEY_G,         2, 0x125}, // 2P right
	{KEY_A,         2, 0x126}, // 2P 1
	{KEY_S,         2, 0x127}, // 2P 2
	{KEY_Q,         2, 0x128}, // 2P 3
	{KEY_W,         2, 0x129}, // 2P 4
	{KEY_I,         2, 0x12A}, // 2P 5
	{KEY_K,         2, 0x12B}, // 2P 6
	{KEY_J,         2, 0x12C}, // 2P 7
	{KEY_L,         2, 0x12D}, // 2P 8

then simply solder/connect your cab buttons according to those keys. Now you have jamma input device :)
Don't forget to define jamma_vid and jamma_pid in MiSTer.ini

@Takohiko
Copy link
Author

Tried it and after defining the controls for P1, no input registered for P2.
I did add my Jamma_PID and VID to MiSTer.ini
I understand that I can rewire the cab for sure, but I am trying to keep it as clean as possible, thus having the JVSpac2 (since that cab is JVS). I mean it works perfectly fine on the arcade cores that are using the default Mame button configuration/mapping (that's why I was asking to have this as an option for the core at the beggining), so I am fine with that,
If it cannot be done for other cores, then it's ok I'll keep using the original hardware for MVS games at least :)
I do appreciate your help troubleshooting!

@sorgelig
Copy link
Member

If it works for arcade cores then it should work for console cores. What you are asking is already implemented. So it's either a bug or something i didn't understand.
You didn't tell, did you try InputTest core? Does it register P2 inputs?
By the way, in /media/fat/config folder (and also inside input subfolder) there can be config files for your device. search by PID and remove all files there then restart Menu core and assign the buttons again. Old configs when your input devices wasn't assigned to jamma may prevent it work correctly.

@Takohiko
Copy link
Author

I did confirm in my last post, but I''' try to sumarrize the troubleshooting so far:

  • Identified and Added my jammasd_vid + jammasd_pid to my MiSTer.ini for my controls
  • Deleted everything from /media/fat/config and the inputs subfdolder
  • Launched the InputTest_20210703.rbf core
  • Configured the P1 buttons in the Core menu
  • Tested P1 on the test screen with the controls, everything light up fine when I press the P1 Buttons
  • Tested P2 buttons, nothing light up/react
  • Tried the NeoGeo core (And SNES, and NES, and Genesis, and TG16) WITHOUT configuring the controls: Not input registered on either P1 or P2
  • Tried the NeoGeo core (And SNES, and NES, and Genesis, and TG16) WITH configuring the controls from the core menu: Input registers fine on P1 but do not work for P1 (same behavior as the InputTest core
  • Some arcade cores dot not work by default: Green Beret, 4D Warriors. Popeye, Bubbles: I have to go and configure the button for p1, and then P2 does not react

Working by default:

  • Launched Tetris (Sega) Core: works perfect for 1 and 2 players + coin WITHOUT touching the button configuration
  • Launched 1943 Kai Core: works perfect for 1 and 2 players + coin WITHOUT touching the button configuration
  • Launched Gauntlet 2 Core: works perfect for 1 and 2 players + coin WITHOUT touching the button configuration
  • Launched Contra Core: works perfect for 1 and 2 players + coin WITHOUT touching the button configuration
  • Launched a lot of Jotego Cores (CPS1, CPS2, System 16 beta,): works perfect for 1 and 2 players + coin WITHOUT touching the button configuration

To go back to my original request, it seems that by default the Jotego core are mapped with MAME keybaord defaults, so it works by default as it's what the buttons are translated to by the jvspac2
The others are not, and when trying to map the buttons, it kinda breaks apart and only register p1 mapping.
That's why I was wondering if an option to default to MAME key mapping could be added, similar to how the Jotego and some arcade games are, without having to manually register them manually through the core input menu as it seems to break P2.

Hope the additional details helped?

Thanks!

@sorgelig
Copy link
Member

if you connect jvspac2 to computer, are buttons on P2 the same as in table in my post above?

@Takohiko
Copy link
Author

Yup, they are the same, and here is the breakdown on the official site for reference:
https://irkenlabs.com/jvs-pac2/keyboard-operation

@sorgelig
Copy link
Member

connect to USB console https://github.com/MiSTer-devel/Main_MiSTer/wiki/Console-connection
and get some debug info. You need to use Menu core (other cores have no such info).

Press buttons on P1 controls - copy debug info. Then do the same for P2.

for example my debug info when i press up/down/left/right on P1 and P2:

Input event: type=EV_KEY, code=290(0x122), value=1, jnum=1, ID:046d:4024:07
Input event: type=EV_KEY, code=290(0x122), value=0, jnum=1, ID:046d:4024:07
Input event: type=EV_KEY, code=291(0x123), value=1, jnum=1, ID:046d:4024:07
Input event: type=EV_KEY, code=291(0x123), value=0, jnum=1, ID:046d:4024:07
Input event: type=EV_KEY, code=292(0x124), value=1, jnum=1, ID:046d:4024:07
Input event: type=EV_KEY, code=292(0x124), value=0, jnum=1, ID:046d:4024:07
Input event: type=EV_KEY, code=293(0x125), value=1, jnum=1, ID:046d:4024:07
Input event: type=EV_KEY, code=293(0x125), value=0, jnum=1, ID:046d:4024:07

Input event: type=EV_KEY, code=290(0x122), value=1, jnum=2, ID:046d:4024:07
Input event: type=EV_KEY, code=290(0x122), value=0, jnum=2, ID:046d:4024:07
Input event: type=EV_KEY, code=291(0x123), value=1, jnum=2, ID:046d:4024:07
Input event: type=EV_KEY, code=291(0x123), value=0, jnum=2, ID:046d:4024:07
Input event: type=EV_KEY, code=292(0x124), value=1, jnum=2, ID:046d:4024:07
Input event: type=EV_KEY, code=292(0x124), value=0, jnum=2, ID:046d:4024:07
Input event: type=EV_KEY, code=293(0x125), value=1, jnum=2, ID:046d:4024:07
Input event: type=EV_KEY, code=293(0x125), value=0, jnum=2, ID:046d:4024:07

@prrole
Copy link

prrole commented Jul 24, 2021

I believe the request here is to get keyboard support for the MVS core, like it exists for many of the other arcade cores - not guidance on how to get the keyboard->virtual gamepad input system working.

Regarding MAME, I think we all are aware of the differences. Instead of thinking of it as a 'keyboard', it could perhaps be more constructive to think of it as a device with a lot of digital switches that works the same regardless of manufacturer with zero user configuration.

MiSTer utilizes the Linux USB input system, are there any technical reason not to support the keyboard input method? From a user perspective, the way @jotego does it is very user friendly.

The physical gamepad input device pr player paradigm does not map perfectly for arcade, and if accuracy is a goal, this will become a bigger issue going forward. Test, tilt and service are momentary switches on the real hardware - not DIP switches, and game PCB's often have other cabinet related input switches for controlling volume etc.

Having a uniform MAME keymapping for arcade would make the user experience a lot better for a lot of people.

@sorgelig
Copy link
Member

sorgelig commented Jul 24, 2021

MiSTer already supports MAME input and it perfectly works with JPAC/IPAC/JammaSD. Service buttons such as Tilt/Test useful are only in couple arcades. It can be simulated through OSD by either DIP options or T/R options without reserving special key/button. MiSTer is targeted for gamepads primarily. If you count amount of games for all supported consoles and computer cores then arcades are small fraction of that. So main input device is gamepad. Adding special very rare button/key such as Tilt/Test means it needs to be reserved on gamepad which is unreasonable as it's beyond capacity of many joysticks. Some users prefer to use even more reduced joysticks with 2-3 buttons only which is already less than MiSTer needs. You want to say you don't care if someone uses joystick to play arcade core?

Besides all said above, specific arcade still can assign special buttons Tilt/Test to button (it's up to core), so MiSTer doesn't deny it. Also arcade can react on key presses - all keyboard codes are transferred to cores.

Why JVS-PAC doesn't work it's unknown.. It can be some bug in firmware, or user does something wrong. May be Takohiko thinks he does essential (for him) thing while it could be incorrect. So i'm trying to understand the source of problem. It has nothing to do with MAME input support as it's already supported and every core (including consoles) should work with 2-player MAME input.

@Takohiko
Copy link
Author

I tried form a fresh install going through the procedures I listed above (adding the Pid and Vid etc), the common thing is that with @jotego 's cores it works out of the box with no configuration needed, and that with the other cores it does not and after configuring p1, p2 does not work. So there is something here that might be valuable to take from Jotego's settings and offer on other core?

I'll work on getting the debug info added to this ticket in the next 24hrs, busy weekend for me but I'll get to it!

Thanks!

@sorgelig
Copy link
Member

sorgelig commented Jul 24, 2021

Btw, please add the list of input devices you see in debug info when Menu core starts.

Additional setting for VID/PID is required because MAME went a wrong way re-using the keyboard. It's not universal way as there are still computer cores using the keyboard as it supposed to be used. USB has special usage pages for joysticks which is supposed to be used.

So there is something here that might be valuable to take from Jotego's settings and offer on other core?

Arcade cores were long time before Jotego, and converter if key codes to P1/P2 players was inside arcades but it's wrong way as it hardcodes and basically does unneeded job. His cores are run on different FPGA chips with limited resource on MCU side, so it's has some points to put this redundant converter in his cores. MiSTer has performance CPU with Linux to do such task and it does at least with other MAME controllers. It even works fine if you will use a generic keyboard. May be just for test you can write VID/PID to jamma options to see if you can use a single keyboard as MAME 2-player input device. My keyboard works ok. Just remember, once you assign the keyboard to MAME, it won't act as a normal keyboard.

@paulb-nl
Copy link
Contributor

I did confirm in my last post, but I''' try to sumarrize the troubleshooting so far:

  • Identified and Added my jammasd_vid + jammasd_pid to my MiSTer.ini for my controls

Probably a typo but it should be jamma_vid & jamma_pid. Just replace the vid/pid values:
https://github.com/MiSTer-devel/Main_MiSTer/blob/1f9a325602479cf96358c347dd58b03b2d36664e/MiSTer.ini#L112

  • Launched the InputTest_20210703.rbf core
  • Configured the P1 buttons in the Core menu

Sorgelig said to map the buttons in the Menu core, not in the Core menu. There is a difference. Replace jamma_vid/pid then reboot to the Menu core and map the buttons there. There is a detailed guide here: https://misterfpga.org/viewtopic.php?f=32&t=448

  • Tested P1 on the test screen with the controls, everything light up fine when I press the P1 Buttons
  • Tested P2 buttons, nothing light up/react

Just get it working in the InputTest core and it will work in every core.

@Takohiko
Copy link
Author

Takohiko commented Jul 31, 2021

OMG Paul. You were absolutely right, there WAS a typo in my ini, is was using jammasd_vid
I changed removed the extra letters, and now it's working.

I remapped from the Menu core (and not the Core menu) as well, and now things re working fine for 2 players on Neogeo and other console cores as well.

For some cores, the default is not great, but I am able to remap them to proper buttons without breaking the 2 players support. Tested with Neogeo, Nes, Snes, + a few of the Arcade core I was talking about above and now they work properly.

That's great news! @prrole , something to add to the FAQ on you side maybe?

@Takohiko
Copy link
Author

Just a note:
Mame changed the default Keyboard controls for P2 button 5 from "i" to "e"
Might be worth updating that in the default jamma controls for MiSTer :)
https://docs.mamedev.org/usingmame/defaultkeys.html#player-2-controls

@sorgelig
Copy link
Member

sorgelig commented Aug 1, 2021

Generally speaking, MiSTer doesn't follow MAME config but input devices config.
for example this map: https://www.ultimarc.com/control-interfaces/i-pacs/i-pac4-board/
Core gets joystick codes, so core doesn't deal with MAME inputs directly.

@prrole
Copy link

prrole commented Aug 1, 2021

To say that one USB report descriptor is more correct than the other is up for interpretation, I doubt the USB Implementers had retro computing in mind when the standards were made. Further the statement does not take into account the thousands of hardware units already out there. You can't change history.

I think from a system perspective it would make sense to accommodate arcade - the number of cores already outnumber console, and judging by development activity this is a trend that will likely continue for quite some time.

From a user perspective, not having to figure out VID/PID values and do global and pr game remaps is desirable - having things like test and service work out-of-the-box is also something that is greatly appreciated by arcade enthusiasts. It took 15 days for @Takohiko to figure out how to get 2p working in MVS, which says a thing or two about user friendliness.

I don't see any reason why one solution should exclude the other, as demonstrated in most of the arcade cores that consume both gamepad and keyboard input.

A bit longer term, a major refactor of the entire input system is likely called for, but that's a topic for another git issue :)

@sorgelig
Copy link
Member

sorgelig commented Aug 1, 2021

Most arcade cores already DON'T accept keyboard input. They relay on joystick input.
Having central management of input on HPS side is much better because it can be tweaked and improved, then all cores will be affected at once. Otherwise any change will require modification in every core.
Universality comes with complexity always. Arcade cabinets is a small fraction of uses. If you use traditional input device (gamepad), then you don't need any tweaks. If You want something special then prepare to read about it. There is a MiSTer forum where it was discussed and solution is given.

@sorgelig
Copy link
Member

sorgelig commented Aug 1, 2021

It took 15 days for @Takohiko to figure out how to get 2p working in MVS, which says a thing or two about user friendliness.

The solution is written in second post of this thread 14days ago. Everybody can make a mistake.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

4 participants