punesemu / puNES

Qt-based Nintendo Entertaiment System emulator and NSF/NSF2/NSFe Music Player (Linux, FreeBSD, OpenBSD and Windows)
GNU General Public License v2.0
653 stars 42 forks source link

[Bug/Feature Request] N163 Sound RAM initialisation + RAM initialisation settings #276

Closed TakuikaNinja closed 1 year ago

TakuikaNinja commented 1 year ago

After discovering that "Erika to Satoru no Yume Bouken" uses uninitialised N163 Sound RAM as wavetable data, I have been testing the Sound RAM initialisation in various emulators. The test ROM I am using and the spreadsheet of the results can be found in this NESdev forum thread: https://forums.nesdev.org/viewtopic.php?t=24349 puNES appears to initialise the Sound RAM with zeroes, despite the fact that every other section of RAM seems to be initialised with $FF. This should be fixed so that the Sound RAM initialisation matches what is used everywhere else. Additionally, an option to switch the RAM initialisation between $00, $FF, and random values would at least give users the ability to choose between compatibility and accuracy.

Current puNES behaviour (ignores $FF initialisation used everywhere else): n163_soundram_init_000001

Correct behaviour in FCEUX (follows the RAM initialisation setting, random values in this case): n163_soundram_init-0

punesemu commented 1 year ago

I will implement it, thanks for the idea.

punesemu commented 1 year ago

Try with the last WIP.

TakuikaNinja commented 1 year ago

The randomisation works, but the memory should persist across soft resets. Also, I've noticed that some bytes are overwritten on power on when they shouldn't be. Coredump (a test ROM for viewing system RAM contents) is showing some odd values (RAM init was set to $FF to make this obvious): coredump-v1 3_000001

Here is the same program on Mesen with the same RAM init setting: coredump-v1 3_000

TakuikaNinja commented 1 year ago

Additionally, some N163 games use the Sound RAM as WRAM or SRAM. Mesen-X, which I've also reported the Sound RAM init issue to, has had to conditionally skip the RAM init option when the battery flag is enabled. https://github.com/NovaSquirrel/Mesen-X/issues/145

TakuikaNinja commented 1 year ago

Also, I've noticed that some bytes are overwritten on power on when they shouldn't be.

BizHawk's QuickNes core does the same thing. This appears to be a holdover from when NESdev Wiki used to contain this information:

All internal memory ($0000-$07FF) was consistently set to $ff except for a few bytes, which probably vary from console to console: $0008=$F7 $0009=$EF $000a=$DF $000f=$BF

The current wiki page on the power up state has since replaced the section with:

Internal memory ($0000-$07FF) has unreliable startup state. Some machines may have consistent RAM contents at power-on, but others do not.

https://www.nesdev.org/wiki/CPU_power_up_state

It may be best to remove the code responsible for setting those values.

punesemu commented 1 year ago

You can test the last WIP?

TakuikaNinja commented 1 year ago

Looking past the misplaced brackets in the sizeof statements, it seems like using the Sound RAM as SRAM isn't implemented at all so I can't test/verify that yet. The wavetable data is still being initialised with zeroes when outputting audio, likely because snd_wave and other sound registers are never updated with the contents of snd_ram after initialisation.

I think this might be a sign of what's to come, considering that every mapper's initialisation was implemented on the assumption that RAM is filled with static values...

punesemu commented 1 year ago

You're right the implementation of the mapper assumed that the initial values were 0 and also when I wrote it, the information in the wiki wasn't as complete as it is now. In version 0.110 I rewrote a lot of mappers updating them but this one had escaped me. I completely rewrote the mapper but before committing the changes and I'd like you to test it, what version are you using? D3D9 or OpenGL? win32 or win64?

TakuikaNinja commented 1 year ago

OpenGL, x86_64 on EndeavourOS (basically Arch Linux). Just make a separate branch for testing this - I can build it on my end.

punesemu commented 1 year ago

Done. https://github.com/punesemu/puNES/tree/n163

punesemu commented 1 year ago

Have you had a chance to try the n163 branch?

TakuikaNinja commented 1 year ago

Sorry, I've been preparing for a vacation. I won't be able to test the branch until around 3 weeks from now.

punesemu commented 1 year ago

Have a nice vacation, enjoy.

punesemu commented 1 year ago

Since there have been no other updates, I consider this issue closed.

TakuikaNinja commented 1 year ago

I apologise for the delay. The Sound RAM initialisation works properly now. The part about the Sound RAM being used as WRAM or SRAM is a lower priority and will be discussed in a separate issue.