n64-crashes after playing 20min in the game

shavecat

for example playing mario party 3 , and it always glitch after 20min or so .
not only this game most of them, did this problem ever get fix / solve ?
no overclcok
Pi Model or other hardware: 3b+
Power Supply used: Adafruit 2.4A power supply
RetroPie Version Used 4.4
n64 Glide emulator

thanks

quicksilver

I will test the current binary and see if I can replicate the issue

mitu

@shavecat Can you attach your /dev/shm/runcommand.log, taken immediately after the glitch ? Are you getting any under-voltage errors during gameplay ? What does 'glitch' means - it's an emulator crash or you just get errors during the game ?

shavecat

@mitu
under-voltage no
everything else work just fine psx or esle...
n64 if i let it just a rom load and play on the screen...
but if i really play something like mario party it getting glitch
thats what said -/dev/shm/runcommand.log

mitu

@shavecat said in n64-crashes after playing 20min in the game:

thats what said -/dev/shm/runcommand.log

Is this after after the 'glitch' ?

shavecat

Its just make me pi freeze ...
so dont know if the glitch is witting

mitu

Can you post also your /boot/config.txt file ?

shavecat

This post is deleted!

shavecat

@mitu

# For more options and information see
# http://rpf.io/configtxt
# 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.
total_mem=1024

# 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
gpu_mem=512

mitu

Your VRAM is a bit large - half of the PI's RAM is allocated to the GPU. Can you try and set it back to the default - 256 - and try again ?
Also total_mem is not part of the default config.txt, remove it or comment it out.

shavecat

@mitu
Sure .
tx

quicksilver

@shavecat I've been playing GoldenEye using gliden64 using the most recent mupen64plus binary and have been playing for over 45 mins with no issues.

Edit: You also have

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

Commented out, these lines by default are not commented out. This tells the pi how much memory to dedicate to the GPU based on the total amount of ram on the pi. Remove the gpu_mem=512 and remove the comments on the above lines and try again.

shavecat

@quicksilver
Tx again :)

saccublenda

I don't know if it is relevant, but I get this crash after 20 minutes with lr-mupen64plus-next and not with Mupen64plus+ gliden64.

quicksilver

@saccublenda lr-mupen64plus-next is based off mupen64plus and gliden64. I would wait until they get it updated to gliden64 3.0 and see if that fixes the issue. May want to report it on the GitHub issue tracker and/or the lr-mupen64plus-next thread here on retropie forums.

saccublenda

@quicksilver Yes, this is what I meant, maybe this problem is related to an old version of gliden64. If @shavecat is using mupen64plus the issue may be fixed updating the emulator from the source.

mitu

@saccublenda I think @shavecat's problem stems from the VRAM settings - which was also pointed out by @quicksilver - but so far we didn't hear if this was the culprit or not.

quicksilver

@saccublenda currently mupen64plus fails to build from source @BuZz is working on it.

saccublenda

@mitu I have the standard VRAM settings, and still having the 20-min crash with lr-mupen64plus-next.

quicksilver

@saccublenda we are talking about potentially two different issues on two different emulators. The op on this thread was having an issue with standalone mupen64plus, an issue that was solved with a recent update (which is why we think he's problem was actually a vram issue).

Your issue is with lr-mupen64plus-next which is based on mupen64plus-gliden64. However, lr-mupen64plus-next is not up to date yet with the standalone emulator so it's likely that the bug still persists until it is brought up to date with the standalone mupen64plus.