As a DSiWare application, Flipnote Studio uses the system's storage, input, display, audio and wireless services. The research follows its NAND and removable-media routines, buttons and stylus input, and interrupt handling. A resource name can suggest a feature, but the relevant code must be followed to confirm that it calls a hardware service. [1]
What hardware tests can confirm
Testing a function on a computer with simulated registers checks its behaviour under those test conditions. It does not reproduce a complete session on a DSi. ARM7 and ARM9 also handle different tasks, so check which module an address belongs to and whether the code was copied to a different location at runtime. [1][2]
For compatibility work, test the client action on hardware or a well-characterised emulator after checking the response and file bytes. Treat unexplained service results as open questions rather than silently assigning them to a feature. [1][2]
DSi context
The program header and service calls determine what the shipped DSiWare application may access. Storage, pen and key input, display, timer/interrupt handling, audio, wireless and camera appear in the studied program evidence. A reconstructed SDK-style name does not establish what happens on hardware. Check the original call and the code that invokes it. [1][2]
Storage
ROM resources, NAND/public save data and SD-card files use different path namespaces and validation rules. A file opened from SD may pass validation and path checks before it becomes a displayed Flipnote. A server response first passes through network and file-commit logic; it is not immediately equivalent to a local save file. [1]
Input and timing
Pen coordinates and button states are sampled, then interpreted as edges by the UI. Timers and interrupts support display and audio cadence. Reproducing a frame function in a host test can verify its arithmetic but not guarantee identical stylus sampling latency or audio output on hardware. [1][2]
Wireless and camera
The research identifies service references and selected callers. Many SDK internals remain unexamined: tests of a request-handling function, for example, do not cover the lower-level transport or a complete network session. The Japanese Viewer's Wi-Fi setup is documented as a separate program path. [1]