Initially I was using a fairly-well-known PDF which explained the gameboy hardware with 90% accuracy, and focussed on just getting the CPU working to a point where it could print “hello world” to the link cable port.
After that, I discovered that some people had written test ROMs - given only the most basic CPU instructions being implemented in a mostly-correct-ish way, these ROMs exercise the more exotic instructions, and edge-cases of the common instructions, and print out an error code if the emulated CPU gives results that differ from the physical CPU. (In this case the error code is just “this instruction is implemented wrong”, without saying what’s wrong about it - but with the gameboy having a fairly simple CPU where the vast majority of instructions map to a single statement in a high-level language, it’s good enough for most cases)
Third, I discovered https://gbdev.io/ which is an open source documentation project which has been bug-fixed and kept up to date and is generally much higher quality than the PDF I started from. Things would have gone much faster if I’d started here :)
In all cases the architecture of my emulator is very basic - no JIT, no worries about sub-CPU-cycle timing being accurate, etc[0]; just a loop which reads an instruction from memory, has a big `switch` statement to decide how to act upon that instruction, and then goes back to read the next instruction.
[0] I think the only place where I’ve allowed a bit of complexity in rather than sticking with the simplest implementation is the GPU - the simplest approach is to render all of the GPU memory to the screen once per frame; the slightly more accurate approach (which I do) is to render one row of pixels at a time (so that the CPU can tweak settings mid-frame to achieve parallax effects); the real hardware is quite a bit more complicated, but the medium-complexity approach works perfectly for nearly all the games I care about, and only has minor glitches for cases where it’s wrong.
After that, I discovered that some people had written test ROMs - given only the most basic CPU instructions being implemented in a mostly-correct-ish way, these ROMs exercise the more exotic instructions, and edge-cases of the common instructions, and print out an error code if the emulated CPU gives results that differ from the physical CPU. (In this case the error code is just “this instruction is implemented wrong”, without saying what’s wrong about it - but with the gameboy having a fairly simple CPU where the vast majority of instructions map to a single statement in a high-level language, it’s good enough for most cases)
Third, I discovered https://gbdev.io/ which is an open source documentation project which has been bug-fixed and kept up to date and is generally much higher quality than the PDF I started from. Things would have gone much faster if I’d started here :)
In all cases the architecture of my emulator is very basic - no JIT, no worries about sub-CPU-cycle timing being accurate, etc[0]; just a loop which reads an instruction from memory, has a big `switch` statement to decide how to act upon that instruction, and then goes back to read the next instruction.
[0] I think the only place where I’ve allowed a bit of complexity in rather than sticking with the simplest implementation is the GPU - the simplest approach is to render all of the GPU memory to the screen once per frame; the slightly more accurate approach (which I do) is to render one row of pixels at a time (so that the CPU can tweak settings mid-frame to achieve parallax effects); the real hardware is quite a bit more complicated, but the medium-complexity approach works perfectly for nearly all the games I care about, and only has minor glitches for cases where it’s wrong.