The program images contain processor modules, executable overlays or regions copied into memory at runtime, filesystems and embedded resources. Addresses used during execution differ from positions in the stored file. The original-ROM guide explains extraction and decoding so that instructions can be located in the correct build and module. [1]
From startup to a frame
At startup, Studio allocates shared data and registers the components that manage scenes. Each frame, it samples input, calls the active handlers, updates child objects and displays the result. A change of scene can take more than one frame. A reconstruction needs to preserve this order, regardless of the names chosen for its functions. [2]
The architecture notes and function tables help locate the original code; they are not Nintendo's recovered source tree. If the function or object supplying a value is still unknown, the guide says which part has not been identified. [1][2][3]
Stored image and loaded program
The DSiWare container has executable regions and a NitroFS index. Its header also names autoload and module-parameter structures. Some bytes must be decoded or copied before they correspond to the instructions a running DSi executes. The original research records stored Modcrypt ranges and the mapping from stored offsets to virtual addresses; copying a ROM offset into a disassembler as an ARM9 address will land in the wrong place. [1]
The main loop
Startup allocates the application objects and enters the main loop. Each pass processes input, runs scene and controller work, advances transitions and updates the display. A scene can register callbacks and store state for a later frame, so the visible effect of a button press may not occur in the same function that receives the press. [2]
Main application components
| Area | Handles | Useful trace point |
|---|---|---|
| Application selector | Current screen or mode | Transition request and commit |
| UI tree | Elements and callbacks | Input edge and hit test |
| Editor document | Frames and sound state | Modification and save |
| Online request handler | Transport and result state | Start, poll and close |
| Presentation path | Screen image and sound output | Decode and upload |
These group names come from the research; they are not Nintendo's original module names. The function atlas shows which function groups have been located across builds and which have not yet been traced. [1][2][3]
Startup addresses in the four builds
Every studied Studio ARM9 image begins at 02004800. Its first 0x180 bytes agree across the four images before the instructions diverge. The common startup handles interrupt state, processor control, stack setup, static-image expansion, autoloads and BSS clearing; later application constructors are not therefore identical. The static constructor tables contain 36 entries in JP V1, 47 in JP V2 and US V2, and 48 in EU V2. Their application transfer points are 020050D0, 020050F4, 02005108 and 02005108 respectively. These are loaded ARM9 addresses. [2]
What a normal loop pass reaches
One traced loop samples keys, aggregates touch, runs a registered callback, advances queued work, updates managers, drains an interrupt-protected list, paces the frame and moves display state. The key sampler reads KEYINPUT at 04000130 plus an extended halfword, then resolves opposite directions so Down cannot remain pressed with Up and Right cannot remain pressed with Left. Touch coordinates are accepted below x=256 and y=192. V2 pacing checks display scanline 192 or exits after a limited number of retries. The loop's full scheduling policy remains open. [2]
Temporary memory and callbacks
The NTR application initialiser creates a 0xC0000-byte expanded arena. JP V1 stores its pointer at application offset +0x2C; V2 stores it at +4. The presentation heap contains a separate 256-byte temporary child arena. After a pending callback is invoked, that child arena is reset. The pending callback field is +0xB4 in JP V1 and +0x1574 in V2. This arena accounts for one group of temporary allocations. Other editor objects can have different lifetimes. [2]
For the selector callback, the original code accepts unsigned values 0 through 8 but has mapped branches only for 0, 1, 4 and 6. The transition handler can process the previous state and then the requested state; callbacks may be cleared and reinstalled between them. A single address or screenshot cannot identify all of the objects involved. The function atlas lists the function addresses for each region. [2][3]