Two arcade joysticks on one control panel

[thorr]

I have built my own arcade panel with two joysticks on it using a Teensy Arduino. I wrote my own code to program the joysticks. I set it up so that the left joystick is the main joystick and the right joystick is the "hat" on the same joystick.

This works fine in some cores like Robotron, but it does not work in other cores like Mario Bros. I am going to be building an arcade cabinet soon, and I want to make sure I do it right.

Should I make each joystick a separate joystick (either separate arduinos, or maybe they can be separated in the code on one arduino), or is there a way to make cores like Mario Bros work with one joystick?

There really needs to be a way to configure the inputs for player 2 like you can for player one in my opinion. The way it works now is a bit of a mystery to me. How do I know which joystick shows up as player 2, and if it is different than the joystick that was set up for player 1, how do you configure it with the MiSTer?

Sometimes I want the second joystick to be part of the first joystick like when playing Smash TV on the SNES. This works perfect the way my two joysticks are configured now. If I separate them into two joysticks, I think I can set them up using alternate buttons when asked at the end of setting up the first joystick and they both will act as player one.

Long story short, can we add the functionality to configure each player's controls on each core so they will work with a single joystick that has a hat? Is it best to separate my two joysticks into their own unique ID's so they show up as two joysticks?

The same would go for more players such as with Gauntlet.

Thanks for your help!
Michael

[thorr]

Anyone? I am assuming the answer is "each core is made by different people, and it is up to them if they want to support two player games on one joystick", or "the main core needs to be updated to support mapping for more than one player, and allow different player controls to be assigned to the same joystick device that was used on a previous player mapping". In my opinion, there should be a definition for how many players there are in the core, and based on this number, allow each core to map whatever they want for each player (map player 1 buttons, map player 2 buttons, etc.). Long story short, it ain't gonna happen without major changes, so just use separate joysticks for each player and hope it maps the way you want it to (left joystick is player one, right joystick is player two). Can anyone give any insight? Thanks!

[jlancaster86]

For the most part, you'd be better off having two independent joysticks.

As you already know, that won't work with games like Robotron: 2048, as you're limited to mapping one controller per player. I'm guessing that's a limitation of the MiSTer framework and not the cores themselves. Maybe the core developers could integrate phantom players into the controls to get around that, but that could get messy.

If you want an all-in one solution, you could build your P2 side with a connector (like a DB-15) that you can easily shift between its own PCB and P1's PCB. If you're really handy, you could even integrate the parts from one of these switches for something more elegant.

[FoxbatStargazer]

Far as I can tell a joystick gets assigned to a player the moment it makes an input on a freshly loaded core, and it becomes de-assigned the moment it is "disconnected." (Whatever that means, but certainly when you pull out the USB for example.) First joystick that moves is player 1, the next joystick that moves while player 1 is still connected becomes player 2, etc. Disconnect player 1 and the next unassigned joystick that moves should become player 1.

As you already know, that won't work with games like Robotron: 2048, as you're limited to mapping one controller per player. I'm guessing that's a limitation of the MiSTer framework and not the cores themselves. Maybe the core developers could integrate phantom players into the controls to get around that, but that could get messy.

Should be possible to adjust the core such that player 1 controls movement and player 2 controls shooting. Far as I can tell a "player" just lines up a gamepad with an input slot on the core, its not inherently linked to credits or start button or anything.

[jlancaster86]

Should be possible to adjust the core such that player 1 controls movement and player 2 controls shooting. Far as I can tell a "player" just lines up a gamepad with an input slot on the core, its not inherently linked to credits or start button or anything.

Yeah, that's what I meant by adding "phantom players". It would certainly be doable, but I'm sure there'd need to be an official and consistent way of doing it across cores.

[thorr]

Thank you for the helpful feedback. Here are some things I have figured out / verified:

From further experimentation, once you map a joystick, if you try to map a second one with alternate buttons, it won't let you if the two joysticks are recognized as the same type. In other words, trying to play Super Smash TV on the SNES with two identical arcade joysticks won't work, while it does work when using the second joystick as part of the first (the hat). If I had separate joysticks, I would have to program the joysticks to appear completely differently in order to be able to program the second with alternate buttons. This may not work though, see more on this below.

