Pi Zero arcade issues

FormulaFox

The wireless on the Pi Zero is giving me grief - it just seems to be some connection instability so I'll try again later, but I can't SSH in at this time. But until I get it worked out I plan to try another ROMset with pifba, however-

THE FOLLOWING IS NOT A REQUEST FOR ROM LINKS. I REPEAT THIS IS NOT A REQUEST FOR ROM LINKS.

-I cannot find a resource for the recommended ROMset(0.2.96.71) for pifba according to Retropie documentation. Is there another ROMset that is known to work on pifba I could look for?

Apologies if I emphasized my "not requesting ROM links" bit a little too strongly. I know the rules forbid the sharing of such links and I wanted to ensure my inquiry was not misinterpreted.

sleve_mcdichael

@formulafox said in Pi Zero arcade issues:

-I cannot find a resource for the recommended ROMset(0.2.96.71) for pifba according to Retropie documentation. Is there another ROMset that is known to work on pifba I could look for?

This might be one of those cases where you need to start with the full current MAME romset and then filter it to your desired version with a tool like clrmamepro. See validating, filtering, and rebuilding arcade romsets.

barbudreadmon

@formulafox fwiw, fbalpha 0.2.96.71 was based on mame 0.114 romsets

FormulaFox

Been a while, but we had a sudden health crisis(not COVID) in my family that understandably took precedence over this project. Still have not had time to check log files but I did another quick search for FBA 0.2.96.71 sets, but still have not found one(again: NOT requesting ROM links here!), but I have another question in the meantime...

Will 0.2.96.74 work with pifba?

dankcushions

@formulafox said in Pi Zero arcade issues:

Been a while, but we had a sudden health crisis(not COVID) in my family that understandably took precedence over this project.

:( wishing you and your family well!

Still have not had time to check log files but I did another quick search for FBA 0.2.96.71 sets, but still have not found one(again: NOT requesting ROM links here!), but I have another question in the meantime...

Will 0.2.96.74 work with pifba?

given that it's only a few versions apart most games should work, but as with every romset version release, some games are re-dumped, new games added, and perhaps some prexisting ones renamed, so you'd expect at least a few games within the 0.2.96.74 romset collection to not work in pifba.

FormulaFox

Okay, he's where I stand. The FBA ROMset I inquired about just kicked me back to the menu no matter what game I tried. (it wasn't a complete set, anyway, and was missing a TON of stuff I was interested in)

So I went and ran my ROMs through clrmamepro following the instructions provided earlier, setting up with the recommended mame4all(0.37b5) information. Whole system just crashes when I try to load a ROM with mame4all.

I cannot ssh in to see if it is still running during the black screen, as no matter when I attempt to do so my PC just refuses to recognize that the Pi is on the network.

So I'm at a complete loss where to go from here.

EDIT: Random retry to ssh in got me a "connection refused" error. First time I've gotten any indication that the PC can see the Pi.

EDIT2: HOLYCRAPIGOTIN. Don't know what changed, but I'm in and will hopefully be able to find the logs. I'll make a separate post for whatever I find.

dankcushions

This post is deleted!

FormulaFox

Okay, I'm going to do MULTIPLE tests to see what we get.

Test 1 - Altered Beast. Black screen freeze. runcommand.log produces the following:
"Parameters:
Executing: /opt/retropie/emulators/mame4all/mame "altbeast""
That's all

Test 2 - Asteroids. Black screen freeze runcommand.log produces the following:
"Parameters:
Executing: /opt/retropie/emulators/mame4all/mame "asteroid""
That's all

Test 3 - Galaga. Gets to initial load screen before freezing. runcommand.log produces the following:
"Parameters:
Executing: /opt/retropie/emulators/mame4all/mame "galaga""
That's all.

I'd do more, but I think we can discern a clear pattern here. I have to run out for a bit so I'll look into verbose logging with lr-mame2000 later.

dankcushions

@formulafox yeah, it's a bit of coin toss as to whether non-libretro emulators provide anything useful in the logs.

but i'm confused why you'd provide us a lr-mame2000 log? you already said it worked:

I can already attest that lr-mame200 has the same slowdown issues on all the same games. Plus not displaying the proper aspect ratio(but I know I can fix THAT within the display options, so no actual concern there)

however it would at least verify that your romset is indeed correct, and give us a bit of info that we're still missing like full filename plus extension, etc.

