Skeetendo

’Cause all games were better on the GBC

You are not logged in.

#1 2016-04-09 08:27:44

Picrodus
New member
Registered: 2015-03-22
Post 8/9

Pointers to the Moves Data Table

Hello,

I am currently in the process of repointing the move data table in Pokémon Yellow originally stored at the start of bank 0E at x38000. I am trying to repoint it at x3BBAA. The problem is that I cannot find the pointer to the table which I assume to reside in the same bank. Since the original table begins at x38000, I am looking for a pointer in the form of 00 40. And am trying to replace it with AA7B to correspond with being repointed to x3BBAA. But so far no luck.

I guess basically what I am asking is if their is a good way to find the pointer aside from typing 0040 into the search function in HXD and replacing it with AA7B to see what happens ingame. (Which is what I have been doing.) I looked in the Pokémon Yellow disassembly and the data crystal for red and blue. But have not found the pointers there either. Help would be very much appreciated.

Offline

#2 2016-04-09 10:39:01

Sawakita
Administrator
Registered: 2010-10-16
Post 362/364

Re: Pointers to the Moves Data Table

Hello,
Running a search (git grep -n "\bMoves\b") on the yellow disassembly (as of revision 9ca431b4f9706a3bbbbcfb03e2bab3360a5258a2), gave these results (I stripped some unrelated matches):

data/moves.asm:1:Moves:
engine/add_party_mon.asm:267:   ld hl, Moves
engine/add_party_mon.asm:268:   ld bc, MoveEnd - Moves
engine/add_party_mon.asm:271:   ld a, BANK(Moves)
engine/battle/core.asm:5370:    ld hl,Moves
engine/battle/core.asm:5371:    ld bc,MoveEnd - Moves
engine/battle/core.asm:5373:    ld a,BANK(Moves)
engine/battle/core.asm:6352:    ld hl, Moves
engine/battle/core.asm:6353:    ld bc, MoveEnd - Moves
engine/battle/core.asm:6355:    ld a, BANK(Moves)
engine/battle/trainer_ai.asm:266:       ld hl,Moves
engine/battle/trainer_ai.asm:267:       ld bc,MoveEnd - Moves
engine/evos_moves.asm:620:      ld hl, Moves
engine/evos_moves.asm:621:      ld bc, MoveEnd - Moves
engine/evos_moves.asm:624:      ld a, BANK(Moves)
engine/heal_party.asm:37:       ld hl, Moves
engine/heal_party.asm:38:       ld bc, MoveEnd - Moves
engine/heal_party.asm:41:       ld a, BANK(Moves)
engine/items/items.asm:2649:    ld hl,Moves
engine/items/items.asm:2650:    ld bc,MoveEnd - Moves
engine/items/items.asm:2653:    ld a,BANK(Moves)
engine/learn_move.asm:46:       ld hl, Moves
engine/learn_move.asm:47:       ld bc, MoveEnd - Moves
engine/learn_move.asm:50:       ld a, BANK(Moves)
main.asm:3627:  ld hl, Moves
main.asm:3628:  ld bc, MoveEnd - Moves
main.asm:3631:  ld a, BANK(Moves)
main.asm:3992:  ld hl, Moves
main.asm:3993:  ld bc, MoveEnd - Moves
main.asm:3996:  ld a, BANK(Moves)

I'm not sure replacing just these will be sufficient (I don't know if there are any other references, in some different form, throughout the code), but I hope it's a good starting point for your task.

Out of curiosity: any reason why you're working on the raw binary file instead of editing through the disassembly? For instance, you could just move that label around instead of updating all referencing pointers by hand.

Offline

#3 2016-04-09 10:45:54

Miksy91
Member
Registered: 2010-10-16
Post 2,251/2,311

Re: Pointers to the Moves Data Table

Since the table is located at the start of a rom bank, that "practically" already means that it is accessed from elsewhere in the rom. It could clearly be so that there would be some code after the table that would use the table, but this is usually not the case.

