It is currently Fri Sep 21, 2018 10:46 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 3 posts ] 
Author Message
PostPosted: Thu Jul 19, 2018 8:49 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20562
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
PostPosted: Thu Jul 19, 2018 11:37 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7537
Location: Seattle
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.


Top
 Profile  
 
PostPosted: Thu Jul 19, 2018 11:45 am 
Online

Joined: Sun Mar 27, 2011 10:49 am
Posts: 265
Location: Seattle
A brief audible pop on screen transitions would be very irritating.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 3 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group