Why does BSNES have a 32040.5 Hz sampling rate?

It's half of a prime number. Is this number chosen so that it only syncs up with the master cycle every 22 seconds, as a way to estimate the randomness of the real chip?

The APU runs at "roughly" 3.07 MHz, with 64 S-DSP cycles and 32 S-SMP cycles per sample. The 32040.5 Hz sample rate implies a 3075888 Hz overall APU rate. I don't see where the 22 enters into anything.

If I were designing a "performance" profile, I'd produce one APU cycle for every 7 master clock cycles. That'd give 945/44*1000000/7/96 = 31960.22 Hz.

It takes 22 seconds for both the master clock and the sampling rate to hit a whole number at the same time.

I believe this is correct.

The S-APU uses a ceramic resonator, which are a comparatively low-precision clock source (≈0.1% to 0.5% error). For whatever reason, the one in the SNES seems to tend fast.

And using a large prime number makes it harder for people to make timed code that will fail on actual hardware when the clock rates don't match, without needing to dynamically change the clock rate every time the emulation starts.

If you're going to make an HDMA streaming code work on every SNES (except for broken ones) you probably want it to tolerate any rate between 64.5 cycles per scanline to 65.5 cycles per scanline. I think having 9 lines of data plus 2 scanlines for timing would be a good idea, because 9 lines would be enough for 4 BRR blocks, and 11*20 = 220 which is close to 224 lines.

relevant thread: https://board.byuu.org/viewtopic.php?f=8&t=1455

"d4s' Breath of Fire II HDMA audio streamer due to a race condition"

Wait, so this is to get it to work on somebody's ROM hack? You'd think Byuu could've got d4s to fix his ROM hack instead?

Note that this was "in an older release of bsnes", so there's a possibility that the timing was slightly off.

Anyway, if the ROM hack works on a real SNES, it's better to change the emulator.

FTFY

It seems to me that if it doesn't work with exactly 32040 Hz, odds are it will fail sooner or later on somebody's console.

I imagine the BoFII streaming code is similar to the N-Warp Daisakusen method, which if I recall correctly uses a constant 66-cycle pickup loop. This is a bit long even for PAL, but it works okay if you keep the data bursts short.* For NTSC it's a full cycle too long and will quickly get out of sync. In any case, if 32040.5 works but 32040 doesn't, it suggests that he was pushing the timing a little hard, and I wouldn't trust it on a real SNES.

But I haven't actually examined the issue, so take the above with a grain of salt. For all I know there could have been a bug in bsnes...


* It helps that he just dumps the data to the stack and relocates it later, rather than writing it directly to the desired location like my proposed method, because the stack method is faster and leaves more room for timing slop. This is why I need a hot-swappable sub-cycle delay block and he doesn't.

It must be off by less than a cycle. I'm not sure if it's the NTSC or PAL version that didn't work at 32040 though.

It's 32040hz now, and has been for a long time. If you choose to use a 7-year old release, it's on you.

Regardless, it really doesn't matter what value is chosen, so long as it's within the accepted tolerance of the ceramic capacitor.

I would bet large sums of money d4s' streamer will break on some real hardware units, but certainly not most ... he's really thorough about testing his stuff.

What actually was the issue? Was the hack fixed, or was there a bug in bsnes causing the problem, or does the hack no longer work?

I got the information from 7-year old forum threads.

Edit:
Wait, that forum thread said 2016? I'm confused.

I stopped caring. No idea if it works or not, sorry ^^;