Pages: « 1234
Posted on 11-16-16, 08:41 pm


Karma: 10
Posts: 10/14
Since: 05-13-16
Was thumb support ever added?
Posted on 11-16-16, 10:06 pm
Fuzzy
Will never finish a hack

Karma: 1773
Posts: 434/777
Since: 03-25-16
Thumb support?
_________________________
hey look, I did a thing
Posted on 11-16-16, 10:08 pm


Karma: 18936
Posts: 823/1087
Since: 04-02-13
Wouldn't thumb support depend on the compiler?
Posted on 11-17-16, 12:07 am


Karma: 10
Posts: 11/14
Since: 05-13-16
Posted by skawo
Wouldn't thumb support depend on the compiler?


Dirbaio said he was gonna add it eventually, and apparently Gericom got it working (but his makes no sense because it only patches code to the ARM9). Don't think the compiler matters.
Posted on 11-17-16, 07:36 pm
Super Mario
( ͡° ͜ʖ ͡°)

Karma: 9135
Posts: 4350/4434
Since: 06-08-11
The ASM hack template compiles all the ASM hack code to ARM mode, not Thumb.

Still, it is possible to add hooks to Thumb code that point to the ARM code in the ASM hack. This is on NSMBe's side, not on the compiler/makefile of the ASM template.

Why are you insterested on patching Thumb code? NSMB has almost no Thumb code, this has never been a problem.
Posted on 11-17-16, 08:23 pm


Karma: 10
Posts: 12/14
Since: 05-13-16
Posted by Dirbaio
The ASM hack template compiles all the ASM hack code to ARM mode, not Thumb.

Still, it is possible to add hooks to Thumb code that point to the ARM code in the ASM hack. This is on NSMBe's side, not on the compiler/makefile of the ASM template.

Why are you insterested on patching Thumb code? NSMB has almost no Thumb code, this has never been a problem.


Multiple code blocks I have found in Zelda Phantom Hourglass are in thumb mode. I need a thumb compiler for some hacks I wan't to make like swapping the top and bottom screens.
Posted on 11-21-16, 02:50 am
Super Mario
( ͡° ͜ʖ ͡°)

Karma: 9135
Posts: 4352/4434
Since: 06-08-11
Okay, I see.

Well, the good news is you don't need a Thumb *compiler*. GCC can compile to Thumb, but it's perfectly fine if you compile your code to ARM: you can make hooks that call ARM code from Thumb code.

To add Thumb support you would need to create some new hook types that emit the proper Thumb instructions to jump to the ARM code.

The hook types are implemented in NSMBe here:

https://github.com/Dirbaio/NSMB-Editor/blob/master/NSMBe4/Patcher/PatchMaker.cs#L106
Posted on 11-23-16, 05:20 am


Karma: 10
Posts: 13/14
Since: 05-13-16
Posted by Dirbaio
Okay, I see.

Well, the good news is you don't need a Thumb *compiler*. GCC can compile to Thumb, but it's perfectly fine if you compile your code to ARM: you can make hooks that call ARM code from Thumb code.

To add Thumb support you would need to create some new hook types that emit the proper Thumb instructions to jump to the ARM code.

The hook types are implemented in NSMBe here:

https://github.com/Dirbaio/NSMB-Editor/blob/master/NSMBe4/Patcher/PatchMaker.cs#L106


Wait, so your saying I can just hook the thumb code and it will be fine? That's a relief. Phantom Hourglass uses quite a bit of thumb from the code I've debugged so far.
Posted on 11-23-16, 09:29 pm
Super Mario
( ͡° ͜ʖ ͡°)

Karma: 9135
Posts: 4362/4434
Since: 06-08-11
No, it won't work out of the box, because of the following:

How patching works is that NSMBe changes one instruction at the destination. For exmaple, if you have nsub_xxx, NSMBe will go to address xxx, and overwrite whatever instruction is there with a "B xxxx" instruction.

NSMBe generates the binary encoding for the instruction. For example this function generates the B and BL opcodes.

