(0.80.0-dev) Some carts that poke to sound registers are broken

[The-Beesh-Spweesh]

After the effect-column update, I've noticed that some carts like this one don't produce any software-generated sound anymore.

The reason for this is because of a change in the stereo registers at 0x0FF98 to 0x0FF9B. The 4-bit values for the left and right balance levels used to be inverted prior to the update (0 becomes 15, 1 becomes 14, etc.). As a result, poking 0x00 (the default value) to either of the four stereo registers causes the level to be 15 (the maximum volume) on both sides.

Now after the update, the left/right level registers aren't inverted anymore. This means writing 0x00 will directly set both sides to 0 (mute), and now you'll need to write 0xFF to set both sides to max. Wait, what? Pre-0.80.0-dev carts don't write here!

The Fallspire demo isn't affected by this change, because that calls sfx() on all four channels, therefore setting all four stereo registers to 0xFF.

[nesbox]

Stereo registers aren't released yet, it's only .80 feature.
I think there is something else that caused the issue if your cart works on .70

[The-Beesh-Spweesh]

1. I know that they are only on 0.80.0-dev.
2. Nah, I'm pretty sure the stereo registers are being defaulted to 0x00 instead of 0xFF, when a channel is not playing SFX or part of music (that play when the sfx() or music() function is called). The NEW TYPE OF MUSIC cart linked above mixes drum sounds on one channel (which are played using sfx()), and some other weird sound on another channel (by ONLY poking to the 0x0FF9C to 0x0FFE3 RAM region.)

[The-Beesh-Spweesh]

@nesbox?

[nesbox]

I see the problem, stereo registers value have to be 0xF-volume

[The-Beesh-Spweesh]

Yup. You did this exact same thing when implementing the volume column into the music tracker back in version 0.27.0. This was to prevent all previous music tracks from being silenced.

[The-Beesh-Spweesh]

I see the problem, stereo registers value have to be 0xF-volume

Will you make a fix commit or so, please?

[The-Beesh-Spweesh]

@RobLoach But @nesbox isn't responding! Please, fix it sooner rather than later. I know you might be busy but this is going downhill for almost a month.

I think you got too obsessed with the Mxy command in the tracker and messed up the stereo registers implementation. Carts made in 0.70.6 and earlier never poke to 0x0FF98...0x0FF9B at all under any circumstance, got it? People can always code their own audio engine at any time because poke exists.

[RobLoach]

I've noticed that some carts like this one don't produce any software-generated sound anymore.

When running https://tic.computer/play?cart=975 in....

• Browser I hear sound
• master as of today, I hear sound
• libretro core, I hear sound

Could you share a demonstration with this behavior? 0.27.0 is quite old. Would you provide a bisect to figure out where the change happened that broke it?

[The-Beesh-Spweesh]

That cart is actually quite new, not just an ancient cart from the old TIC days. The 0.27.0 thing I'm talking about was the version nesbox first implemented the volume column in the music tracker, way back in 2017, before I even knew about TIC-80.

The commit the change occurred was 7644aa1, when the music commands branch got merged into master.

Run the cart on the build prior to that commit, and any build that was compiled on or after the commit. The "screechy" sound should play on the former 0.80.0-dev build (and on 0.70.6), and should be silent on the latter 0.80.0-dev build. This is because the stereo registers defaulting to 0 are causing the output of the sound to be silenced on the left and right sides, and the cart code needs to be patched to set both sides to max. Place this line at the start of its TIC function:

poke(0x0FF98, 0xFF)

[nesbox]

I know about the problem, please be patient, .80 not released yet