N64 crashes after 10 min

Riverstorm

@bobberella said in N64 crashes after 10 min:

Does anyone know why the over voltages on the SDRAM are always suggested to be setting to over_voltage_sdram

Using over_voltage_sdram sets the SDRAM Controller, SDRAM I/O and SDRAM PHY (RAM Chip) all to the same value from 0.8 to 1.4v in 0.025 increments. The values are -16 to 8. The default 0 at 1.2v. I know bumping them [up] help in stability in overclocking RAM as well as sdram_schmoo when bumping the sdram frequency fairly high. Why they recommend setting the physical RAM chip at a higher voltage I don't know. I know the engineers on the Raspberry Pi forum would probably be able to split the hairs there. I used to use the separate values but now I just use over_voltage_sdram set to 2 for 1.25v with sdram_freq set to 600. I have overclocked the SD card as well and it seems to run stable.

I will test out a few of the game mentioned and see what happens.

Riverstorm

@quicksilver said in N64 crashes after 10 min:

Artifacting, and other signs of improper or undesired behavior are other signs of unstable overclocking.

I pushed the gpu_freq right up to seeing artifacts in ES and then backed down. It was running but not sure how stable. A stable overclock is really about time and tedium. Tweak, retest, tweak, retest, tweak, retest, tweak, retest...well a stable one at least! :)

quicksilver

@riverstorm I have found that quake 3 is a good resource for testing overclocks. I run all the automated tests that are recommended first like memtester and stress and if I get a passing grade then I test with quake 3 . Often times clock speeds that pass the automated tests fail miserably when put to a real world test like quake 3. Quake 3 works the GPU/CPU and RAM pretty hard. I found it to be more stressful than the individual tests and in most cases if your overclock is unstable the game will crash within a few minutes. However to verify my overclocks stability I will usually let the game run in first person spectator mode for 4-5 hrs at least. I have had quake 3 freeze after 1-2 hours if the overclock is unstable. So thorough testing is definitely needed when overclocking. I doubt most people test thoroughly enough and are running around with unstable overclocks.

Riverstorm

@quicksilver said in N64 crashes after 10 min:

I have found that quake 3 is a good resource for testing overclocks.

I have just base Quake III but not the expansions. Does that work for testing? Are the Docs sufficient to install it libretro-tyrquake? I do the same and let it run several hours too. This past weekend I hooked it to the TV and let it go all afternoon while I did some other work. The heat seems to creep up real slow right before it peaks so I let it run a good long time. I always try to share ambient when talking overclocking temps as it doesn't make much sense if you don't have a baseline to work from. Big difference if it's 15 or 25C in the room.

quicksilver

@riverstorm the freeware version of quake 3 should work fine. I believe it's listed as quake3 under optional packages. Easiest way to test is to load a skirmish, load a bunch of bots (8 seems a good number). Set kill count and time limit to 0. Once you get into the game press ~ key to open the console. Type /team spectator

Then press enter. Press ~ again to close the console. You are now spectating. Press the fire button and it will place you in a first person view of one of the bots. Now the game will run until you stop it or it crashes. Make sure you have good cooling because it will (as you noted) get your pi very warm. I am using a kintaro 9k case that has an awesome heatsink. For me the temp will climb to 69C and hover there indefinitely. Before i had that case I had a small heatsink and my pi would overheat within about 15 mins of quake 3.

Riverstorm

@quicksilver - Whew, I locked up within minutes running Quake III. I'll have to take another look at my settings as they are pretty modest. I didn't even break an arm_freq of 1300 but I suspect the GPU and RAM are more taxed with Q3.

quicksilver

@riverstorm I am going to start a separate thread on overclocking as we are veering off topic somewhat.

quicksilver

@dankcushions just setup a stock image on my spare SD card. Nothing on it except two N64 games. Within 10-20 minutes of playing battle tanx the graphics glitched out and the game froze. This is using mupen64-glide. Something is going on here.

quicksilver

Just happened again while playing Diddy Kong racing. I managed to get a picture this time. Again, stock retropie image. Happened about 10-20 mins into play time.

https://imgur.com/a/lgqGz

I will update Mupen64 from source and test again.

Edit: just updated from source. Same issue.

Bobberella

I can manage to get through the 10 minute glitch fairly easily with a lower SDRAM frequency than a higher one.

If you set SDRAM_freq to 550 and not something insanely high the Rpi 3 can sort itself out pretty well. If you set it to 600 or above then screen will get worse and worse and will it freezes.

I am currently matching my GPU and SDRAM overclock and it seems to help get thought the 15 minute glitch...

Here is a reddit post I found that seems to be the same issue.

