Mupen-glide crashing

quicksilver

So I have been having issues with mupen64-glide. Overall it works fine, however, after about 10-20 minutes of gameplay everything on the screen will glitch out and start shaking and all the graphics will turn into a big corrupted mess. After that it will either freeze the emulator completely or it will suddenly stop glitching out and I can play for a few more seconds before it glitches out again. When it freezes I can still ssh in and reboot the pi safely. Or in some cases and can quit back to ES before it freezes and then I can relaunch the game. It only happens with the glide plugin and has happened with multiple games (Diddy Kong racing, road rash 64, perfect dark; to name a few). At first I thought it was an unstable overclock (although I tested thoroughly using tools like memtester, stress, and quake 3) but I am still having issues even after restoring the default clock settings. I do not get any thermal or undervoltage warnings. I am using the latest mupen build from source although it was happening even before that on the latest binary build. Can anyone shed some light on what might be happening?

Pi Model or other hardware: Pi 3B
Power Supply used: 5.25v 3a mackertop (have also tried 5v 2.5a canakit
RetroPie Version Used: 4.3
Built From: image from retropie website
USB Devices connected: wireless keyboard, Xbox 360 wireless connector.
Controller used: wireless Xbox 360
Error messages received: none
Emulator: mupen64-glide
How to replicate the problem: playing any game using mupen64-glide for about 10-20 mins (sometimes happens faster than that) will result in graphics glitching out and then usually freezing.

dankcushions

@quicksilver said in Mupen-glide crashing:

At first I thought it was an unstable overclock (although I tested thoroughly using tools like memtester, stress, and quake 3) but I am still having issues even after restoring the default clock settings

can you post your /boot/config.txt so we can confirm?

5.25v 3a mackertop (have also tried 5v 2.5a canakit

i don't know what the mackertop one is like, but the canakit has been known to have give problems for some people. i only trust the official pi power supply.

are you using a case (which?)? does it happen with wireless devices unplugged?

quicksilver

Here is my boot config when I set it back to defaults:

# For more options and information see
# http://rpf.io/configtxtreadme
# Some settings may impact device functionality. See link above for details

# uncomment if you get no picture on HDMI for a default "safe" mode
#hdmi_safe=1

# uncomment this if your display has a black border of unused pixels visible
# and your display can output without overscan
disable_overscan=1

# uncomment the following to adjust overscan. Use positive numbers if console
# goes off screen, and negative if there is too much border
#overscan_left=16
#overscan_right=16
#overscan_top=16
#overscan_bottom=16

# uncomment to force a console size. By default it will be display's size minus
# overscan.
#framebuffer_width=1280
#framebuffer_height=720

# uncomment if hdmi display is not detected and composite is being output
#hdmi_force_hotplug=1

# uncomment to force a specific HDMI mode (this will force VGA)
#hdmi_group=1
#hdmi_mode=1

# uncomment to force a HDMI mode rather than DVI. This can make audio work in
# DMT (computer monitor) modes
#hdmi_drive=2

# uncomment to increase signal to HDMI, if you have interference, blanking, or
# no display
#config_hdmi_boost=4

# uncomment for composite PAL
#sdtv_mode=2

#uncomment to overclock the arm. 700 MHz is the default.
gpu_mem=256
arm_freq=1200
sdram_freq=450
gpu_freq=300
core_freq=400
disable_splash=1

# Uncomment some or all of these to enable the optional hardware interfaces
#dtparam=i2c_arm=on
#dtparam=i2s=on
#dtparam=spi=on

# Uncomment this to enable the lirc-rpi module
#dtoverlay=lirc-rpi

# Additional overlays and parameters are documented /boot/overlays/README

# Enable audio (loads snd_bcm2835)
dtparam=audio=on
#gpu_mem_256=128
#gpu_mem_512=256
#gpu_mem_1024=256
#overscan_scale=1

In regards to the power supply I started with the canakit which never gave me any low voltage warnings while in game but it did when I ran cpuburn-a53. When I switched to the mackertop I no longer got the low voltage icon while running cpuburn. I am using a nespi case (never got the low voltage warnings except as I described above). Since the mackertop power adapter resolve the voltage issue when running cpuburn I didnt think of it further. Since you brought it up I will pull the pi out of the case and test mupen64-glide with power going straight into the pi itself.

When you say test with "wireless devices unplugged" I am assuming you mean just use a corded game pad and nothing else plugged into the USB?

dankcushions

@quicksilver that is not a default config.txt. default should have none of these lines:

gpu_mem=256
arm_freq=1200
sdram_freq=450
gpu_freq=300
core_freq=400
disable_splash=1

and these should be uncommented:

#gpu_mem_256=128
#gpu_mem_512=256
#gpu_mem_1024=256

i don't know if it will fix the issue, but worth a try.

with regards to the power supply I started with the canakit which never gave me any low voltage warnings while in game but it did when I ran cpuburn-a53. When I switched to the mackertop I no longer got the low voltage icon while running cpuburn. I am using a nespi case (never got the low voltage warnings except as I described above). Since the mackertop power adapter resolve the voltage issue when running cpuburn I didnt think of it further. Since you brought it up I will pull the pi out of the case and test mupen64-glide with power going straight into the pi itself.

yes, the nespi case is famous for causing power issues. i wouldn't trust the absence of the lightning bolt symbol - sometimes power issues happen before it displays. i also wouldn't trust command line cpuburn stuff as they don't stress the system in the same way as a 3d emulator would. no gpu load, for example. even quake 3 isn't a like-for-like.

When you say test with "wireless devices unplugged" I am assuming you mean just use a corded game pad and nothing else plugged into the USB?

right

quicksilver

@dankcushions aren't those the stock clock speeds for a pi 3? I will see if I can find a standard config. My image came from a overclocked pi2 so I tried to restore the boot config back to stock speeds myself. I will report back after I've tested out your suggestions. Appreciate the help!

dankcushions

@quicksilver you get the stock speeds when you set no speeds :) they might be right, but that’s what i expect from a default config.txt.

quicksilver

@dankcushions so it looks like the nespi case is the culprit. I have been playing several N64 games using mupen64-glide for over an hour with no issues. I just hope I can still return it. It's a shame really because it's a nice looking case. Thank you again for your help!

dankcushions

@quicksilver no problem :) my understanding with a beefier power supply (eg, the official raspberry pi one), you can still use that case. there's been some threads on reddit about it.

quicksilver

@dankcushions said in Mupen-glide crashing:

@quicksilver no problem :) my understanding with a beefier power supply (eg, the official raspberry pi one), you can still use that case.

I wonder if that would even work. Like I said I never had issues with the lightning bolt icon showing up except while running cpu-burn (probably not many people running that). Only running mupen64-glide for long periods of time revealed that the nespi case was causing power fluctuations. All other emulators seemed to run fine and I have been using the case for over two months now. There are probably a lot of people who think that by making the lightning bolt icon go away that they have solved their voltage issues with the nespi case, but I would bet that they havent actually solved it.