Devlog 8 - Organisation, and timing, again

Ok, so this didn’t exactly go how I wanted (again), but most of this devlog time was spent fixing the past devlog, and organising code in a better way
Firstly: I realised that before, my timing code checked based on M-cycles, rather than T-cycles. There’s a specific reason for the distinction, but for now all you need to know is that there’s 4 T-cycles in an M-cycle, so my code was targeting a 4x faster speed. I changed this to be correct, but changed it again later so it doesn’t really matter.
Then, I cleaned up a lot of cpu.c, changing functions to return values directly rather than using a local variable first, pre-calculating some variables, et cetera. This was an attempt to speed up the CPU, as I was having a bit of trouble meeting the target speed with debug builds (mentioned in devlog 7), but again, this was a bit pointless because I changed the way the timing worked later. While doing this, I also replaced all of the numerical types with their stdint.h counterparts; for example, an unsigned char became a Uint8 (SDL has macros for the stdint types, so they have a slight naming difference from standard C in my code). This was mainly done for specificity and some Hail Mary for performance (although fruitless), and should make the code at least a bit more portable and easy to maintain.
I also implemented a couple of new instructions; RST and SWAP. RST effectively calls from a set of pre-specified addresses , and SWAP just swaps the upper and lower 8 bits in a byte, so these weren’t too hard. I also had to fix some bugs with the flags register´s value after an SBC A instruction, which admittedly did take me a while to fix because I basically banged my head against the wall to fix it.
The main change in this devlog was switching the timing system (again). Previously, the CPU ran one instruction for each loop of the SDL_AppIterate function. After reading the documentation and realising that this function is supposed to run each frame, I realised that I was causing all of my speed issues by only doing one cycle per iteration. Instead, the code now does as many instructions as it can until it has run enough T-cycles for a full frame to render (70224). It then renders (to be implemented), and moves on to the next iteration. This is way more performant, and has the added benefit of being more cross-platform, as SDL specifies that sometimes AppIterate may only run at the refresh rate on some devices. Tbh, this took me a while, maybe too long, to conceptualise and implement, and basically made all of the time on the other timing system wasted, but in the end it was worth it for a much better system. You can see the uncapped FPS (in a debug build mind you) here, although when actually playing games, the framerate will be locked to around 60 FPS.
Finally, there was a few more miscellaneous changes: copying a ROM file into memory uses memcpy instead of a loop, which may or may not be faster; memory is now a union of smaller arrays of memory banks, for each function, such as work ram (WRAM), high ram (HRAM), ROM banks 0-n and etc; and lastly, some register code has been moved out of cpu.c for organisation.