Super Mario Bros (NES) Must Press Start with Player 2?

obsidianspider

@mediamogul Here's the contents of that file. I don't recall ever messing with it.

pi@sfc-pi:~ $ cd /opt/retropie/configs/nes/
pi@sfc-pi:/opt/retropie/configs/nes $ ls
content_history.lpl  emulators.cfg  retroarch.cfg
pi@sfc-pi:/opt/retropie/configs/nes $ cat retroarch.cfg
# Settings made here will only override settings in the global retroarch.cfg if placed above the #include line

input_remapping_directory = "/opt/retropie/configs/nes/"

#include "/opt/retropie/configs/all/retroarch.cfg"
pi@sfc-pi:/opt/retropie/configs/nes $

mediamogul

@obsidianspider

That seems to be OK. The only two settings I can think of that would be limited to NES, yet affect all the different NES cores would be at /opt/retropie/configs/nes/retroarch.cfg, or any remapping files at /opt/retropie/configs/nes/. I believe I read above that you've already eliminated the latter. Very strange indeed.

Edit: You might also try looking at /opt/retropie/configs/all/retroarch/config/remaps/. Nothing should be outputting there, but it's worth a look.

obsidianspider

@mediamogul said in Super Mario Bros (NES) Must Press Start with Player 2?:

/opt/retropie/configs/all/retroarch/config/remaps/

Nothing in there.

pi@sfc-pi:~ $ cd /opt/retropie/configs/all/retroarch/config/remaps
pi@sfc-pi:/opt/retropie/configs/all/retroarch/config/remaps $ ls
pi@sfc-pi:/opt/retropie/configs/all/retroarch/config/remaps $

dirthurts

I had this issue a while back and found that running the older version of the default emulator (sorry can't remember what the default was) worked just fine for me.

obsidianspider

@dirthurts I'm not opposed to that, but I don't know how to regress the emulator or to prevent it from upgrading when I upgrade other things.

dirthurts

@obsidianspider
right after you launch the game, simply hit any button to launch the configuration menu (you'll see the prompt). From there, simply choose a different emulator for that rom and you're good to go.

mediamogul

@dirthurts

I believe he's wanting to regress the emulator version rather than select another available option.

@obsidianspider

That shouldn't be necessary, as the current versions of the various NES cores don't exhibit this behavior for most people. However, I'm at a loss as to why it is happening to you. If you were wanting to give regression a shot and have it available for continuous use, you could make a copy of the NES script modules at ~/RetorPie-Setup/scriptmodules/libretrocores/. Using lr-fceumm as an example you would first alter the existing module ID with something unique like:

rp_module_id="lr-fceumm regression"

also, (someone correct me if I'm wrong here) changing it's selection classification to 'experimental' seems to be the trigger for disallowing a binary installation option, which would yield whatever the most current version is.

rp_module_section="exp"

From there, look for the line beginning with gitPullOrClone and add your desired version number to the end rather than the zeroes in the example below:

    gitPullOrClone "$md_build" https://github.com/libretro/libretro-fceumm.git v0.0.0

Afterward, when you're selecting the option to install from the RetroPie-Setup menu, if the option to install as binary is still present, you'd obviously need to install from source to avoid installing whatever is most current.

Again, this whole process shouldn't even be necessary, but if it is something you're looking to experiment with, this should allow that experimentation without interfering with the existing modules. Reverting back to the default versions would be no more difficult than selecting the install options from the original default script modules, which would overwrite what was done here. You could then delete your custom script modules and be back where you were.

obsidianspider

@mediamogul I'm really not wanting to regress the emulator, especially since it's only one game (well, three, SMB on NES, Famicom, and FDS), but it's happening on all three emulators, fceumm, nestopia, and quicknes. I've tried different variants of the ROM, and since versions for "different systems" also do it, leads me to believe something else is up. I am not sure if anyone else here is using the 4-player Raphnet adapter.

I'm not the only one it's happened to, ( I found a post on another forum about it in 2012 on Windows ) but I don't know what caused this to break.

I've determined that the game worked before I reimaged my SD card. Before that I was running whatever version of RetroPie was out in 2016 and had been updating every week or so. When I borked my install a few months ago I did a fresh reinstall of 4.3 from the website. I didn't test this game immediately after doing the fresh install, but the problem arose after it happened, and it worked just fine before.

mediamogul

@obsidianspider said in Super Mario Bros (NES) Must Press Start with Player 2?:

I am not sure if anyone else here is using the 4-player Raphnet adapter.

As nice as Raphnet adapters are, that's a good candidate for your issues. My personal experience is that multi-port adapters and Linux don't mesh perfectly without a dedicated driver. If I'm remembering right, there's a certain part of the USB HID "standard" that makers of multi-port adapters employ that is meant to delineate a single controller entry in multiple entries. This element is not fully implemented in Linux and causes confusion in some scenarios between the multiple controllers.

obsidianspider

@mediamogul Yeah, I have to wonder if something in a kernel update caused things to get funky.

For what it's worth, while adding this week's MAME ROW games to my system I updated to 4.3.15 (07d9f95) and it didn't resolve the issue. I'm hoping either reverting to a really old version of RetroPie and then just not doing any updates, ever, or updating to the new Stretch version will resolve the problem. I haven't made the time yet to disassemble everything and put a different card in to try that route.