Robotron can be configured to work with a second joystick or a dual single joystick, so that will work either way.

Mario Bros works with a second identical joystick, but not with a single joystick with dual sticks (hat).

It seems for 99% of the time, I would be better off with separate joysticks, and I could get to 100% if I can make the second joystick recognized differently than the first joystick so I can reprogram the controls to different things than the first joystick. I still need to do more testing to make sure this would even work, or not work and automatically be joystick 2 if it is the second one plugged in even if it is different. After thinking about it, it probably won't work because it will just be a second joystick with different button mappings on it, and act as player 2. That switchbox idea may be the only option, or maybe I can program the Arduino to reconfigure itself on the fly somehow.

Thanks again!

Edit: I thought of another idea. I can have multiple Arduino sketch files on hand and reprogram the Arduino on the fly to be one or two joysticks with a script. I don't know if I can load the Linux Arduino software on the DE10 Nano or if I would need to plug it into my PC and reprogram it there.

[thorr]

This input subsystem really needs reworked!

Agreed, and the sooner the better because the longer it goes on, the more cores will need to be updated to the new framework.

[invzim]

To make matters worse, IMHO, it seems some cores have standard MAME input removed in other words making the user experience worse, on purpose.

MAME got this figured out a decade or more ago.

https://github.com/MiSTer-devel/Arcade- ... 4d2cb8ede6

And yes, the input system needs to be reworked into something half sane.

[jimmystones]

I've been working on a soon to be released input tester core, which I only created because I have a plan to work on a new more unified input system for arcade cores and need something that'll be quicker to iterate on.

The test core is here is any of you fancy giving it a review - critiques/suggestions always welcome!
https://github.com/JimmyStones/InputTes ... 210703.rbf

The thing with MiSTer is there are so many ways people want to play it, it is difficult to make it work perfectly for everyone! If the community can come up with a list of all the different scenarios that they would like supported I'll certainly try and factor them in if possible.

[paulbnl]

This input subsystem really needs reworked!

Agreed, and the sooner the better because the longer it goes on, the more cores will need to be updated to the new framework.

Maybe I am missing something but I don't know what the problem is.

All cores on MiSTer expect different controllers per player so if you want to use 2 joysticks for 2 players then they should be separate controllers.

Robotron has had an option in the core since last March to use the 2nd player Joystick to fire and 1st player Joystick to move. "Fire->Second Joystick"

MiSTer maps inputs per controller, not per player, so if you have 2 identical controllers then mapping is only needed once and which ever controller is used first will be player 1.

Player assignments can be reset in the MiSTer menu.

[invzim]

I've been working on a soon to be released input tester core, which I only created because I have a plan to work on a new more unified input system for arcade cores and need something that'll be quicker to iterate on.

The test core is here is any of you fancy giving it a review - critiques/suggestions always welcome!
https://github.com/JimmyStones/InputTes ... 210703.rbf

The thing with MiSTer is there are so many ways people want to play it, it is difficult to make it work perfectly for everyone! If the community can come up with a list of all the different scenarios that they would like supported I'll certainly try and factor them in if possible.

I believe a level of de-coupling is needed. My idea is inspired by the JVS standard bitfields(and not a single line of mister code written ), and goes something like this:
1 - input daemon running in the HPS that reads HID, does translation, mapping, all the dirty plumbing.
2 - this daemon populates a shared memory segment with standardized bitfields and values for analog
3 - something else (prob main mister to begin with) reads from this shared memory segment and sends it to the core.

Linux has the mutex mecanisms etc in place to do this cleanly. I did something like this on a different project and it worked well.

JVS has fields defined for everything arcade and can be used for inspiration/QA that everything is covered like service buttons, buttons, switches, analog sticks, rotary, analog etc.

jvs switch.PNG (20.36 KiB) Viewed 10178 times

With this scheme, supporting an odd device, using MAME keys etc would involve patching/updating the input daemon and making sure the standardized shared memory segment is populated correctly - not everything else.

