[SJ@JX Arcade] Using start select in Makecode(detected&working)

[QuadDam]

Hi! I talked a bit about this on the Makecode Arcade forum with you. At a bit of a loss how to do this I am using this encoder https://www.amazon.ca/gp/product/B07FZ3YT1G/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1
and when setting up the joystick and keys in emulation station I configure them all. However as I mentioned the start/select will not bring me out of Makecode as it does in Mame. I know you mentioned the .cfg files but I am a bit new to Raspberry Pi so if you could walk me through how to get those to work in Makecode that would be awesome.

[Vegz78]

...if you could walk me through how to get those to work in Makecode that would be awesome.

Hi @QuadDam / @Dace,

I'll try my best, even though it's hard to be precise and correct when I don't have first hand access myself to your particular gamepad. We therefore have to try to help eachother on the way.

First a brief introduction to how MakeCode Arcade games and McAirpos handles game controller inputs:

Basically, there are 2 kinds of button/input event types for the various supported controllers(keyboards, gamepads etc.):

1. EV_KEY: These are "digital" type of buttons, with either value 1(pressed) or 0(released), typical for keyboards and many gamepad buttons, like typically the START button in question, SELECT etc. EV_KEY is the only type of inputs that MakeCode Arcade games understands natively.
2. EV_ABS: These are "analog" or graded inputs with values typically somewhere between -255 and 255, denoting how much a joystick axis/button is moved/pressed in one direction. Most modern gamepads have several EV_ABS for both axis and various buttons. McAirpos uses uniput-mapper to translate EV_ABS input values, if present, to EV_KEY values and mappings, which MakeCode Arcade games understand.

Then there is the fact that MakeCode Arcade games operates with "RAW"/physical/most basic inputs, totally unaware of any higher level gamepad systems/libraries, like SDL etc. in RetroPie etc. To be precise, MC Arcade games uses input events directly from Linux Input Subsystem, and how these were implemented in the gamepad hardware driver, which has no adapted standard between gamepad producers, and where e.g. value -127 for a given input could be either up or down, within or outside bounds etc., and the names for the various axis and buttons varies just as much...

MC Arcade games with McAirpos have 3 logical levels to deal with this, in order of higher complexity to get it right:

1. Physical/Linux Input Subsystem(LIS) level(is the button intended to be START physically wired correctly to driver's representation of the START button, and how/by what name and type is it represented in LIS?)
2. Are all gamepad inputs EV_KEY and can be mapped directly to MC Arcade games in /sd/arcade.cfg without the need for uinput-mapper,(run launCharc with nomap option), or
3. Are some buttons EV_ABS which have to be translated by uinput-mapper to EV_KEY, and the re-mapped via ../uinput-mapper/configs/arcade1.py to the mappings in /sd/arcade.cfg?

The good news are that with most buttons/axis working, you're already 95% there, and with a high probability of success, hopefully on the first/lowest level. (And if you're lucky, your gamepad driver only sends EV_KEY input events, and you may also choose to optimize away the highest level/uinput-mapper, saving a lot of resources running Python and re-mapping of mappings, with just a few edits to /sd/arcade.cfg.)

What you need to do is:

1. Find your gamepad's input eventX number: more /proc/bus/input/devices
2. Read out all registered button and types, and test to which button name each physical button is mapped by(maybe install evtest first if not already installed) running: evtest /dev/input/eventX, where X is the input number found in the first point.

Hopefully(normally) your gamepad driver has registered keys for START and SELECT, and you just have to rewire the two buttons you intended to be START and SELECT, respectively, and everything works out of the box(except for a required quick remap inside RetroPie afterwards). If not, or if you only have EV_KEY inputs, please come back here again, and we'll give it another shot with the various config files.

Other issues maybe related to yours:
#9
#6

Thanks for the star and nice pictures of and other resources from your great project that you shared on the MakeCode forum! I hope you get this to work for yourself and your students!

