How to enable Reset function in ControlBlock 2.1?

ortsac

@petrockblog The reset button function is dependent upon unused or unconnected control I/O connection on the ControlBlock. However this does not make it universal for all build scenario since some build like "arcade" and "mame" uses all I/O connections.

I know that the ControlBlock uses a microcontroller(MCU). Since it is not open-source I do not know whether there are available connections to the MCU that you can use as terminal connection, like the power switch, for the reset button. This will make the function more universal for all users. Perhaps a redesign of the board (ControlBlock 3?) to use a larger MCU and use quick connect/release connector for the game buttons as well (the terminal block is a pain to use).

ortsac

@petrockblog It seems the victory dance on the "Reset" button functionality was premature.

My NES/SNES build is simple:

Case: 1985 NES console
Game I/O Interface: ControlBlock 2.1
Game Controller: NES/SNES Gamepad (1 only) using front panel Player connectors
Switches: Console Front Panel ON/OFF and Reset switch
RP1 3 and 5V, 4A power supply housed inside the NES case
Retropie 4.2 and Comic-Book Theme
ControlBlock Configuration: SNES with "onegamepad only"

On the original build with the old ControlBlockService2 driver everything was working well except, of course, the "Reset" function of the ControlBlock.

Two days ago, @petrockblog release a new driver for the ContolBlock to fix the non-functioning "reset" button. I updated my build at the time but did not extensively tested its operation until today. Here are my observations:

Intermittently, when ES boots up, the system will go into the Retropie menu section and hangs. No other button will work but only the Power ON/OFF switch or F4 via keyboard if connected.
During game play, without pressing the "reset" switch and without pressing SELECT+START on the controller, the system will go into the Retropie menu section and hangs. Again, no other button will work but only the Power ON/OFF switch and sometimes F4 via keyboard if connected but not always.
None of the games in my build can now be played without hanging-up as in item 2 above.

How do I know that it is the latest ControlBlockService driver that's acting up? I also happen to have a USB SNES game controller, which I do not use in conjunction with the SNES controller. So I reconfigured the service by editing /etc/controlblockconfig.cfg and change the "gametype" to "none". This disables both the NES/SNES controller and the reset function. With the USB controller connected, it becomes active for game play and none of the anomalies and erratic behavior cited above have been observed. All games can be played without premature interruption.

Reset functionality on the ControlBlock is not yet stable or fully debugged.

petrockblog

@ortsac I will take al look into it when I come home this evening. Is it the same in your case when onlyonegamepad is set to false?

ortsac

@petrockblog Yes. The behavior is the same either way.

ortsac

@petrockblog What are your findings on this latest issue with the "reset" function? I would like to showcase my build and Retropie to my nephew's bday. Please let me know.

petrockblog

I tested the current version of the driver (c9d0ab3) especially for the gamepad type snes and "onlyonegamepad" values set to true and to false. Everything is working as expected: The controllers react as configured and the reset button is also working as intended.
This is the hardware setup that was used for testing - the parts come from an original SNES console:

The SNES controllers are connected to the connectors as described at https://blog.petrockblock.com/gadgets/controlblock-power-switch-game-controllers-and-io-for-the-raspberry-pi/#Using_SNES_Controllers_with_the_ControlBlock.
The reset button is connected to GND and Player 1 - B.

I made a video of that test:

What could be different with your installation? Here is a list of thoughts:

Unstable wiring: Check the connections
More than one instance of the ControlBlockdriver is running: You can see this with the top command
Old version of the ControlBlock driver: You can always get the latest version of the driver via git with the command git pull from within the ControlBlockService2 folder.

Hope that helps!

ortsac

What could be different with your installation? Here is a list of thoughts:

Unstable wiring: Check the connections
More than one instance of the ControlBlockdriver is running: You can see this with the top command
Old version of the ControlBlock driver: You can always get the latest version of the driver via git with the command git pull from within the ControlBlockService2 folder

As you have suggested, I will recheck all my connections to the ControlBlock. As I am new to all this, could you please give me the full syntax to the 'top' and to the 'git pull' commands ? Much appreciated.

petrockblog

Show all Running Processing

To see all running processes you can use the top command by executing top from the command line. You get something like this then:

0_1497260797387_Ohne Titel.jpeg

You can exit that screen by pressing q.

The above screenshot shows one running instance of the ControlBlock driver. Each instance of would have a row on its own.

Update a Git Repository to most Recent Version

Change to the folder to update - in our case via cd ControlBlockService2. From within that folder execute git pull. If that executes without an error message you just got the most recent version of the sources.

ortsac

Thanks. I used the 'top' command and I see only one instance of 'controlblock', but it comes and goes out of the process screen. It is not always shown. Is that normal?
There are a lot of instances of the 'bioset' process though and I do not really know what that is.

ortsac

@petrockblog After issuing the 'git pull', and executes without error, do I have to recompile?

petrockblog

@ortsac Can you post the output of the git pull command here?

If the sources got updated (when it were not already the newest ones) you need to recompile the driver. You can use the command sudo ./install.sh for that.

petrockblog

@ortsac It is normal that the controlblock process comes and goes within that list. The bioset processes are nothing to worry about.

pillbug22

Always hate to bring back an old thread to life, but I didn't see a final solution, and I am was having a similar situation.

Using original NES case, front panel LED and buttons
ControlBlock 2.1
Power & LED working correctly connected to ControlBlock
RetroPie, emulators, and original NES controllers working OK

The reset button was the only part not working.

Searching around the web, found multiple people who dropped a RasPi into a NES case before the ControlBlock, so using just the original GPIO pins. All of them had some comments about the LED being wired in a funny way form Nintendo and having to cut part of the board to make a one of the LED wires connect to the metal bracket as a ground.

Got me thinking, so I swapped the +/- wires on the LED pins of the ControlBlock. Now the rest button worked, but not the LED.

My solution was to "cross" the wires on the LED bulb itself. Instead of going straight from the LED bulb into the board, I made the 2 LED wires (on the bulb itself), going into the opposite connection spot than where they originally were on the board.

Now both LED and Reset button are working as I would expect.

sfc_K

@ortsac hate to hijack this, do you have pictures of your completed project? You may have built exactly what I need to build myself for the misses. I am looking to also emplace a Pi3 into an authentic NES console, for use just for NES and SNES emulation. I would like to bounce some ideas of you if possible as well as get some feedback/guidance of any issues you may have ran across.