[nejimakipiyo]

Hello everyone! I'm pretty new to the hacking community. Worked on translations before with my friend Chicken Knife doing all of the actual hacking... but now I've decided to try a little project of my own and I'm already stumped.

Game: Dragon Warrior Monsters, for GBC

About the project: I'm looking to improve some areas where ideas were lost in translation. Jokes in the monster arena, a puzzling sign in the gate of Bewilder, puff puff censorship, etc.

What I've done so far: ...not really a whole lot, to be honest. I can so far open up the ROM and its table file in a Hex Editor (I'm using WindHex) and look at some of the code. Using various online resources and help from Chicken Knife, I was able to look at the header bytes to determine that the cartridge type for Dragon Warrior Monsters is MBC5+RAM+BATTERY, which apparently means it uses 3-byte pointers (and that explains why I wasn't able to find any 2-byte pointers!)

So, I started trying to work out the rom addresses for the pointers I need. Let's take the beginning of the monster list as an example. The offset for the beginning of the monster list, starting at "DrakSlime", is 105B1F. From that I worked out (using the hex mode of Windows Calculator + information on Data Crystal + help from a friend who speaks math) that my pointer should be 411F5B.

What I need help with: 411F5B comes up with exactly 0 search strings when I search it in WindHex. I understand that the 41 may not be attached to every pointer, but I wasn't able to find the pointers by searching for 1F5B either. I'm completely stumped at how I should progress with this, so some direction and tips would be helpful if anyone has the time to do so!

[Cyneprepou4uk]

https://www.romhacking.net/forum/index.php?topic=29648.0

[nejimakipiyo]

Thank you for your response. I read through that thread a few times since you linked it but having trouble applying that information to what I'm viewing in the Hex Editor, because I'm not prepared for this level of complexity. It seems like this exercise is going to require a lot of trial and error on my part.

I was looking for pointers for lists, and I don't see any blocks of space above the lists where the pointers could be. I've tried corrupting any similar bytes to see if I could find the pointer by that method, which failed. There is a chunk of space above the first dialogue in the game, though, so maybe I can try to find a pointer there.

Would the pointer for dialogue be in the same location as the pointers for the lists, or do you think that's unlikely?

[Cyneprepou4uk]

Technically anything is possible, so I can't say for sure.

I've tried to look for 105B1F pointers by simply searching for 5B 1F.



This whole area looks like a giant pointers table, because high address value keeps increasing downstairs.

Next to 5B 1F is 5B 29. When I go to 105B1F, I see that bytes here are separated with F0, and the next theoretical string is started at 105B29

[nejimakipiyo]

Thank you so much! I've been tinkering with the bytes based on what you said in the other thread and what you said here, and I've discovered some things. I managed to find the pointer for the game's opening dialogue based on your info in the other thread. That's a 3-byte pointer that doesn't have contiguous bytes. (42 at 108000, 40 at 108002, 41 at 10800A)

Now, I did find the 5B1F bytes at 104338 before. Except that I tried corrupting them and the monster list didn't change. Your feedback made me take another crack at it, and instead of working on the assumption that every monster's name would change, I made an effort to go recruit the first monster in the list, who I didn't have in this save file yet. And that name disappeared completely when I corrupted the bytes.

So I guess I've got the first pointer I needed, now, and hopefully enough information to track down the others. Thanks

It's strange to me that the pointers for different areas vary in how many bytes they use and whether or not the bytes are sequential, but I gather from reading the other thread that they don't have to be the same. Kind of makes my life a bit harder but that's what I get for jumping into hacking on a GBC ROM lol

[Chicken Knife]

Starting at 0x104338, it appears that we have 2 byte pointers for the monster list. What is very interesting is how each name on the monster list seems to have its own pointer, unlike the NES Dragon Warrior games that had 1 pointer cover numerous names on the lists via a system that counted end tokens. I do find it a little odd that we anticipated 3 byte pointers but these 2 byte pointers seem to be sufficient to address any data within the bank.

[nejimakipiyo]

Yes. As Chicken Knife said, every monster on the list has its own pointer. 5B1F corresponds to DrakSlime, 5B29 corresponds to SpotSlime, etc. That's why changing a single pointer wasn't enough to change the whole list. And I suspect these pointers are only 2 bytes because the pointer table is in the same bank as the lists themselves.

However, where it's getting interesting is that I'm having mixed success corrupting the pointers to get results in the game. All of the successful name changes (TreeSlime, GoldSlime, and DragonKid) had pointer addresses beginning with 5B. So when I put them in the pointer table in place of DrakSlime (5B1F), the name was produced successfully.

The unsuccessful name changes (Herb, TERRY, Sidoh, etc) had pointer addresses whose bytes began with something other than 5B, which produced various jumbled results such as "e", and a blank name.

I went to the monster list and found the first monster that didn't have a pointer address beginning with 5B. This was LizardMan, whose pointer address was 5C00. So I replaced DrakSlime (5B1F) with LizardMan (5C00) and when I booted up the game DrakSlime was now called MARI... a name which I recognized from a list of 4-letter name suggestions.

MARI's pointer address is 5B00. So it appears as though the pointer table with all the 5B bytes is treating everything there as if it begins with 5B, and ignoring the 5B part of the pointer. It has to be pulling the big byte from another location in the data, I guess? Or is there still a 3rd byte that is also functioning as part of the pointer, but separate from the bulk of the pointer table? Not sure how to progress here, and any more help would be appreciated.

[Cyneprepou4uk]

If you learn gbc assembly language and get used to debugger, the problem of finding any pointers won't be the case anymore. Nothing more to add on the topic.