n64-crashes after playing 20min in the game

shavecat

This post is deleted!

shavecat

# 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.

shavecat

Sorry to birng and old topic -
but just played mario party 3 (on lr-mupen64plus-next ) with 4 plaers after like 20 min the game stuck ... can still go from putty , but the game is stuck on it .
I did finish Yoshi world on the n64 with the lr_mupen64plus-next , and with not stucks....
Anyone try the new fix's with mario party 1-3 more then 1 player and didnt get stuck ?

Nightfire

I had this same issue (2 player on Mario Party 2, haha), never solved it.
We could play for 15-20 minutes, then it would slow down over the next minute, then lock up (would have to hard power off the pi)
It was like a year and a half ago now, so I believe it was the Pi 3B...and I really can't remember what little troubleshooting I did, I think just trying some the different cores and other video resolutions.
I mainly just saw this thread and wanted to add that I had the same problem, over a year ago

quicksilver

@shavecat I know that some of the mini games on Mario party one will cause a freeze with some emulators on the pi. Not sure about Mario party 3.

At this point just wait until retropie is up and running on the pi 4. It's not worth the frustration on early pi models.

shavecat

Thanks !:))"

hhromic

@shavecat in lr-mupen64plus-next there is a core option titled Max texture cache size to control the size of the texture cache. On Raspberry Pi it should default to 1500, on Switch to 4000 and in any other system to 8000.

This option is very related to the issue you are experiencing, if you have it set to anything but 1500, try to lower it down and see if it helps.

shavecat

@hhromic
Amazing ! will give it a try
haha funny , i cant change it to lower .
maybe upper .