When the program turns on rendering by changing bit 7 of LCDC ($FF40) from 0 to 1, the PPU goes straight to the start of rendering (scanline 0). And for some reason, the LCD does not receive the first frame that the PPU generates, instead displaying a white screen for one frame. (On monochrome systems, this is the same whiter-than-white shade displayed when rendering is off.) Some games, such as Pokémon Pinball, use this blank frame to prepare things before the first visible frame, such as the sprite display list to be DMA copied to OAM during the first vblank.
Though recent BGB emulates this quirk, mGBA 0.8-5388-f92059be does not. This causes 1 frame of corruption to appear in Pokémon Pinball and numerous other games after a screen transition. Many games on KiGB's compatibility list are there because of this quirk.
By the way, @liji32 determined that the LCD timings differ on DMG models and CGB ones - IIRC, on DMG Mode 0 is always at its longest, CGB instead has variable Mode 0's as normal.
When the program turns on rendering by changing bit 7 of LCDC ($FF40) from 0 to 1, the PPU goes straight to the start of rendering (scanline 0). And for some reason, the LCD does not receive the first frame that the PPU generates, instead displaying a white screen for one frame. (On monochrome systems, this is the same whiter-than-white shade displayed when rendering is off.) Some games, such as Pokémon Pinball, use this blank frame to prepare things before the first visible frame, such as the sprite display list to be DMA copied to OAM during the first vblank.
Though recent BGB emulates this quirk, mGBA 0.8-5388-f92059be does not. This causes 1 frame of corruption to appear in Pokémon Pinball and numerous other games after a screen transition. Many games on KiGB's compatibility list are there because of this quirk.
So I've made a test ROM for this quirk.