Br, Vegard

[QuadDam]

Great thanks for the info, so

1. I ran evtest /dev/input/eventX
   https://drive.google.com/file/d/1Eaonui26ALcExJGZZnt45Xp70Wr46nZn/view?usp=sharing
2. It created this running list, so I tapped the select and start buttons (how do you stop the list from running? I had to hit ctrl/alt/ delete)
   https://drive.google.com/file/d/1ahhOZiYPh3amjEUKrqec77v6RPnSgyrt/view?usp=sharing
3. I am unsure what to do from here so I looked up how to retrieve the event log
   https://drive.google.com/file/d/1BTeWm5qNHSUi0I7fkOGmSeUEC_1Hqxbq/view?usp=sharing
   which results in nothing, just a blinking cursor, so I am a bit sure what to do beyond this, even if I get that list what would be the next step? Sorry for my lack of skills on the Pi :( thanks for any help!

[Vegz78]

1. I ran evtest /dev/input/eventX

Ok, so you found the "Dragonrise" controller at /dev/input/event2, that's good and seems correct.

2. It created this running list, so I tapped the select and start buttons (how do you stop the list from running? I had to hit ctrl/alt/ delete)

Then, when running evtest /dev/input/event2 (I assume event2 and not eventx that you wrote above), you got a running list instead of the normal static list of all available button/axis names for the driver, which we want, and a cursor waiting for you to press a button or move the stick in a direction.

This might be because your stick maybe not is not dead center in one of the axis directions(EV_AVS....ABS_Z), and therefore giving continuous inputs in the range 128-133, which makes it harder to read the button presses in between.

However, at around 9 seconds into your movie, I was able to read out button press (EV_KEY....BTN_THUMB), which is neither the button BTN_START or BTN_SELECT I was expecting from you pressing either of the two front buttons that you intend to be START and SELECT, respectively:

So you could either try to center the joystick or disconnect its wires, and then run evtest /dev/input/event2 again and note down the BTN_ name for all your buttons. Exit evtest, normally, by pressing CTRL+C.

From what we have discovered so far, I now more strongly suspect that some of the buttons are wired wrong in respect to what the RAW driver uses as factory BTN_ names. Very often you have at least buttons BTN_A and _B and BTN_START and _SELECT, but not always...

3. I am unsure what to do from here so I looked up how to retrieve the event log

If you want to write to file, maybe try with two angle characters instead: evtest /dev/input/event2 >> ~/evtest.log. But more importantly, try instead to center the joystick or disconnect it before running evtest again and noting down each button name for each button, and then maybe rearrange/connect some of them differently(especially BTN_START and BTN_SELECT, which don't work for you, and where probably one of them are connected incorrectly as BTN_THUMB).

[QuadDam]

Ok figured it out! Start now restarts the game, select takes you out! Just to reiterate this is the joystick I am using, I built another arcade before with a fancy Sanwa Joystick but this works just as well https://www.amazon.ca/gp/product/B07FZ3YT1G/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1

here is a pic with the correct wiring

https://docs.google.com/drawings/d/1ZH0-auSRxWGQiEpPQlnAV9Nv_ROVA1Jr8BCn6CPLqPA/edit?usp=sharing

and below is the config you should set up for the running the buttons in the correct order (light punch medium punch....) if you want street fighter etc to work

Button Config for Street Fighter/fighting games

Light Punch - y
Med Punch - x
Hard Punch - Left Trigger

Light Kick - b
Med Kick - a
Hard Kick - Right Trigger

Thanks so much for your help! Just need a volume control for my usb and we will be all set! The kids will love this, time for me to get back to focusing on my coding in Makecode, to build out some games for this unit, thanks for all your hard work on this amazing platform, Makecode should be paying close attention to what you are doing! Quick question I unplugged the joystick but I still got that running log, any idea why? thnx

[Vegz78]

Ok figured it out! Start now restarts the game, select takes you out!

Great! Glad to hear that it works now!

Thanks so much for your help!

You are welcome and thank you for the final write-up above for others to follow with similar arcade controllers! The idea stems from wanting to get my son's MakeCode Arcade creations playable on a big screen with some Raspberry Pis and some old PS3 console controllers lying around in the house. But my impression is that various impressive homemade arcade cabinet creations, like yours, is the more common use case. Sadly, I don't have any such arcade controllers at home to test myself, and they come in countless different flavours, so I appreciate your support here!

Just need a volume control for my usb and we will be all set!

Also thank you for finding and sharing a solution to the USB sound issues, which many have been complaining about, and that I also have been unable to figure out myself!

The kids will love this, time for me to get back to focusing on my coding in Makecode, to build out some games for this unit, thanks for all your hard work on this amazing platform, Makecode should be paying close attention to what you are doing!

Thanks for the kind words! MakeCode is really amazing, with Arcade and alle the supported hardware and interfaces(Minecraft), and the unique seamless transition from block based to text based programming! It's a real treat to watch how my son learns and evolves his programming and creative skills, and all his and the nice community's game creations(and all the creative maker stuff). It is also a bit odd to me that MakeCode therefore isn't the biggest thing around yet since the invention of ice cream... ;-) Anyhow, good luck with future cabinet and MakeCode coding projects for you and your students!

Microsoft, by the way, have been really supportive regarding compilation of MC Arcade games for the RPi, figuring out why the games froze the screen initially and the inner workings of the controller support. They also awarded McAirpos a link on the RPi hardware pages, so I guess we cannot complain... ;-)

But don't forget that McAirpos is as close to the definition of a kludge/hack as it is possible to get. The elegant and best (and probably not that hard for anyone competent enough in C++/TypeScript)solution to the screen freeze and controller support issues on the RPi(or other OS'es and devices) would have been directly in the compiler source code itself, which is open source, too. I am still battling with Bjarne Stroustrup's books, but this might be a fun challenge for anyone who dares to take it on, and I know that there are people in both the RetroPie and Recalbox teams who are willing to help anyone's efforts to integrate MakeCode Arcade game support into their installers and with their respective gamepad implementations.

