especially including verbose log, but also please provide /opt/retropie/configs/all/retroarch-core-options.cfg
note that your "libretro.cfg" (what is this? there's not file of that name in default retropie) looks to be non-standard. a retropie default one for /opt/retropie/configs/all/retroarch.cfg will be much smaller, for example.
@dank-cushions CDMage looks like some sort of disc extraction/manipulation tool. There shouldn't be anything inherently wrong with consolidating the .bins, but maybe it was done incorrectly. That's why we should see if the original files work before we start pointing fingers at the conversion.
But a single .bin or multiples shouldn't matter as long as the .cue is correct; as I understand it, they both represent the same raw binary data stream to recreate the original optical disc. I ended up with one when trying to apply the English patch to Rondo of Blood for the TG-CD, that worked fine (as far as I can tell. I've only played through the first level but it works at least that far.)
Before I knew that chdman would work on .iso/.wav./.cue sets, I thought you had to have .bin/.cue. So, starting with the multiple .bin/.cue set I:
Burned the multiple .bin/.cue set to a disc.
Re-ripped the resulting disc to .iso/.wav/.cue using TurboRip (the included binchunk tool that was originally meant to do this conversion gave a divide-by-zero error on Win10, and in compatibility modes for Win7 and XP.)
Patched the resulting .iso/.wav/.cue set with the included instructions.
Burned the patched .iso/.wav/.cue set back to another disc.
Ripped that disc to .bin/.cue using ImgBurn.
This gave me a single .bin file. At first I was worried I had messed it up, but I put the .cue through chdman, dropped the resulting .chd in my tg16 (pcengine) folder, fired it up, and was pleasantly surprised when it worked just fine.
If after the update the problem is still there, follow this steps:
To disable the multitap:
Open the RetroArch menu while the game is running and from the options, enable the Show other input settings.
After that, restart the game and open again the RetroArch menu and from the options set to off the Mutitap1 and Multitap2 and you are ready.
A head ache, but now I know what's wrong and feel like I wasted your time lmao. Thanks again, I think I know what's going on, now. Maybe that the corrupt images are making the emulator default to the hle bios
It's not a waste of time if we find out what's the cause.
Regarding the SSD issue, it might not be the cable, but the USB/SSD controller. There is an extensive topic in the Raspberry Pi forums about it, including workarounds and ways to diagnose it.
Hey! Thanks to you guys and the other linked posts, I found and fixed the same issue. I had some old overrides saved and sure enough, my Multitaps were "auto". Changed to "disabled" and all is well again in PSX land!
Thank you for your post. Having two SF30 pro and got the same issue.
After configuring as per you post above, the mapping is strange. For example, the hotkey is used to jump under tomb raider.
In other words, the controller map is not as per lib-retro "standard" for psx. Any idea how to be back on standard lib retro mapping ?
My config : retropie 4.7.3 / pi 4
@mitu i installed the latest precompiled binary from retropie setup script. but at least everything works now again and i do not even know what to do with this multitap thing.. not a funktion that i am missing now :)
I didn't add entries for P3 and P4 on retroarch.cfg because, what would I set them to if I only have two controllers? 4 and 5, assuming that I could be plugging in additional ones?
Anyway, I tried to re-add the two physical Logitech controllers to EmulationStation; it detect 4 controllers, but it would keep detecting the button presses as coming from the emulated Xbox controllers.
I then reset the controller settings for EmulationStation on the Retropie menu and again, it would detect 4 controllers, but it also would keep detecting the button presses as coming from the emulated Xbox controllers.
I had to disable xboxdrv and then it would only detect 2 controllers and the button presses a coming from the physical Logitech controllers. The conclusion here is for EmulationStation the physical and emulated controllers don't clash; the emulated ones take priority and the button presses are understood to be coming from them.
I then checked that on the Retroarch menu the emulated controllers were assigned to P1 and P2 and removed the physical controllers that were assigned to P3 and P4. And then everything was fine. The crux here appears to be that I had a clash, as both the emulated and physical controllers were assigned to players and probably registering button presses. Something that support this hypothesis is that on games where you have a grid to select your character (e.g. Mario Kart) it was fairly obvious that when I was pressing once to move one cell to the right, for instance, the selection box was moving two cells.
Thanks again for all your time helping me figure this out.