https://www.copetti.org/writings/consoles/game-boy/
https://gbdev.io/pandocs/Specifications.html
The model above should be very versatile in interfacing in both the software version (mock version) of the emulator, and the actual hardware on the STM32.
I am thinking of a pub-sub model here, maybe each master—slave connection can have a callback so everything can be generalized, and then each module may implement/register their own addresses, and implement a callback function to service their reads and writes.
Maybe something like:
// Still need to play around in C a bit :P
// some_component.h
struct RWInterface
- addrs
- fn ptrs for read
- fn ptrs for write
// and have the bus being an array of RW Interfaces
// bus could also implement a RW interface too actually!, and have CPU call
// the RW interface!.
// In a nutshell, the master keeps the code around
This could actually be a very flexible framework to work with, as I can easily add components later, and unit test each components.
However, this might not really work with DMA (if I decided to implement it), as DMA requires more than one master to do this, while everything here is more CPU centric…
KM: The CPU interfaces directly with the bus, and is controlled by the main emulator program loop. It’s main interface to the emulator is through these functions
/* Called during emulation initialization phase */
void cpu_init();
/*
Called during emulation loop, represents the CPU reading
one INSTRUCTION (note that this differs from 1 word (1 byte), as
instructions could be consisting of multiple bytes
*/
void cpu_step();
In addition, the CPU also has an internal state to keep track of the registers, number of cycles elapsed, stack pointer, program counter, and interrupt flags.
https://gbdev.io/pandocs/CPU_Registers_and_Flags.html
TLDR; AF is a special register, being the accumulator and the flag register respectively, and the others are just general purpose registers