ROM Hack Rom Format

[- Wrath of God -]

Ok, so I'm out looking for the format that NDS files are stored in. Since I can't find a rom manager that can fill my needs, I'm thinking of making my own. But don't get excited just yet - this could just end up as one of those "I don't feel like finishing" projects.

A couple of days ago, someone posted a link to a really helpful website, but I can't find it anymore

.

So... Please help.

Thanks in Advance (yet again)


... god this forum is helpful

 

[FAST6191]

If you want something that details the header and nitroROM file system (which is what you seem to be asking for) then GBATEK is for you:
http://nocash.emubase.de/gbatek.htm#dscart...ryptionfirmware

 

[- Wrath of God -]

Yes, thank you very much. This site is even more helpful than the one I found before, but now I have a more specific problem. I'm trying to extract the icons from the games, but I find that the data where the address in the header (68h) points to isn't consistent in every rom. Even though the site says that it ought to be, and the titles (relative to the icon header) aren't there either. So if someone could please help me out, I would be very thankful.

 

[FAST6191]

GBATek says the offset 68 Hex (and the 4bytes from that position) contains the location of the icon (you have to do a byte flip (32bit unsigned) first mind) and then proceeds to give info relative to the start of that offset, every rom I tried over the course of the last few months using this method worked fine.

 

[- Wrath of God -]

Well maybe I wasn't looking in the right place. Say, now I have another question. How would you go about identifying a trimmed rom? Comparing it to a release list that has CRC32s for examples (but no CRC32 for the trimmed rom, just the full one)

 

[FAST6191]

Your best bet is to use the name/serial in the header and maybe some other point in the rom (which would be quite good for trained/hacked roms), you could also fake the presence of 00's/FF's for the CRC hash although that could get tricky if you use a hashing library not your own.

 

[- Wrath of God -]

Yeah, I was thinking of identifying roms by the name, but the dat file I'm using (ADVANsCEne's dat for offline list) doesn't contain the game code or internal name as one of the fields.

Then I was thinking about faking the presence of FF's, but that could get confusing and buggy.

edit: Oh yeah, and is there any place that describes the language code and/or country code?

 

[- Wrath of God -]

Sorry for the double post, but when I try to pad the ROMs that can be trimmed a lot (like Brain age [16MB -> 7MB]), when going up to the next power of two, it doesn't pad to the right value, and I end up with the incorrect CRC32, but I guess if there's no better way to do it, I'll have to deal with the lack of support for trimmed roms

 

[FAST6191]

Snowboard kids US is another one of those large amount of padding roms if you needed one.

Without a code sample I can not help but (I would not count on me being able to with one either) you might with to try overlaying the rom onto a premade (and compressed) file of correct size.

 

[- Wrath of God -]

A code sample of what?

All I do is take the
ceiling(log(filesize) / log(2))
and check if log(filesize)/log(2) = the ceiling of it
(basically check if it's a decimal or not)

If it is a decimal, then I round the filesize to the next power of two and pad it to there with 0xFF

Honestly, Brain Age is the only one that I've tried trimming, but I think that the system works for everything.... Probably... =P

Anyway, tell me more specifically what you need a code sample of and I'll get it to ya

 

[- Wrath of God -]

Again, sorry for the double post, but the M3 trimmer does something weird. In my previous experiment with Brain Age, I tried filling it to the size that it should be with 0xFF, yet it gave me a different CRC32. So I started wondering why. After taking a close look at both files in Hex editors, it appears as though the M3 trimmer made some bytes that were originally 0x00's into 0xFF's. Is there any particular reason that it did that? Is it a bug or what?

 

[FAST6191]

Anything other than FF and I would say it was a stopguard against further trimming, as for a bug I can not think of a way to do that without adding some extra code (unless the compiler/assembler wanted (q/d) word alignment for file i/o stuff and then used FF's to pad).

 

[- Wrath of God -]

No - this was different. Here's how it went in the original file - Most of the game, some 00's and then some more random data, then it was filled with FF's.

After the M3 trimmer got through with it, it ended up being most of the game, some FF's, then some more random data, and the file ended.