FormulaFox

@dankcushions said in Pi Zero arcade issues:

@formulafox yeah, it's a bit of coin toss as to whether non-libretro emulators provide anything useful in the logs.

but i'm confused why you'd provide us a lr-mame2000 log? you already said it worked:

I can already attest that lr-mame200 has the same slowdown issues on all the same games. Plus not displaying the proper aspect ratio(but I know I can fix THAT within the display options, so no actual concern there)

however it would at least verify that your romset is indeed correct, and give us a bit of info that we're still missing like full filename plus extension, etc.

Well, for one thing because a while back you recommended it if the mame4all logs weren't helpful, but more importantly because lr-mame2000 is not working properly. Like I said in the post you quoted, it's having severe slowdown issues with numerous games. It loads, but few games actually run correctly. I would not still be trying to solve this if I was only having the aspect ratio issue.

Anyhow, I've done the verbose logging check with lr-mame2000. I did the previous three games plus Galaga 88 just as a double check. Since we're dealing with the extensiveness of VERBOSE logging, I won't copy/paste. and will instead post a link to a zip file containing the three logs. But first, you'll probably want to know exactly what each game did...

Altered Beast: Ran normal speed during gameplay when no major visual or voiced sound effects were occurring - mild slowdown when such things WERE happening. Audio was glitching out throughout play sessions regardless of game slowdown.

Asteroids: Loaded to main screen but as soon as the "controller configured" messages appeared, I got kicked back to the menu.

Galaga: No issues at all save for incorrect aspect ratio.

Galaga 88: Constantly running slow, incorrect aspect ratio.

I have plenty of other games I can try if you want further info.

Here are the log files: https://www.dropbox.com/s/tzop55xfv6cppn4/runcommandlogs.zip?dl=0

dankcushions

@formulafox said in Pi Zero arcade issues:

Well, for one thing because a while back you recommended it if the mame4all logs weren't helpful, but more importantly because lr-mame2000 is not working properly. Like I said in the post you quoted, it's having severe slowdown issues with numerous games. It loads, but few games actually run correctly. I would not still be trying to solve this if I was only having the aspect ratio issue.

i don't think it working slowly is not it working "properly" - it's not a recommended emulator for pi 1/0. the mame4all-pi emulator is standalone (libretro cores add a little bit of overhead), which can make a lot of difference for very low power devices like a pi zero, and it's got some specific optimizations - hence we recommend it.

i realise that mame4all-pi crashing, and your bad luck with the pifba romset, leaves you with little choice, but yeah.

that said, the logs can still prove useful, like i said. it looks like there's room for improvement with your setup

[INFO] [Video]: Video @ 960x672

[INFO] [Video]: Video @ 1200x900

[INFO] [Video]: Video @ 864x672

these don't seem quite right - retroarch should default to 640x480 for pi1/0. can you please supply /opt/retropie/configs/all/retroarch.cfg and /opt/retropie/configs/arcade/retroarch.cfg ?

EDIT: also /boot/config.txt

FormulaFox

@dankcushions https://www.dropbox.com/s/ue5t7hwf7mzbjck/configs.zip?dl=0

Can the resolution really be responsible for slowdown issues? I have raspi-config's resolution set to monitor preferred(it's a 1080P TV), in case that helps.

dankcushions

@formulafox

Can the resolution really be responsible for slowdown issues?

yes. pis are very memory bandwidth limited and driving a high resolution gives a measurable performance penalty, especially on older pis.

onto your configs:

/opt/retropie/configs/all/retroarch.cfg - this is non-default. whilst it DOES have the resolution settings i referred to above, it may have some hidden gotchas. you should revert to default by renaming it to retroarch.cfg.bak and renaming /opt/retropie/configs/all/retroarch.cfg.rp-dist to retroarch.cfg

/opt/retropie/configs/arcade/retroarch.cfg - looks fine

/boot/config.txt

hdmi_group=1
hdmi_mode=16

you could try

hdmi_group=1
hdmi_mode=4

which is 720p

i would also be curious if mame4all-pi suddenly starts working with a reduced resolution.

FormulaFox

@dankcushions Guess that makes sense. All my previous experience is on Pi 3 and 4 so it's not odd I never encountered it before.

Anyhow, result of changes: Mame4all still freezes as before. Altered Beast has improved is playing full speed at all times and has only occasional brief audio glitching. Asteroids fails as before. Galaga runs exactly as before. Galaga '88 runs even SLOWER than before.

