header's loadAddress doesn't compensate for bootchip offsets about n64loaderwv

[zeroKilo]

your code seems to work via crc checks, how reliable is that? would it be enough to add a loading offset to the loader that you can enter per hand?
greetz

[ethteck]

I haven't had any issues with it so far, but I haven't comprehensively tested it or anything. I'm not sure, but it seems like it should be trivial to do the same thing in Java via the CRC32 class. I could maybe give it a shot later on, but in case I don't get to it, I wanted to at least open an issue to raise awareness.

A way to adjust it manually might be nice, but I think most users won't know what to enter and so it may be a bit confusing.
cheers :)

[zeroKilo]

so, if I get this right, you make a crc from 0x40:0x1000, and depending on its crc32, the rest of the rom is moved? I mean, the hardware would load the bootcode at normal address, but the bootcode would overwrite it, right? so is the rom already aligned when I load it to normal address, and I just have to move the entrypointer or do I need to split the memory and insert a gap?

PS: just reread my code, this would only affect the .RAM section, right? Ill make you some example code to test

[zeroKilo]

try this:
replace:

import java.util.zip.CRC32;
...
	public N64Header(byte[] data) {
		raw = data;
		BinaryReader b = new BinaryReader(new ByteArrayProvider(data), false);
		try {
			magic = b.readInt(0);
			loadAddress = b.readInt(8) & 0xFFFFFFFFL;
			title = b.readFixedLenAsciiString(0x20, 0x14);
			gameCode = b.readFixedLenAsciiString(0x3c, 0x2);
			maskRomVersion = b.readByte(0x3F);
			byte[] bootLoader = b.readNextByteArray(0xFC0);
			CRC32 crc32 = new CRC32();
			crc32.update(bootLoader);
			long value = crc32.getValue();
			if(value == 0x0B050EE0) //"ntsc-name": "6103", "pal-name": "7103"
				loadAddress -= 0x100000;
			if(value == 0xACC8580A) //"ntsc-name": "6106", "pal-name": "7106"
				loadAddress -= 0x200000;
		} catch (IOException e) {
			Msg.error(this, e);
		}
	}

in: https://github.com/zeroKilo/N64LoaderWV/blob/master/src/main/java/n64loaderwv/N64Header.java
and let me know if this solves your issue. thx

[zeroKilo]

https://github.com/zeroKilo/N64LoaderWV/releases/tag/10.1.2

hi, I included this in the current release, could you please test it?

[ethteck]

Hey, sorry for the lack of responses! I'll try now.

[ethteck]

and to repond to your question (very late), yes, I believe you described the correct way to fix it :)

[ethteck]

Unfortunately I'm still getting the wrong memory addresses in the latest version of the plugin with yoshi's story. do you get the adjusted address or the 0x802XXXXX?

[zeroKilo]

I dont have a rom to test it, you saw the code I changed, just put a bp there. maybe crc32 works different on java, maybe I hash the wrong numbers, thats what I meant with "please test this". Or link me a rom that I can use, but no idea how to help you now

[ethteck]

I tested it in that I ran the program. If you're asking me to debug it, I have a lot of projects I'm juggling and setting up a ghidra dev environment isn't the highest priority for me, nor do I even know how to do that. If you give me some instructions on how I can debug your plugin, maybe I can get to it at some point soon. Also I can't share roms, sorry.

This issue isn't really a blocker for me personally, I just thought you may want to know about it because it will prevent your loader from working on a large portion of the n64 library

[ethteck]

maskRomVersion = b.readByte(0x3F);
byte[] bootLoader = b.readNextByteArray(0xFC0);

this does indeed look like it's loading bytes 0x40:0x1000 into a byte array and running crc32 on it...so yeah the next step indeed is to see if the result is the same in python and java

[zeroKilo]

I think I know the problem:

readByteArray vs readNextByteArray

because all commands before didnt moved the current index, so it reads those bytes starting from 0

I think it should read:

byte[] bootLoader = b.readByteArray(0x40, 0xFC0);

btw im busy aswell, if theres such a large portion of roms, you can surely point me to a name at least, that I can google. I mean, how am I supposed to test this?

PS: https://github.com/NationalSecurityAgency/ghidra/blob/master/Ghidra/Features/Base/src/main/java/ghidra/app/util/bin/BinaryReader.java
https://fossies.org/linux/ghidra/GhidraBuild/EclipsePlugins/GhidraDev/GhidraDevPlugin/GhidraDev_README.html#Install

[ethteck]

As I've mentioned earlier today and when I opened the ticket, Yoshi's Story is one of the roms you can use to debug. For legal reasons, though, I can't share roms with people. Another chip that has a ram offset, 6103 is used by many popular games such as Paper Mario, Pokemon Snap, and Pokemon Stadium. You can find more info about which games use which chips here: http://micro-64.com/database/gamecic.shtml

If you don't have any of those games' roms, then I guess someone else will have to look into this later. Feel free to close this if you want. I wasn't expecting you to fix it in any timely manner, I just wanted to report it since I came across it when testing your loader.

[ethteck]

tecto.zip
a friend created a 6106 version of his homebrew rom that I can share here. I hope this helps

[zeroKilo]

alright thanks, I have to boot into my other pc for this, but then you can maybe already have an update :P

[zeroKilo]

alright, it seems to work on my end, I tested it with your rom and it loaded it to 0x800XXXXX

https://i.imgur.com/uLxu5dv.png

problem was the one I expected and then java doesnt know unsigned numbers, so a compare with if(value == 0xACC8... compares it against a negative number, so I have to add an L to fix it...

anyway, now the extension should work for you, I also make a new release in a minute or so

greetz

EDIT: https://github.com/zeroKilo/N64LoaderWV/releases/tag/10.1.2 there it is

[ethteck]

Ah, nice catch! I appreciate your time and effort on this. It does indeed look fixed :) tested it on Yoshi's Story. I'll let you close the issue, but as far as I'm concerned, this is all good. 😁

[zeroKilo]

thanks for testing, have a nice day! :)