ROM Hack Changing text Inside the arm9.bin

[Necron]

Hi people. I'm working in a soundtrack swap in a game and when I was changing the titles (they are inside the arm9) I found a problem. The text ingame shows in any order. Guess its because of the pointers, but I have 0 hacking skills, so maybe someone may lend me a hand. The text inside the arm9 is like this:

And in another part. In this area, because of the ".\jukebox_menu" I need to use more space (I use the firsts . (00) after the Alles word), while in the first case I use less spaces (do I need to fill the gaps with . (00) ?):

Any help is apreciated =)

P.S: the highlighted blue area is the space for the songs names.

 

[jjjewel]

If it uses Shift-Jis encoding, most of the game will require one byte of 00 at the end of the text.

Here's some info about changing pointer for arm9.bin I wrote for a project some time ago. Not sure if it also applies to your game but it might help.

The pointers in Arm9.bin are in xxxxxx02 format. For example if your text starts at 00|0B|26|64, the pointer for that text will be the value of 64|26|0B|02. (Read the text address from back to front and add 02 at the end.) You can use "Search" --> "Find" in CT2 to look for value 64260B02 and change it to your new address if your text address has been changed. Also, remember to add 00 as the ending byte for your text. (All the texts must end with byte 00 so the game knows it has to stop reading there.)

P.S. From what I see from your pictures, seems like all the texts must start at bytes that are divisible by 4. (Ex. bytes that end with 0, 4, 8, C). If you relocate your text, you might have to consider this issue.

 

[Necron]

Thanks for the answer. Well, it uses a normal enconding (you can replace the text directly) and after each song there is a couple of 00, so I guess it uses the form you described. But the 00's after the name in some ocasions are just one 00, a couple or three, but it doesn't follow a pattern or something. So if I use just one 00 after each name will it be the same?

 

[jjjewel]

Thanks for the answer. Well, it uses a normal enconding (you can replace the text directly) and after each song there is a couple of 00, so I guess it uses the form you described. But the 00's after the name in some ocasions are just one 00, a couple or three, but it doesn't follow a pattern or something. So if I use just one 00 after each name will it be the same?

I just edited my previous post to explain about this part.

I don't know the significant of this padding but many games tend to restrict where you can start the text to every 4 bytes or 8 bytes. If you put your text somewhere in-between, the game won't read it and might crash.

In your pics, you see some extra 00's at the end of some texts because the next texts must start at bytes that are divisible by 4. (There might be a scientific term to call this, but I don't know it.

)

 

[Necron]

Thank you again. I remember seeing this in other part. Ok, will test it.

Edit: If I need more space, can I add the text somewhere where there is empy space (00s or FFs?) and the repoint them?

 

[jjjewel]

Edit: If I need more space, can I add the text somewhere where there is empy space (00s or FFs?) and the repoint them?

I'm not sure about that. It depends on the game, so you might have to try and test if the game still works after you do that.

 

[rastsan]

fast answered this one... just make a bigger arm 9 and point to the end of the bigger arm9 then point it back to where its supposed to be after you point to the new space at the end. (if need be)


And to answer your question no... as you cannot be sure what you are replacing is not actual programming. you could do it if you knew the previous stuff is replaceable.

 

[Necron]

OK, it wasn't necessary to do that. It worked

Thanks jjjewel for the help and rastsan for the tip =D

 

[FAST6191]

Hmm hacking the Tony Hawk's titles are you (they were one of the games many of us learned on/initially pulled apart).

I know you seem to have it sorted but I feel like waffling a bit.

The starting of things at given points is usually referred to as either alignment or boundaries
"The values in this game use 16 bit boundaries"
"The games requires these values to be byte, word, double word/dword, quad word aligned" (do also note some now older/rare machines use different meanings for word)

Some might also use more programming related terms like short and long but that can get odd and varies between programming language and architecture so if all else just stick with bits or bytes. Also note there is no great issue for a game to shift things in memory- I am sure we have all seen pointer tables magically line up when you delete a few bytes from the header of the file.

Back on topic
NDS9 Memory Map

00000000h Instruction TCM (32KB) (not moveable) (mirror-able to 1000000h)
0xxxx000h Data TCM (16KB) (moveable)
02000000h Main Memory (4MB)
03000000h Shared WRAM (0KB, 16KB, or 32KB can be allocated to ARM9)
04000000h ARM9-I/O Ports
05000000h Standard Palettes (2KB) (Engine A BG/OBJ, Engine B BG/OBJ)
.....
More
http://nocash.emubase.de/gbatek.htm#dsmemorymaps

That gives you the 02 thing.
Two things at this point-
The pointing at the end of the file and doing work there. It works on occasion but you have to remember that things might be used there and might either get overwritten by something else or overwrite something else. The games compiler or if the authors are kicking it to assembly level then chances are the authors at some level are managing the memory usage and although you can change it the work required tends to prevent it from happening. To this end it is probably better to find a blank space in the memory and use that (although that can be tricky too when dealing with games that have overlays that are not used early on in the game).

Do also consider that the text might be fixed length or parsed (new line on 00 or something) and just have a basic pointer to the start of the value and maybe a length value.

Although we call the ARM9 the code for the ARM9 they can and do often include a lot of other stuff (this hack being a prime example) rangings from thing that directly interact with the ARM code but are not opcodes or payloads to entire "files" (I was pulling text, fonts, images and more out of a ARM9 file the other day).

Do also note that not all binaries have to start at the start of the 02 section (although most do) and the ARM9 memory address is contained within the header- just about every program that can deal with the DS file system will be able to tell you this although I tend to keep ndsts around for this- http://www.no-intro.org/tools.htm The maths is but a minor difference at this point (if the starting offset is 02004000 you just add 4000 to the number (accounting for any endianess issues).