DS game only The DS doesn't have a lot of RAM. The ROM does have a lot of code. The way DS games bridge that gap is the overlay system: chunks of code that get swapped in and out of a shared RAM slot as the player moves between game modes. Tongari has 180 overlays plus a main ARM9 binary. Each overlay handles one screen or one feature.
ARM9 binary
The main game executable β 723 KB of persistent engine code that stays resident from boot. Asset loading, input, sound, dialog parsing, save data, and every shared service the overlays depend on.
The overlay system
180 overlays, shared RAM slots, controller-and-body pattern. Why ov137 is loaded almost always and ov003 only when you're at a shop.
Overlay knowledgebase
The plain-English "what's an overlay" explainer. How they load, why their edits are delicate, and how the compression wrappers fit in.
Per-overlay catalog
One descriptive page per overlay: what it does at runtime, the containers it references, the strings baked into its binary, the function table Ghidra found.
The content cache
The asset loader. Every screen calls the same function to bring its art into memory, indexed by a path string and a sub-index.
From code to pixels
How a sprite gets from a loaded asset into the OAM hardware buffer, and why every sprite update is synchronized to the vertical blank.
Memory map
What's at each address range in main RAM. Where the engine lives, where overlays land, where the game state struct sits.
NPC data system
Where NPC identities, personalities, and face textures live. Speaker ID ranges, the NpcDataOfs record layout, and the 140-face-to-252-NPC mapping.
Crafting and items
How the game stores crafted products, quality descriptions, recipe data, and the item icon pipeline. The UCC system, the 12-char buffer cap, and why one item name appears in five places.
The big picture
When you start a new dialog with an NPC, here's roughly what happens:
- The game state machine decides "we're in dialog now."
- The current controller overlay is unloaded, and the dialog controller is loaded into its slot.
- The dialog controller asks the content cache to load the right
message file from
data/message/. - It loads a body overlay that knows how to render dialog bubbles.
- The body overlay reads the dialog payload from cache, decodes the wire format, and builds an OAM list of sprite chips.
- At the next vertical blank, the OAM hardware copies the list from RAM into video memory and the dialog appears.
Almost every screen in the game follows that same pattern. The controller overlay handles "what's happening," the body overlay handles "what does it look like," and the rendering engine (ov137) handles "get it onto the screen."