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

[TakuikaNinja]

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):

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

[punesemu]

I will implement it, thanks for the idea.

[punesemu]

Try with the last WIP.

[TakuikaNinja]

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):

Here is the same program on Mesen with the same RAM init setting:

[TakuikaNinja]

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.
NovaSquirrel/Mesen-X#145

[TakuikaNinja]

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]

You can test the last WIP?

[TakuikaNinja]

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]

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]

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

[punesemu]

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

[punesemu]

Have you had a chance to try the n163 branch?

[TakuikaNinja]

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

[punesemu]

Have a nice vacation, enjoy.

[punesemu]

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

[TakuikaNinja]

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.