@GongStar the output of dmesg might be useful after the build fails. You are right there is nothing else in the log - I thought there might be something. Not sure of the issue if you have plenty of free space on card, and no overclock.
You could rename the folder /opt/retropie/emulators/ppssppto something else and then modify the /opt/retropie/configs/psp/emulators.cfg and make a new entry for your copy. Retropie will ignore it then and won't touch it.
@funkotron77 Again, I see nothing. Maybe also check the /var/log/syslog, but without grep to see every message. A simple cat /var/log/syslog will show it, and you could copy & paste the last part of the output. To be sure, you could look at it before and after the remount command, to check for changes (the same goes for dmesg).
After that, alas, I'm out of ideas. I never had to deal with something similar myself yet.
Is there an lr-mame core? Could I build one? I have used lr-mess both prebuilt and built from source and I see from its build script that it just pulls from https://github.com/libretro/mame.git.
Yes. Both lr-mess and lr-mame are built from the same codebase you mentioned (forked upstream MAME), but with different build options, which results in different supported systems (arcade vs. non-arcade).
I was referring to MAME (the upstream project), not the libretro cores.
Does this mean that mame itself is the part of the mame distribution that can run that system?
Upstream MAME distributes only 1 binary which supports all systems included - either arcade, computer, mechanical, etc. There's no separate MESS anymore and I think hasn't been for quite some time.
Then it might be something with the latest update. I tried to test the libretro builbot version, but for some reason, the armv7-neon-hf build for the lr-mame core is build for aarch64 and it can't be used on RetroPie.
You can copy the drastic.sh version from that repo to your own RetroPie-Setup installation (overwriting $HOME/RetroPie-Setup/scriptmodules/emulators/drastic.sh) and then re-install drastic.
Do note that replacing the scriptmodule with another version will make updating the RetroPie-Setup fail, since you modified the file locally.
Update: after getting my replacement, I'm now able to update both RetroPie and the underlying OS packages without getting stuck. So my problem was probably due to a bad SD card, even though H2Testw didn't report any error.
Do you care to elaborate on the Video appears a bit degraded part ? I confess I didn't use advmame before, so I don't have a past reference, I just test it out on the Pi4 - the 3.9 version - to see how it works.
Overall, it looks like anti-aliasing doesn't work with the SDL driver. Examples:
Vector game lines are not anti-aliased
System menu font appears jagged
Video Rgb Effects, such as scan2horz do not blend nicely with the game screen.
The setting display_antialias is set to yes, but there is no visual difference when it's disabled or enabled.
One of the draws of using AdvanceMAME is for the clean high-res Vector images, so that's a bit of a miss. But having AdvanceMAME available for rendering raster games like Cotton 2 and Baku Baku is a must-have.
There are also some issues going in and out of the settings menu (Tab). Sometimes, when returning to the game, the screen blanks. Also, gets very sluggish and occasionally hangs. Might not be related to the driver, but different from running this on a 3B+ without Buster.
Its not removing any configuration the devices are named the same what you need to to is wire them up the same and you only need to set it one time will work for both players as its configured per device.