ROM Hack Quick pointers question

[xvirus]

Bit of a technical question here: is there any easy way to have a pointer address space from a file outside of itself in the rom? I know that on the GBA, you could point to any part of the rom with an 08xxxxxx pointer and was wondering if there was any way to do this on the DS. In my specific case, I am replacing strings that are embedded in the arm9 file. All of the pointers have are of 02xxxxxx format and I was wondering if there was a quick solution that I could point to file.. say.. translation.bin elsewhere in the rom. I'm assuming this is going to be a "no" since I didn't see anything about it when researching about the memory banks on the DS.

Beyond this, I was assuming the only other possible options would be either expanding the arm9(probably not easy) or loading them permanently into the ram(most strings are used throughout the game). Any ideas on what the best implementation would be?

 

[rastsan]

Why don't you just try it and then tell us if it works. (I'm curious too)
I'm currently fiddling around with nftr from (E) games in others (J) games that I'm tryng to translate - some success but mostly failure. You won't know till you try...

example the one company rerouted the j version (i think it was Away something dungeon) files to at what at first looks like .tbl files. But the .tbl files were just a bunch of things that were repointed (changing the file names it was directing too to something else and just having that file set up the way its with pointers in it and all the way supposed to be. you'll need to research fat.bin and another file that eluding me right now I think to get this to work but try away (I am going to be doing the same)

 

[FAST6191]

I have never tried it or even considered it for rom hacking but I might later- the 08000000 to 09FFFFF range is still available/mapped for the GBA slot (will almost certainly have to write the data to the NOR of whatever device you are using though unless you really want to initialise a GBA cart as well- to help dodge any troubles with flashing software you might as well give it a gba header) in DS mode (the higher waitstate mirrors are not there but that does not matter). As you found out the filesystem is not mapped to memory and trying to get it to read "extra" files is quite tricky (one of the reasons we tend not to just add in a translation and a language switch option)- this being said I have never tried this or had much reason to. Note that the DS itself has no file system access so you can either use those afforded by the binaries themselves or go manual (in which case you could probably read outside the rom/filesystem afforded data). http://nocash.emubase.de/gbatek.htm#dscartridgeprotocol is what you want if you want to go down that route.

Back on topic the only real trouble you might find (assuming you have not run out of memory and have redone any compression/length values in various headers) is if your expanded binary overwrites the space reserved for overlays or other data which would not be that hard to change either although there are ways around it.

My suggestion- think back to your GBA hacking days and drop/shorten all the "wifi not working" and other error messages that I usually see buried in binaries (picking a random binary from the pile here I have a commercial game built with lua here that has loads). Rather nicely they are often plain ASCII (rarely U16 unicode but you can hope) in English even on Japanese games going way into the kilobytes range. You might have to change their pointers as well but for extra space in a binary that is a small price to pay. It is not pleasant but can be automated and also can dodge some pitfalls with rom reading time (the DS does not do overly well when it comes to race conditions)

Option 2 and one more risky- not every game pushes the system to the limits so do as trainer makers do and deadbeef pad the ram (you might have to disable any initialisation wipes but that is probably basic startup hacking) and see what remains after getting into the game and playing for a while (take note of any overlays though- they should use a contiguous memory section).

Option 3 is compression possibly coupled with a pointer hack of sorts (think how cheats sometimes need pointer hacks- same idea here except you are the one implementing it).

Option 4 is a bit more tricky- hook another file not to do with text and with a few more instructions get it to grab some text data in addition to the data- if you have made it this far in DS hacking you will almost certainly have seen file systems stacked on top of file systems.

Of course you could always do my favourite thing and mix methods.