Disassembling XSE to ASM

[some_asm]

Hi, I'm new to romhacking and confused concerning the relationship between XSE, ASM and binary.

If I, for example, compile this XSE script:

Spoiler:

#dynamic 0x800000
#org @start
givepokemon 0x34 0x14 0x0 0x0 0x0 0x0
end

I get this in binary:

Spoiler:

79 34 00 14 00 00 00 00 00 00 00 00 00 00 00 02

And if I disassemble it, I get:

Spoiler:

https://imgur.com/a/fEWwzuO

How come I don't get assembly code that I can compile into the same binary as XSE did?

 

[Shiny Miner]

Hi, I'm new to romhacking and confused concerning the relationship between XSE, ASM and binary.

If I, for example, compile this XSE script:

Spoiler:

#dynamic 0x800000
#org @start
givepokemon 0x34 0x14 0x0 0x0 0x0 0x0
end

I get this in binary:

Spoiler:

79 34 00 14 00 00 00 00 00 00 00 00 00 00 00 02

And if I disassemble it, I get:

Spoiler:

https://imgur.com/a/fEWwzuO

How come I don't get assembly code that I can compile into the same binary as XSE did?

What you want to do by this? If you want to test the script just compile it and give the compiled offset to a n pc in advance map , but in your script with there are so many 0x0? Click f1 key in xse and check about giveegg command.

 

[some_asm]

What you want to do by this? If you want to test the script just compile it and give the compiled offset to a n pc in advance map , but in your script with there are so many 0x0? Click f1 key in xse and check about giveegg command.

I was probably unclear! I know how to use the compiled XSE code; that's no problem. I'm trying to learn assembly in, so I would like to produce the same code as the XSE did but with assembly. Intuitively I should be able to disassemble the binary from the XSE code to get the corresponding assembly code, but that doesn't work, and I am unsure why!

 

[Shiny Miner]

I was probably unclear! I know how to use the compiled XSE code; that's no problem. I'm trying to learn assembly in, so I would like to produce the same code as the XSE did but with assembly. Intuitively I should be able to disassemble the binary from the XSE code to get the corresponding assembly code, but that doesn't work, and I am unsure why!

Hmm... Interesting , pokecommunity discord is best place to findout, an asm maker can help here.

 

[some_asm]

What you want to do by this? If you want to test the script just compile it and give the compiled offset to a n pc in advance map , but in your script with there are so many 0x0? Click f1 key in xse and check about giveegg command.

Hmm... Interesting , pokecommunity discord is best place to findout, an asm maker can help here.

Alright, I'll go to the discord! Thanks for your help :)

 

[Asith]

Hi, I'm new to romhacking and confused concerning the relationship between XSE, ASM and binary.

If I, for example, compile this XSE script:

Spoiler:

#dynamic 0x800000
#org @start
givepokemon 0x34 0x14 0x0 0x0 0x0 0x0
end

I get this in binary:

Spoiler:

79 34 00 14 00 00 00 00 00 00 00 00 00 00 00 02

And if I disassemble it, I get:

Spoiler:

https://imgur.com/a/fEWwzuO

How come I don't get assembly code that I can compile into the same binary as XSE did?

XSE starts with a special "scripting language code" (which is really just a bunch of macros) and compiles it into what you call "binary" (which is really just a representation in hex values). This can be converted (or "decompiled") back to scripting language code by XSE again, or by other tools with script editors like HexManiacAdvance. The hex is literally a direct sequential representation of the commands in the script except using hexadecimal and a command table. It is entirely unique to these pokemon games. The game or XSE can read this hex and understand it as script, but it's entirely meaningless outside of that world. If you try to read it as ASM on its own, it's essentially garbage.
ASM can be compiled and represented as hex values as well, and vice-versa, but that isn't a direct bridge to the scripting language used in the pokemon games. In layman's terms these are two different "languages".

Basically, both ASM and our scripting language can be represented in hex, but they are not the same. XSE doesn't just spit out ASM into the rom, it spits out a collection of macros. Eventually these macros may be understood as ASM, but the script itself isn't a store of ASM information, it's just a sequence of values to be understood later

 

[some_asm]

XSE starts with a special "scripting language code" (which is really just a bunch of macros) and compiles it into what you call "binary" (which is really just a representation in hex values). This can be converted (or "decompiled") back to scripting language code by XSE again, or by other tools with script editors like HexManiacAdvance. The hex is literally a direct sequential representation of the commands in the script except using hexadecimal and a command table. It is entirely unique to these pokemon games. The game or XSE can read this hex and understand it as script, but it's entirely meaningless outside of that world. If you try to read it as ASM on its own, it's essentially garbage.
ASM can be compiled and represented as hex values as well, and vice-versa, but that isn't a direct bridge to the scripting language used in the pokemon games. In layman's terms these are two different "languages".

