* The DMA routine on the IOP works similarly to the PSX version with a
few additions. There are 7 channels from the PSX and an additional 6 new
PS2 exclusive ones. One the PSX, each channel has 3 registers used
to configure and use it and 3 global registers.

* The PS2 contains all the older DMA registers, but it add 6 more channels
and duplicates the global registers (DPCR now has a counterpart called DPCR2)
This is done because each global register can control up to 7 channels.
An additional register on each channel (tadr) and 2 additional
global registers have been added as well. For now we don't really
care to implement them, only read/write to them.

* For reading and writing to the registers structs are used to prevent
the usage of switch and if statements.

* Nothing to really say here, just looks better imo

* So after a week, it's finally here! The initial implementation of the
IOP has been added to the emulator. You might wonder why did it take so
long? This was mostly because I wanted to make the implementation as complete
as possible and also test it to ensure it's bug free. So this is actually
based on the MIPS R3000A interpreter I wrote last year for my PS1 emulator.
So did I just copy the code and call it a day? Hell no, the code in that
ancient project is awful, even if it works. So I completely rewrote the
interpreter by using our modern techiniques of storing state. So rewriting the old
code allowed me to test if it actually worked in that environment
and could boot PSX games.

* Due to this, the implementation is a bit more complete than the EE
as it includes interrupt support. In addition we have to account for
the fact that the IOP runs at 36.864MHz, in constrast to the EE which
clocks at 295MHz. This maps approximatly to an 1/8 ratio, which means
that 1 IOP instruction will run every 8 EE cycles. The current implementation
of this is hacky and a bit inaccurate because some EE instructions
can take more than 1 cycle to execute, but it's good enough for now
(Play! assumes this as well and can boot 40%+ of games).

* Because both the CPU emulators can share a lot of naming conventions,
to avoid confusion each processor has been seperated into a namespace
so we can always know which CPU we are refering to. Finally, for now
reads/writes except for the BIOS and IOP RAM, haven't been implemented
but will come soon.

* Currently the BIOS only writes to scratchpad and some very few mysterious
addresses that don't seem to do anything. However it is important to know
when it will try to write to DMAC for example so we can implement it. So
instead of writing anything and uncontrollably into a single large buffer
let's make an if-else with all the known addresses and how to handle them.
When the BIOS tries to write somewhere new we will be notified immediately.

* Also rework the disassembly logger to use C FILE* since these are faster
then std::ofstream. Normally I wouldn't care about this but in our usecase
which is very performance sensitive, it makes a noticeable difference.

* The BIOS tries to write to 0x1000f430/0x1000f440 which contain the
registers MCH_RICM/MCH_DRD. Saldy these registers are quite undocumented.
So the writing logic has been taken from PCSX2:
https://github.com/PCSX2/pcsx2/blob/master/pcsx2/HwWrite.cpp#L237
Forgive me, for I have sinned.

* Having the header files in a seperate dir is only useful when developing
libraries that are meant to be used by other programs. In our case though
it makes the file structure more tedious so gather everything in one place.

* Currently the BIOS tries to write something to scratchpad and it fails
because its address is not our currently supported range. So add a new buffer
for the 16KB scratchpad used by the CPU and add a function to use it if the
address is in the correct range.

* Also shorten some function names and change some array to C-style because we
like to work with pointers and STL doesn't like that.

* Now that the BIOS is loaded we can start executing it!
The starting address the EE uses is 0xbfc00000 which maps
to KUSEG1. Since all KUSEG regions except KUSEG2 are mirrors
of each other we only need to translate the address to the
KUSEG appropriate.

* The functional differences between KUSEG0/1 are minimal and
very niche so I won't bother emulating them now. Address wise
we can notice that the only difference between addresses is the
most significant half byte. By using that byte as an index in
a mask table we can define an appropriate mask for each KUSEG
address. Idea taken from a very handy PSX document I discovered
last year [1]

[1] https://svkt.org/~simias/guide.pdf (43)

* The ps2tek documentation states the memory map clearly [1].
It seems to have a similar architecture with the PSX, where
the main memory map (KUSEG0) is mirrored in multiple regions
(KUSEG1/KUSEG2) with different access patterns for each region.
For now we don't have to emulate all of them, just the main
memory map.

* Allocate the entire 512MB memory into an array and make a convenient
struct to abstract memory range operations.

[1] https://psi-rockin.github.io/ps2tek/#memorymap

* This commit adds a most basic CPU class that acts as a template
which we will slowly build.

* The architecture is pretty simple; the ComponentManager will create all
the seperate components (EE, VP, IOP, GS etc) as unique_ptr's since
it owns them and only it has access to them. All the other components
must pass through the manager to read/write data to memory.
To achieve this they are given a pointer to the ComponentManger in their constructor.

* For now the CPU directly accesses the bios which shouldn't
happen but will be fixed eventually when I implement generic
read/writes. The goal is to start implementing the CPU as fast as
possible in order to get to the GPU/VPU's and display something!