That would be really cool, but not worth anyone's effort to build on top of the McAirpos hack. I don't know exactly why, but Microsoft seems to prioritize small handheld devices over native execution support on RPi(with many retro game users and systems) and other OS'es and devices, and the RPi community seems a bit lukewarm towards MakeCode. Maybe I am wrong.

Quick question I unplugged the joystick but I still got that running log, any idea why? thnx

I was wondering about the same thing myself. The closest thing I know about was the Raspberry Pi OS built in driver for the PS3 controller, which did not have a "dead zone" for the "analog"/graded thumb joysticks, and showed a similar behaviour. But this does not quite fit with running values in the interval 128-133(strange "center" values), and definitively not when still showing if the joystick is physically disconnected... But some switch/input is definitively in an "ON" state. Maybe a driver or electrical fault, where I would start searching for the error by first identifying what the axis ABS_Z really is. However, if it doesn't noticeably interfere with how your controller works in games, I would just leave it be.

One optimization tip, though: To maximize controller support, I added a calibration script to get max values for joystick left, right, up and down, which runs every time you start a game, and some redundant button mappings for uinput-mapper. If you ever get the time or need, the max values can be hard-coded for your specific controller instead and the redundant mappings removed in ../uinput-mapper/configs/arcade1.py to get somewhat better and more stable performance(sometimes your game character sprite might shoot in one direction until you have moved the stick fully in every direction). I once had a grand plan to make or gather from the community uinput-mapper config files for common controllers that should be supported, but I am personally not that fond of doing almost the same config operation many times over... ;-)

[QuadDam]

