• Just a reminder that providing specifics on, sharing links to, or naming websites where ROMs can be accessed is against the rules. If your post has any of this information it will be removed.
  • Our friends from the Johto Times are hosting a favorite Pokémon poll - and we'd love for you to participate! Click here for information on how to vote for your favorites!
  • Cyndy, May, Hero (Conquest), or Wes - which Pokémon protagonist is your favorite? Let us know by voting in our poll!
  • Welcome to PokéCommunity! Register now and join one of the best fan communities on the 'net to talk Pokémon and more! We are not affiliated with The Pokémon Company or Nintendo.

[ASM & Hex] Label address

  • 61
    Posts
    9
    Years
    Hi everybody, I'm analyzing the ASM code of the special 0x17b (boat animation) in pokemon fire red, it uses the instruction bl, the disassembled code shows "bl $080006f4".
    I think this rom address is a label since bl instructions branch to labels as far as I know, but the address isn't pointed anywhere in the game, and after observing the debugger, the address is not in a register either.

    My question is : how to find this address ?
    I mean, how does the machine know it ? this address comes out of nowhere. There must be a calculation but I don't know what it is.

    When I assemble ASM code, there is usually a pointer for each label at the end of the routine, but it's not the case for the special 0x17b (and probably many other functions).
     
    Last edited:
    I'm not sure if the address is calculated from the program counter in this case, here is what the debugger vba-sdl-h shows:
    [PokeCommunity.com] Label address


    If you or anyone else can explain how the address 080006f4 is calculated, I would appreciate.
     
    Last edited:
    Firstly, don't use VBA-SDL-H. Use the debugging version of No$GBA.

    You never need to care how instructions are encoded. You will never need to do this yourself.

    The offset is a 23-bit signed integer; the least significant bit is zero. Because the least significant bit is always zero, it doesn't need to be encoded, so you split the remaining 22-bits in two 11-bit halves.

    A bl instruction, despite ostensibly being a single instruction, is actually a pair of instructions. Each instruction in THUMB is 2-bytes, so a bl is 4-bytes. We'll call the first half-instruction bll and the second one blh (note that these aren't standard names).

    The more significant half of our offset is placed into the 11 least significant bits of the encoding of bll, and the less significant half of our offset is placed into the 11 least significant bits of the encoding of blh.

    0x08146E7C (the location of your bl instruction) contains B9 F6 3A FC. Based on the description above, you calculate the offset with ((0xF6B9 & 0x1FF) << 12) | ((0xFC3A & 0x1FF) << 1). This gives you 7051380, but of course this is a signed 23-bit integer, so that's really -1337228.

    This is relative to where we will return to, so that's 0x08146E80. 0x08146E80 + -1337228 is 0x080006F4, and what do you know, that's where the bl is supposed to go to.
     
    Last edited:
    Back
    Top