• Welcome to Final Fantasy Hacktics. Please login or sign up.

(App) MassHexASM: Encode directly to little endian (v13 Update: 1/11/2017)

Started by Glain, May 08, 2011, 12:41: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


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).
  • Modding version: Other/Unknown


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).
  • Modding version: Other/Unknown


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.
  • Modding version: PSX


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..."
  • Modding version: Other/Unknown


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 =)


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.
  • Modding version: Other/Unknown


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?


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.
  • Modding version: Other/Unknown


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.
  • Modding version: Other/Unknown


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.

The destruction of the will is the rape of the mind.
The dogmas of every era are nothing but the fantasies of those in power; their dreams are our waking nightmares.


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!

  • Modding version: Other/Unknown


Whenever I translate multiple lines, branch labels get messed up. Yes, I'm using the latest version.


Could you post the ASM that isn't encoding correctly so I can investigate?
  • Modding version: Other/Unknown


Ah, sorry about the wait there, Glain.

beq r2, r0,0x004c

sltu r2,r5,r15   
beq r2, r0,0x004c
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



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)
  • Modding version: Other/Unknown


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!
  • Modding version: Other/Unknown


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.

  • Modding version: Other/Unknown