Devlog 5 - Adding instructions, the stack and lots of debugging

After the last devlog, the first think I did was implement some more instructions, namely the jump instructions, and the increment and decrement functions. Luckily these were pretty simple; all the jumps do are set the program counter (effectively the next instruction) to a specified value, and the increment and decrement are pretty self explanatory, increasing or decreasing a register or memory byte by 1;
After this, I started implementing the stack. The stack is a section of memory that is ordered, with values being written to it (pushed) and read off of it (popped). You must read the “top” value, meaning the most recently pushed, which is then removed and the next highest is the next available to read. This wasn’t too hard, although I did have to introduce a new register, the stack pointer (sp). While I was at it, I also implemented load functions, which load data into a specified memory byte or register.
After realising it would cause issues down the line, I walked back my previous decision to make the flags register a struct of booleans, and instead made it a single byte with 4 bits representing the 4 flags, making it more accurate. I also made some functions to easily set or reset each flag, rather than use bitwise operations everywhere.
Finally, I implemented logging support, so that I could use Gameboy Doctor, a brilliant debugging script that reads a log file from your emulator with a known ROM, and compares it to the correct result. All you have to do is write a line to a log file with all the register values and some memory bytes after each instruction, and it automatically tells you where the first error is, what register or piece of memory is wrong, and even the last instruction to give you a hint as to the problem. This didn’t take much time to implement, but I did spend a considerable amount of time debugging, as previously I hadn’t actually got a way to check that my functions worked correctly (which is why this devlog has quite a few more hours on it). You can see an example of a error in the screenshot; I intentionally changed the SUB instruction to add instead because I forgot to take screenshots of the actual errors 🥀.
Next time, I want to implement more of the CPU, especially more complex behaviours like halting and interrupts, and also implement some of the graphics, so that the games can actually be seen visually.