Creating this issue to track support for memory overlays.

Mario Party makes use of overlays. There is a core portion of assembly that persists in RAM for the entire runtime, and an overlay region where different overlays are swapped in depending on the current game scene.

I created a marioparty.u.yaml that attempted to represent this game. All overlays are assembled assuming they are copied to 0x800F65E0, so that is what I had placed for each asm entry in the yaml.

The problem is that all the symbols for all overlays get mixed together. Overlays should have isolation of symbols, such that one overlay cannot see another. However, they do need to see the core code, as they often call into that.

this makes linux and other *nix oses use these tools easier

In README.md, n64split is said to have the -p flag that generates a procedure table. However, this is not actually implemented in n64split.c.

Simply, i used the extender and it made an 64MB ROM file.
I've tried compressing it directly without changing anything in the ROM and it crashes after the "count : 135" output.
No arguments are used in both extender and compressor.

I noticed that n64split does not compile properly when using CMake on Linux. libsfx needs to be compiled. This diff fixes it.

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 2c0e6fe..154e517 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -17,6 +17,7 @@ include_directories("${PROJECT_SOURCE_DIR}/external/include")
 link_directories("${PROJECT_SOURCE_DIR}/external/lib")
 
 add_library(sm64 STATIC libmio0.c libsm64.c utils.c)
+add_library(sfx STATIC libsfx.c utils.c strutils.c)
 
 add_executable(sm64extend sm64extend.c)
 target_link_libraries(sm64extend sm64)
@@ -49,5 +50,5 @@ set_target_properties(n64graphics PROPERTIES COMPILE_DEFINITIONS "N64GRAPHICS_ST
 target_link_libraries(n64graphics png z)
 
 add_executable(n64split blast.c mipsdisasm.c n64split.c n64graphics.c strutils.c yamlconfig.c)
-target_link_libraries(n64split sm64 capstone yaml z)
+target_link_libraries(n64split sm64 sfx capstone yaml z)

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?

Hi, thanks for your work!
Even if I unpack cean 8MB USA z64, repacking in windows 10 with binutils-2.25, I obtain a no working 12MB rom :(
Thank you for help

After a bunch of troubleshooting, I've gotten stuck here. glabel is never defined, and it's causing a lot of assembler errors. I can't find any way to build the ROM with these errors.

N64Split seems to be unable to disassemble code before the entrypoint of the game. Many games place Main function before the entrypoint, whic makes full disassembly impossible. Is there a way to fix this issue?

When running n64split on the Shindou and European versions of SM64, I get the error mentioned in the title. I'm not sure how to trace it back to specific lines in the config file though. The U and J versions are fine.