FPGAzumSpass
patreon
Special fast clocked core
🕑 Added 2023-12-22 14:46:50 +0000 UTCHi Everyone,
one topic that seems to be important for a lot of people is the speed of the core. While it is already at least as fast as the original console, some games struggle a lot with low performance.
I often get asked if the core could ever do something about it. I have to say, this is not easy, because the core was very difficult to fit in the DE10-Nano at all, so how could there be even more room? I wanted to know myself how much clock speed reserves we still have the core and so I made a faster clocked core.
Increasing the clock
In the core we have 4 clock domains:
- 62.5 MHz for Systembus, SDRAM, RSP, RDP, ROM interface, pad emulation
- 93.75 MHz for the CPU
- 125 MHz for the DDR3 interface
- 48.68 MHz(NTSC) and 49.65 MHz(PAL) for Video and Audio out
The goal when driving the clock higher would be to have the performance critical parts run faster so we get more frames per second, but keep the game speed at original values.
Because the game performance typically is based on either CPU, RSP, RDP or Memory performance, let's increase all and keep the clock ratio between them:
- 1x: 62.5 MHz -> 80 MHz (+28%)
- 1.5x: 93.75 MHz -> 120 MHz
- 2x: 125 MHz -> 150 MHz
We will keep the Video and Audio clock at the original speed, so the games still run at 60 and 50 Hz with original Audio speed.
CPU internal Timer
Some games are purely based on the line interrupt which comes once per frame and already run at the same game speed, but some create their game speed from the accurate CPU internal clock counter.
This counter will tick up every two clock cycles at 93.75 MHz. If we run the CPU at 120 MHz, it will tick up faster and some games run 28% faster than they should. To fix that, I made a special counter that ignores exactly 28% of the clock pulses to make that counter run at the same speed as the original CPU.
With that change, games cannot tell anymore if they are running with a faster CPU, RSP or RDP unless they count with very primitive ways of counting up in a loop in the CPU, so this covers most games.
Results
With that in place I tested several games that are known for bad performance and if they improved. As the difference is only 28%, you cannot expect miracles, but the result is not bad at all:
- Banjo Tooie runs much more stable at the 30 fps goal
- Goldeneye has around 20-30% higher fps
- Shadowman has around 40-50% more fps
How would that even be possible? Assume fixed costs every frame for the game logic, audio processing, controller processing and such things. Everything that is left can be used for the rendering. But still, improvements above 30% is more the exception than the normal case.
I also played several hours through Banjo Kazooie and Paper Mario and left Goldeneye in attract loop for some more hours, all without issues, to make sure it has some stable behavior on the two DE10-Nano I have here.
How to use
To try the core, you can copy the rbf in the attached zip file to your SDCard just like a normal core and start it. It's completly compatible with settings, save games and folder structure.
Be aware that this is a very experimental core: I cannot give any guarantee that it will work at this high clock speed on your DE10-Nano or that games run stable, so I cannot accept bug reports based on it.
If you don't like to play around with such things, you can completly ignore this core, but hopefully this will make some of you happy who wishes to have a better performance in some games or just like to see the MiSTer pushes to it's limits.
I wish you all a lot of fun and all the best for the new year :)
Robert
Comments
Trifle
Thanks Robert, enjoy Xmas with the family!
This is what N64 dreams are made of! Thanks so much! :)
ER
If this turns out to be a stable feature I suspect it will become a setting in the N64 core menu, since there will always be some usecases for being able to play at the original speed for preservation or preference reasons. Just a guess though.
Dandi and Matija
Very exciting. Is this something that will always require a separate core?
RobF228
Amazing stuff! Can't believe how far you have come on this core. The timing info you discuss is something I have always been curious about and you confirmed 1 or 2 of my guesses, though I am not much of a programmer anymore - corporate stuff was for me. Glad I am on your Patreon.