Everything has a black border around it, but that is to be expected since I'm now on a 720 setting on a 1080 display.

dankcushions

@formulafox i presume you're not seeing the 'lightning bolt' power symbol in the corner at any point?

Galaga '88 runs even SLOWER than before.

that doesn't seem right, but maybe it's within the margin of error. i have an idea to speed this up, if you're feeling brave:

edit /home/pi/RetroPie-Setup/scriptmodules/libretrocores/lr-mame2000.sh
change the line

    isPlatform "arm" && params+=("ARM=1" "USE_CYCLONE=1")

to

    isPlatform "arm" && params+=("ARM=1" "USE_CYCLONE=1" "USE_DRZ80=1")

then update the emulator from source (will take a while)

note that changing scripts like this will cause retropie_setup to complain when you update it in the future. to revert this change, run:

git checkout /home/pi/RetroPie-Setup/scriptmodules/libretrocores/lr-mame2000.sh

(you can always apply the change again after you update)

Everything has a black border around it, but that is to be expected since I'm now on a 720 setting on a 1080 display.

it shouldn't - 1080p displays should display 720p fine natively, but there may be a tweak you need to do: https://retropie.org.uk/docs/Overscan/#my-image-has-a-border

FormulaFox

@dankcushions
No lightning bolt at any time. I know what that means and I would have tackled it first thing if it was showing.

I'll try the other suggestions to see what I get. Obviously I'll have to get back to you later once the update from source finishes.

I get the feeling that this is going to work, because my PC is again refusing to recognize that the Pi exists on the network. That's the way my luck works - if I'm on course to find a solution, something else will get in the way.

I'm going to reinstall Paragon Linux File Systems For Windows to edit the file that way(I didn't use it before because I've had bad luck with it SAVING my changes to the card, but I'll just keep redoing this until it cooperates). The stubbornness of this Pi will not stop me!

If it comes down to it, I'm willing to attempt a mild overclock to see if that helps. (I have an aluminum heat sink on this thing, but no fan)

Also, before making the attempted emulator tweak I checked out some of the border fixes. Just had to change disable_overscan from 0 to 1. Fixed it right up.

FormulaFox

@dankcushions
Hokay, so, here's the situation...Altered Beast dipped slightly in performance - still plays full speed with no slowdowns but audio issues returned in full force.

But something else has been noticed. Since I am considering trying to overclock the Pi, I did my due diligence and checked to make sure the CPU was running at the advertised clock speed of 1GHz. It is not. It is running at 700MHz.

Could this have been the problem all along? I know from messing with a Pi 3B that I overclocked to 3B+ performance(1.4GHz) that a few hundred MHz goes a long way.

(I'm heading in to work soon and I sleep after work, so any overclocking will take place tomorrow if there may be a benefit to it)

dankcushions

@formulafox said in Pi Zero arcade issues:

But something else has been noticed. Since I am considering trying to overclock the Pi, I did my due diligence and checked to make sure the CPU was running at the advertised clock speed of 1GHz. It is not. It is running at 700MHz.

i don't think so. how are you measuring the clock speed? rpis downclock when idle. looking at your config you have the cpu speed commented out which should mean it runs at default (1GHz)

overclocking could help, mind.

FormulaFox

@dankcushions
I used vcgencmd measure_clock arm in the terminal.

I just looked at the config.txt file and noticed the overclocking line reads as follows(emphasis added, obviously):
"#uncomment to overclock the arm. 700 MHz is the default.
#arm_freq=800"

I am definitely going to uncomment that and set arm_freq to 1000 when I get up just to see what we get.

EDIT: A thought occurs. The Retropie build for the Pi Zero is also meant for the Pi 1. Which, IIRC, uses a 700MHz chip. Could something have glitched out and set up some sort of hardware config that assumed it was being set up on a Pi 1?

dankcushions

@formulafox said in Pi Zero arcade issues:

@dankcushions
I used vcgencmd measure_clock arm in the terminal.

I just looked at the config.txt file and noticed the overclocking line reads as follows(emphasis added, obviously):
"#uncomment to overclock the arm. 700 MHz is the default.
#arm_freq=800"

yes, you get the same comment on pi4 builts. raspbian have never update the comment, but it still defaults to an appropriate value for the hardware. don't worry about that message.