Game Boy LCD Rending Diagram

[zeroone]

Is a Game Boy LCD rendering diagram available that is analogous to the NES / Famicom PPU Rendering Diagram?

Since an LCD doesn't contain a moving ray like a CRT, I assume the horizontal and vertical blanking times are artificially introduced by the Game Boy video circuitry. And, there are interrupts associated with these events. That being the case, do Game Boy emulators simply generate one full scanline at a time between triggering HBlank interrupts? Or, for accurate raster effects, do Game Boy emulators handle individual pixel timing, like NES / Famicom emulators?

Also, since there is no ray, are the LCD pixels updated at a consistent rate like a CRT? Or, does the Game Boy video circuitry update pixels in bursts?

[mikejmoffitt]

The game boy's video output takes a certain number of cycles per line. Depending on whether or not the short pixel buffer going to the display has to be flushed and restarted, the dot clock will be halted until this is complete, which in turn reduces the length of h-blank to compensate. Ultimately the line length is the same, just with gaps in it.

This presentation covers your questions thoroughly I hope: https://www.youtube.com/watch?v=HyzD8pNlpwI

[tepples]

"Nitty Gritty Game Boy Cycle Timing" by Kevin Horton

Yes, the Game Boy's PPU pauses at times when clocking pixels into each scanline. It pauses when loading each sprite's pattern, at the start when skipping pixels for fine scroll, and when switching from the main plane to the window plane.

[zeroone]

@mikejmoffitt Thanks for the YouTube link. I'll watch through that presentation when I get a chance.

@tepples Thanks for the doc.

Do any Game Boy games use exact pixel timing (as opposed to complete scanline timing) to generate graphical effects, as is occasionally seen in NES games? Kevin Horton's doc is marked as preliminary, suggesting that current emulators might not be using all of the rendering details.

[tepples]

The demoscene-inspired title screen of Prehistorik Man uses timed code to lighten or darken the palette, but that's probably it. Otherwise, timed code is not as necessary because the Game Boy PPU has a built-in scanline counter and hblank status register.

[zeroone]

The demoscene-inspired title screen of Prehistorik Man uses timed code to lighten or darken the palette, but that's probably it. Otherwise, timed code is not as necessary because the Game Boy PPU has a built-in scanline counter and hblank status register.

That's really impressive for the GB. I wonder if that homebrew will work correctly on the Super Game Boy or Color Game Boy, if there are any pixel timing differences that is.

[tepples]

SGB should be cycle-identical to Game Boy because it works by collecting pixels into a frame buffer that it sends to the Control Deck. GBC I don't know because I don't own a copy of that game.

[zeroone]

I read more about the difficulty in getting games like Prehistorik Man to work. Unfortunately, the emulator authors that understand the functionality of the Game Boy PPU are not documenting and sharing the info, limiting the ability of others to develop highly accurate emulators. We need a site like nesdev for the GB with people interested and able to do the research.

[zeroone]

@mikejmoffitt That video is brilliant.

@tepples After watching the video, that doc makes much more sense.

I may have to mess this with after all. Thanks guys. Hopefully, someone will combine this info into a great wiki one day.

[tepples]

We need a site like nesdev for the GB with people interested and able to do the research.

Something like GbdevWiki and awesome-gbdev?

[ISSOtm]

Actually, eevee made such a diagram.

(I know, I'm late.)

As for the GBDev Wiki, it's rather sad that it's not up to the same quality as the corresponding NES wiki, partially as it's based on the lackluster and sometimes incorrect Pan Docs.

[tepples]

The NES wiki was likewise initially derived from some non-ideal* docs. The mappers were largely Disch's, the PPU was something I wrote for Everything2 back in 2001 or so, etc. It took a lot of work over years to bring it to the state it's in right now. I guess GbdevWiki just needs more smart people editing it in order to make it less bad.

The trick is figuring out where you're repeating yourself to every forum or Discord newcomer. If you can write your rehearsed response on the wiki instead, you'll be able to refer newbs to a wiki page to save time when answering a question.


* "Not ideal" is the word that Microsoft appears to use publicly for what others might more colloqually call "sucks" or a "hack". See Windows Forms pull request #144.

[ISSOtm]

That's basically what I'm trying to achieve with gb-asm-tutorial, though the presentation and purpose are different.
And the project is frozen while i'm working on something else, too.

(There's also a lot of information that's known by the community's members, but not written anywhere. Dunno if that's happened to NESDev too.)

[tepples]

(There's also a lot of information that's known by the community's members, but not written anywhere. Dunno if that's happened to NESDev too.)

I guess NESdev has the advantage that it's primarily a forum, not primarily a Discord or IRC server. Unlike messages on a Discord or IRC server, posts on a forum have a URL that a wiki page can cite as the source for a particular discovery or confirmation, and they are searchable by anonymous visitors. See "Why Slack is inappropriate for open source communications" by Dave Cheney.

As for forums: gbdev.gg8.se has no attachment feature for test ROMs or homebrew games. Before NESdev added attachments sometime in 2012, these had to be uploaded to a developer's personal site or a third-party file host, both of which had a good chance to go 404 a few years later. In theory, forum users could upload screenshots, photos, and the like to the wiki on that domain, but that wouldn't work quite as well for, say, a zipfile with a test ROM and source code. In fact, I confess a habit of (ab)using this very forum's Game Boy section as a file host for gbdev.gg8.se.