Gen 3 Pokemon Inaccurate healing Sound Effect

[DarthPidgey]

As title says the sound effect for using a healing item like potions in a Gen 3 Pokemon game is inaccurate compared to real hardware, MiSTer audio was tested on both HDMI and IO board.
Sound effect comparison.zip

[Toryalai1]

What is your core version? Latest?

[DarthPidgey]

Yes the one released a few days ago, though it's always seemed to have the issue

[Toryalai1]

How did you record from GB?

[DarthPidgey]

Via the headphone out, recording software was audacity, but the sound is clearly different even if you were to listen by yourself no matter if it was headphone or speaker

[birdybro]

Sounds like the duty cycle is wrong. This sound effect happens on PSG channel 1.

[DarthPidgey]

the march 17th build didn't fix this

[DarthPidgey]

the mGBA emulator had the same sound glitch reported by me but was fixed today, any ideas on how to implement something similar? mgba-emu/mgba#3086

[RobertPeip]

Yes, looks possible to implement.
Can you please create a savestate before the sound effect in question?

Best would be for me: loading savestate -> press a -> sound happens.

Sorry, I'm very bad at hearing these differences, so i must be sure I'm researching the right thing.

[DarthPidgey]

savestates.zip
The pokemon pinball ruby & sapphire savestate is for the standard US version and should be the easiest to test. The others I used the leaked debug roms since they have an easily accessible soundtest allowing one to hear the sound effects with no music.

[RobertPeip]

TLDR: not fixed yet. Explanation below.

So the sound effect consists of 3 independent parts. Each part is starting with a frequency and then ramps it up using the sweep functionality.
You can see it in the screenshot(upper one is mister, lower is hw)

Interesting is the third sequence.
There is a new start marked with the red box , causing the frequency ramp to restart and therefore never reach the high frequency as it should.

I found a mistake in the code in that the freuency register is updated, even when only the lower 8 bit are written and even if the "Start" bit (initial) is not set, so I changed it.
However, it doesn't seem to have any effect.
I included the rbf and the changed source file in the zip here if anyone wants to debug further. I'm out of clues currently, sorry.
rbf_source.zip

[paulb-nl]

The sound test in the debug rom is great for debugging.

The game writes to the upper bits of the frequency in NR14 after the sweep has already increased the frequency. The expected behavior seems to be that the new frequency is the new upper written bits with the Sweep increased lower bits.

The current core behavior is that Sweep does not update the frequency in NR13/14 so when it reloads freq_divider from the Channel_Frequency then the Sweep increment is lost.

Here are the changes that I made based on your above changes:
paulb-nl@59e5886

When the CPU writes to the frequency it updates the lower or upper bits of freq_divider. I added the byte enable signals to eProcReg_gba for that.

I changed the frequency counter a bit. Instead of counting from 0 to (2048 - freq_divider). It just counts to 2047 starting from the value in freq_divider. When the Start bit is set or when freq_cnt is 2047 then it reloads freq_divider into freq_cnt.

[RobertPeip]

Great find, thank you so much!

Are you going to start a pull request from it?

[paulb-nl]

Sure, do I need to change anything for save states?

[RobertPeip]

The soundchannel is not saved anyway in savestates, so the count up/down change does not matter there.

Only the register values are saved, but the savestate loading bus will set all byte enables, so it should be ok as far as I see it.