Romhacking => Newcomer's Board => Topic started by: mikey3 on January 23, 2013, 04:08:58 pm

Title: NDS Pointers
Post by: mikey3 on January 23, 2013, 04:08:58 pm
Are they calculated the same as GBA games?
Title: Re: NDS Pointers
Post by: FAST6191 on January 23, 2013, 04:43:49 pm
Yes and no

Pieces of hardware are usually mapped to memory (most notable exceptions being the 3d side of things and the touchscreen) though some things are subtly different (it is all in GBAtek) however file level pointers are probably the most common type of pointer to deal with for most of what you will be playing with in DS ROM hacking (most graphics, most text, most sound and most levels in most games will use them exclusively).
When playing in file level pointers anything goes- most are big little (edit- must not do these sorts of posts on autopilot) endian straight count from 0 and that is your pointer affairs but I have seen relative pointers, pointers that need shifting (3d formats and the other day we had a script do it-,15605 ), offset pointers, all manner of things between 8 bits and 64 bits for a pointer, things that eschew pointers in favour of section/file sizes, things like the upper 8 bits are taken for something else so you get to AND them with 00FF or something (my usual example is just the single upper bit in NARC files indicates a subdirectory), things that are a scripting language for all other intents and purposes (,12953 ) and the list goes on. I have not see so much in the way of sector addressing as such (though I have seen things referred to by ordinals on several occasions) but it is entirely possible. Naturally pointers do not have to be end to end either and they can be buried among file names and other useful data (one of my favourite examples is probably El Tigre- make my mule), different files entirely (even in binaries for files in the filesystem) or something else you might be able to cook up in your head.

The only thing I really feel the need to note is overlays when it comes to binaries- if you are unfamiliar with the concept overlays are small fragments of code that get dropped into memory and swapped out as necessary. Commercial DS ROM images make extensive use of these (most have six or seven but a few dozen is not unheard or, a few hundred would be nothing terribly special and I have seen one or two worry the thousand range*) and they can be dropped anywhere in general memory, tools like crystaltile2 will tell you where they are designed to go so you can direct your disassembler though.

*for the curious passer by a quick search did not bring it up but I think it was one of the rockman/megaman offshoots. Edit- found it, Rockman EXE OSS at 1114 of the things for the ARM9. To be fair most the resources were located in them.... and I thought including everything in the binary had gone away with the rise of filesystems.

Do not let me put you off though- most of it is fairly basic and file level pointers are things many of the (S)NES hacking crowd would kill for on occasion as they are so much nicer to work with. Likewise if you can show you have given it a good stab then many around here and elsewhere will be happy enough to lend you a hand- there are limits but it is nowhere near as much of a faux pas to ask for help with pointers as it might be to ask about getting yourself a basic table file made.
Title: Re: NDS Pointers
Post by: StorMyu on January 23, 2013, 06:41:17 pm
most are little endian
It's a LE system, why would anyone torture himself using Big Endian pointer (or maybe just a stupid compiler but still...)
Title: Re: NDS Pointers
Post by: Xenesis on January 24, 2013, 07:55:00 am
The other thing to note is that NDS games actually use a filesystem.

In a lot of cases it is easier to replace files and rebuild the rom (CrystalTile2 can do it) rather than going through a mess of repointing.
Title: Re: NDS Pointers
Post by: FAST6191 on January 24, 2013, 08:52:03 am
Thanks StorMyu- I really must stop rattling these sorts of replies off.

To add to my little list I have actually seen a few games (usually those with scripting engines for their text/levels or high level programming languages) use big endian though. That is rarely a problem unless you have set your hex editor up to flip things for you "in place"- by all means go for it but if you plan to edit text you are quite likely to then make a little error and shift a piece of markup or something into the wrong place as the ASCII readout tends not to be flipped with it.