n64split v0.4a: ROM splitter and build system

[queueRAM]

(17-10-2016, 01:55 AM)Essem Wrote: I really need a split of the Shindou Edition because I have to rip some sounds from it. Can you please add a config for it?

​

If you have any hacking notes for SM64 Shindou Edition, I can certainly put together a config for it. Are the sounds in the Shindou Edition any different than the US version?

Also, did you you try Subdrag's Sound Tool as ergazoobi suggested to you?
According to that page, it supports export/import in all versions of SM64:
Super Mario 64 (E) (M3) [!]
Super Mario 64 (J) [!]
Super Mario 64 (U) [!]
Super Mario 64 - Shindou Edition (J) [!]

[Essem]

(17-10-2016, 02:07 AM)queueRAM Wrote:

(17-10-2016, 01:55 AM)Essem Wrote: ​
I really need a split of the Shindou Edition because I have to rip some sounds from it. Can you please add a config for it?

​

If you have any hacking notes for SM64 Shindou Edition, I can certainly put together a config for it. Are the sounds in the Shindou Edition any different than the US version?

Also, did you you try Subdrag's Sound Tool as ergazoobi suggested to you?
According to that page, it supports export/import in all versions of SM64:
Super Mario 64 (E) (M3) [!]
Super Mario 64 (J) [!]
Super Mario 64 (U) [!]
Super Mario 64 - Shindou Edition (J) [!]

​

Never mind, I figured it out using that program; I'm an idiot for not seeing the save button XD However, just for the sake of providing better tools to work with: Yes, it does have different sounds. The first and second jump sounds are different in pitches (don't know if this counts or not), and "So long, eh-Bowser!" was replaced with Mario saying "Buh-bye!"

[gcr27]

how do extract blast corps carrier its any models n64split not extraction problem

[Cyborg]

(13-11-2016, 08:34 PM)gcr27 Wrote: how do extract blast corps carrier its any models n64split not extraction problem

​

You need a blast corps config for splitting it

[gcr27]

(13-11-2016, 10:36 PM)Cyborg Wrote:

(13-11-2016, 08:34 PM)gcr27 Wrote: ​
how do extract blast corps carrier its any models n64split not extraction problem

​

You need a blast corps config for splitting it

​

ok im brazilian player

[mitchasdf]

Hello!

I've been trying all day to get my command prompt to rebuild SM64[U] without errors. At first I had the error of "make [2]: file does not exist (or something synonymous)", and after playing around with CygWin and building the toolchain myself I managed to get past that.
I think I'm down to the final boss error now.

C:\Users\Mitchell\Desktop\n64split-0.4a-win32\sm64.split>make
mips64-elf-ld -T sm64.ld -Map build/sm64.map -o build/sm64.elf build/sm64.o
mips64-elf-ld: section .text80246000 VMA [0000000080246000,000000008033a57f] overlaps section .text8016F000 VMA [000000008016f000,000000008071c1ff]
make: *** [Makefile:60: build/sm64.elf] Error 1

C:\Users\Mitchell\Desktop\n64split-0.4a-win32\sm64.split>_

I've had a look online. Similar errors would point towards "a header file being included more than once" or "bit sections being defined more than once", but I can't find anything wrong in your code. You've even commented out the part that apparently causes the error I'm having.

The current /build/ output is :
- sm64.map (143,562 bytes) which appears to be complete
- sm64.o (12,089,368 bytes) not sure how to view it

I hope you might be able to help. I'm keen to get started on modifying the game!

[queueRAM]

(06-11-2017, 03:24 PM)mitchasdf Wrote: I've been trying all day to get my command prompt to rebuild SM64[U] without errors. At first I had the error of "make [2]: file does not exist (or something synonymous)"

​

Hi mitchasdf, a win32 build of GNU 'make' is included with the archive in the tools directory, so if you don't already have it, you can use that prebuilt one.

(06-11-2017, 03:24 PM)mitchasdf Wrote: ​
and after playing around with CygWin and building the toolchain myself I managed to get past that.
I think I'm down to the final boss error now.

C:\Users\Mitchell\Desktop\n64split-0.4a-win32\sm64.split>make
mips64-elf-ld -T sm64.ld -Map build/sm64.map -o build/sm64.elf build/sm64.o
mips64-elf-ld: section .text80246000 VMA [0000000080246000,000000008033a57f] overlaps section .text8016F000 VMA [000000008016f000,000000008071c1ff]
make: *** [Makefile:60: build/sm64.elf] Error 1

​

This is caused by a bug that was unfortunately introduced in n64split 0.4a with some pseudo-instructions with only certain assembler versions. It will be corrected in a future release. It works on my end for mips64-elf-as 2.25, but not for some newer versions.

Code:

​>..\tools\make
mkdir build
mips64-elf-as -mtune=vr4300 -march=vr4300 -o build/sm64.o sm64.s
mips64-elf-ld -T sm64.ld -Map build/sm64.map -o build/sm64.elf build/sm64.o
mips64-elf-objcopy build/sm64.elf build/sm64.bin -O binary
../tools/n64cksum build/sm64.bin sm64.z64

>mips64-elf-as --version
GNU assembler (GNU Binutils) 2.25