The problem is these are B and BL opcodes for ARM. The binary encoding for these opcodes in Thumb is different, so if you use one of the hook types currently implemented, it'll insert an ARM instruction in the middle of Thumb code, and the CPU will go boom when it executes that.

You'd need to make new types of hooks (for example nsubt, replt, and hookt) and make them inject Thumb instructions instead of ARM instruction.
Posted on 11-23-16, 11:26 pm
Death by cuteness

Karma: 6284
Posts: 592/598
Since: 05-01-13
Posted by MeroMero
  • ASM patcher handles 2 new methods:
    • xrpl: which replace the 4 bytes on where you hook the code into a BLX instruction
    • lrpl: which replace the 6 bytes on where you hook the code into a PUSH LR followed by a BLX instruction, which is only needed in case you want to modify a part of THUMB code that uses the BX LR return method




http://nsmbhd.net/file/f721ce0c46e4a98bd2bd/nsmb-editor-380b.zip


This is the prototype version of NSMBe that I sent to  Dirbaio a while back, which contains this:



and also the following updates:
_Added support for Chinese NSMB Rom.
_NSMBe can open .ids files now.
_iQue protection byte will automatically be set to 0 for any NSMB ROM regardless of the region.
_When drawing the sprites in the Level Editor, NSMBe now takes into account the Actor itself rather than the Sprite.
_Decompress overlays work again!
_Also added the xrpl and lrpl method for the ASM Patcher.
_On top of that the ASM Patcher now takes into account the following 35 ROMs before putting the "uint sectionTableAddr" parameter to use:

_Conveyor Belts direction highlighted as per  Hiccup request
_Tileset, FG and BG names updated according to  KingYoshi list
__Sprites will take the ActorData from the Actor they are linked to;
_Sprites' names on the level editor will now take into account their respective Actor rather than the Sprite itself;
_Changes to Sprite<>Actor associations in the table located in overlay 0 will be reflected correctly on the Level Editor upon restarting the NSMBe;
_spritedata.xml, while it keeps its name, now holds the data for the Actors themselves rather than the Sprites as it previously did;
_the ids in the spritedata.xml field tags now take ids from 1 to 48 (bit), improved from the previous range of 0 to 11 (nybble).
_last but not least, SpriteData.cs was modified to make the Level Editor capable of reading and writing SpriteData (or rather ActorData now) bit per bit as opposed to nybble per nybble, allowing for far more accurate parameters (as in taking into account modulos when data was read nybble-wise), or even new parameters that couldn't be previously specified



The xrpl method (x as in BLX and rpl as in replace) is the one you're going to use the most.
The lrpl method (l(r) as BX LR and rpl as in replace once again) as said before is the one you want to use if you want to hook your code at a place that uses a BX LR return, in the case you should use a BX Rn method to end your custom code with, where n can be any free register from 0 to 12 included.

Keep in mind that your custom code have to be written in ARM, those two methods just make it so that custom ARM branches are also compatible with THUMB.

Now whether you use xrpl or lrpl, your custom branch should always begin with a NOP instruction, and that's because there's a glitch that can happen when switching from THUMB to ARM (not from ARM to THUMB though), sometimes the BLX instruction will branch at the specified offset + 4 instead; beginning your custom code with a NOP will nip that inconvenience in the bud quite nicely.

Below you can have a look at some examples on how to use the xrpl and lrpl branches:
http://nsmbhd.net/get.php?id=OIbD70dHkh91UirT
Posted on 11-23-16, 11:37 pm


Karma: 10
Posts: 14/14
Since: 05-13-16
Posted by Dirbaio
You'd need to make new types of hooks (for example nsubt, replt, and hookt) and make them inject Thumb instructions instead of ARM instruction.


Yeah, no way I would be able to make it do that.

Another question: is the OS_GetInitArenaLo method the same for all games? I don't mean the offset, I know that that is different, but do any of the instructions change from game to game? I opened my ROM in IDA Pro and can't seem to find it.
Pages: « 1234