Thanks for all that, ive learned a lot from this little adventure, one more question before I go, I am now attempting to use a potentiometer for the volume. It looks like I will need to use 4 GPIOs, I am assuming the joystick/button encoder takes up some of these GPIOs, how would I determine which ones those are? thnx

[Vegz78]

Sorry, I have no experience with the GPIOs beyond a power button and script that I use. Your controller states a USB interface, and you mentioned audio over USB, as well. I thought USB was fully independent of the GPIOs on the RPi?

I would image, just like it is possible to read GPIO signals from a button press in the power Python script I am using, that it would be possible to have a program reading either voltages from a potentiometer position or button presses(up and down) from the GPIOs and then translate to volume levels or volume in-/decrements? But really I have no tested idea.

[QuadDam]

Thnx again, have a great day!

[Vegz78]

I reopened this issue for @sofiania, for the same controllers, from this issue:
#13

I get the game going, but I can't use the buttons, neither on keyboard nor the encoder...

Please read and follow this issue as best you can, and maybe you could ping @QuadDam (@dace at the MakeCode Arcade forum) for help here, as he is one who has actually had success with this.

is there any guide for this.

No, not that I know of outside:

• The McAirpos readme
• The relevant solved issues here and on the MakeCode Arcade forum.
• The official guide for /sd/arcade.cfg
• The uinput-mapper repository

I find a lot of troubleshooting threads, but no summary, so I'm a bit confused.

I understand your confusion(which I share...), controller support is a giant subject, where everything has to play together in the correct order, from:

1. Correct physical wiring, via
2. Working driver that recognizes and maps raw inputs events according to physical wiring in the Linux Input Subsystem, via
3. Mapping of EV_KEY digital input events correctly in /sd/arcade.cfg, to
4. Mapping of EV_ABS analog input events correctly in_~/McAirpos/McAirpos/uinput-mapper/configs/arcadeX.py_

Therefore, after advise from the creators of MakeCode Arcade, I have tried to the best of my abilities to maximize controller support out of the box in McAirpos, and then I leave it up to the community to help each other, share knowledge and maybe write guides, publish pull requests etc., and I try to help with the issues here and update the code when I have time.

I tried to change the config files, but neither keyboard nor encoder works (they both work in RetroPie though).

Please reset /sd/arcade.cfg and the ~/McAirpos/McAirpos/uinput-mapper/configs/arcadeX.py_ files to their original McAirpos state, where they are configured to play nicely together:
https://raw.githubusercontent.com/Vegz78/McAirpos/master/McAirpos/MakeCode/sd/arcade.cfg
https://github.com/Vegz78/McAirpos/tree/master/McAirpos/uinput-mapper/configs

Then, please start at the physical step 1. above, maybe with some help from reading further up inside this issue or from @QuadDam (@dace at the MakeCode Arcade forum).

Remember, that MakeCode Arcade games uses raw input event codes from keyboards and controllers, so normally you have to start from the beginning with checking the physical wiring(most common issue with DIY arcade controllers), and the, when it all works in McAirpos, reconfigure RetroPie etc. again/accordingly. McAirpos controller setup does not know about controller configuration in RetroPie, Recalbox etc., because it operates directly in the OS level below.

If stuck after trying a while, please post another question here.

[SuperPupperDoggo]

Try using evtest /dev/input/eventX | grep "(type 1)" and see what pressing each of the buttons shows. Specifically, press B, then press select, and see what shows up. If they have the same button name, there might be a problem with the encoder. Maybe try plugging the select button into a different port on the encoder if another is available, and seeing if it fixes the issue.

Edit: close quote

[Vegz78]

I have now changed to this encoder https://www.electrokit.com/uploads/productfile/41017/SBC-ZDE-Datasheet.pdf, because it's the one the kids will have (I'll revert to the SJ@JX later)
Originally posted by @sofiania

Closing this issue again as originally solved by @QuadDam, and can reopen again if others experience issues with the SJ@JX controller, or if @sofiania reverts to it later and still needs support.