I had tried all 3 methods on my pi 3. I used the manual cmake steps, I had tried the wget install.sh method, and I had also tried the GUI option in the retroarch "optional package" menu. I ran into no errors during any method, but nothing worked. Nothing was responsive in jstest. When performing the GUI option pi 2.5, it worked. (I didn't try other 2 methods on the pi 2.5 as my first attempt worked).

I think its my pi. I bought it a few years ago and this was my first time trying to use the GPIO headers. I downloaded a pigpiod GPIO test script and it identified some of my pins as bad. I think I'll grab a pi 4.0 in the near future.

I made a video going over my gamepad design if anyone is curious.

@sincion What controller type have you connected?
Do you have other peripherals connected to the RPi?

I did a similar project not too long a go. E.g. built RetroPie into Atari 2600 case. Anyways - yes, key presses that ControlBlock sends when using MAME layout are hardcoded into it's driver:

URL: https://github.com/petrockblog/ControlBlockService2/blob/master/src/controlblock/gamepads/MAMEGamepad.cpp#L41-L141

To change e.g. switch 'z' to send something else than z, say a, you would modify lines below and replace KEY_Z with KEY_A. And recompile and re-install the driver (instructions here https://github.com/petrockblog/ControlBlockService2).

URL: https://github.com/petrockblog/ControlBlockService2/blob/master/src/controlblock/gamepads/MAMEGamepad.cpp#L68-L70 to

Available KEY_* events (that you could replace KEY_Z above) are found from here: https://github.com/petrockblog/ControlBlockService2/blob/master/src/controlblock/uinput/UInputEventCodes.h

I hope this helps you forward. I did a slight re-write for the driver myself as I wanted all the Atari 2600 switches to provide their original functionality. Which isn't straightforward since official ControlBlock driver doesn't support switch where both on and off indicate certain state (e.g. on -> colorTV, off B&W). I suppose I could clean up my code a bit and put it up to github sometime.

I am so glad to hear that :-)

Hello everyone, in the end I will use Recalbox with two USB interfaces.
For me it is much easier.

Thank you all for the help, best regards.

Glad to hear!

@SuperPitendo Thank you so much for all the info and effort. Much appreciated!

The power switch on the ControlBlock lead to a small voltage-drop at the switching component (as does every electronically component). From other projects I know that especially additional USB devices can be problematic. I guess that when you disconnect, one or both USB devices (SSD, converter) the under voltage disappears. Alternatively, you could get an active USB hub that powers the additional USB devices and keep the connection between the RPi and the USB devices.

@paulmalko I am having a very similar problem. When you say you "re-imaged the SD card". What did you reimage it with? RetroPi, Raspbian, ...??? Any help would be appreciated.

@petrockblog It appears that I can get the service running by commenting out the line "[ -x "$DAEMON" ] || exit 0" and then starting the service. This also allows the service to run on boot.

So, why does this line need to be commented out? I'm confused why this would work for everyone else and not my setup (even though I started from a completely fresh RetroPi 4.5).

Glad to hear that you are making progress!

It should always be possible to use the ControlBlock together with any USB controller. You would just need to run the input configuration for each device on EmulationStation. All controller types should be recognised and working afterwards.

Regarding your question about the need for an additional keyboard: What you would need to do is to configure the emulators such that you have full control with your arcade / gamepad controls only. That should be possible.

Hope that helps!

Thanks for getting back to me, and thanks for making fantastic little bits of hardware, I hope it works out with the 3A+

I ordered the B model in the end, I figured that I might regret not having those extra USB ports down the line, and the larger footprint means I'll be forced into making a tidier build :)

Glad to hear that!

@m2306 I also need a few weeks to finish my stuff and get back to the Topic. I will keep you up to date as well!

@petrockblog

I guessed as much, just me beeing a linux n00b. Thanks and sorry for wasting your time. Still, this could have been prevented with clearer instructions. It went fine with installing the software though, nice and easy to copy the commands, all clear there. Just small things like this one that you who know command line better maybe don’t realize that others don’t get.. Thanks again.

@m2306 Yes, it's possible to use different gamepads as P1, depending on the system you play or choose at runtime. You can use Meleu's joystick selection tool to do that.

OK, this is probably my last post on this matter. It isn't solved, by any stretch of the imagination, but i do have a workaround!

I don't believe that the short has fried anything, the controlblock is still working exactly as advertised, but it DID scramble the outputs. All the outputs are still there, just in different places!

If it is possible to re-flash the firmware i think it would restore the normal operation, but that is just a hunch, and as it stands now i am not willing to take the risk.

Just in case someone out there ever has a similar problem i'm posting how i rewired the controlblock:

WARNING! WARNING! WARNING! WARNING! WARNING! WARNING! WARNING! WARNING! WARNING! WARNING! WARNING!

THIS WON'T WORK ON YOUR SYSTEM, IT FIXED MY SYSTEM ONLY. I ONLY POST HERE TO SHOW WHAT THE SHORT DID TO MY CONTROLBLOCK!

In the end i rewired my project to match the new outputs of the scrambled Controlblock as follows:!

MyControlblockOut

Hope that helps, if anyone else finds themself in a similar situation!

END WARNING! END WARNING! END WARNING! END WARNING! END WARNING! END WARNING! END WARNING! END WARNING!