pandocs VS gb-test-roms

Use https://gbdev.io/pandocs/ , https://gbdev.io/gb-opcodes/optables/ and https://github.com/gbdev/awesome-gbdev to get started.

Probably the most important one (the one I've used the most for reference) was the Game Boy Pandocs.

Based on my reading of https://gbdev.io/pandocs/

The pandocs are probably the most up to date documentation about the GameBoy in existence. It's a console which is still under active research - these days it's very focused on the extremely low level hardware behaviour.

The Pandocs are easy to read and contain pretty much everything you need to know to get a basic GB emulator up-and-running. The section on the Power-Up Sequence would answer this question for you and then some. You would've gotten the answer to your question yesterday if you looked at the Memory Map section, which tells you where ROM is mapped, and then some.

Does anyone know of good documentation beyond: - Pan Docs - The Cycle-Accurate Game Boy Docs - Complete Technical Reference - Nitty Gritty Gameboy Cycle Timing

For actual documentation, you probably know the pandocs, but there are a lot of more specific information in the docs linked in their references, especially the cycle-accurate GB docs, the GB complete technical reference by Gekkio. You can also check the source code of the relevant test roms, like the Blargg’s test roms for more general behaviour and the MooneyeGB test suite for more specific things.

For the Game Boy, being a closed system, there's fewer resources. Nintendo made a programming manual, but it's not very good. Pandocs is a good supplement: https://gbdev.io/pandocs/

Very cool article!

If you want to know more about the hardware side of the Game Boy (Color), have a look at the Pan Docs: https://gbdev.io/pandocs/

It's been revamped in the recent years, in terms of presentation. I do kind of miss the old version which had a refreshing "old-school" UI like the RFCs of the IETF, but the newest version is IMHO much more usable when developing an emulator.

Make sure you incorporate testing your implementation with test roms: https://github.com/retrio/gb-test-roms Do this as early in the project as possible. This will save you a huge migraine later on.

Have you tested your emulator against blargg's instruction timing test ROM? I believe this one only checks cycle counts, not memory timings: https://github.com/retrio/gb-test-roms/tree/master/instr_timing

Yeah the source for cpu_instrs is in github. https://github.com/retrio/gb-test-roms/tree/master/cpu_instrs/source

I actually have a question about this. I've been building a Gameboy emulator, the CPU works but when it runs the RET instruction the PC jumps to some really high address like 0x2000 or something when it's meant to jump to somewhere around 0x400 instead (after comparing it with another GB emulator). I think the RET address is meant to be read from HRAM, where the stack is stored, but when I look there it is the value around 0x2000 like I mentioned earlier. Are there any special quirks with this section of memory that I might not have implemented? I'm pretty much just reading and writing from an array for HRAM at the moment. I'm having the issue on one of blarggs cpu-instrs test roms https://github.com/retrio/gb-test-roms/blob/master/cpu_instrs/cpu_instrs.gb

So just start with implementing the CPU's fetch/decode/execute loop and a rudimentary memory bus, so that you can run simple test ROMs. You don't even need a display for many test ROMs (like Blargg's well-known test suite, which writes the results to the serial port as well as the display). After that you can do test-driven development (in a way) and focus on making more and more tests pass. Don't worry about details until you need to.

It looks like the test enables interrupts and then invokes the timer interrupt.