@StuMcBill Glad to hear!

I finally got the driver to enable through the retropie config screen without shutting the whole thing down. I had to update all drivers, packages and everything on the pi through the retropie config screen and then I was able to enable the ControlBlock driver. When I edited the controlblock config file it was blank so I added all the code that is usually there and configured it to work with arcade and a power button. I restarted everything and it's like it's not even there. jtest doesn't even pull up, ControlBlock isn't on services running. I'm at a loss. I've been messing with this for a week now and it doesn't work like it should.

Anyone willing to take a look at my boot and see if they can see what I'm missing?

https://www.dropbox.com/sh/ec2vitua6pg23rk/AACaonRDQT7RdW_Ed6iUC7bSa?dl=0

Glad to hear that!

Thank you @petrockblog , I found out the switch I used was a normally on momentary switch, and I expected it to be normally off. I've had those switches forever in my components to reuse bin. I never bothered to measure with multimeter based on the fact that pressing it did shut down Retropie as I expected. This one's totally on me and sorry to bug you, I appreciate you helping out.

@erik-m Ok, I pushed a fix a minute ago. Something changed with the system execution. I updated it accordingly.

@antomost I can only second @mitu 's advice.

Sorry for this delayed reply.

What does the ControlBlock installation do, if you you run the ControlBlock installation directly from the command line via

wget -O - https://raw.githubusercontent.com/petrockblog/ControlBlockService2/master/install.sh | sudo bash

(see https://github.com/petrockblog/ControlBlockService2#quick-installation)

Do you observe the same behavior?
Can you post the link to the OS image that you are using, so that I can try to replicate the error?

Hi, interesting project idea!
In case of simulating a controller towards a console it depends on the protocol and submission speeds.
Generally, you can control the GPIO pins of the ControlPins via the SPI interface of the Raspberry. As long as SPI is fast enough for your use case, things should work.
Hope that helps!

@mitu Hey, that did the trick, thank you very much, sir !!!!

I've waited a week and aeverything just works fine again...

@petitssuisses Sorry if this reply is too late.
I would go for a new gamepad type to keep the existing in its current state as fallback. You could start with a copy of the MAMEGamepad.cpp file.

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.

@Sabaro my problem.... I set the cable wrong
1 2 3 4. 4321.

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 :-)