Offline

Now, I don't have a real Gameboy Color, but instead a GB Boy Colour. Through some testing, I came to the conclusion that... unfortunately or not, depending how you look at it, it's a 1:1 clone of the Gameboy Color CPU-B revision, the buggiest one, mainly known for audio issues. The one reported issue I tested was apparently it completely breaks Prehistorik Man's music, and indeed it does (I'm sad, because I want to hear that awesome soundtrack on a bootleg Gameboy!). It probably has all the other audio problems that are mentioned in the same blog post (I won't post it unless it doesn't break the rules.) (Though, it is compatible with the 5th voice demo by irrlicht, and GBVideoPlayer2 by LIJI32 (if I got the name right,) which both utilize other audio bugs that don't normally work on emulators.) If I wanted to write an audio-intensive demo in assembly for the Gameboy, does anyone know what could completely destroy the audio with glitches? I know code that executes really fast audio-wise might cause it to glitch out, but not much else. I also want to inform others of the extent of the GB Boy Colour's bugginess.
CORRECTION: it also might be a clone of the first revision (CPU-A), if that has all the audio/PPU bugs as the second revision.

Last edited by JavierBlitse (Sep 28, 2020 2:49 pm)

Offline
Sweeeeeeden

I believe the main issue with early GBC CPUs is with the length timer function. In LSDj that's the LEN setting in the instrument view. In asm, that's bit 6 of the NRx4 group of registers. If you activate that function at any point for a channel, and then write to the pitch register, there's a risk that the channel stops playing, as if the length timer expired. This is especially obvious during vibrato and other pitch effects that change the pitch often. I think if you never activate the length function you should be fine.

5th voice and GBVideoPlayer2 are not relying on hardware bugs per se, but on the correct implementation of DC offsets as well as fast/correctly timed sampling of register changes. DC offsets were sometimes not considered important among emulator authors because it requires precise hardware research, but the only benefit an emulator would get (before these tricks were invented) is that the little clicks when a channel starts playing or when settings are changed sound correct. Correct sampling of register changes means that the emulator would have to emulate aspects of the audio emulation at higher sample rates than the audio output. (Essentially 1 MHz vs the usual 44.1 kHz) It would, again, be a lot of effort for essentially no benefit before these tricks were invented. Which is way it wasn't really done in emulators until the era of accurate emulation that started about 10 years ago.But there's nothing to suggest that those things would be more likely to be incorrect on a hardware clone.

If you want to discuss GB audio programming, feel free to shoot me a message.

Offline

That actually makes a lot of sense. I'm sure that if I disassemble Prehistorik Man and take a look at the music code, I'll see a lot of the length counter and pitch modulation being used at the same time, because that "small" bug has the potential to break a lot of music. I also assume the bug makes the wave channel more finicky than the other channels, maybe because there's a chance that the length counter does not get restarted when the channel is triggered? (I noticed in Pocket Puyo 2 the wave channel behaves very oddly, consistently cutting out in specific parts of most songs, even when the pitch isn't being changed.)