Basically, both ASM and our scripting language can be represented in hex, but they are not the same. XSE doesn't just spit out ASM into the rom, it spits out a collection of macros. Eventually these macros may be understood as ASM, but the script itself isn't a store of ASM information, it's just a sequence of values to be understood later

Thanks for the great explanation! As you said, I assumed that XSE was transpiled to ASM, which I now see isn't! It makes perfect sense that the disassembly in that case is garbage, as you explained.

I'm curious about this "command table" you mentioned. Is this table the same thing as the predefined functions you call by memory addresses in ASM, or is it something else?

I'm referring to this, for example, where Blah is calling the checkflag function:

Spoiler:

main:
push {r0-r2, lr}
@derive 0x828 in register r0
mov r0, #0xFF
lsl r0, r0, #0x3
add r0, r0, #0x30
@this is how we call the function
ldr r1, =(0x806E6D0 +1)
bl linker
@check if set or not
cmp r0, #0x1
beq set
pop {r0-r2, pc}

set:
@if we get here it's set

linker:
bx r1

I took the code from here: https://www.pokecommunity.com/posts/8625292/

 

[Asith]

Thanks for the great explanation! As you said, I assumed that XSE was transpiled to ASM, which I now see isn't! It makes perfect sense that the disassembly in that case is garbage, as you explained.

I'm curious about this "command table" you mentioned. Is this table the same thing as the predefined functions you call by memory addresses in ASM, or is it something else?

I'm referring to this, for example, where Blah is calling the checkflag function:

Spoiler:

main:
push {r0-r2, lr}
@derive 0x828 in register r0
mov r0, #0xFF
lsl r0, r0, #0x3
add r0, r0, #0x30
@this is how we call the function
ldr r1, =(0x806E6D0 +1)
bl linker
@check if set or not
cmp r0, #0x1
beq set
pop {r0-r2, pc}

set:
@if we get here it's set

linker:
bx r1

I took the code from here: https://www.pokecommunity.com/posts/8625292/

If I understand your question correctly, then yes the command table ultimately sends you to the predefined functions for the command itself. I would assume to call them directly in ASM you would indeed call their memory address like in your example. That said, I don't actually use ASM myself, so I won't say I'm sure of that
At this point I would ask if you've heard of the decompilation projects? They are great aides for learning such as this. After all, the game wasn't written in ASM, it was written in C and then compiled into ASM, and we have access to all that C code. It makes it easy to figure out things under the hood.
For example, you can see that the scripting macros themselves are written here, the command table that lines up functions to the commands is written here, and the functions themselves, such as checkflag, are here. Well, probably, I just found these in a quick 5 minute search so they may be elsewhere but you get the idea of how looking through the decomps is easier than looking at a rom when trying to figure out how things work internally. Those links were for the pokeemerald decomp, but the pokefirered decomp would have its own equivalents too

 

[Anon822]

I'm curious about this "command table" you mentioned. Is this table the same thing as the predefined functions you call by memory addresses in ASM, or is it something else?

You can find the command table here.
The functions in that table are not the ones you would call in your own code. If you for example look at the checkflag command, you'll see that it's doing some scripting specific stuff and using the "FlagGet" function which is what you would use in your code to check flags.

 

[some_asm]

If I understand your question correctly, then yes the command table ultimately sends you to the predefined functions for the command itself. I would assume to call them directly in ASM you would indeed call their memory address like in your example. That said, I don't actually use ASM myself, so I won't say I'm sure of that
At this point I would ask if you've heard of the decompilation projects? They are great aides for learning such as this. After all, the game wasn't written in ASM, it was written in C and then compiled into ASM, and we have access to all that C code. It makes it easy to figure out things under the hood.
For example, you can see that the scripting macros themselves are written here, the command table that lines up functions to the commands is written here, and the functions themselves, such as checkflag, are here. Well, probably, I just found these in a quick 5 minute search so they may be elsewhere but you get the idea of how looking through the decomps is easier than looking at a rom when trying to figure out how things work internally. Those links were for the pokeemerald decomp, but the pokefirered decomp would have its own equivalents too

Oh, I though the game was made in ASM! Yes, going through the decomps would be really good idea, especially if there's some kind of tool chain which transpiles the C to ASM. Thanks for the suggestion!

 

[some_asm]

You can find the command table here.
The functions in that table are not the ones you would call in your own code. If you for example look at the checkflag command, you'll see that it's doing some scripting specific stuff and using the "FlagGet" function which is what you would use in your code to check flags.

Oh, so that's how it's done. Thanks a lot!