How do GPU/PPU timings work on the Gameboy?
-
- Posts: 2
- Joined: Tue Sep 04, 2018 3:15 pm
How do GPU/PPU timings work on the Gameboy?
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.
Re: How do GPU/PPU timings work on the Gameboy?
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.
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.
-
- Posts: 2
- Joined: Tue Sep 04, 2018 3:15 pm
Re: How do GPU/PPU timings work on the Gameboy?
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?
Re: How do GPU/PPU timings work on the Gameboy?
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.
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.
- 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?
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.
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
https://github.com/ISSOtm
ASMu is laifu <3
Re: How do GPU/PPU timings work on the Gameboy?
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?
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?
Re: How do GPU/PPU timings work on the Gameboy?
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.
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.
- 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?
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.
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
https://github.com/ISSOtm
ASMu is laifu <3
Re: How do GPU/PPU timings work on the Gameboy?
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?
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?
- 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?
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 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
https://github.com/ISSOtm
ASMu is laifu <3
Re: How do GPU/PPU timings work on the Gameboy?
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.
- 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?
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
https://github.com/ISSOtm
ASMu is laifu <3
Re: How do GPU/PPU timings work on the Gameboy?
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.
-
- Posts: 271
- Joined: Sun Mar 27, 2011 10:49 am
- Location: Victoria, BC
Re: How do GPU/PPU timings work on the Gameboy?
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.
- 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?
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 displayand 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.
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
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
https://github.com/ISSOtm
ASMu is laifu <3