Final Fantasy Hacktics

Modding => Hacking/Patching Tools => Topic started by: Glain on May 08, 2011, 12:41:12 am

Title: (App) MassHexASM: Encode directly to little endian (v13 Update: 1/11/2017)
Post by: Glain on May 08, 2011, 12:41:12 am
Latest version now included with FFTPatcher suite! (Thread: https://ffhacktics.com/smf/index.php?topic=7163)

---

After being frustrated with manually switching ASM byte order, I've decided to write MassHexASM, a program that lets you encode directly to little endian, and furthermore, should be able to encode ASM in a format where you just copy/paste the output to an XML patch (or what have you).

This program was written in C#/.NET, so you'll need some version of the .NET framework to get this to run. I believe it should work with .NET version 2.0 or later. Other than that, should be all good. Let me know if you find bugs and I'll do what I can to fix 'em.

Note on using the program: If you define a label, you need to put a colon ( : ) after it. If there is a command on the same line, separate it from the label by at least one space.

Some differences between MassHexASM and the Renegade64 assembler:
     * The little endian format uses the correct byte order: B4,B3,B2,B1. It also outputs the hex directly instead of trying to format for Gameshark.
     * My program encodes BEQ and BNE instructions properly. Renegade64 switches the order of the registers for some reason, which it can get away with because they're just used for an equality check, but it is still weird.
     * Encoding and decoding in the same form with little endian format. In testing, I've looked in the various XML files used by FFTorgASM, pasted patches straight into my program, entered a starting address, specified little endian and decoded it. Useful if you've got encoded hex but can't remember what the ASM is.
     * Ability to specify a starting address without using .org (Important for decoding as well)
     * You can pad the output with spaces if you want to preserve formatting when pasting into an FFTorgASM patch.
     * You should be able to use same-line labels. (i.e. put a label and the next instruction on the same line)
     * Registers can use the $[num] format. (e.g. $4 instead of r4). You can still use names like $s0, $t2, etc.
     * You can specify negatives as offsets in save/load instructions (i.e. -0x7fad, as the screenshot shows). The negative sign has to be before the 0x, not after.
     * Encodes statements without regard to whether or not they make sense. This means Renegade64 will stop you in certain cases where my program won't, primarily when BEQ/BNE addresses are invalid.

Java version now available... check the attachment list. To use it, run "java -jar JMassHexASM.jar" in the command line in the directory that contains the jar file. (Updated: I fixed a bug with the Java version)

Changelog:

v13:
      * LEDecoder has been added to MassHexASM, accessed via a menu item (Form -> LEDecoder), and LEDecoder is no longer a standalone program.
      * MassHexASM now checks the ASM upon encoding or decoding and displays warnings for various possible hazards, listed below.
      * MassHexASM uses the latest version of the ASM Encoder/Decoder, which includes numerous fixes, as well as the latest changes:

     * Added check functionality that warns about various possible hazards:
        * Load delay (Attempt to use a loaded value from memory immediately after loading it; ignored in PSP mode)
        * Unaligned offset (When doing a memory load or store)
        * Using mult or div within 2 commands of mflo/mfhi
        * Adding or subtracting a value from the stack pointer register ($sp, r29) that is not a multiple of 8
        * Putting a branch inside a branch delay slot
       
    * Added the ability to use %hi(address) and %lo(address) to get the high and low 16-bit parts of an address.  The low 16-bit portion is considered to be signed.  e.g.:
        * .label @address_current_action, 0x80192d90
        * # (...)
        * lui   t0, %hi(@address_current_action)
        * # (...)
        * lw    t0, %lo(@address_current_action)(t0)
       
        * Note that %hi(address) will be one higher than first 16 bits when the low 16 bit value is negative.
        *   e.g. %hi(0x8018f5f0) = 0x8019; %lo(0x8018f5f0) = -0x0a10 (0xf5f0).
        * This means that the %hi,%lo combination works well with load and store commands, and also with the (lui, addiu) pattern, but not with the (lui, ori) pattern.
       
    * Fixed some issues with the load and store psuedoinstructions when using values between 0x8000 and 0x10000.
       
    * Modified the error checking functionality to report more errors, particularly when an undefined label is referenced.
       
    * Now recognizes GTE and COP0 register names as used by pSX's disassembly.
    * Added beqz (branch if equal to zero) and bnez (branch if not equal to zero) psuedoinstructions.
   
    * Fixed potential issues with byte order that could have occurred if running on a big endian machine.
   
    * Added "replaceLabels" optional attribute to the <Location> tag in XML patches, which, if set to "true", will replace any labels found in the hex with the correct hex address.  The idea here is basically to be able to create dispatch tables using a list of labels if so desired.
   
    * (Undocumented from last release)
    * Added "equivalences" which function similar to macros. Defined with .eqv and are replaced with the specified value before encoding.  e.g.:
        * .label @address_controller_input, 0x80045944
        * .eqv   %start_button_flag, 0x0800
        * # (...)
        * lw     t0, @address_controller_input
        * nop
        * andi   t0, t0, %start_button_flag
        * # (...)

    * The "li" pseudoinstruction now accepts negative values correctly.

v12:

     * Changed the window anchoring so that resizing the window causes the ASM and/or Hex textboxes to expand.  Expanding the window to the right now causes the ASM textbox to expand (as well as the messages window); expanding downward causes both ASM and Hex to expand.
     * Any label starting with the '@' character is now a "persistent label" that will stay around even if not defined in the current code block.
     * Added ".label" directive to define label addresses without putting them inside the code.  The format is: .label (name), (address).  Example: .label  @clear_data_block, 0x05e644
     * Decoding no longer requires newlines; you should just be able to paste straight from a hex editor and it will decode every 4 bytes (8 hex digits) as a command. 
     * Fixed some bugs relating to labels that contained a command on the same line.
     * The encode/decode textboxes are no longer limited to 32767 characters.

v11:

     MassHexASM

     * Both textboxes are now using a fixed-size font (Courier New) at a bigger size. Widened the ASM textbox to accommodate the bigger font.
     * Error reporting (in the "Messages" area) should now report more errors and be more specific.  You should at least get a warning if it skips a line entirely (e.g. an unrecognized command when encoding).  Decoding will also report unknown commands.

     LEDecoder

     * Can now specify starting address.

     Both (MassHexASM and LEDecoder)

     * "Mode" dropdown added to select between PSX/PSP modes (as well as a generic Base mode).  This will primarily affect coprocessor 2 instructions (GTE, VFPU) which differ between the two.  This won't restrict the instruction set completely to ones supported by the CPU.
     * Added support for many new MIPS instructions up to the MIPS32R2 instruction set.
     * PSX mode should contain GTE instructions. Format is slightly different from psxfin's disassembly. GTE registers (both data and control registers) can be referred to simply using the generic format $(num), which works with all register types.
     * Coprocessor 0 registers can also be referred to using $(num).
     * PSP mode should contain the VFPU commands as well as other PSP-specific commands (bitrev, max, min, etc).
     * With the new instructions recognized, there should be no more unknowns in PSX/PSP code!
     * MassHexASM and LEDecoder now both use the same encoding/decoding engine (as well as FFTorgASM, upon release of the next FFTP version).
     * You should be able to specify addresses >= 0x10000000 (either with the starting address textbox, or a .org statement).
     * Encoding/decoding uses an entirely new process and should be significantly faster (In my testing, a decoding of the PSP's EBOOT.BIN going from about 10s to < 3s on LEDecoder). You'll probably only notice the speed if encoding/decoding a LOT (thousands) of commands at once.
     * The input file formats have changed significantly with a lot more options/flexibility. I can give more detail if needed, though it's somewhat complicated...
     * Decoding a line can produce "illegal" if the decoder found the instruction and determined that the inputs are illegal/impossible (typically this can only happen with ins/ext instructions). An unrecognized encoding is still "unknown".  If the program hits an unexpected error trying to decode a line, it can produce "error", but this shouldn't happen if the program is working properly.
     * You can use ';' to denote comments, just like '#'.
     * Syscall and break should now properly use 20-bit immediates.
     * Decoding is less lenient; invalid code will produce more unknowns.

v10:
     * Fixed a bug where load/store instructions with negative offsets were encoded with incorrect hex (and were treated incorrectly as pseudoinstructions).

v9:
     * Fixed a bug where newlines in the assembly section were erroneously removed when encoding.
     * Added a "name registers" option that uses register names like r2 = v0, r4 = a0, r29 = sp, r31 = ra, etc, when decoding.

     * MassHexASM can now support many psuedoinstructons even if they take multiple lines. The list of psuedoinstructions here (http://en.wikipedia.org/wiki/MIPS_architecture) should mostly be supported. You can also do fun things like lw r2,0x80192d90 and lbu r3,0x801908cc(r4), although these commands always generate the entire address, so this will be less efficient in cases where you can reuse part of the address. Those two statements would become 5 lines of regular ASM, but this example can be done in 4. As a sidenote, these pseudoinstruction patterns are very apparent in FFT's ASM code.

v8:
     * When decoding, immediates will now properly show as signed or unsigned based on the instruction. These are the affected commands:
         Unsigned: andi, ori, xori, sltiu
         Signed: addi, addiu, slti

     * Added a "Show Addresses" option which will show the appropriate addresses on encode/decode in the left textbox.

     * Added support for 'select all' using ctrl+A.
     * Little Endian is now the default byte order.

v7:
     * Added support for srav, jalr, break (10-bit immediate), syscall (10-bit immediate) and trap (26-bit immediate) commands.
     * Fixed a bug where label addresses could be calculated incorrectly when the input contained instructions on the same lines as labels, resulting in incorrect hex for branch/jump instructions.
   
v6:
     * Fixed a bug where an instruction on the same line as a label could be parsed incorrectly.

v5:
     * Fixed a bug with encoding long immediates (such as in the j command) when all eight hex digits were not specified.

v4:
     * Fixed a bug where the program failed to encode certain I-type instructions (bgez,blez,bgtz,bltz,bgezal,bltzal).
     * Fixed a bug where the program could incorrectly decode certain I-type instructions (bgez,blez,bgtz,bltz,bgezal,bltzal).
     * Added support for mthi/mtlo instructions.

v3:
     * Added support for comments on the same line as commands. (They'll need to preceded by #)
     * Fixed a bug where labels would only be recognized if they were from earlier points in the code.
     * Fixed a bug involving placement of tab characters that could cause the program not to recognize lines of code.
     * Added support for nor/not instructions.

v2:
     * Can now decode to negative offsets in the appropriate cases for addi and similar instructions.
Title: Re: (App) MassHexASM: Encode directly to little endian
Post by: Eternal on May 08, 2011, 01:29:56 am
I'm sure this will be incredibly helpful for your fellow ASMers. Thanks for the contribution, it means a lot! :D
Title: Re: (App) MassHexASM: Encode directly to little endian
Post by: formerdeathcorps on May 08, 2011, 02:34:40 am
Your tool is great: it makes Renegade64 obsolete and has a copy/paste feature.

Just as a digression:

Quote
8. You can specify negatives as offsets in save/load instructions (i.e. -0x7fad, as the screenshot shows). The negative sign has to be before the 0x, not after.


Does this also work with addi?
Title: Re: (App) MassHexASM: Encode directly to little endian
Post by: Xifanie on May 08, 2011, 04:15:23 am
Awesome. Adding an option to save to quicksave would be terrific.
Title: Re: (App) MassHexASM: Encode directly to little endian
Post by: pokeytax on May 08, 2011, 11:11:35 am
Quote from: formerdeathcorps on May 08, 2011, 02:34:40 am
Your tool is great: it makes Renegade64 obsolete and has a copy/paste feature.


What he said, I've already forgotten about Renegade64 after fifteen seconds of using this. The easy decode is great.
Title: Re: (App) MassHexASM: Encode directly to little endian
Post by: Pride on May 08, 2011, 02:34:02 pm
This. Is. Incredible. Thank you so much!

Edit: Deleted Renegade, completely worthless now.
Title: Re: (App) MassHexASM: Encode directly to little endian
Post by: Glain on May 08, 2011, 08:56:45 pm
Thanks guys! Glad to see the program being used and speeding things up! Didn't expect I'd just waltz right in and make Renegade totally useless, but if that's what I've done then that's sorta hilarious and awesome at the same time.

Xifanie: Quicksave as in a pSX quicksave, like a save state? That would be interesting... I may have to look into that.

formerdeathcorps: I believe it would encode the negative offsets correctly, but would decode the hex to a positive offset. A new version I've just added to the original post should rectify that. I wasn't sure which instructions treated the offsets as postive/negative, so I got my hands on SPIM and played around a bit.

(I totally didn't just realize that the "addiu" instruction on the stack pointer that I keep seeing in subroutines is actually a subtraction instead of a huge addition... :) I was always wondering how that register got back to its original state... now it makes sense)
Title: Re: (App) MassHexASM: Encode directly to little endian
Post by: Pickle Girl Fanboy on May 10, 2011, 12:06:44 pm
You should tell the guys over at RHDN and gamehacking.org about this.
EDIT
Nevermind, I already did.

http://www.romhacking.net/utils/635/
^Gemini says this is better.
Title: Re: (App) MassHexASM: Encode directly to little endian
Post by: Lazy Bastard on May 10, 2011, 03:39:30 pm
Nice app. Mind if I add it to the Downloads section of GameHacking.org?

Incidentally, it should be noted that Renegade64 (which, by the way, has been superseded by RenegadeEX) isn't made useless by this tool, except in the specific way you previously used it. It's still a very good hacking tool, with many other uses.
Title: Re: (App) MassHexASM: Encode directly to little endian
Post by: Glain on May 10, 2011, 08:28:47 pm
Quote from: Lazy Bastard on May 10, 2011, 03:39:30 pm
Nice app. Mind if I add it to the Downloads section of GameHacking.org?

Incidentally, it should be noted that Renegade64 (which, by the way, has been superseded by RenegadeEX) isn't made useless by this tool, except in the specific way you previously used it. It's still a very good hacking tool, with many other uses.


Yeah, I'm pretty sure this context was understood for Renegade. Sure, you can host my program if you want; if I do make updates I'll probably put them here though.

Regarding armips: I checked it out, pretty cool. It looks like it's both an assembler and a patcher, which in certain situations is going to be easier, but in others may not fit as well, like in this case (Since we're using FFTorgASM as patcher, we really just needed an assembler). Just depends on what you're trying to do. If I was just going to assemble codes and was going to load a program as an external file, I'd just use PCSpim probably (heck, it even executes the code).
Title: Re: (App) MassHexASM: Encode directly to little endian
Post by: Glain on May 21, 2011, 10:27:27 am
All right, I'm releasing an updated version (v3) because I realized it needed a few fixes.

* Added support for comments on the same line as commands. (They'll need to preceded by #)
* Fixed a bug where labels would only be recognized if they were from earlier points in the code. (Branches to labels could only go backwards) (When defining a label you still need to put a : after it)
* Fixed a bug involving placement of tab characters that could cause the program not to recognize lines of code.
* Added support for nor/not instructions.

With this version I encoded a pretty big (100+ statements) code block with labels and comments (and using that as a test case was what prompted the release of this version). The goal, as always, is to be able to just copy/paste ASM and get the hex in the right format.
Title: Re: (App) MassHexASM: Encode directly to little endian
Post by: Pride on May 21, 2011, 02:23:38 pm
Very nice update, thank you!
Title: Re: (App) MassHexASM: Encode directly to little endian
Post by: Xifanie on May 21, 2011, 03:01:30 pm
I will need the source of this later on; I have an idea of creating an excel workbook which patches directly to the ISO.
It would take all the ASM hacks, and concatenate them perfectly next to each other to save a lot of space. It would also be able to remove ASM hacks; only and only if you have the spreadsheet alone that you patched with. Else it will not be able to remember the old code in order to restore it. It will also allow anyone to edit the code without worrying to much about other hacks.
I'd love to implement a "patch directly to quicksave" feature.
Title: Re: (App) MassHexASM: Encode directly to little endian
Post by: Pickle Girl Fanboy on May 23, 2011, 05:40:24 pm
I love you Xifanie.
Title: Re: (App) MassHexASM: Encode directly to little endian
Post by: Glain on June 21, 2011, 07:41:56 pm
A few issues were brought to my attention with this, so it looks like it needed an update. I attached it to the original post. I also edited the OP to clean it up a bit.

Anyhow, v4's changelog:
     * Fixed a bug where the program failed to encode certain I-type instructions (bgez,blez,bgtz,bltz,bgezal,bltzal).
     * Fixed a bug where the program could incorrectly decode certain I-type instructions (bgez,blez,bgtz,bltz,bgezal,bltzal).
     * Added support for mthi/mtlo instructions.
Title: Re: (App) MassHexASM: Encode directly to little endian
Post by: Pride on June 21, 2011, 07:49:47 pm
Like always, thank you for your updates on this.
Title: Re: (App) MassHexASM: Encode directly to little endian
Post by: FFMaster on June 25, 2011, 07:26:56 am
Hey, this is a great program, but there is just one tiny thing I get annoyed at =p

For example, the jump command

instead of simply typing j 0xaaaaaa, i have to type j 0x00aaaaaa. If you could set it up so that it accepts both formats, that would be awesome. If not, no biggie, I'll just get used to adding a few 0's.
Title: Re: (App) MassHexASM: Encode directly to little endian
Post by: Glain on June 25, 2011, 12:57:11 pm
Ah, you've uncovered a bug. That was supposed to work, but the program was doing some things incorrectly. I've gone ahead and fixed it; I've attached a new version to the original post. Happy encoding... let me know if you find anything else that seems off!

Edit: I'm sure 0xaaaaaa is just an example, but if you do try to use that as a test case, I should probably point out that it isn't a valid address for j, as it's not a multiple of 4 and therefore can't be a code address :) I was testing encode/decode on it and was confusing myself when I saw that it decoded to [j 0xaaaaa8] but that's correct because it's the closest previous code address.
Title: Re: (App) MassHexASM: Encode directly to little endian
Post by: Pickle Girl Fanboy on June 27, 2011, 05:47:49 pm
Hey, is this written in C# or some other .NET language?

EDIT
Quote from: Glain on May 10, 2011, 08:28:47 pm
Regarding armips: I checked it out, pretty cool. It looks like it's both an assembler and a patcher, which in certain situations is going to be easier, but in others may not fit as well, like in this case (Since we're using FFTorgASM as patcher, we really just needed an assembler). Just depends on what you're trying to do. If I was just going to assemble codes and was going to load a program as an external file, I'd just use PCSpim probably (heck, it even executes the code).


Gemini said:
QuoteI really don't know why you'd need XML hacks when the same stuff (if not even better stuff) can be accomplished with simple batches and armips. Something as uncomplicated as a few .include commands can do this magic and much more.


EDIT
You can reply to Gemini directly at:
http://www.romhacking.net/forum/index.php/topic,12592.0.html

http://aerie.wingdreams.net/?cat=18
^Here's where you can download the lastest version of armips.
Title: Re: (App) MassHexASM: Encode directly to little endian
Post by: Glain on June 28, 2011, 07:47:40 pm
MassHexASM is written in C#. The reason I went with C# is primarily because I wanted access to the Windows forms and the web-like elements it contains (textboxes, buttons, what have you). ...Come to think of it, a lot of our apps would probably be more portable (for example, to Linux) if we wrote them in C++ using GNU gcc, or even Java, but that could be annoying.

armips is great and all, and we could use it, but there's no reason to uproot our current encoding/patching process, since we already have our patcher (FFTorgASM) and assembler (MassHexASM, as it takes the mantle from Renegade64). Not worth changing.
Title: Re: (App) MassHexASM: Encode directly to little endian
Post by: RandMuadDib on June 28, 2011, 10:24:43 pm
i'm sorry every time i see 'armips' it always looks like 'armpits' to me o.O
Title: Re: (App) MassHexASM: Encode directly to little endian
Post by: Pickle Girl Fanboy on June 29, 2011, 05:21:40 pm
I don't care one way or another, but I felt obligated to give you Gemini's opinion on this, because he has years of experience with this.
Title: Re: (App) MassHexASM: Encode directly to little endian
Post by: formerdeathcorps on November 02, 2011, 02:27:41 am
Two problems I'm noticing.

sllv/jalr/srav does not convert from hex to ASM and vice-versa.
jr r31 sometimes is translated as jr r1 if you also require a non-zero amount of padding on the generated hex.  I'm not sure if this is just me typing jr 31, though.
Title: Re: (App) MassHexASM: Encode directly to little endian
Post by: Glain on November 02, 2011, 08:27:02 am
I simply missed srav and jalr, so I'll have to add those in. As for sllv, not sure what I'm missing; I see the program producing output for that command, at least if it's got three registers, e.g. sllv r2,r3,r4. That command would shift r3 left r4 bits and store the result in r2?

jr 31 does seem to produce jr r1 if decoded, so it might just be that typo; I'll be on the lookout to see if jr r31 produces the wrong hex in certain situations.
Title: Re: (App) MassHexASM: Encode directly to little endian
Post by: formerdeathcorps on November 28, 2011, 12:46:40 am
sllv is right, I found no more errors there.

Labels still don't work though.  If I try

bne r3, r0, PLACE
....
PLACE:

it will sometimes fail.  If PLACE is separated at least 5 commands from the branch command, it is almost always an undercount.
Title: Re: (App) MassHexASM: Encode directly to little endian
Post by: Glain on November 28, 2011, 02:09:43 am
I made a few attempts to reproduce that, and couldn't; can you give some input that will result in incorrect hex? From my understanding, the number encoded in the beq/bne instruction is the number of commands to jump over, thus:

bne r3,r0,PLACE
nop
nop
nop
nop
nop
nop
PLACE: nop

would result in the bne being encoded as (little endian) 06006014 (jump over 6 commands).

(I suppose the first command after the beq/bne is actually the branch delay slot so it actually isn't "jumped over" at all, but it's still 6 commands between the bne and the label, exclusive.)
Title: Re: (App) MassHexASM: Encode directly to little endian
Post by: formerdeathcorps on November 28, 2011, 02:18:16 am
No, 06 is correct.

The problem is this.  If you do:

bne r3, r0, PLACE
nop
nop
nop
SPOT: nop
nop
nop
nop
nop
PLACE: nop

you'll get 7 instead of 8 because you skip the command with SPOT:
Title: Re: (App) MassHexASM: Encode directly to little endian
Post by: Glain on November 28, 2011, 01:57:17 pm
Ah, nice find. It was getting the label address wrong, because it wasn't incrementing the address of the current line if it ran into a label, without regard to the fact that a command could be on the same line as the label, and it would need to increment the address in that case.

I fixed that problem and added in support for the missing commands you mentioned as well as a few others. I've attached a new version (v7) and added a changelog entry in the original post of this thread. Let me know if you find any more bugs or what have you.
Title: Re: (App) MassHexASM: Encode directly to little endian
Post by: formerdeathcorps on January 15, 2012, 08:48:11 pm
Another small issue.

ori / andi are never signed commands because they are logical bitwise commands.  It's actually quite odd to read
lui r1, 0x8005
ori r1, r0, 0xF874 (just as a random example)

as

lui r1, 0x8005
ori r1, r0, -0x078C

since what I care to find is the address (5F874), not a meaningless (or in this case, wrong) arithmetic/logical operation.

Also, a feature request.  It's annoying in a long routine to find the address of a command buried deep in the routine.  Would it be possible to use the "Comment" box to display the starting and ending address of a highlighted section?
Title: Re: (App) MassHexASM: Encode directly to little endian
Post by: Glain on January 16, 2012, 01:50:21 am
I never even noticed that it was displaying signed numbers for and/or operations. We'll definitely want the unsigned numbers there... I'm adding in some code to differentiate some of those commands. How about this?

Unsigned: andi, ori, xori, sltiu
Signed: addi, addiu, slti
(I'm pretty sure sltiu actually treats the immediate as unsigned, unlike addiu).

You have a good idea there about displaying the addresses of the commands, but I don't like using the Messages box to do it. I was thinking of displaying them to the left of the assembly textbox, but I'm not sure how I'd make that work with scrolling. Maybe I could display

[address] command
[address] command

in the textbox itself, and just ignore everything between brackets when encoding, and have a flag to decide whether you want to see the addresses when decoding. Something like that.
Title: Re: (App) MassHexASM: Encode directly to little endian
Post by: FFMaster on January 16, 2012, 03:15:08 am
I would like that a lot. It would help me, at least.
Title: Re: (App) MassHexASM: Encode directly to little endian
Post by: Glain on January 17, 2012, 12:05:51 am
Here's what I've got now. Does this look about right? I'm just ignoring anything between brackets.

(http://img528.imageshack.us/img528/5223/mha2.png)

Title: Re: (App) MassHexASM: Encode directly to little endian
Post by: FFMaster on January 17, 2012, 01:29:20 am
Yeah, that looks good.

If I had say, these 3 lines of code:

lui r2,0x8019
addiu r2,r2,0x0001
nop

and copy/pasted it into the left box, would the addresses automatically be added in with Show Addresses on?
Title: Re: (App) MassHexASM: Encode directly to little endian
Post by: Glain on January 17, 2012, 10:20:24 am
I don't think I can add the addresses unless I'm going through an encode/decode process... I have to differentiate blank lines, comments, labels, etc, from ASM commands; only the commands get addresses. Plus I don't want to trap the paste action, or typing; it can get a bit messy. I can make Encode show the addresses on the left though.
Title: Re: (App) MassHexASM: Encode directly to little endian (v8)
Post by: Glain on January 25, 2012, 09:02:22 pm
All right, I've released a new version and updated the original post. It should be decoding immediates correctly for all the commands we mentioned, should be able to show addresses on encode/decode and I made a few other changes.
Title: Re: (App) MassHexASM: Encode directly to little endian
Post by: Choto on February 09, 2012, 08:29:14 am
Hey Glain, I'm getting a problem with beq commands, not sure if its me or MHA

I tried encoding:

beq r4, r0, 0x0018ea80

and get

A9638010

I then press decode to check if its correct, and it turns into

beq r4,r0,0x00018ea8

The other address I'm trying goes from

beq r4,r0,0x0018ea24 to
beq r4,r0,0x00018ea4,

which is a little different because it doesn't just shift everything over 1 bit(?) like the previous example.

I wasn't sure if this was the same problem as you guys described before. There were 2 cases of it, one when jumping from 0x0018ea14 to 0x0018ea24 and when jumping from 0x0018ea20 to 0x0018ea80

whachu tink?

P.S. I'm using MasshexASM 8.0
Title: Re: (App) MassHexASM: Encode directly to little endian
Post by: Glain on February 09, 2012, 09:51:44 am
I can test this later, but one thing about the beq/bne instructions is that they're actually encoded as branches over a certain number of statements, as opposed to branching to an address... so the address it displays is very dependent on the "starting address" box and the position in the code it's in. If I have:

0x0018ea6c: beq r4,r0,0x0018ea80
0x0018ea70: (branch delay slot)
0x0018ea74: ...
0x0018ea78: ...
0x0018ea7c: ...
0x0018ea80: (branch target)

The final instruction is basically just "if (r4 == r0), jump over 4 lines (but still run the one in the branch delay slot first)". In other words, the target address isn't in the encoded instruction at all, so if you encode it in different places in the ASM or use different starting addresses, you'll actually get different results. If I decode that example command with MHA and don't specify a starting address, it'll assume a starting address of 0 and it'll come out as:

beq r4,r0,0x00000014

Something to keep in mind with those statements.

EDIT: Oh, and there's also a limit to how far you can branch with the conditional branches (beq,bne,et.al.). You can only go so far (I think 65535 statements?). If you need to go further, use a shorter conditional branch to another place in your code, then use a j statement to get there (which actually encodes an address). In other words, instead of doing this...

beq r4,r0,(really far away address)        # Too far for beq to go... this won't work and can't encode properly.
nop

Use this pattern:

beq r4,r0,(JUMP)
nop
j (PAST_JUMP)
nop
(JUMP):
j (really far away address)                  # j is awesome and can go anywhere (as long as it's a valid code address, i.e. a multiple of 4).
nop
(PAST_JUMP):
(rest of routine)
Title: Re: (App) MassHexASM: Encode directly to little endian
Post by: Choto on February 09, 2012, 10:32:28 am
Ah ha, I see. I specified the starting address and it worked like a charm, thanks for the explanation!
Title: Re: (App) MassHexASM: Encode directly to little endian
Post by: Pickle Girl Fanboy on March 18, 2012, 06:34:11 pm
Testing Java version on Linux Mint 10, 32-bit, Gnome dot dot dot

Fails to load.  I will update my Java and try again tomorrow.
Title: Re: (App) MassHexASM: Encode directly to little endian
Post by: Glain on March 18, 2012, 08:43:14 pm
If you're getting the "Unsupported major.minor version" error, then it is indeed because you need to update Java. I compiled with Java 1.7, which, in retrospect, seems to be pretty recent, and it seems you need Java 1.7 to run it. Basically if "java -version" gives you anything before 1.7, then you need to update.

I just tried this on a Linux (Ubuntu) laptop and got it to work after finally managing to install Java 1.7 (I was getting the "Unsupported major.minor version" error before then). For some reason, apt-get didn't work for me, so I had to follow these (http://askubuntu.com/questions/55848/how-do-i-install-oracle-java-jdk-7) instructions (top answer). I downloaded the JDK, but I imagine the same instructions would work for the JRE.
Title: Re: (App) MassHexASM: Encode directly to little endian
Post by: Pickle Girl Fanboy on April 26, 2012, 06:08:23 pm
Quote from: Glain on March 18, 2012, 08:43:14 pmafter finally managing to install Java 1.7 (I was getting the "Unsupported major.minor version" error before then). For some reason, apt-get didn't work for me, so I had to follow these (http://askubuntu.com/questions/55848/how-do-i-install-oracle-java-jdk-7) instructions (top answer). I downloaded the JDK, but I imagine the same instructions would work for the JRE.

Didn't see this here last time.  And gee golly, Oracle sure does fucking love it's users - see how easy they make updating!
Title: Re: (App) MassHexASM: Encode directly to little endian
Post by: Pickle Girl Fanboy on April 26, 2012, 06:19:23 pm
What portions of each bash script should I change, and what should I change them to?  I'm installing the Java Runtime Environment, not the JDK.

This really makes me want to quit.  Fuck you, Oracle.
Title: Re: (App) MassHexASM: Encode directly to little endian
Post by: Glain on April 26, 2012, 07:29:13 pm
You could probably just follow this (http://askubuntu.com/questions/56104/how-can-i-install-oracle-java-jre-7). I'd also look to make sure they haven't added it to apt-get before writing that off.

Honestly, though... I may just deprecate the Java version (although I suppose it could still be useful). It's annoying to maintain both a C# and a Java version.

You might as well just get everything working with Wine. I'll play around on Ubuntu and see if I can get it to work.

I've got an update coming, mostly for pseudoinstruction support, but that's the C# version.
Title: Re: (App) MassHexASM: Encode directly to little endian
Post by: Pickle Girl Fanboy on April 26, 2012, 07:38:13 pm
I don't really need all the latest features, just bug-fixes.  Though I'll be the only person using the Java version, so IDK about that.

There are C# and VB compilers that are cross-platform.  And I bet that it will work with Wine, but I can't update Wine until I update my OS, can't update my OS until I have an external (this is getting old).
Title: Re: (App) MassHexASM: Encode directly to little endian
Post by: Pickle Girl Fanboy on April 27, 2012, 05:13:07 pm
Okay, I have JRE 1.7 installed.  However, there doesn't seem to be any way to open JMassHexASM with anything but the JDK 1.6, which is what I used to have installed.  I tried to add JRE 1.7 to the Open With prompt, but JRE 1.7 doesn't appear.
Title: Re: (App) MassHexASM: Encode directly to little endian
Post by: Glain on April 27, 2012, 05:52:18 pm
If java -version is telling you anything but 1.7 (might be 1.7.(something)), then 1.7 still isn't being used as the default java version.
If java -version does give you 1.7, then java -jar JMassHexASM.jar should run it. Not sure why the UI would be dumb there.
Title: Re: (App) MassHexASM: Encode directly to little endian
Post by: Pickle Girl Fanboy on April 27, 2012, 06:06:23 pm
ryan@bacon ~ $ java -version
java version "1.7.0"
Java(TM) SE Runtime Environment (build 1.7.0-b147)
Java HotSpot(TM) Client VM (build 21.0-b17, mixed mode)
ryan@bacon ~ $

Thanks!

Feature request: Fixed width font.  Like Monospace, which distinguishes between O and 0 (unlike Courier New or Courier 10 Pitch, which is a free version of Courier New).  It doesn't actually matter at all, because I can format my hex data in leafpad (and windows users can format in notepad), but it is something you may want to consider for your next major release.
Title: Re: (App) MassHexASM: Encode directly to little endian
Post by: Glain on April 28, 2012, 11:13:52 am
Just released version 9, mostly for pseudoinstruction support. This should also fix a few annoying bugs.
Title: Re: (App) MassHexASM: Encode directly to little endian
Post by: Pickle Girl Fanboy on April 28, 2012, 04:28:43 pm
Are psudo-instructions used in existing games?  Because I came across some lines that probably aren't data, yet can't to be decoded.
Title: Re: (App) MassHexASM: Encode directly to little endian
Post by: Glain on April 28, 2012, 06:38:41 pm
Pseudoinstructions are an intermediate step -- they have to be translated to real instructions before being encoded. They don't even have an encoding. Actual program code consists of all real instructions, without exception.

There could just be a few instructions that your disassembler doesn't recognize. I know LEDecoder for one isn't perfect... there are even a few commands in FFT that it marks as unknown. I think they may be graphics or coprocessor calls but I'm not sure. (Example: Some effect files have ASM at the top of them and I get some unknowns in there.)

If everything around the unknown line(s) seems to be valid code in the normal construct of a subroutine, it's probably that. And by that I mean:

(subtract from sp/r29 - pSX makes this look like a huge addition)
(save things to sp/r29, notably ra/r31)
(valid code)
(unknown)
(valid code)
(load things from sp/r29, notably ra/r31)
(add to sp/r29)
(jr ra/r31)
(usually a nop)
Title: Re: (App) MassHexASM: Encode directly to little endian
Post by: Pickle Girl Fanboy on April 28, 2012, 07:03:16 pm
SaGa Frontier
SCUS_942.30
0x00000800 : lb r2,0x0014(r0)
0x00000804 : lb r2,0x2adc(r0)
0x00000808 : lb r2,0x3084(r0)
0x0000080C : lb r2,0x3630(r0)
0x00000810 : lb r2,0x3e34(r0)
0x00000814 : lw r1,-0x7200(r16)
0x00000800 : lb r2,0x0014(r0)
0x00000804 : lb r2,0x2adc(r0)
0x00000808 : lb r2,0x3084(r0)
0x0000080C : lb r2,0x3630(r0)
0x00000810 : lb r2,0x3e34(r0)
0X00000814 : FAILED TO DECODE LINE : 02 06 00 5C
0x00000818 : lw r1,-0x7200(r16)
0x0000081C : FAILED TO DECODE LINE : 03 06 04 9C
Title: Re: (App) MassHexASM: Encode directly to little endian
Post by: Glain on April 28, 2012, 07:21:36 pm
None of that is actually code.

Data can coincidentally be "decoded" to real instructions a lot of the time, because there are only so many possible encodings and a LOT of them are valid. It's just a matter of seeing whether or not what's there actually makes any sense as code.

That doesn't. It isn't. (Why would they overwrite r2 every single line?) Generally only the stuff that follows the "subroutine structure" that I mentioned in my last post is actually code. (Without the unknown, and the sp/r29 stuff may or may not happen) Try searching for jr r31 to try to find real code blocks.
Title: Re: (App) MassHexASM: Encode directly to little endian
Post by: Pride on May 06, 2012, 03:31:01 am
Sometimes when I'm putting code into v. 9 I get a different, slightly longer code then what I originally put in and I'm not sure why. For example, I get this code output:


lui r3,0x800d
addiu r3,r3,0x4644
lw r2,0x0000(r3)
nop
ori r2,r2,0x0002
jr r31
sw r2,0x0000(r3)
lui r2,0x8014
add r2,r2,r3
lui r1,0x8000
addu r1,r1,r2
lbu r2,-0x2a00(r1)
lbu r3,0x0016(r3)
nop
slt r2,r2,r3
bne r2,r0,0x0013d5d4
nop
j 0x00091614
nop
j 0x000915f8
nop


From this one, the hex I put in comes out as the code above with the extra, unnecessary commands of lui r1,0x8000
addu r1,r1,r2


lui r3,0x800d
addiu r3,r3,0x4644
lw r2,0x0000(r3)
nop
ori r2,r2,0x0002
jr r31
sw r2,0x0000(r3)
lui r2,0x8014
add r2,r2,r3
lbu r2,-0x2A00(r2)
lbu r3,0x0016(r3)
nop
slt r2,r2,r3
bne r2,r0,0x0013d5d4
nop
j 0x00091614
nop
j 0x000915f8
nop
Title: Re: (App) MassHexASM: Encode directly to little endian
Post by: Glain on May 06, 2012, 11:01:27 am
Ack, that's pretty bad. Uploading v10 to fix that problem. (Also updating patcher)
Title: Re: (App) MassHexASM: Encode directly to little endian
Post by: Pride on May 11, 2012, 04:25:15 am
It also doesn't appear to convert jalr commands correctly as well

jalr r2,r31 - 00400009
Title: Re: (App) MassHexASM: Encode directly to little endian
Post by: Glain on May 11, 2012, 12:50:50 pm
That's interesting. I had the wrong encoding for jalr.

Try opening mips_encode.dat in a text editor, find the line for jalr, and replace it with this:
jalr : 5 : 000000s00000t00000001001

Then save the change and reload MHA. For "jalr r2,r31", you should get: 0040F809 (big endian). That seems to match up with what the pSX disassembler says the encoding is.

I can add that fix to the next version of MHA, but that should do for now. I can also add a default r31 for the second argument fo jalr. From what I can tell, that's what it's supposed to default to, but for now, it'll just require both args.
Title: Re: (App) MassHexASM: Encode directly to little endian
Post by: Pride on May 11, 2012, 01:51:34 pm
Perfect, thank you ^__^
Title: Re: (App) MassHexASM: Encode directly to little endian
Post by: Choto on January 06, 2013, 10:31:33 pm
I'm gonna make one small quality of life request.. It would be awesome if there were a checkbox that toggled deletion of text that isn't in code format. alot of times I make notes on the ASM routine in notepad and then c/p it to masshex, but then I have to erase each line of notes. If possible, thanks but it's requested at your liesure :P
Title: Re: (App) MassHexASM: Encode directly to little endian
Post by: Glain on January 07, 2013, 12:43:00 am
You mean for notes being added to the end of ASM lines without any separator at all?  Any text following # is treated as a comment and will be ignored (I'm also adding ; to that for the next iteration).

Without some kind of character as a separator for a comment, I'm not sure if I can come up with a rule to determine where the ASM ends and where the comment begins.  There are a few special characters (for example, the comma character, which separates the parameters for an instruction), and if a comment includes one of those characters, it's going to mess up the parsing of the instruction.  If I have a separator character like #, I can just ignore that character and everything after it (which is what it currently does).
Title: Re: (App) MassHexASM: Encode directly to little endian
Post by: Choto on January 07, 2013, 08:26:17 am
Oh crap! that # key is magical! That's perfect, life just got much more convenient lol thanks Glain!
Title: Re: (App) MassHexASM: Encode directly to little endian
Post by: xhai on January 11, 2013, 02:10:12 am
sir is this same as madedit.. can you differentiate the difference.. I'm having trouble in string limitation.. i used madedit for psp translation
Title: Re: (App) MassHexASM: Encode directly to little endian
Post by: Glain on January 11, 2013, 12:20:36 pm
No, this program converts MIPS assembly language to machine code (encode) and vice versa (decode).  MadEdit is a hex editor (the one I use, actually, if I need to hex edit anything).
Title: Re: (App) MassHexASM: Encode directly to little endian (v11 Update: 1/21)
Post by: Glain on January 21, 2013, 08:18:03 pm
All right, I'm finally releasing v11.  This was a pretty big overhaul of the internals and should also provide support for a lot more commands (mostly PSP, but there were a few unsupported PSX ones as well like lwl/lwr/swl/swr and the GTE instructions).  Check the first post for the new version and changelog (I'm sure there are things I forgot in the changelog, but that should cover most of it).
Title: Re: (App) MassHexASM: Encode directly to little endian (v11 Update: 1/21)
Post by: pokeytax on February 03, 2013, 11:15:46 pm
Is jalr intended to be working yet, Glain?  I can't get it to compile correctly.

EDIT: Never mind, I didn't unzip it properly.  Working fine, looks great!

Just so you know, I did the Suikogaiden translation work completely with MHA, by choice.  ARMIPS is useful for certain purposes (I have used it on a GBA translation) but I love this tool, thanks for making it.
Title: Re: (App) MassHexASM: Encode directly to little endian (v11 Update: 1/21)
Post by: Glain on February 05, 2013, 11:37:07 am
You're quite welcome!  It's really good to hear that you've put MHA to some good use in a project (even outside of FFT)!  Looks like it's come a long way from me looking at some assembly encodings and thinking "Hey, it could be fun to write a program that can do this..."
Title: Re: (App) MassHexASM: Encode directly to little endian (v11 Update: 1/21)
Post by: Choto on April 02, 2013, 10:33:44 am
I have another request about comments. Could you make it so that as you resize the window, the text boxes stay anchored to the right and the ASM text box gets stretched? It would make it much easier to read the code with long comments as the commands and comments would be lined up nicely =)
Title: Re: (App) MassHexASM: Encode directly to little endian (v11 Update: 1/21)
Post by: Glain on May 28, 2013, 11:03:26 pm
So I think I have that figured out... the window resize/anchoring thing, that is.  I also hit a situation where putting a label on its own line was giving me a warning that the encoder was ignoring the line. The encode still worked fine and the label worked properly, but the warning message was extraneous, so I've added a check for that and it should no longer display that in the next version.

I've currently got both MHA and LEDecoder in the actual FFTP project since I'm compiling the same ASM encoding library into FFTorgASM.  I'll probably update this at the same time as FFTP .483 since they're all compiled together, although I could update this early.  Really, for FFTP, most all the actual changes of .483 are in, it's just the testing and/or trying to reproduce bugs-with-no-test-cases-but-that-have-happened-before-no-really is something I keep putting off.

Edit: I'm also adding in "persistent labels" starting with @ that will stay around even if you don't define the label in the next chunk of ASM.  Basically what this is working towards is allowing me to specify huge swaths of ASM to FFTorgASM without having to specify concrete addresses for jal/branching/etc. (e.g. In one XML block:  @routine_name: [routine ASM], then in another block: "jal @routine_name" instead of "jal 0x16c034" or whatever).

Edit: Decoding no longer requires newlines; you should just be able to paste straight from a hex editor and it will decode every 4 bytes (8 hex digits) as a command.  I'm also supporting a ".label" directive to define label addresses without putting them inside the code.

Edit: I've also fixed some bugs with same-line labels.  The encode/decode textboxes are no longer limited to 32767 characters.
Title: Re: (App) MassHexASM: Encode directly to little endian (v11 Update: 1/21)
Post by: Choto on May 29, 2013, 08:03:50 pm
Glain makes dreams come true! Thanks man.

Question for you, what are these programs edited in? I'm getting my feet wet developing a Visual Basic application that i'm keeping somewhat of a secret for now. I'm designing the layout first and then i'll dive into coding for it.. any tips or things I should know going in?
Title: Re: (App) MassHexASM: Encode directly to little endian (v11 Update: 1/21)
Post by: Glain on May 30, 2013, 11:19:25 am
Hmm, nice.  Mysterious coding projects are always fun!

FFTP/MHA/LED are all done in C# using the standard Windows forms for the layout. (I'm using an express version of Visual Studio 2012 as the IDE at the moment)

Visual Basic actually uses a similar framework for layout, though the code syntax is quite a bit different.

As for tips... well, for one thing, when you design the layout, don't forget to name your form elements (e.g. for a textbox that contains a title, you could give it a name like txt_Title). You might not see the difference when you're designing the layout, but when you get to the coding, it's far easier to work with form elements with names like txt_Title than ones with names like Textbox3 or what have you.
Title: Re: (App) MassHexASM: Encode directly to little endian (v12 Update: 7/4)
Post by: Glain on July 04, 2013, 07:00:14 pm
Updated with a new version containing the features discussed in the last few posts.  The first post is updated with the download and changelog for v12.
Title: Re: (App) MassHexASM: Encode directly to little endian (v12 Update: 7/4)
Post by: formerdeathcorps on November 26, 2013, 11:39:27 am
Two requests:
1) The ability to save my work (replete with comments and labels) in a readable (i.e. 1 ASM command + comments per line) format.  For writing long routines, this is an absolute must because if I only finish half my routine and want to come back to it later, I literally have to leave my computer and massHex open until my second sitting or post my half-finished work on FFH.  The latter isn't very efficient because I need Internet to access my code again (not a guarantee) and all the previous labels would be gone, so I would need to spend some time relabeling (and re-remembering) the logic of my previous code.  This also has the added benefit of making it easier for coders to check each others' work because we can transfer labels.  Although I'm fairly fluent in ASM, I know some of the newer coders find my code hard to read upon first inspection (and being able to transfer labels and comments would greatly help them understand).
2) The ability to use Ctrl + F to find certain registers or labels (very helpful for debugging long routines).  I'm sure pokeytax could use this to even better effect than me.

Title: Re: (App) MassHexASM: Encode directly to little endian (v12 Update: 7/4)
Post by: Glain on December 04, 2013, 02:11:39 am
I could probably just save what's in the ASM textbox as a big string to a text file.  The search feature is a good point too; I hadn't really thought about it.

But, if you want text editor features, why not write your ASM in a text editor?  That's what I do when I write long ASM (I'm rather fond of Notepad++). That way you can save, find/replace, tab/shift+tab on blocks of text, use syntax highlighting, etc.  Then you can just copy (ctrl+A, ctrl+C) and paste (ctrl+V) into MassHex and encode (If that's even necessary...  FFTorgASM will encode for you if you specify mode="ASM" in the Location tags (ever since one of the later versions), though I'd still use MassHex as a check to make sure the ASM "compiles").

I spent a decent amount of time making MassHex play nice with various kinds of formatting (tabs, newlines, etc) so that it could work with nicely formatted text.  It should be able to deal with whatever kind of formatting a text editor throws at it!

Title: Re: (App) MassHexASM: Encode directly to little endian (v12 Update: 7/4)
Post by: Dokurider on May 22, 2014, 03:49:45 pm
Whenever I translate multiple lines, branch labels get messed up. Yes, I'm using the latest version.
Title: Re: (App) MassHexASM: Encode directly to little endian (v12 Update: 7/4)
Post by: Glain on May 22, 2014, 07:46:11 pm
Could you post the ASM that isn't encoding correctly so I can investigate?
Title: Re: (App) MassHexASM: Encode directly to little endian (v12 Update: 7/4)
Post by: Dokurider on May 29, 2014, 04:35:03 pm
Ah, sorry about the wait there, Glain.

beq r2, r0,0x004c
12004010

sltu r2,r5,r15   
beq r2, r0,0x004c
nop        
subu r5,r5,r3      
slt r2, r5, r7   
bne r2, r0 0x0010   
subu r2,r7,r11   
ori r5, r2, 0x0000
subu r3, r2, r15   
slt r2, r5, r0   
beq r2, r0,0x0010

2B10AF00
11004010
00000000
2328A300
2A10A700
FEFF4014
2310EB00
00004534
23184F00
2A10A000
F9FF4010
Title: Re: (App) MassHexASM: Encode directly to little endian (v12 Update: 7/4)
Post by: Glain on May 30, 2014, 10:16:25 am
No worries. 

I get the same hex output, but it seems fine and decodes to the original ASM.

If you're worried about the encoding of "beq r2, r0,0x004c" changing from 12004010 to 11004010, it's because conditional branch statements like beq don't actually store the address they branch to in the encoding; they just store the number of lines to skip over.  In the first example, it needs to skip 18 (0x12) lines to get to 0x4c, since it's at address 0, and in the second example, it only needs to skip 17 (0x11) lines since it's at address 4.

(Conversely, j and jal do store the address they jump to, and their encodings wouldn't change in a scenario like this)
Title: Re: (App) MassHexASM: Encode directly to little endian (v12 Update: 7/4)
Post by: Dokurider on May 30, 2014, 03:26:21 pm
Ah so that behavior is just fine then.
Title: Re: (App) MassHexASM: Encode directly to little endian (v13 Update: 1/11/2017)
Post by: Glain on January 11, 2017, 07:19:05 pm
I'm finally updating this with the latest version (v13), which features a bunch of incremental fixes to the ASM engine, a check mechanism for detecting ASM hazards on an Encode or Decode operation, and LEDecoder rolled into MassHexASM!
Title: Re: (App) MassHexASM: Encode directly to little endian (v13 Update: 1/11/2017)
Post by: Dokurider on February 21, 2017, 05:38:32 pm
I think we have a problem here.
Title: Re: (App) MassHexASM: Encode directly to little endian (v13 Update: 1/11/2017)
Post by: Glain on February 25, 2017, 01:43:44 pm
The issue here is that 0xe618 isn't a valid value for the offset in your lbu statement.  The valid offset values go from -0x8000 to 0x7fff.

Since you specified a value outside that range, MassHex is trying to expand your lbu statement into a series of multiple statements to still get the proper result, assuming you want a positive 0xe618 as your offset. The method it's using here would normally work, except that you're using the assembler temporary register (r1) as the base register for your load, and MassHex needs that register to do the expansion, so the result is messed up.  Regardless, looking at what you're doing, this is unnecessarily complicated anyhow.

I suspect, based on the input you're giving MassHex, that you're looking to load a byte into r4 from RAM address (0x8016e618 + r2).  You could actually tell MassHex to do that with the following statement:

lbu r4, 0x8016e618(r2)

You'll notice that will expand into:

lui r1,0x8017
addu r1,r1,r2
lbu r4,-0x19e8(r1)

Which is probably the input you're looking for.

Title: Re: (App) MassHexASM: Encode directly to little endian (v13 Update: 1/11/2017)
Post by: nitwit on August 07, 2022, 09:52:07 pm
Could you add a checkbox to right-pad each line of decoded assembly and add a # for easy commenting? This is a little tedious.

[0x00186c04] lui r2,0x8019          #
[0x00186c08] lhu r2,0x38d6(r2)      #
[0x00186c0c] addiu r29,r29,-0x0018  #
[0x00186c10] addiu r3,r2,-0x0075    #

There's an option to pad, but it seems to be left-padding unless I'm missing something.