Devlog 9 - Basic graphics (finally)

I’ve finally gotten some basic picture processing unit (PPU) functionality implemented into the emulator, which will hopefully make debugging a lot easier going forward.
Firstly, to implement this, I had to move the timing logic out of cpu.c and into cycles.c. This was so that, when the loop calls a CPU step, it also calls a PPU step at the same time. I also refactored some of the cycle functions and removed the ones that were no longer being used
Then, I implemented the timing code for the PPU. This part and the actual rendering were mostly based on this tutorial series that shows you how to make a GB emulator in javascript, which I based my C code on. Basically, the PPU runs on the clock as the CPU, and a ‘dot’ on the PPU is equal to a T-cycle on the CPU. The PPU renders progressively, like a CRT television, and so also has modes to move the nonexistent electron beam down and back to the start of a scanline before it continutes rendering, known as VBLANK and HBLANK, (vertical and horizontal blank). The Pan Docs were also quite helpful for understanding the basic functionality, although the tutorial was useful to understand the programmatic side. The PPU also has 2 other modes, used for scanning the Object Attribute Memory (OAM) and actually drawing, and all 4 modes have a precise amount of dots that they run for.
In terms of actual rendering, the Gameboy doesn’t have a full framebuffer, and instead uses different tiles to create a full image. I implemented a function that, when the CPU writes to VRAM, also updates the data in a separate tileset variables, for easier access in the render pipeline. Each tile is 16 bytes, with 2 bits per pixel colour depth, and 8 x 8 pixels per tile. As the Gameboy renders progressively, I then implemented the function to draw a scanline to the screen, based on the tile data in the background layer. The afformentioned tutorial series helped a lot here, as the tiles need to have a specific offset and mapping applied which would be quite hard to figure out on my own.
Then, that function calls a draw pixel function for each each of the 160 pixels in a scanline, which writes the corresponding colour from the palette to an SDL_Surface as the framebuffer. Once the frame is finished, the surface is converted into a texture, which is then scaled to fit the screen size and rendered, with another frame being made afterwards. Below you can see the screen of the previously mentioned blargg’s test ROM 7.