How do GPU/PPU timings work on the Gameboy?

Discussion of programming and development for the original Game Boy and Game Boy Color.
IntensifyingRug
Posts: 2
Joined: Tue Sep 04, 2018 3:15 pm

How do GPU/PPU timings work on the Gameboy?

Post by IntensifyingRug »

I’m writing a gameboy emulator and I’ve come to implementing the graphics. However I can’t quite figure out how it works with the cpu as far as timing/clock cycles go. Does the CPU execute a certain amount of cycles (if so how many) and then hand it of to the GPU? Or is the gameboy always in a hblank/vblank state and the GPU uses the CPU in between them? I can’t find any information that helps me with this. Nothing really explains how the GPU works, only that setting certain values changes certain things.
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: How do GPU/PPU timings work on the Gameboy?

Post by tepples »

The Game Boy CPU and PPU run in parallel. The 4.2 MHz master clock is also the dot clock. It's divided by 2 to form the PPU's 2.1 MHz memory access clock, and divided by 4 to form a multi-phase 1.05 MHz clock used by the CPU.

Each scanline is 456 dots (114 CPU cycles) long and consists of mode 2 (OAM search), mode 3 (active picture), and mode 0 (horizontal blanking). Mode 2 is 80 dots long (2 for each OAM entry), mode 3 is about 168 plus about 10 more for each sprite on a given line, and mode 0 is the rest. After 144 scanlines are drawn are 10 lines of mode 1 (vertical blanking), for a total of 154 lines or 70224 dots per screen. The CPU can't see VRAM (writes are ignored and reads are $FF) during mode 3, but it can during other modes. The CPU can't see OAM during modes 2 and 3, but it can during blanking modes (0 and 1).

To make the estimate for mode 3 more precise, see "Nitty Gritty Gameboy Cycle Timing" by Kevin Horton.
IntensifyingRug
Posts: 2
Joined: Tue Sep 04, 2018 3:15 pm

Re: How do GPU/PPU timings work on the Gameboy?

Post by IntensifyingRug »

So just to help clarify. The gpu switches modes and then while doing its own stuff, the CPU functions normally except for some limited read and write capabilities? Also for the point of emulators, should I execute the 2 GPU cycles and then a CPU cycle or vice-versa?
squall926
Posts: 35
Joined: Wed Jan 03, 2018 3:50 pm

Re: How do GPU/PPU timings work on the Gameboy?

Post by squall926 »

IntensifyingRug, did you win the chalenger?
I'm done one chip8 emu and started one GameBoy, finished the CPU and half mmu but stop on GPU, no have ideia how do this part.
User avatar
ISSOtm
Posts: 58
Joined: Fri Jan 04, 2019 5:31 pm
Location: France, right of a pile of consoles
Contact:

Re: How do GPU/PPU timings work on the Gameboy?

Post by ISSOtm »

I'm going to say what tepples just said, just differently. The CPU and PPU run completely indepedently, the PPU pushes pixels and cycles its own modes no matter what the CPU does; the only direct influence the CPU has on the PPU is turning it on and off via LCDC bit 7.

As for the PPU's modes, each of the 144 scanlines is divided into Mode 2 (OAM scan), followed by Mode 3 (rendering) where the PPU pushes pixels to the LCD at a rate of 1 per cycle of the 4MHz clock (with exceptions), and finally Mode 0 (HBlank) where the PPU does nothing.
Between scanlines 143 and 0 is VBlank, which consists of 10 "scanlines" in Mode 1, numbered 144 through 153. An interesting quirk is that LY starts reporting 0 in the middle of scanline 153.
The French Lord of Laziness (and a huge Legend of Zelda fan)
https://github.com/ISSOtm
ASMu is laifu <3
squall926
Posts: 35
Joined: Wed Jan 03, 2018 3:50 pm

Re: How do GPU/PPU timings work on the Gameboy?

Post by squall926 »

Hello!
I'm a layman in image processing, V-Blank, H-Blank, scanline, sprite, bg... never worked with this. but I found great sites explaining the operation of the GPU and Interruption, more and more I understand the operation better. looking now I have to implement the IO mapping in the MMU.
What is the minimum to see the logo on screen?
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: How do GPU/PPU timings work on the Gameboy?

Post by tepples »