[thorr]

Maybe I am missing something but I don't know what the problem is.

All cores on MiSTer expect different controllers per player so if you want to use 2 joysticks for 2 players then they should be separate controllers.

Robotron has had an option in the core since last March to use the 2nd player Joystick to fire and 1st player Joystick to move. "Fire->Second Joystick"

MiSTer maps inputs per controller, not per player, so if you have 2 identical controllers then mapping is only needed once and which ever controller is used first will be player 1.

Player assignments can be reset in the MiSTer menu.

The problem is when you build a single control panel with two or more joysticks on it and want to use one Arduino and plug it in with one USB connection. Any two or more player game should allow each player to be mapped to the same single joystick. Otherwise you would need separate arduinos for all the joysticks and if you plugged those into a hub inside the control panel, you wouldn't know which was player one and which was player two because they would be plugged in at the same time.

Regarding Robotron, this fixes this one game. I would also want it for Super Smash TV on the SNES which is almost the same style game, but since that is just one player and a console, it won't work. In the case of Super Smash TV on the SNES, both joysticks need to be a single joystick, not separate. As it is today, this same control panel can't be used for Super Smash TV on the SNES and two player Mario Bros arcade for example.

I haven't checked out jimmystones' test core yet (thanks for this btw!), so this is just my initial thought:
From the core menu, start mapping the joystick. When it gets to the end of player one, ask "Continue mapping player 2 on same joystick?" (Y/N). If you say no, then it can work the way it does now with multiple same-style joysticks plugged in one at a time mapping to each player. If you say yes, then it asks for mapping definitions for the next player and continues on until all the players for the core are mapped. It would also be cool if a per button toggle for turbo/rapid-fire option could be added as a separate option in the menu. This would be great for games like Commando and Contra on the NES. I programmed this into my Arduino, but it would be cool if it was built into the MiSTer joystick system.

[thorr]

I've been working on a soon to be released input tester core, which I only created because I have a plan to work on a new more unified input system for arcade cores and need something that'll be quicker to iterate on.

The test core is here is any of you fancy giving it a review - critiques/suggestions always welcome!
https://github.com/JimmyStones/InputTes ... 210703.rbf

The thing with MiSTer is there are so many ways people want to play it, it is difficult to make it work perfectly for everyone! If the community can come up with a list of all the different scenarios that they would like supported I'll certainly try and factor them in if possible.

I tried this and it looks like a great start. I would suggest to add detection of the joystick connected so all inputs are recognized (extra buttons, directional hat, extra axes, etc. similar to what Windows does when you plug in a joystick there). If detection is not possible, then I would add all of the buttons, thumbsticks and their buttons, direction dpads and analog sliders on an Xbox/Playstation controller. That should cover most situations.

I am hoping the new unified input system can be used for consoles as well and that you can add the option decouple the physical joystick from the player assignment to allow any input device to control any player control assignment. For each core, just ask what you want for all the buttons, joysticks, etc. for all the players in one big long list of questions and allow the user to use anything to answer it (anything from joystick1, joystick2, keyboard, mouse, etc.). Thanks for all of your efforts!

[jimmystones]

I agree there is a lot of scope for improvement in general, but managing expectations is important The current system I think probably works well for a good majority of the MiSTer audience, and frankly far reaching changes like separating the input system from the Main mister framework are unlikely to be accepted, especially if is only of interest to a subset of users.

Currently my input tester core is just a standard MiSTer core - it receives the same inputs that you have mapped in the menu like any other, and from the FPGA side that is literally all you can do. To get more inputs in they need to be mapped and tracked in the Main framework and menu core.

By unified input system what I had meant was to go through all the official arcade cores and try to provide a consistent set of options for all the input styles that currently exist - e.g. digital, analog, spinner, paddle, dual joysticks, emulated this and thats etc! They are currently a very variable bunch of implementations, and I'm sure something standardised can be achieved. I think that would help simplify further efforts in future also.

To comment further on all the above ideas I would need a deeper understanding of the Main framework - not something I've delved that far into as yet!

[thorr]

