It is currently Mon Jun 17, 2019 9:56 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 18 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Tue Sep 04, 2018 3:19 pm 
Offline

Joined: Tue Sep 04, 2018 3:15 pm
Posts: 2
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.


Top
 Profile  
 
PostPosted: Tue Sep 04, 2018 3:51 pm 
Offline

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

_________________
Pin Eight | Twitter | GitHub | Patreon


Top
 Profile  
 
PostPosted: Tue Sep 04, 2018 4:04 pm 
Offline

Joined: Tue Sep 04, 2018 3:15 pm
Posts: 2
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?


Top
 Profile  
 
PostPosted: Sun Jan 13, 2019 8:19 am 
Offline

Joined: Wed Jan 03, 2018 3:50 pm
Posts: 18
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.


Top
 Profile  
 
PostPosted: Mon Jan 14, 2019 1:56 am 
Offline
User avatar

Joined: Fri Jan 04, 2019 5:31 pm
Posts: 35
Location: France, right of a pile of consoles
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


Top
 Profile  
 
PostPosted: Mon Jan 14, 2019 9:20 pm 
Offline

Joined: Wed Jan 03, 2018 3:50 pm
Posts: 18
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?


Top
 Profile  
 
PostPosted: Mon Jan 14, 2019 9:29 pm 
Offline

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

_________________
Pin Eight | Twitter | GitHub | Patreon


Top
 Profile  
 
PostPosted: Mon Jan 14, 2019 11:39 pm 
Offline
User avatar

Joined: Fri Jan 04, 2019 5:31 pm
Posts: 35
Location: France, right of a pile of consoles
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


Top
 Profile  
 
PostPosted: Wed Jan 16, 2019 9:09 pm 
Offline

Joined: Wed Jan 03, 2018 3:50 pm
Posts: 18
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?


Top
 Profile  
 
PostPosted: Thu Jan 17, 2019 1:05 am 
Offline
User avatar

Joined: Fri Jan 04, 2019 5:31 pm
Posts: 35
Location: France, right of a pile of consoles
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


Top
 Profile  
 
PostPosted: Thu Jan 17, 2019 5:53 am 
Offline

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

_________________
Pin Eight | Twitter | GitHub | Patreon


Top
 Profile  
 
PostPosted: Thu Jan 17, 2019 9:49 am 
Offline
User avatar

Joined: Fri Jan 04, 2019 5:31 pm
Posts: 35
Location: France, right of a pile of consoles
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


Top
 Profile  
 
PostPosted: Thu Jan 17, 2019 1:59 pm 
Offline

Joined: Wed Jan 03, 2018 3:50 pm
Posts: 18
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.


Top
 Profile  
 
PostPosted: Thu Jan 17, 2019 2:55 pm 
Offline

Joined: Sun Mar 27, 2011 10:49 am
Posts: 271
Location: Seattle
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.


Top
 Profile  
 
PostPosted: Thu Jan 17, 2019 11:51 pm 
Offline
User avatar

Joined: Fri Jan 04, 2019 5:31 pm
Posts: 35
Location: France, right of a pile of consoles
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:
    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


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 18 posts ]  Go to page 1, 2  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 1 guest


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