Was thumb support ever added?

Thumb support?
_________________________
hey look, I did a thing

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.

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.

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.

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.

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

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.