-
Notifications
You must be signed in to change notification settings - Fork 81
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SA-1 Speed Test v5.1 shows some major differences #350
Comments
The ROM is faster on this core because it reads the ROM at 10.74Mhz 16bits while it should be 5.37Mhz 16 bits.
For the Page 4/4 IRAM<->BWRAM DMA tests, the core speed is 0.14Mhz because during the test the SA1 accesses IRAM and currently the core pauses the SA1 when DMA and SA1 both access IRAM. My guess is that because BWRAM is accessed at 5MHz and IRAM at 10MHz there is one 10Mhz idle cycle for IRAM during DMA so there is 1 cycle for DMA and 1 cycle for SA1 so it should not be paused. |
No, it's not. Core just reads the high and low bytes over again every cycle. The original SA1 reads a word every 2 cycles, uses the high byte in the current cycle and saves the low byte for the next cycle. But after the jump commands you have to re-read the new word because the next byte follows the new address, not the next address. This feature is not emulated in the core.
I think the same thing. I ordered the original cartridge with the SA1 chip. When I got it, I will try to research these aspects with the LA. |
The SNES SA-1 Speed Test v5.1 rom from @VitorVilela7 shows some interesting results. This is all tested with the 20220909 release build. These are minor observations, I am not sure if they actually impact gameplay that much at all, but figured it was worth it to document and put here in case it's useful.
MiSTer Results:
Compare these results to the real hardware tests from QcRetro:
https://github.com/VitorVilela7/SnesSpeedTest/tree/master/img/hardware#1l8b-10-v51
Most results are going quite a bit faster than the original hardware (there may be some hardware variation to account for some of this). The ones that stand out are:
I'm not sure if any gameplay is affected by these, just reporting them as @wwark brought it to my attention. There are some other minor differences, but I chose not to include ones that were less than 1MHz difference in the results, since it's possible hardware variance could account for this.
The text was updated successfully, but these errors were encountered: