Virtual Boy - wavetable written during sound output & other inaccuracies

[skyfloogle]

I recently put together a .vgm player for Virtual Boy, with the hope of playing back songs created in Furnace on real hardware. Furnace is by far the most user-friendly software for making Virtual Boy music out there, and I thought it'd be neat to actually play back songs made with it in hardware.

Having made that, I quickly found that my test songs didn't sound right. After looking into it, this is because .vgm files exported from Furnace first enable all the sound channels, and then write wavetable data. On a real Virtual Boy, writing wavetable data while any channel is active has no effect, but Mednafen, the emulator Furnace was designed against, doesn't emulate this. As a result, the exported .vgm files would work in Mednafen, but not on real hardware or newer, more accurate emulators.

Having looked into things, I've found a few other weird undocumented edge cases as well. For example, after a fade-out ends, it is impossible to trigger another fade-out on that channel without writing to that channel's SxINT register. I've done some testing and improved my own emulator, which I'm pretty sure is fully accurate to the hardware now (as far as the VSU is concerned at least).

As I understand it, Furnace currently allocates one waveform per channel. If a channel were to change its waveform, this would present challenges. If a song were to use at most five waveforms, these could be loaded upfront and allocated to channels as needed. With more than six waveforms, sound output might need to be disabled while the wave is being written. This could be done very quickly, but the process of re-enabling the channels could lead to stuff like modulation effects retriggering.

I'd be interested in trying to figure out how to adapt Furnace's Virtual Boy code to account for these edge cases and produce playable .vgm files, but I'd like to know whether you're interested first, as while these changes would make Furnace more hardware-accurate and boost its authenticity, these changes are potentially complicated and might have adverse effects on existing tracks (though I haven't investigated this). Are there other soundchips in the codebase with similar "turn off audio to change settings" type quirks?

[tildearrow]

Thank you for testing Virtual Boy playback on hardware!
It appears you have brought confirmation that it is indeed impossible to change waveform data on the fly...

If a song were to use at most five waveforms, these could be loaded upfront and allocated to channels as needed.

Furnace has a mode which does exactly this - only allows you to use the first 5 waves. In Manage chips or Configure chip, check out the Waveform storage mode option.

[tildearrow]

I have pushed a fix which makes Furnace write wave data first at least in static (first 5 waves only) mode. Please test with a static mode song (demos/virtualboy/ghx_melodic.fur will do) using latest artifact or Git master.

Update: Pushed a fix for dynamic mode as well, but there are a bunch of unavoidable clicks.

[tildearrow]

Also I have a question.

https://github.com/skyfloogle/red-viper/blob/c6b813a5cc1cd479d035daccf864049d433ad21b/source/3ds/vb_sound.c#L240

Does channel 6 (noise) being active actually inhibit wave memory write as well? I am a bit skeptical considering it's a noise channel and doesn't have a reason to access wave memory

[skyfloogle]

Thanks for the quick response!
I've tested, and the noise channel does indeed prevent writing wave memory.
I'll get back to you with my test results.

[tildearrow]

That's terrible...

I have pushed another fix. Dynamic mode should work on hardware now.

[skyfloogle]

Zip with an ogg in it because GitHub doesn't like oggs
ghx_melodic on hardware!