Reconciling GB and (S)NES frame rate

Discussion of programming and development for the original Game Boy and Game Boy Color.
Post Reply
tepples
Posts: 21748
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Reconciling GB and (S)NES frame rate

Post by tepples » Thu Jul 19, 2018 8:49 am

The Game Boy and NES/Super NES don't run at the same frame rate: 59.73 Hz vs. 60.10 Hz. This means a solution to use the NES/Super NES PPU to display Game Boy video has to provide some means of converting the two. But it can't just run the Game Boy ahead and pause it at the end of each frame, as the same master clock is also divided to produce analog audio, and pausing that would cause distortion at about 60 Hz.

4*341*262-2 = 357366 qpels (quarter pixels, NES/Super NES master clocks) per field
456*154 = 70224 GB master clocks per frame

Nintendo's solutions drop or duplicate frames. Super Game Boy produces the master clock by dividing the master clock by 5. The resulting refresh rate 945÷44×1000000÷5÷70224 = 61.17 Hz leads to dropped frames. Super Game Boy 2 (Japan only) produces the master clock with a separate 20.97 MHz oscillator that it divides by 5. This produces correct CPU speed, which improves sync under link play, but also duplicated frames.

The lowest latency solution would run the Game Boy core at exactly 60.10 Hz. This means dividing the NES or Super NES master clock by 357366/70224 = 5.088943951. This can be approximated as 229/45: add 45 to a counter every qpel, and when it exceeds 229, subtract 229 and pull GB master clock high for 2.5 qpels. That'll finish one GB frame in 357362.13 qpels. Then the NES PPU fetch pattern or Super NES DMA pattern can be used to hard sync the two, allowing the GB to fill the frame buffer. With hard sync, it need not even be a full 5760 byte frame buffer; calculating the minimum size of the needed circular buffer is an exercise for later.

The remaining problem is to account for the GB's variable frame rate when display is turned off. As soon as forced blanking is released, the LCD draws exactly one white frame and then starts drawing full frames. But the forced blanking time need not be a multiple of one frame. Would it be acceptable to pause the GB CPU, causing a brief audible pop, every time forced blanking is disabled? It's not as if GB software forces blanking for other than scene transitions, as starting forced blanking mid-frame causes undue wear to the scanline where it's disabled, and there's not quite as much demand to do so to improve video memory bandwidth because VRAM is writable during the (fairly long) hblank.

lidnariq
Posts: 8768
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Reconciling GB and (S)NES frame rate

Post by lidnariq » Thu Jul 19, 2018 11:37 am

The other option that occurs to me would be to use a simple PLL to tweak the clock seen by the DMG hardware after video is turned back on such that there is some tearing until it's back in phase.

Or synthesizing a DMG softcore on an FPGA and making it inauthentically pause the CPU but not the audio generators until vsync realigns.

adam_smasher
Posts: 271
Joined: Sun Mar 27, 2011 10:49 am
Location: Seattle

Re: Reconciling GB and (S)NES frame rate

Post by adam_smasher » Thu Jul 19, 2018 11:45 am

A brief audible pop on screen transitions would be very irritating.

Post Reply