Thanks! Believe me my expectations are in check and I am only providing suggestions that I hope will lead to improvements. I don't expect or demand anything, just hope. What you have stated sounds like a huge step in the right direction and I am very excited to see what you can do with it to improve the current situation. Currently as an end user, the input system is very confusing. For example, I don't know off the top of my head how the MiSTer handles it when a game requires a spinner and a joystick (Discs of Tron - I haven't tried this), or a driving wheel and a separate USB stick shifter. These would be different devices plugged in at the same time and used by one player. When mapping the joystick buttons, it only lets you do it from one device at a time as far as I know. I guess you can map them both separately and skip the buttons that don't apply. I am not sure.

far reaching changes like separating the input system from the Main mister framework are unlikely to be accepted

I am actually suggesting the opposite. I am suggesting that the main mister framework input system get an overhaul and the cores use the new standardized framework. In the new framework, let any attached device get mapped when defining the buttons, and in the cores add the option to use multiple input devices when defining the buttons for any given player, and when this is active, ask about the controls for all of the players at once.

I am currently building an arcade cabinet that I am very proud of because I have never done something like this to this magnitude before, and I am struggling with how I will implement the control panels given the limitations of the MiSTer input system. When you have a control panel with lots of stuff on it, sometimes those things will show up as multiple devices, and sometimes as the same device. Trying to map that to the MiSTer can be a challenge.

One example situation of how it could work is imagine if you have a giant arcade control panel with four players, a trackball, spinner, etc. and one USB cable. The MiSTer main framework could detect all of this and provide a list of everything it detected and have options to define what each button, spinner, etc. is. Button 1: Player 1 Button 1; Button 17: Player 4: Button 3; Mouse X: Trackball X; Mouse Y: Trackball Y; Mouse Z: Spinner; etc. Pressing a button or moving a controller could bring the list to that point and allow you to define it. Then the cores would just say, hey I have two players with two buttons each. Use Player 1 Button 1 and 2, and Player 2 Button 1 and 2. Unplug this USB connected massive controller and plug in your next controller, and allow that to be profiled. If you have two identical gamepads, when defining it, choose "player 1 or 2, button 1" and it assigns them in the order they are plugged in.

[jimmystones]

I was referencing invzims suggestion regarding far reaching changes

There are a lot of unknowns for me still around the handling of multiple different devices, as you say - and I don't have a lot of them at the moment to even test it!

I agree that some kind of mode where devices can all be detected and mix and match assigned to the common types (pad, spinner, paddle, etc, etc) does sound like it has legs to me. Lots of thinking to do

[warham]

Many moons ago I built a control panel for discs of tron. It has two controllers,
1. ultimarc minipac connected to a homemade push pull spinner.
2. a joystick with two buttons.

CXhaC7O.png (222.38 KiB) Viewed 8158 times

thorr I used your vid/pid lines to add spinner function so I have Joystick and spinner spin.
But none of the other buttons connected to the minipac work in that scenario.

Mister seems to choose (1) or the other... either the minipac OR the joystick when i try to map buttons. I need both controllers.

Are there lines similar to your spinner= axis 0 type of mister.ini lines that can be used for mapping buttons?
OR
Is there a way to map two controllers at the same time for 1 player?

[thorr]

Many moons ago I built a control panel for discs of tron. It has two controllers,
1. ultimarc minipac connected to a homemade push pull spinner.
2. a joystick with two buttons.

thorr I used your vid/pid lines to add spinner function so I have Joystick and spinner spin.
But none of the other buttons connected to the minipac work in that scenario.

Mister seems to choose (1) or the other... either the minipac OR the joystick when i try to map buttons. I need both controllers.

Are there lines similar to your spinner= axis 0 type of mister.ini lines that can be used for mapping buttons?
OR
Is there a way to map two controllers at the same time for 1 player?

From what I have gathered, the best way to do all of this is to map everything to the keyboard. So in the minipac, instead of programming it to be joystick buttons, have it be keyboard keys. Many/most cores use the Mame keyboard keys for player 1 and player 2. I think the joystick will work with the keyboard at the same time for one player. Hope this helps!