It’s been 3 months since my last entry, and unfortunately not much has gotten done in the background. Life kind of got in the way with getting a new job, moving, adjusting to a new routine etc. Actually I never took the PC that has all my work as my new place doesn’t have furniture, I left it back at my dad’s house. Finally came back for it and will start plugging away again.
I did accomplish a few things in between the last devlog entry. I was able to figure out the xa manager and have the assembly documented in ghidra with notes and labels. Unfortunately there will be no log about it as I honestly forgot how I went about it and I’m not going to restate the behavior of the function in a blog format. While the site was already updated to reflect this, I had cleaned up the function documentation a bit and got most of the cd request pipeline documented in the architecture section.
Just today I finished up the cd request pipeline write up and figured out the starting structure for the architecture section. I feel like instead of taking a top down approach from main and trying to describe how different systems work together, with how many gaps there are, it will be easier to go bottom up and describe individual systems in isolation. Once I fully understand each system in isolation it will be easier to map out what each one requests from another and what services it provides.
I settled on this structure because as I was thinking of where to write about initialization (the context, not the hardware) and describe how not all CD requests flow through the pipeline I came to realize the CD library provides different kinds of functionality and can be divided into subsections or subsystems.
For example I identified three sub systems in the CD Library: the request pipeline, the asset loading system, and a final one that handles minigame execution and game restoration and to top it off these don’t enforce strict encapsulation because while these systems provide a standardized way to accomplish tasks, I’ve noticed some overlays and part of the main executable have specific needs that require them to manage the IO process themselves while still using the same cd context and state tracking. So before I can really talk about the functionality of the CD library as a whole I need to figure out how these subsystem work and fit together. From there I can build a global view of the CD library which would in turn make it easier to talk about how a piece of the game engine uses the CD library.
Next up is the function level documentation and architectural write up of the asset loading system.