Unable to compress arm9.bin for Tales of Hearts DS Anime Edition

[TheCopulator]

Rom: Tales of Hearts DS Anime Edition

Hi,

I'm still very new to romhacking. I am currently working on Tales of Hearts DS to translate in English.
Most of the menu text is in arm9.bin. I first used CrystalTile2 to do the following steps
1) Open Crystaltile2, decompress Arm9.bin
2) Translate a string
3) Open Crystaltile2, replace arm9.bin with the compression option

These steps works most of the time. (Sometimes, I do get the infamus, file is too small blabla when compressing arm9.bin), but I had a lot of success with this method.
I was able to translate most of the main menu.

The thing is this method is relatively manual and I would like to have a one click batch file to create a new NDS rom with my arm9.bin translated to test it in Desmume.

I read a lot of different romhacking sites and found out that the arm9.bin file used some kind of BLZ compression than be compress/decompressed using CUE's tool.
So what I did is

1) Unpack the original nds rom using ndstool in a folder
2) Decompress arm9.bin using Cue's tool
blz -d arm9.bin
3)Translate a string
4) Recompress using cue's tool
blz -en9 arm9.bin
5) Create the new rom using ndstool

When I do these steps, the game stays on a black screen when I open it. I'm not even able to see the Namcobandai title.

- Decompresing arm9.bin using Cue's tool works perfectly.
- I already did some test and I'm able to use desmume to open the memory view, find my string and hex edit and this works
- When I say translate a string in my steps, I'm basically hex editing the file with hxd, not updating any pointers and padding with 00s

What I also tried:

1) Take arm9.bin from Tinke
2) Decompress arm9.bin using Cue's tool
blz -d arm9.bin
3)Translate a string
4) Recompress using cue's tool
blz -en9 arm9.bin
5) Replace the file in Tinke and save the rom

Using Tinke will work when I just hex edit a simple string. If I try to update the pointers and update more strings, I'll still get a black screen and the game won't load.

Is it that I'm not using properly cue's tool to recompress the arm9.bin?
Maybe there are some steps required?

Thank you for all your help!

Post automatically merged: Dec 19, 2023

To add more information, The command I uses with ndstool are the following. They have been taken from DSLazy batch files.

- Unpack the rom
ndstool -x TOH_Original.nds -9 NDS_UNPACK/arm9.bin -7 NDS_UNPACK/arm7.bin -y9 NDS_UNPACK/y9.bin -y7 NDS_UNPACK/y7.bin -d NDS_UNPACK/data -y NDS_UNPACK/overlay -t NDS_UNPACK/banner.bin -h NDS_UNPACK/header.bin

- Pack the rom
ndstool -c new.nds -9 NDS_UNPACK/arm9.bin -7 NDS_UNPACK/arm7.bin -y9 NDS_UNPACK/y9.bin -y7 NDS_UNPACK/y7.bin -d NDS_UNPACK/data -y NDS_UNPACK/overlay -t NDS_UNPACK/banner.bin -h NDS_UNPACK/header.bin


Also, I'm not sure if this is the expected behavior but the new size of the rom is lower than the original.
Original: 262144Kb
New: 242 524Kb

Thank you!

 

[mn1712trungson]

Read history.txt inside Cue's GBADS compressors folder.
You need update ARM9 size after compressed with Cue's tools (usually smaller than OG).
ndstool often trims data, making the output file smaller, but usually does not affect the structure.
You can use Tinke (legacy) to resave the file to its original size.

You need the NDS ROM to update the ARM9 size in the ARM9 file:
- get the ARM9 load address (offset 0x0028)
- get the ARM9 autoload (offset 0x0070)
- the offset is the previous dword value @ autoload
- change the sizes in the 1st/2nd/6rd dwords pointed by the offset:
+ 1st: ARM9 decompressed size - 0x18
+ 2nd: ARM9 decompressed size
+ 6rd: ARM9 compressed size (0 if ARM9 is uncompressed)
(do not forget update all values with the load address)

load = *(int *)ROM[0x0028];
auto = *(int *)ROM[0x0070];
offset = *(int *)ARM9[auto - 1*4] - load;
*(int *)ARM9[offset+0*4] = load + ARM9_decompressedsize - 0x18
*(int *)ARM9[offset+1*4] = load + ARM9_decompressedsize
*(int *)ARM9[offset+5*4] = load + ARM9_compressed_size (0 if decompressed)

 

[plasturion]

When you get screen freeze after updating pointers (if it's the main reason after file update), probably you didn't calculated new address correctly. Do you add segment of arm9.bin ram location to put absolute value of pointer? commonly it's the fourth byte speaking of low-endian contianing 02h (common location for most games where the arm9.bin begins in ram - 2000000h ), you need that value. However I'm not sure, I'm just guessing, try also revision of your pointers updating method and compare with original ones on your uncompressed output file.

 

[TheCopulator]

Hi @mn1712trungson, thanks a lot for all this information!! I'm sure I didn't update any of the information that you mentioned so I assume you're pointing me in the right direction to fix the issue! I'll be working on that today or tomorrow. Thanks again

@plasturio, thanks for your comment. I think I'm updating the pointers correctly because I was able to recompress Arm9.bin with Crystaletile2 at some point and I had updated like 40 different entries in the files and they all worked.

I'll get back to you with what I've found.

 

[TheCopulator]

Hi @mn1712trungson,

Thanks to your advice, I was able to fix the issue. I'm now able to open my patched rom easily and very happy now .

For those that are interested, I made a small python function to update the arm9 values based on the instructions.
It is not rocket science but it may help someone

game_iso_path: path to the original iso to read the load and auto value
compressed_arm9_path: path to your arm9 compressed file
decompressed_arm9_path: path to the decompressed version of the arm9 file

And now, I'll be working on some overlays and have some fun.

Thanks again everyone