I have Stupid questions about the vblank signal off the DMG's lcd

[spaceharrier]

I am working on a mechanism to capture the lcd data signals from a DMG-01 and drive it through a tmds serializer.

I realize this has been done before, but I am challenging myself to get something that synchronizes the HDMI output with the gameboy at the same frequency to prevent tearing.

By luck, I am able to obtain an oscillator that is a multiple of the 2^22 MHZ frequency supplied by the Gameboy, and I would like to use the actual vblank signal coming off of the gameboy itself as part of my synchronizer, which I think is possible, with acceptable jitter, for most modern monitors to capture.

If the vblank is disabled in the gameboy's LCD Status register, or the display is completely disabled in the gameboy's LCD Control register, does this stop the vertical blank signal to the LCD, or does it simply disable interrupt routing from the ppu to the cpu?

[lidnariq]

If the vblank is disabled in the gameboy's LCD Status register, or the display is completely disabled in the gameboy's LCD Control register, does this stop the vertical blank signal to the LCD, or does it simply disable interrupt routing from the ppu to the cpu?

Everything stops.

When you restart, it begins at the scanline just below the one where the vsync signal is asserted.

There's basically no way to handle this without tearing, variable latency, or a monitor that supports Freesync or GSync

[tepples]

I agree that FreeSync aka VESA Adaptive Sync is probably the least bad way to accommodate this timing quirk of the Game Boy LCD. Then as a fallback for monitors without FreeSync, you could implement a full frame buffer and display "For less lag, use a FreeSync monitor" on the upscaler's OSD during the boot ROM.

[spaceharrier]

At just $3700 to upgrade my copy of Quartus from "Poor People Edition" to one with an adaptive sync core, this might not be easily doable.

Someone did make a FOSS implementation of HDMI 1.4b (not just DVI tmds) that might drive a display at 120 hz, which could reasonably work without tearing or rejecting locked frames (and ~8ms delay is not terrible) This requires a beefier FPGA, but the cost is nowhere near as bad as upgrading Quartus.

[lidnariq]

Can you do 640x480@120 instead? It's not like the DMG emits all that many pixels...

[spaceharrier]

Can you do 640x480@120 instead? It's not like the DMG emits all that many pixels...

My TFP410 board has the bandwidth for that. I don't know if that would work, but it would be a cheap solution if so. I'll run a test later.