I would suggest taking a look at the code of rom bank 0 (0x0 - 0x3FFF) and see if the table is accessed from there. If it is, you can just repoint it elsewhere from there. If it isn't, you would have to look, which rom bank accesses this table in one form or another. The rom bank that does this is most likely before bank 0E but I'm not totally sure about that either.

Debugging could be a good choice here as well unless you can't pick up how this is handled in pokered disassembly, and can't figure out how it is accessed that way.

Offline

#4 2016-04-09 18:41:47

Picrodus
New member
Registered: 2015-03-22
Post 9/9

Re: Pointers to the Moves Data Table

Hi guys thank you for your help. Though I must confess that although I realize Sawakita has posted stuff from the pokeyellow disassembly. ASM files it seems? I am not sure how to find those locations within the rom. For example, do I use the 267 from     engine/add_party_mon.asm:267:   ld hl, Moves     to search for a command and change the address. Because I tried searching the values in Gameboy Assembly Editor and am having trouble understanding what exactly I am supposed to change.

Also Sawakita, when I first started working on my hack, I had no idea what the pokeyellow disassembly was. I now kind of get the basic idea how it works. But until you said something I actually didn't know there was a pokeyellow disassembly. I did know of of pokered however. Although I cant say whether or not I would understand it if I tried as I have no prior experience with a dissasembly while I am quite content with hex editing.

Last edited by Picrodus (2016-04-09 18:42:49)

Offline

#5 2016-04-09 21:16:18

Crystal_
Member
From: Spain
Registered: 2012-09-16
Post 369/430
Website

Re: Pointers to the Moves Data Table

The problem of doing these kind of things through hex editing is that it's going to take an hour while it would be taking a few minutes through the disassembly and you'd end up with a cleaner and less bug-prone result. In this case where all the references seem to be farcalls, in the disassembly you'd be able to get it done by just moving the include of the moves file to the section/bank you want and fixing what appears to be a reference from the same bank in trainer_ai.asm. With hex editing you'll have to spend a lot of time searching every single pointer/bank load in order to modify it, while the code in trainer_ai will probably require moving some of the code to the new moves bank.

267 is just the line where the Moves load instruction is in the asm file, which has nothing to do with the instruction's rom location. In the disassembly most functions have the rom location commented at their start and end, so you can use them as a reference when trying to find the pointers with a hex editor.

Last edited by Crystal_ (2016-04-09 21:17:02)

Offline

#6 2016-04-10 13:50:33

Sawakita
Administrator
Registered: 2010-10-16
Post 363/364

Re: Pointers to the Moves Data Table

Picrodus wrote:

when I first started working on my hack, I had no idea what the pokeyellow disassembly was. I now kind of get the basic idea how it works. But until you said something I actually didn't know there was a pokeyellow disassembly. I did know of of pokered however. Although I cant say whether or not I would understand it if I tried as I have no prior experience with a dissasembly while I am quite content with hex editing.

I see, you might have a bit of stuff to port over the disassembly, which I understand might be tedious.

Anyway, as Crystal_ clarified, you can check the previous list of files (the numbers after the colon area the line in those source files where you'd find the pointer references) to retrieve the address in the ROM file.
So, if you open file engine/add_party_mon.asm around line 267 you see we're inside a procedure labeled "AddPartyMon_WriteMovePP", followed by a comment which tells you the address (in this kind of file, anything in a line, after a semicolon, is a comment):

AddPartyMon_WriteMovePP: ; f2fc (3:72fc)

So if you go to address F2FC using your hex editor you'll find the beginning of that procedure, and after a few bytes you'll see the "00 40" you're looking for.

Do it with all the references and you should be closer to the solution.

Offline

#7 2016-04-11 01:06:03

comet
Member
Registered: 2012-04-09
Post 634/679

Re: Pointers to the Moves Data Table

Beware: pokeyellow is not finished, and the maintainer has some files in the repository taken straight from pokered that don't actually make it into the build.

You should still use it, but it's not quite as flexible as pokered yet.

Last edited by comet (2016-04-11 05:36:58)

Offline

Board footer

Powered by FluxBB