MiSTer FPGA Forum

Neocaron wrote: ↑Fri Mar 15, 2024 9:04 am

Coolbho3k wrote: ↑Thu Mar 14, 2024 9:39 pm

Neocaron wrote: ↑Thu Mar 14, 2024 2:04 pm

I ust wanted to throw out here that after some testing last night, I would recommand for people who experience crashes on RE2 and Conker to use the overclock DDR3 RAM script, yesterday I was wondering if I got lucky since I never had any crashes on RE2 while using the script in the past month. So I decided to not use it last night and RE 2 crashed 3 times out of 5 in less than 30min while it never happened with the DDR3 OC script: You can find more info about it here:

viewtopic.php?p=77612&hilit=overclock#p77612

The OC I use is 1050mhz, it's always stable for me:
script is available here. I know there is a way to prioritize the timing instead of the speed but I didn't look into it.
https://github.com/coolbho3k/MiSTer-Ove ... _mem_oc.sh

Let me know how it goes for you on the games like Conkers and RE2 regarding crashes

It's important to note that the script has to be reactivated everytime you reboot or turn off your Mister

I was testing the script with Jet Force Gemini and it always still crashed at the same point in the intro no matter what I did. I even tried overclocking the FPGA to HPS bridge that DDR3 accesses have to cross, by 33%, as Robert said that was a bottleneck to no avail on JFG.

Conker and RE2 crash too infrequently to consistently test I just was too lazy to try to test those lol. I guess I can try to play through one of those games.

For what it's worth the memory overclock script improves worst case DDR3 latency by about 20% at 1000 MHz for me, measured using Robert's DDR3 test core. For what it's worth, Robert doesn't think it helps worst case latency last time he checked, but I recently measured different. I don't know enough about the core whether this should help or not.

Are you using PAL or NTSC? Because I did use PAL and I'm guessing timing are less critical since it has more time per frame to acces the DDR3, maybe that's why it crashes less or not all on PAL game with the OC? Does Jet Force Gemini have a PAL version? Did you try OC both timing and speed to see if you could see an improvement?

I was always trying NTSC. And yes I did play quite a bit with a lot of registers to tweak things. Unfortunately I haven’t been able to get any improvement on JFG. Since Conker is more stable to begin with it’s possible maybe the overlock works to fix it though

I just wanted to thank Robert for his incredible work on the core, hats off for what he has achieved a remarkable achievement!

It seems like these guys found a solution to the latency issue in DDR3 on another FPGA board, but it's DDR3 memory as well.

https://www.ultrafp64.com/

Look the logs.

Primeira_Fase wrote: ↑Sat Mar 16, 2024 6:57 am

It seems like these guys found a solution to the latency issue in DDR3 on another FPGA board, but it's DDR3 memory as well.

https://www.ultrafp64.com/

Look the logs.

Some of the REPLAY2 folks have said similar things with regards to queuing and caching to fix the problem. "clever cache arrangement" " using two channels in pairs" From what I understand Laxer3a also had a workaround for the VRAM timing issues that currently exist in the available PSX Core.

It's a little sad to see, but Robert never had to do any of this. He went against the grain and gave a year of his life to the community.
Thanks Robert.
I am interested in the future of FPGA emulation. From what I understand, Robert had to reverse engineer the N64 so documentation on how it functions is now existent. The Analouge N64 is in the works (although I've never cared for analouge) and MARS FPGA may or may not exist. Time will tell, I suppose.

Primeira_Fase wrote: ↑Sat Mar 16, 2024 6:57 am

It seems like these guys found a solution to the latency issue in DDR3 on another FPGA board, but it's DDR3 memory as well.

https://www.ultrafp64.com/

Look the logs.

Completly different story.
Mazamars has a dedicated DDR3 that is not shared with other components. With hardware like this, we would have zero issues.

FPGAzumSpass wrote: ↑Tue Mar 19, 2024 2:11 pm

Completly different story.
Mazamars has a dedicated DDR3 that is not shared with other components. With hardware like this, we would have zero issues.

Aren't you supposed to be resting? Off to bed mister!!

BrYaN55 wrote: ↑Thu Mar 14, 2024 11:48 pm

Neocaron wrote: ↑Thu Mar 14, 2024 2:04 pm

I ust wanted to throw out here that after some testing last night, I would recommand for people who experience crashes on RE2 and Conker to use the overclock DDR3 RAM script, yesterday I was wondering if I got lucky since I never had any crashes on RE2 while using the script in the past month. So I decided to not use it last night and RE 2 crashed 3 times out of 5 in less than 30min while it never happened with the DDR3 OC script: You can find more info about it here:

viewtopic.php?p=77612&hilit=overclock#p77612

The OC I use is 1050mhz, it's always stable for me:
script is available here. I know there is a way to prioritize the timing instead of the speed but I didn't look into it.
https://github.com/coolbho3k/MiSTer-Ove ... _mem_oc.sh

Let me know how it goes for you on the games like Conkers and RE2 regarding crashes

It's important to note that the script has to be reactivated everytime you reboot or turn off your Mister

I can confirm this for RE2! I was able to finish Leon A without any crash. I was using the 950 mhz since 1050 mhz didn't seem to be working all the time for me. But that was a great fix so far, thank you Coolbho3k!

Glad to hear this is seemingly working for multiple people. I have not been able to find a way to prevent JFG from crashing but if RE2 and/or Conker can somehow be made more stable then it would be great news.

Great news indeed, I did more test with the NTSC version and with a 1050mhz OC no crash after 2 hours of play on RE2. And I'm sure the PAL game are less latency sensitive in the first place because each frame has a higher frametime budget to render by the fact it's running at 25fps/50fps. The memory OC is really really safe so maybe it could be nice if ths could be directly integrated in the core itself so we don't have to run the script everytime. Maybe with a more conservative increment speed like 950 or 1000mhz

pbsk8 wrote: ↑Thu Mar 14, 2024 10:26 am

now let's see how the analog n64 will have same compatibility coincidentally as robert's core

So without any reason or evidence you are basically implying that Analogue is going to steal code? And you won’t even just straight up say it?

This is not something which Analogue have done before with any other core or console and Kevtris has not only been developing FPGA cores for classic consoles for more than a decade before mister was even conceptualised but he has stated numerous times that he steers well clear of looking at mister source so that it never becomes an issue.

Besides this, it’s widely theorised that the development for the Analogue N64 core is being led by another very talented and experienced FPGA dev, Murray Aickin, AKA “Mazamars312”: https://github.com/Mazamars312

Murray has been developing an N64 FPGA system for at least the last 5 years: http://www.ultrafp64.com/

Why are you even going into an argument about that statement?
Just let it pass, there's nothing to gain from that, this isn't facebook or twitter.

MostroW wrote: ↑Tue Mar 26, 2024 11:29 am

Why are you even going into an argument about that statement?
Just let it pass, there's nothing to gain from that, this isn't facebook or twitter.

I’m simply pointing out that implying plagiarism on the part of reputable developers without basis is not cool.

Yes i got that, but isn't that a waste of (your) time and energy is what i meant.

In addition to that, since the N64 Core is released under the GPL license, even assuming Analog will use it (which doesn't seem the case, and that's another good reason why it's best to get facts first before assuming anything), they would be completely in the clear using it, as long they'll comply with the GPL license, which means open sourcing any eventual modifications they made to the core to work on their hardware.