Hi folks!
First time posting and I'm fairly new to rom hacking. I'm currently working on a translation of Hamtaro: Nazo Nazo Q which is (to my knowledge) one of the only Hamtaro games to never get an official English release. The first section of this post will be about the progress I've made so far and the second will detail the current challenges I'm facing.
Progress So Far
With the exception of the game icon and SDAT sound, this game seems to not use any standard DS files or conventions. Cracking open the file system, we can see this:
Even the things that CrystalTile2 is convinced are LZ22 archives are actually not. All of these DAT files begin with a series of pointers to items later in the file as can be seen here:
(That's sort of a lie -- some of the DAT files start with a pointer to the first pointer, which is always 0x08 in those files, followed by the total file length; however, they're otherwise identical.)
In some files, like MSysMsg.dat, these point to strings (encoded in a weird custom Japanese-modded ASCII) and simply encode text displayed in game (these will hereon be referred to as message files). In others, however, they're pointers to other files, essentially acting as a directory (hereon referred to as directory files). (A custom file system within the NDS file system...I don't know why anyone would do that.) I've written a quick & dirty utility to parse and edit both kinds of files (including the message files contained within the directory files). I'll include a couple of screenshots to demonstrate:
It's very much rough around the edges still (particularly when it comes to UX which is not my strong suit) but it accomplishes its job for the most part.
Using this utility, I'm able to change all of the strings in the game:
Honestly, this is probably enough to release a fairly solid translation patch (given the help of a couple of translators since there are a lot of strings in the game). However, there's quite a bit of text in the game locked up in image files. Which brings us to our next section...
Current Challenges
As with everything else in this cursed ROM, the image files exist in a custom format. Because of my work with the directory files, I can at least locate which files are which with the help of a corrupter. As you can see from the screenshot of the utility above, I successfully located the main menu's "Hajimeru" (はじめる, "Start") graphic (included below for reference).
Not pictured in that screenshot of the utility is the palette file, which in that directory is located after all tilesets and maps, but I have concluded that every graphic contains follows the tile/map/palette pattern. However, none of these files are in a normal format (as best I can tell) and CrystalTile2 is unable to display the tilesets no matter which settings are chosen (as far as I can tell).
Within the tile files, there are some bytes that I can edit and get sort of logical outputs; for example, here's the result of mucking around with the above Hajimeru file and carefully replacing only certain bytes with FF:
However, here's what happens when I change a single "wrong" byte:
To me, this seems weird to happen while changing the bytes of a tileset (but again, I'm pretty unfamiliar with graphics files and have mainly relied on CrystalTile2 to edit stuff previously).
Things I have considered:
First time posting and I'm fairly new to rom hacking. I'm currently working on a translation of Hamtaro: Nazo Nazo Q which is (to my knowledge) one of the only Hamtaro games to never get an official English release. The first section of this post will be about the progress I've made so far and the second will detail the current challenges I'm facing.
Progress So Far
With the exception of the game icon and SDAT sound, this game seems to not use any standard DS files or conventions. Cracking open the file system, we can see this:
Even the things that CrystalTile2 is convinced are LZ22 archives are actually not. All of these DAT files begin with a series of pointers to items later in the file as can be seen here:
(That's sort of a lie -- some of the DAT files start with a pointer to the first pointer, which is always 0x08 in those files, followed by the total file length; however, they're otherwise identical.)
In some files, like MSysMsg.dat, these point to strings (encoded in a weird custom Japanese-modded ASCII) and simply encode text displayed in game (these will hereon be referred to as message files). In others, however, they're pointers to other files, essentially acting as a directory (hereon referred to as directory files). (A custom file system within the NDS file system...I don't know why anyone would do that.) I've written a quick & dirty utility to parse and edit both kinds of files (including the message files contained within the directory files). I'll include a couple of screenshots to demonstrate:
It's very much rough around the edges still (particularly when it comes to UX which is not my strong suit) but it accomplishes its job for the most part.
Using this utility, I'm able to change all of the strings in the game:
Honestly, this is probably enough to release a fairly solid translation patch (given the help of a couple of translators since there are a lot of strings in the game). However, there's quite a bit of text in the game locked up in image files. Which brings us to our next section...
Current Challenges
As with everything else in this cursed ROM, the image files exist in a custom format. Because of my work with the directory files, I can at least locate which files are which with the help of a corrupter. As you can see from the screenshot of the utility above, I successfully located the main menu's "Hajimeru" (はじめる, "Start") graphic (included below for reference).
Not pictured in that screenshot of the utility is the palette file, which in that directory is located after all tilesets and maps, but I have concluded that every graphic contains follows the tile/map/palette pattern. However, none of these files are in a normal format (as best I can tell) and CrystalTile2 is unable to display the tilesets no matter which settings are chosen (as far as I can tell).
Within the tile files, there are some bytes that I can edit and get sort of logical outputs; for example, here's the result of mucking around with the above Hajimeru file and carefully replacing only certain bytes with FF:
However, here's what happens when I change a single "wrong" byte:
To me, this seems weird to happen while changing the bytes of a tileset (but again, I'm pretty unfamiliar with graphics files and have mainly relied on CrystalTile2 to edit stuff previously).
Things I have considered:
- Compression. It's possible these graphics are compressed, but if they are, they're the only things on the ROM that are compressed and they're not in a standard compression format that I recognize
- The "weird" bytes determine the length/width of the tile. Seems unlikely but it would at least explain why they completely jank up the output with such small changes.
- ASM debugging to try to unroll what's happening. I have very little experience here and even more unfortunately, no$gba can't run this game. If people have tips on other ways to start with ASM debugging I'd greatly appreciate it.
- Staring at these files is making me sad.
Last edited by jonko_,