(06-11-2017, 03:24 PM)mitchasdf Wrote: ​
The current /build/ output is :
- sm64.map (143,562 bytes) which appears to be complete
- sm64.o (12,089,368 bytes) not sure how to view it

​

The error above is from the linker which is one of the last commands to run. The .o file is an object file output of the compiler before final linking is done. I'm actually kind of surprised the .map file is generated because that is an output from the linker too, although it might give a clue as to which functions are spilling over from one section to another.

[mitchasdf]

Very informative!

I can't find any obvious overlaps happening

The download link for the toolchain on your original post is a DNS error for me. If I go to cen64.com however I can get a toolchain there, but it also causes the overlap error.

I should've also mentioned, it gives me the multiple branch warnings the first time I run it if it hasn't already tried to build just to let you know it's on the same page in that regard.

So I can't seem to find an older version of the toolchain. Any idea where to get a compatible version?

I'll also include this, just in case something seems off.

Split textures

[queueRAM]

(07-11-2017, 02:49 AM)mitchasdf Wrote: I can't find any obvious overlaps happening

​

I took a closer look into it and my original assessment wasn't quite right. One section includes unassociated data with it at the end which makes it look to the linker like it overlaps another section's virtual address. At the end of ".section .text8016F000" there is "# Unknown region 2577B8-269EA0 [126E8]". This region should be the start of a new section.

(07-11-2017, 02:49 AM)mitchasdf Wrote: ​
The download link for the toolchain on your original post is a DNS error for me. If I go to cen64.com however I can get a toolchain there, but it also causes the overlap error.

So I can't seem to find an older version of the toolchain. Any idea where to get a compatible version?

​

Yeah, the cen64 dev maintains that. I don't really use Windows, so I don't really know how to build or find GNU binutils binaries for it. Next version of n64split will more than likely use armips instead of binutils for assembling, so this won't be an issue because armips can easily be packaged with it.

(07-11-2017, 02:49 AM)mitchasdf Wrote: ​
I should've also mentioned, it gives me the multiple branch warnings the first time I run it if it hasn't already tried to build just to let you know it's on the same page in that regard.

​

Do you mean macro instruction expansion warnings like this?

Code:

​sm64.s:220139: Warning: macro instruction expanded into multiple instructions in a branch delay slot

​
Those are expected. I got a little too aggressive with the pseudo-instruction detection, so some fall in delay slots which should generate warnings because only one of the two real instructions will be allowed to be placed in the delay slot.

[mitchasdf]

Thanks for taking all this time to respond to my posts. I have tried using n64split 0.2 and 0.3, but both have the exact same overlap error.

I'm not sure if it's something I have done before I got to the overlap error. I'll try and explain this as best I can - as I'm still a newbie at this stuff.

So I started with step one, downloading n64split 0.4 and the toolchain from cen64 and then adding the folder to my Environment Variables.
At the time, I didn't realise that I would have to restart command prompt for my environment variable changes to take affect, which is why I was having trouble with "make (e=2): mips-elf-as cannot be found (or something)", and was also the reason for me going on to this next step.

Since you don't use windows I'll explain what I had to do to build the toolchain...

I had to install CygWin (a unix shell console) and on that I had to download, build and install GCC. After that, I needed to do the same for 2 other packages (binutils and another one which I cannot remember the name of)

After that, I could then do the same for the toolchain using a repository where you "cd" into the directory and run the build-win64-toolchain.sh.

All of these packages took an hour or more each for me to figure out how to obtain and install (because they all have different build configurations) which made it all the more confusing.

Anyway, after that, I then realised you need to simply restart command prompt in order for the environment vars to apply. I think somewhere between step 1 and this point is where I have messed something up.

Here's where it gets weirder - I cannot add the folder you specified to add to my environment variables to make any sort of difference.
You specified the folder: "n64tools_dir/mips64-elf/bin"
When I add this folder, I get the error "make (e=2): mips64-elf-as not exist"

When I add this folder (this is the folder mips64-elf-as.exe is located in): "n64tools_dir/bin" It will actually get to the overlap error instead.

When I add both folders, it makes no difference to just adding "n64tools_dir/bin".

I'm curious as to what's wrong. I swear I couldn't have gotten a worse outcome if I tried.

(07-11-2017, 08:15 AM)queueRAM Wrote: ​
I took a closer look into it and my original assessment wasn't quite right. One section includes unassociated data with it at the end which makes it look to the linker like it overlaps another section's virtual address. At the end of ".section .text8016F000" there is "# Unknown region 2577B8-269EA0 [126E8]". This region should be the start of a new section.

​

As I said, I'm quite newb and I don't fully understand what you mean by there is "unassociated data with it at the end" and also don't know what you mean by "This region should be the start of a new section."

I am interested in finding a fix. One thing that does stand out to me:
section#1 (0x80246000 to 0x8033A57F)
section#2 (0x8016F000 to 0x8071C1FF)

Not only are they overlapping, section#1 is completely encased by section#2. Is this right?

Is there any way at all to stop this from happening? Such as make it so section#1 is not part of section#2?

I can vaguely understand C/C++ code if I'm reading it (I wouldn't be able to write it), but I cannot seem to locate anything in your code that would be causing these overlaps; not that I understand it that much.

Sorry for giving so much reading material. But this tool looks stunning. I really really want to get it working