Investigate correlations between DS Download Play binary and release binaries

[UsernameFodder]

Existing information

(First pointed out by Discord user jacknet) Sky's NitroFS contains a runnable DS Download Play ROM at /SYSTEM/main.srl, which can run dungeons and has working debug menus, debug flags, and some other assertions and program trace logs that are either not included or stubbed out in the main game.

As is, it runs into crashes due to allocation failures, but (credit to irdkwia) this can be prevented with a simple patch that extends the memory arena used by the allocator from 0x180000 to 0x1A0000:

; Hook at 02000DBC with NO$ to change the instructions
:02000DBC mov  r3,#0x1A0000
:020010AC rsb  r3,r0,#0x1A0000
:020013B4 mov  r1,#0x1A0000

; Doesn't seem to be used, but may be related (set breakpoint in case it reaches this line; it didn't in my test)
:020018A8 rsb  r2,r8,#0x1A0000

When unpacked, main.srl contains only ARM9 and ARM7 binaries and no overlays. When decompressed (python3 -m ndspy.codeCompression decompress <path/to/arm9.bin>), it can be analyzed just like the release binaries. Looking at this binary might give some easy insights, given that it likely has debug code such as assertions and file names.

I wrote a script called arm5correlate.py that tries to map regions in main.srl's arm9.bin to release binaries, which could be useful for mapping known symbols in pmdsky-debug to the debug binary, and for mapping anything learned from the debug binary back to the release binaries.

Relevant addresses

These addresses are all for the NA version.

Stuff from the ROM header

• ARM9 RAM load address: 0x2000000
• ARM9 entrypoint: 0x2000850
• ARM7 RAM load address: 0x2380000
• ARM7 entrypoint: 0x2380000

Stuff from arm5correlate.py

The correlation script seems to show that the debug ROM shares large chunks of code with the release binaries, in particular ARM9, overlay 29, overlay 10, overlay 31, and maybe overlay 26. It seems likely that all the aforementioned overlays are concatenated in the debug binary almost in full. Here's a "correlation map" of the debug ROM (generated with chunksize=8, tolerance=512):

Here's a finer-grained version (chunksize=8, tolerance=16):

Here's the quantitative offset maps corresponding to the two correlation map diagrams above:
correlation-maps.zip. Each text dump comes from arm5correlate.py in doubly verbose mode and has 3 sections:

• Raw chunk correlations between raw 8-instruction chunks
• Per-file larger-chunk correlations generated by merging the raw chunk correlations
• (Most useful) An overall map of the best-attempt inferred correlations from the debug binary to the relevant release binaries. The diagrams above are generated from the correlations in this section.

File names

These likely come from the __FILE__ C macro. Found by a simple regex byte search for \b\w*\.[ch]\0:
ds-download-arm9-files.txt

Other

Identified by @End45 (probably the same in NA vs. EU?):

• 0x200AA58: GetDebugFlag1
• 0x200AA68: SetDebugFlag1
• 0x200ABF8: DebugPrint
• 0x200AC94: FatalError

Also noticed by both End and me: 0x200AC10 appears to be an "assert" function, called in 825 different places with various developer assertions.