pandocs VS metroboy

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.

He wrote a game engine, it renders transparent items using the painter's algorithm, which requires the items to be sorted in Z. He has a routine that iterates over all items to render them, and bubble-sorts the items in-place while iterating over the items (all in the same thread). The "compare and swap" in this case is the innermost functionality of bubblesort.

I assume the author is https://github.com/aappleby but I don't see any obvious candidate for this code. Maybe this? https://github.com/aappleby/metroboy but I can't see why a gate-level emulator woudl need to render transparent items using painter's algorithm.

If you want to go deeper, you can look at the reverse engineered schematic of most of the stuff except the CPU core in the DMG-CPU-Inside project. You could also consult the MetroBoy project, which builds on the previous project and aims to be accurate pretty much down to the logic gate level.

Well then, here's the ground truth - https://github.com/aappleby/MetroBoy/blob/master/src/GateBoyLib/GateBoyPixPipe.cpp

First I would try to deduce the timing from this gate-level simulation of the game boy, but the master branch was broken at the time, so I didn't manage to compile it. So, I tried deducing it from its underling reverse engineered schematics, but it would take too much time, if it even was possible.

You might find my hobby project interesting - https://github.com/aappleby/MetroBoy

Did you know the original Game Boy has non-deterministic behavior? Due to some strangeness in the integrated circuit that provides the CPU and some related parts (the SoC (system on a chip)), the same ROM may behave differently at different times when you'd think it should not. GateBoy is an attempt to make a perfect gate-level emulator for the Game Boy. Its README says:

Reminds me of GateBoy, which was posted a while back: https://news.ycombinator.com/item?id=28396927, https://github.com/aappleby/MetroBoy

GateBoy runs surprisingly fast for a gate-level simulation.