DMG-CPU-Inside VS gameroy

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.

There's an ongoing project like this for the Gameboy that aims to build a logic block level description of the CPU and peripherals. There's also an emulator that's in very early stages (not sure if it's working at all yet). There's another edge accurate GB emulator which I don't believe is released yet, but should be work in progress.

The furthest I've seen publicly is the original Playstation ASICs. http://psxdev.ru/ [Russian Language]

Similar in time to the playstation ASICs (and similar design in sort of a soup of standard cells on a CMOS process), but at a gate count similar to Ken's fantastic work here on the 8086 is the work reversing the Gameboy SoC: https://github.com/furrtek/DMG-CPU-Inside

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.

I recently found https://github.com/Rodrigodd/gameroy to be a very complete implementation

Hey there! I've been working on a Game Boy emulator since last year and found the GameRoy project, which translated the PPU's logic from SameBoy, the (AFAIK) most accurate GB emulator around. I basically copied the PPU logic into my emulator and replaced the "state" property (an integer) with enums for some extra clarity.

https://github.com/nicolas-siplis/feboy

https://github.com/rodrigodd/gameroy

https://github.com/LIJI32/SameBoy/

What I did was isolate the logic of every component apart from the CPU (video, sound, timer, etc.) behind a correspondent fn update(cycle_count: u64) method (like in the sound controller or in the timer). Currently, I am calling these methods every 4 cycles, but the idea is that I would only need to call it before a read or write to a component register, or before a possible interrupt (I would need to figure out if it is possible to efficiently predict the next interrupt).