Related to #7, as a workaround, I created a Mario Party config that just specified a single overlay, leaving the rest as plain bin sections. The thought was this would get a good disassembly of the core and a single overlay, which is plenty to start with.

I've been making each overlay two sections, asm and bin, as shown below, thinking that bin was the closest thing that represents rodata.

- [0x2418A0, 0x244B50, "asm", "overlay54_main", 0x800F65E0]
- [0x244B50, 0x2455C0, "bin", "overlay54_rodata"]

n64split generates symbols starting with D_ in the asm that point into the rodata. However, these symbols are never defined, because the rodata is just a binary file, and make results in many errors.

I made a change to say that the overlay is just entirely asm, so that the disassembler would pass over the rodata.

- [0x2418A0, 0x2455C0, "asm", "overlay54_mainandrodata", 0x800F65E0]

The result is much closer to compiling, since the data becomes garbage instructions in the .s file, and those do get symbols. However, some of the instructions are not supported by the architecture (make still fails), and generally, this doesn't really get me much closer to having a working assembly; I'd have to totally rework the data portion still.

All that said, should there be a rodata section in yaml that would instruct n64split to generate something with data + symbols (using writes)? It seems it could really make the ROM rebuildable without any manual changes if this was implemented.

Or am I doing something wrong in my current config setup?