https://www.google.ca/amp/s/amp.reddit.com/r/RetroPie/comments/7kvgq9/n64_games_graphical_errorsfreezing_my_pi_3_after/

quicksilver

@bobberella overclock isn't the root issue here. Read my earlier posting, I tried a stock image and the emulator is still glitching out and freezing. I'm wondering if it is somehow related to the framebuffer issue that the fps counter was supposed to solve.

EndersEnigma

@quicksilver @dankcushions

I did a fresh load from a brand new SD card with no overclock settings and updated from source, I am still getting the same 10-20 min crash time. I have even downloaded ROMs from different locations just inc case my ROM was corrupt, this does not seem to be the case. I have the EXACT same issues with varying levels of overclock (which I am not using any more as I continue to test issues per admin instruction).

It seems to be software related, but I am not sure what information the developers need to further look into this issue.

At this time I am using GLES when possible as it performs great (once you tweak the audio setting to allow save states). If the game does not run on GLES, RICE, or LR-, then I just cant play it because every game I have tested on GLIDE crashes at the 10-20 min mark. I use the spreadsheet on the n64 emulation page as a starting point to guide which emulator I run, but I have found that list is not up to date and its better to just experiment on my own. This is very frustrating as playing the same game up to 4 different times for 20 min to test for the "GLIDE glitch" as i have come to call it is painstakingly tedious.

SUMMARY:
I have found out that GLIDE crashes between 12-15 min on almost every game I have tried (about 12 games total). The problem happens only once at that time interval (does NOT repeat every 12-15 min after the first one). If i let the game sit at an idle point such as a load screen, save screen, or face my character into a wall or something, the game will blur and stutter for about 30-45 seconds then recovers and runs great, If I move at all or force the game to process movement of almost any kind it crashes. This is impossible on games like Aerofighters Assault where you are in constant motion, these types of games crash every time as a result. The indicator if the game has crashed or not is tied to audio output. So long as sound is playing normally when the problem starts, it is in the "blur" phase and recovers within 30-45 seconds every time. If you try to move or jump or cycle through a menu during the "blur", the sound will cut out completely or hang on a note and sustain until you hard reset.

I hope this helps, I am happy to provide any additional information if it assists in solving this issue.

quicksilver

@endersenigma I see you have spent as much time trying to figure this out as I have. I've noticed all the strange nuances with this glitch as well. I suspect this is an issue with mupen64-glide on the pi itself. If this issue was universal to all devices I'm sure the mupen64 devs would already know about it. At this point I just need to figure out who to report it to.

EndersEnigma

@quicksilver
I did a search looking for the contact information of the GLIDE devs, no luck. Maybe one of the admins/mods can point us in the right direction.

Bobberella

@quicksilver

I have known that overclocking isnt the root of the issue for a long time now... What im more interested in is setting up my retropies so that they will overcome the glitch and not freeze up given the chance.

I have run about 50 tests. You can start the game, set the timer for 14 minutes and let the game run without hitting pause and then see how your new settings react to the glitch.

I cant fix the glitch. I have no idea who can but I dont care either. All I want is to play so N64 in peace.

If you know of any other componants I can tweek that will allow the Rpi 3 to recover better from a glitch like this I would be interested in hearing it. :)

I am glad you guys are gonna try and get it fixed and thats awesome because this glitch has been around for at least a year now.

quicksilver

@endersenigma https://github.com/mupen64plus/mupen64plus-core

This is most likely the place to report an issue. I too would like a mod/admins opinion though.

Bobberella

@quicksilver

I found that Dolphine was crashing at exactly the 15 minute mark and they found:

"Oh, looks like I found the solution.

I changed DSP HLE to LLE, and I changed the driver from XAudio2 to Direct Sound"

So what does that mean?

dankcushions

@quicksilver said in N64 crashes after 10 min:

@endersenigma https://github.com/mupen64plus/mupen64plus-core

This is most likely the place to report an issue. I too would like a mod/admins opinion though.

if this isn't happening in other graphics cores then it's not a mupen64plus issue, it's a gliden64 issue. please report it here: https://github.com/gonetz/GLideN64/issues, but lets hold fire on that for a while until we have more details

i think a video of the issue would be ideal, and even better would be a stack trace, but that's kinda difficult to explain if you've not done it before. tagging @gizmo98 if you have a moment :)

quicksilver

@dankcushions I will try to get a video of it, it's hard though because sometimes it glitches and freezes faster than I can get my camera ready (I don't have capture equipment). It's easily reproduced though.

EndersEnigma

@quicksilver
I might be able to capture some video this weekend, will update as able.