You at least need to emulate the boot ROM at $0000-$00FF, which can read cartridge header at $0100-$014F (in fact the entirety of ROM space at $0100-$7FFF) and write VRAM at $8000-$9FFF. You will also need PPU ports (LCDC, SCY, BGP) and HRAM ($FF80-$FFFF). You don't need sprites, as the logo is background. And I don't think it touches WRAM ($C000-$DFFF) or OAM ($FE00-$FE9F) at all. The last thing the boot ROM does is disable itself, enabling the cartridge ROM at $0000-$00FF as well.

If you need a boot ROM to test with, you can extract one from SameBoy. It's not a perfect copy (only Nintendo has the right to distribute that) but it does most of the same things.
User avatar
ISSOtm
Posts: 58
Joined: Fri Jan 04, 2019 5:31 pm
Location: France, right of a pile of consoles
Contact:

Re: How do GPU/PPU timings work on the Gameboy?

Post by ISSOtm »

I wouldn't advise trying to emulate the boot ROM. It adds extra complexity, especially since the way the boot ROM is mapped to the address space varies depending on the model.

And there's also that the boot ROM is quite sloppily coded.
The French Lord of Laziness (and a huge Legend of Zelda fan)
https://github.com/ISSOtm
ASMu is laifu <3
squall926
Posts: 35
Joined: Wed Jan 03, 2018 3:50 pm

Re: How do GPU/PPU timings work on the Gameboy?

Post by squall926 »

I uses some ROM test and read on &FF02 byte writed on $FF01, always 0. And Program no finish. I believe got some inst nos work properlly, ill find.
About dissassembler i see an Lot emulador that put Full code dissassemble on a list. Me debug Just print opcode in execution and result.
The ideia ia read ALL ROM so fast execult and put on list? Back and run normally?
User avatar
ISSOtm
Posts: 58
Joined: Fri Jan 04, 2019 5:31 pm
Location: France, right of a pile of consoles
Contact:

Re: How do GPU/PPU timings work on the Gameboy?

Post by ISSOtm »

Sorry, but I don't understand what you meant.
The only thing I grasped was that you're manipulating $FF01 and FF02, which are related to serial. Which is completely irrelevant to this topic. So..??
The French Lord of Laziness (and a huge Legend of Zelda fan)
https://github.com/ISSOtm
ASMu is laifu <3
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: How do GPU/PPU timings work on the Gameboy?

Post by tepples »

Just a guess, but the issue might be that a particular test ROM expects working (or at least faked) serial in order to write out the result over serial.
User avatar
ISSOtm
Posts: 58
Joined: Fri Jan 04, 2019 5:31 pm
Location: France, right of a pile of consoles
Contact:

Re: How do GPU/PPU timings work on the Gameboy?

Post by ISSOtm »

That might make sense, as Blargg's ROMs write their output to serial
The French Lord of Laziness (and a huge Legend of Zelda fan)
https://github.com/ISSOtm
ASMu is laifu <3
squall926
Posts: 35
Joined: Wed Jan 03, 2018 3:50 pm

Re: How do GPU/PPU timings work on the Gameboy?

Post by squall926 »

Kkkkk, sorry for my terrible eng, I was referring to blargg's rom. and my question was about the dissassembler. all i see has an list of all the code already with values ​​how is this done. if I do a reset, the list goes back to $0100 and already has the other steps.
adam_smasher
Posts: 271
Joined: Sun Mar 27, 2011 10:49 am
Location: Victoria, BC

Re: How do GPU/PPU timings work on the Gameboy?

Post by adam_smasher »

The way an emulator implements its disassembler probably has nothing to do with how it executes code. Both no$gmb and bgb (the two most common debugging emulators) are closed-source so I can't speak with any certainty, but I would imagine both of them handle their disassembly displays entirely outside of the main emulation logic.
User avatar
ISSOtm
Posts: 58
Joined: Fri Jan 04, 2019 5:31 pm
Location: France, right of a pile of consoles
Contact:

Re: How do GPU/PPU timings work on the Gameboy?

Post by ISSOtm »

And indeed, they do. I know nothing about no$gmb; BGB begins its disassembling from the address at the top of the screen, and assumes everything is code.
Some known addresses are enforced as starting points, such as known entry points (vectors = rst + handlers), labels (if a SYM file is loaded) and (maybe? I'm unsure...) memory boundaries.
For example, if a label is inserted in the middle of a `ld a, $AF` instruction, BGB will display

Code: Select all

    db $3E
Label:
    xor a
and resume from there.
The disassembler itself is separate from the emulation core, however the debugger is somewhat tied to the core, since it must be able to break on certain events, etc.
The French Lord of Laziness (and a huge Legend of Zelda fan)
https://github.com/ISSOtm
ASMu is laifu <3
Post Reply