Game Boy display disable/enable and frame timing
Posted: Tue Jul 07, 2015 6:35 pm
I'm trying to work out how to sync between my nascent Game Boy emulator's CPU/video/audio processors, and there's a sticky edge case: when a write to 0xff40 disables the LCD display.
Before implementing audio, I ran everything on a per-frame basis. When I hit the end of vblank, I would yield control to the renderer, wait until the next frame, and pick up. If display was disabled, I'd keep running until it was re-enabled and the following rendering frame completed. As a result frames would have a variable number of CPU cycles (which I think did cause some subtle timing bugs) but mostly it worked fine.
Now that I've added audio processing, I'm generating 735 audio samples (44100 / 60) per one frame's worth of CPU cycles (usually 456 * 154 = 70224 cycles.) This works until LCD is disabled and enabled again later, which results in too many audio samples being pushed to the audio buffer that frame, and the audio playback gets progressively more backed up. I've tried cutting the audio sample generation off after exactly 735 samples each frame, but this doesn't seem correct either and results in audible gaps in playback.
Any advice on how to resolve this, and how many cycles to run each processor per frame?
Before implementing audio, I ran everything on a per-frame basis. When I hit the end of vblank, I would yield control to the renderer, wait until the next frame, and pick up. If display was disabled, I'd keep running until it was re-enabled and the following rendering frame completed. As a result frames would have a variable number of CPU cycles (which I think did cause some subtle timing bugs) but mostly it worked fine.
Now that I've added audio processing, I'm generating 735 audio samples (44100 / 60) per one frame's worth of CPU cycles (usually 456 * 154 = 70224 cycles.) This works until LCD is disabled and enabled again later, which results in too many audio samples being pushed to the audio buffer that frame, and the audio playback gets progressively more backed up. I've tried cutting the audio sample generation off after exactly 735 samples each frame, but this doesn't seem correct either and results in audible gaps in playback.
Any advice on how to resolve this, and how many cycles to run each processor per frame?