N64 crashes after 10 min
-
@endersenigma strange that we should have the same issue and I was able to resolve mine. I wish I could think of something else for you to try.
-
I was having problems with freezing (although not specifically with N64). But I was getting bad power at the wall and it was corrupting things.
I tried everything else and at the end of my ropes a quality power conditioner inline saved the day. Just a suggestion.
-
@quicksilver
I just stopped using glide, some games don't work but it's better than nothing. -
I have the same issue. Sometimes it freezes and sometimes I can wait out the glitching till I can play again. If I wait it out I can play for as long as I want.
I think i heard something about a memory system in the pie being unable to clear so it fills up in 15 minutes and then glitches out the system.
So i would lean towards software issue. However it seems way too complicated to fix. So my whole plan is to get it to make it through the glitch so I can keep playing.
-
@bobberella what is your setup? What case, power adaptor, overclocked? I had this issue but was able to resolve it. Also are you using mupen64-glide from binary or source?
-
Alright, so I thought my problem was solved but today I have had a handful of instances where the graphics glitched out while using mupen64-glide. It happened on several games but only after about 10-20 minutes of gameplay. In this case it did not lead to a freeze but after a few seconds of glitched out shaky graphics the game would suddenly become playable again. Not sure where to go from here.
-
I have a case/fan/heatsink(with thermal paste) that idles. Idle temperature is around 37 C and after an hour 42 C. I am overclocked at 1.44Ghz.
I thought it might have been caused by the SDRAM frequency and over voltage SDRAM settings so I messed with that. It seem to fix the glitches and replace them with freezes.
I have had this glitch at almost every overclock setting and I would assume bone stock... too lazy to waste 15 minutes finding out.
-
@bobberella I have tested at stock clock speeds and still get the glitched out graphics after about 10-20 mins. If you are getting straight up freezes, then I suspect your overclocks aren't stable. 1.44ghz is insanely high, I would guess most pi3s aren't stable at that speed. Mine personally isn't stable above 1350mhz. Just because your pi will boot at 1.44ghz doesn't mean it's stable.
-
Yeah. I have 3 Pies and they all glitch at 10 minutes. The 1.44Ghz one im working on is the fastest... possibly too fast.
The others are stable at 1.4Ghz. All you have to do is goid all of the warrenties. My GF has played more than 100 hours on each of the 1.4Ghz ones.
However... im getting this glitch so I started to tinker with the SDRAM. The 1.4Ghz ones will make it past the glitch and continue on but the 1.44Ghz one is a little more weird. Its the only pi i could boot at 1.75 GHz.
-
@bobberella said in N64 crashes after 10 min:
My GF has played more than 100 hours on each of the 1.4Ghz ones.
irrelevant unless that was n64. each emulator taxes the hardware in different ways.
like i said before, for us to get any meaningful bug reports we people to remove ALL their overclocks, use a stock image ideally, update to the latest mupen64plus via source, and see if the issue is still happening. also test with different videoplugins (gles2n64, etc).
If the issue happens to everyone with that scenario, then there's obviously some kind of issue in gliden64 (memory leak?) which can then be taken further. right now we have nothing.
-
@dankcushions I have tested at stock speeds and the glitch does still occur for me. It has only occurred using glide. It has never happened for me with the other plugins. When I have some time later today I will test using a fresh stock rpi image and will test mupen64-glide from binary and source.
-
@dankcushions said in N64 crashes after 10 min:
irrelevant unless that was n64. each emulator taxes the hardware in different ways.
Agreed, did you get it to run at 1750MHz? I had an issue that went undetected for months. It only crashed in one scenario when installing packages. Buzz pointed out it might be worth looking at my overclock. When I did some "real" stress testing it was revealed my overclock settings were unstable.
Here's a great Overclock testing link. It takes time to get through all the tests but you can almost guarantee it's stable.
I think also I read somewhere where they had the Pi 3 SDRAM overclock settings in the raspi-config at 500MHz for Turbo but found occasional corruption on SD cards so they bumped it to 600MHz. I am guessing it was some correlation with the other settings.
At work when we have issues with firewalls we strip everything down to basically an all/all--any scenario in both directions with no AV, IPS, IDS, proxies, web filtering, SSL inspection, etc. all off. I think Dank is correct to strip it down. Your overclocks seems exceptional and potentially unstable. If it was a global problem more people would probably be reporting the issue.
It has only occurred using glide.
What game? I have a Pi setup I could run a test to see what happens here using Glide.
-
@riverstorm I personally have had it happen on diddy kong racing, battle tanx, road rash 64 and some others. Doesnt happen at a specific spot but seems to occur after about 10-20 mins of continuous gameplay. Basically what happens is the screen gets shaky and all the graphics get all jumbled up. I will try and post a pic next time it happens. I thought at one point I had the issue solved when I removed my pi from my nespi case but now the glitch still happens occasionally (though not as bad as before). Like I told DankCushions I will try a fresh stock image and test to see if I can get it to occur. Hopefully that will narrow down whats causing this.
-
"irrelevant unless that was n64. each emulator taxes the hardware in different ways."
@dankcushions It is N64... and I understand it may not be "stable" but if it doesnt crash then I wont worry.
"What game? I have a Pi setup I could run a test to see what happens here using Glide."
@Riverstorm Mario Party 2 & 3 so far are the issue.
=============
"SD cards so they bumped it to 600MHz"Does anyone know why the over voltages on the SDRAM are always suggested to be setting to over_voltage_sdram - voltage of all SDRAM parts (c, i, and p) as (p=6,i= 4,c=4) and not ( (p=6,i= 6,c=6)? The literature says to set them all equally.
-
@bobberella stability is more than just crashes. Artifacting, and other signs of improper or undesired behavior are other signs of unstable overclocking. Playing around with an unstable overclock because it's "good enough" is asking for trouble. It can lead to SD card corruption and loss of data. Also for our purposes we need to find out what the root issue is and an overclocked pi adds way too many variables. If you are getting straight up freezes while playing games then I can bet 100% that your overclock is not stable. We don't want to confuse the issue here so it would be best to discuss results based on Pi's running at stock speeds.
-
@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_sdramsets 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 useover_voltage_sdramset to 2 for 1.25v withsdram_freqset 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.
-
@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! :)
-
@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.
-
@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.
-
@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.
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.