Romhacking.net

Romhacking => Programming => Topic started by: KC on June 18, 2009, 02:39:02 pm

Title: armips assembler (v0.7c released!)
Post by: KC on June 18, 2009, 02:39:02 pm
Update: PSX and GBA/NDS support is done now. You can download it here (http://www.romhacking.net/utils/635/).

I've worked on this for quite a while now. After multiple rewrites and a longer break, I think it's almost ready to be released. I'm not sure when it will be done, but if everything goes as planned, it should be in the foreseeable future.
It is intended to be a very romhacking friendly assembler for PSX and also GBA/NDS. My main motivation to write this was the lack of virtually any decent assembler for PSX. You can insert and overwrite code into existing files, add cross-references between overlays and insert everything at once.

Currently implemented features:

Planned features:

It would be nice to hear what you think about it, and also further feature requests. I can't guarantee that I will add anything, but I will consider every suggestion.
Title: Re: armips assembler (tentative name, unreleased)
Post by: RedComet on June 18, 2009, 02:41:56 pm
Glad this is finally almost ready for release! :D

Also, didn't anyone else misread the title as "armpits assembler"? >_>
Title: Re: armips assembler (tentative name, unreleased)
Post by: Nightcrawler on June 18, 2009, 02:59:02 pm
This sounds great!

Red, I made the same mistake. I think it plays on how when we read, we don't actually read letter by letter, rather we word recognize.
Title: Re: armips assembler (tentative name, unreleased)
Post by: KC on June 21, 2009, 01:25:15 pm
I finished adding THUMB support now, with a proper literal pool logic if someone cares. So now only ARM support and some testing remain before I can release a first version.

And yeah, I'm not all that happy with the name either. I'm open for any other suggestions.
Title: Re: armips assembler (tentative name, unreleased)
Post by: Nightcrawler on June 22, 2009, 09:02:15 am
Actually calling it 'Armpits' would certainly get some recognition. ;)
Title: Re: armips assembler (tentative name, unreleased)
Post by: DaMarsMan on June 23, 2009, 12:36:44 pm
Any chance you could get full R5900 support in before release?
Title: Re: armips assembler (tentative name, unreleased)
Post by: scarboy on June 30, 2009, 03:38:49 am
This sounds very useful, especially the load delay stuff. It's ridiculous that emulators do not give you a warning if you leave the nop out, especially knowing that it wouldn't work on real hardware.
Title: Re: armips assembler (tentative name, unreleased)
Post by: golden on June 30, 2009, 02:46:10 pm
It's going to be an awesome tool, I'm really looking forward to it.
Title: Re: armips assembler (tentative name, unreleased)
Post by: KC on August 15, 2009, 04:38:20 pm
Still no release, but I made some progress lately. I added most of the ARM instruction set, and also parts of the PS2 and PSP specific instructions. Still a lot to go, though.

I also added conditional statements and macros, though both probably still need some testing. This piece of code:
Code: [Select]
.macro myli,dest,value
.if value < 0x10000
ori dest,r0,value
.elseif (value & 0xFFFF8000) == 0xFFFF8000
addiu dest,r0,value & 0xFFFF
.elseif (value & 0xFFFF) == 0
lui dest,value >> 16
.else
lui dest,value >> 16 + ((value & 0x8000) != 0)
addiu dest,dest,value & 0xFFFF
.endif
.endmacro

.macro myrolv,destreg,sourcereg,shiftreg
subu r1,r0,shiftreg
srlv r1,sourcereg,r1
sllv destreg,sourcereg,shiftreg
or destreg,r1
.endmacro

myli a1,0FFEE0000h
myli a0,15h
myrolv v0,a1,a0
will assemble to this.
Code: [Select]
lui a1,0xFFEE
ori a0,r0,0x15
subu r1,r0,a0
srlv r1,a1,r1
sllv v0,a1,a0
or v0,r1
Title: Re: armips assembler (tentative name, unreleased)
Post by: Wareya on August 15, 2009, 11:07:08 pm
This is leaning towards HLASM now, so watch your code when people start calling it a compiler. ;)
Title: Re: armips assembler (tentative name, unreleased)
Post by: Klarth on August 19, 2009, 09:00:13 pm
Speaking of compilers...if you're uber motivated...add this feature (using GCC as an example):

Program some routine in C
Compile using GCC with target r3000a
Add reference to a C function in armips asm file
Insert assembly code generated by GCC
???
PROFIT!

Just use assembly for small mods and add the ability to use C with larger mods...say adding compression.  Maybe somebody would find this useful.
Title: Re: armips assembler (tentative name, unreleased)
Post by: KC on August 20, 2009, 11:31:59 am
I don't think that's worth the trouble. The compiler should be able to output the assembly itself anyway.
Title: Re: armips assembler (tentative name, unreleased)
Post by: Kajitani-Eizan on August 27, 2009, 12:01:35 pm
wow, this looks awesome! :P
Title: Re: armips assembler (tentative name, unreleased)
Post by: magusneo on September 08, 2009, 07:16:55 am
Great!
Will this assembler support cops opcodes likes "swc1,lwc1,add.s" for ps2?
PS2 hacking really needs it.
Title: Re: armips assembler (tentative name, unreleased)
Post by: KC on September 08, 2009, 08:08:18 am
Yes, it will support the whole R5900 instruction set.
However, I can't work on it as much I want to, so everything is going pretty slowly. ARM is at 90%, and about half of the PS2 opcodes are added. But as I don't know how it'll take me to finish these two, I think I will release a PSX-only version first. That alone should already help some people.
Title: Re: armips assembler (tentative name, unreleased)
Post by: magusneo on September 08, 2009, 10:44:13 am
That's really good news!
Currently we have to use gcc-as for ps2 games,but gcc does not suit hacking.
Thanks!
Title: Re: armips assembler (tentative name, unreleased)
Post by: KC on September 08, 2009, 02:58:04 pm
Well, here it is. It only includes PSX support, as previously stated, but it should be working well enough. Let me know if there are any errors.
Documentation and an example file are included. I'll submit it to the database later.
http://gemini.aerdan.org/upload/armips_v05b_by_kingcom.zip
Title: Re: armips assembler (v0.5b released!)
Post by: Rocket Science on September 08, 2009, 10:05:36 pm
(http://i213.photobucket.com/albums/cc211/RoanK/EPICWIN.jpg)
Title: Re: armips assembler (v0.5b released!)
Post by: KC on September 12, 2009, 01:35:57 pm
I finished adding the missing ARM opcodes now, but I still have to thoroughly test them. Some of them are so confusing that the possibility of errors is pretty big. Whoever thought stuff like "mrc p6,5,r4,c3,c2,1" or "smlatbeq r2,r3,r4,r5" was good deserves to be punished hard.
I also discovered that the current release doesn't check if an instruction is valid inside a delay slot or not. That will be fixed in the next version.
Title: Re: armips assembler (v0.5b released!)
Post by: Kronus_Arm on September 12, 2009, 04:05:43 pm
Will it support MIPSII compatible Ingenic Semiconductor devices?

Thanks!

 :thumbsup:
Title: Re: armips assembler (v0.5b released!)
Post by: KC on September 18, 2009, 06:19:51 pm
It should be eventually usable for that.

Well, I finished checking the ARM and THUMB opcodes, and fixed every mistake I could find. I also tested it with the 170kb of assembly code I have for Tales of Innocence, and it assembled fine and works with no problems.
So the release shouldn't take much longer now.
Title: Re: armips assembler (v0.5b released!)
Post by: Kronus_Arm on September 18, 2009, 08:14:41 pm
Thanks!

 :thumbsup:
Title: Re: armips assembler (v0.5b released!)
Post by: KC on September 19, 2009, 12:37:48 pm
Alright, ARM is done and released! http://www.romhacking.net/utils/635/
I hope there aren't errors left, but as it's very complex, it's possible that I missed a few.
Changes since the last release:
Quote
  0.7b -ARM/THUMB support
       -fixed break/syscall MIPS opcodes
       -added check if a MIPS instruction is valid inside
        a delay slot
       -fixed and extended base detection
       -added "." dummy label to the math parser to get the
        current memory address
       -added dcb/dcw/dcd directives
I also extended the readme quite a bit, many more things are explained now. This will probably be the last new feature for a while, but I will add PS2 support eventually.
Title: Re: armips assembler (v0.7b released!)
Post by: KC on December 19, 2009, 09:49:45 am
There are several bugs in the current release. One of these is that using an ldr= ARM/THUMB opcode without defining a pool after it causes the assembler to crash.
Additionally, quite a few ARM opcodes are missing...

-ldrh/sh/b and strh/sh/b don't work with post indexing, be it register or immediates
-ldrh/sh/b and strh/sh/b also don't work with negative pre indexing or writebacks
-there also no pc relative variants for them (ie ldrh r0,[Label])
-no ldr/str variant at all works with negative register pre or post indexing

If there are more that I missed, it would be great if you could report them so that I can fix them for the next release.

On the bright side, I've added a few new things since the last version. Macros can now contain local labels that will get an unique name every time the macro is used, there is a new area directive that ensures that the data doesn't cross a specified boundary and there are also directives that output a warning/error to the console (useful for nested if/else blocks).
Title: Re: armips assembler (v0.7b released!)
Post by: meunierd on December 19, 2009, 11:39:31 pm
Is source available should your harddrive/you die? I'm sure it would be a fairly trivial port to posix.
Title: Re: armips assembler (v0.7b released!)
Post by: Penance on December 27, 2009, 10:19:19 am
Great job!
Looking forward to the PS2 Support version. PS2 never gets any hacking attention these days =(
Title: Re: armips assembler (v0.7b released!)
Post by: KC on July 07, 2010, 04:07:41 am
I think I'm getting closer to the next release.

Here's a list of the changes since the last version:

The next release should be an overall improvement, and also much more stable. I just need to test it more.
Extended MIPS support won't make it into the next version, unfortunately, but I'm still open to feature requests.
Title: Re: armips assembler (v0.7b released!)
Post by: DaMarsMan on July 21, 2010, 11:04:41 am
Best assembler ever. Keep up the good work and I hope to see PS2 support sooooon!  :woot!:
Title: Re: armips assembler (v0.7c released!)
Post by: KC on December 11, 2010, 04:30:45 am
The new version has been released: http://aerie.wingdreams.net/?p=152

    * macros can now contain unique local labels
    * area directive added
    * added missing ARM opcode variations
    * countless bugfixes
    * no$gba debug message support
    * full no$gba sym support
Title: Re: armips assembler (v0.7c released!)
Post by: Normmatt on December 29, 2010, 10:03:36 pm
a few complaints for the arm support, you dont seem to support the pseudo opcode adr nor can i use pc relative addressing on ldr
for example:
ldr r1, label
label: .word 0

should convert the ldr into ldr r1, [r15,-4] but all i'm getting is errors. If you could fix that and add support for the adr opcode this would be perfect :)

EDIT: looks like i can make a quick little macro for adr
.macro adr,destReg,Address
here:
   .if (here & 2) != 0
      add destReg, r15, (Address-here)-2
   .else
      add destReg, r15, (Address-here)
   .endif
.endmacro

also looks like i fixed my problems with ldr
Title: Re: armips assembler (v0.7c released!)
Post by: KC on December 30, 2010, 05:27:32 am
Thanks for the feedback.

There's currently no adr opcode, yeah. I didn't about this one as I used the no$gba specs to implement everything. There is a slightly different opcode with the same functionality though.
PC relative stuff can be done this way:

Code: [Select]
add r0,=label ; pc relative adds
ldr r1,[label]  ; pc relative loads
label: .word 0

I'll add adr to the next version, but I think it's better to keep all ldr opcodes with brackets.

For the next version, I have also implemented a few optimizations. immediate loads will be converted to mov/mvn if possible, and mov/mvn, and/bic, and cmp/cmn will all try to use the other one if possible and necessary. So these two will result in identical code:
Code: [Select]
and r1,0xFFFFFFFE
bic r1,1

Edit: Damn. I'm sorry, it looks like there is no add= after all... I was sure I implemented it. I'll definitely add it for the next version.
The math parser also supports "." as a replacement of the current position, so you could use it instead of the "here" label.

So something like this:
Code: [Select]
.macro adr,destreg,address
 add destreg,r15,address-.
.endmacro

Edit2: I DID implement it, but only in Thumb mode.
Title: Re: armips assembler (v0.7c released!)
Post by: Normmatt on February 01, 2011, 07:46:12 am
Another bug to report.

Code: [Select]
.org 0x08FFFD00
.thumb
FixSpriteNumber:
;LDRB    R0, [R4,#6]
;ADDS    R0, #1          ; patch this mother fucker for number of oam entries

ldr     r0, [currentChar2]
ldrb    r0, [r0]

STRB    R0, [R4,#6]
MOV     R0, #1
STRB    R0, [R4,#1]

LDR     R0, [R4,#0x4C]
ADD     R0, #2
;STR     R0, [R4,#0x4C]

bx      lr

If I remove the commented line it assembles fine but if its there armips seems to hang, I'm not sure why either its happened a few times now on various opcodes.

EDIT: Apparently if i change the ADD R0,#2 into two ADD r0,#1 with that STR uncommented it assembles fine, possibly some sort of weird alignment issue?
Title: Re: armips assembler (v0.7c released!)
Post by: Prof. 9 on August 18, 2011, 02:36:16 pm
I'm having a bit of trouble with the area directive; it's making ARMIPS crash without error messages or "Done" for me.

I made a bunch of free space offset labels, like this:

Code: [Select]
fspace1 equ 0x08000000
fspace2 equ fspace1+n
fspace3 equ fspace2+n
fspace4 equ fspace3+n
...etc
fspace43 equ fspace42+n
fspace44 equ fspace43+n
fspace45 equ fspace44+n

If, for n, I use a 16-bit number at least 28 (0x1C) times, the following piece of code will cause the assembler to crash:

Code: [Select]
.area fspace45-fspace44
.endarea

However, the following will assemble without a problem:

Code: [Select]
.area fspace44-fspace43
.area fspace45-fspace43
.area n ; n = fspace45 - fspace44

If you're wondering, the reason why I'm using such a system is because I'm working on a translation project and this setup lets me not have to worry about free space addresses, just about the size of the data loaded into free space (which is checked by the area directive).

I've removed all irrelevant files and opcodes from my project to make a small environment for testing, which can be found in the link below. If "fspaceN.asm", where I used a 16-bit number 28 times, is .included in "src.asm", the assembler will crash. In "fspaceY.asm", I used a 16-bit number only 27 times, and it works with that.

Test case: http://www.mediafire.com/?iu8sjd7fl7odzrh
Title: Re: armips assembler (v0.7c released!)
Post by: KC on August 18, 2011, 02:54:41 pm
Thanks for the detailed bug report! I located the error and I'll send you a PM with a fixed test build shortly.
Title: Re: armips assembler (v0.7c released!)
Post by: StorMyu on August 22, 2011, 10:26:43 am
Is there a way to remove the automatic Nop command after each branch/jump ?
Title: Re: armips assembler (v0.7c released!)
Post by: KC on August 22, 2011, 12:25:21 pm
There are no automatic nops after branches. The only time nops are automatically inserted is when you use .fixloaddelay and have a MIPS load delay issue (accessing data before it's ready). If something other than that happens, it would be nice if you could provide a sample.
Title: Re: armips assembler (v0.7c released!)
Post by: StorMyu on August 22, 2011, 12:40:22 pm
Ok, it's just a bad habit, I was a bit tired I guess and I'VE put the nop...  thanks anyway  ;)
Title: Re: armips assembler (v0.7c released!)
Post by: KC on November 16, 2011, 09:41:54 am
I've been working on it again lately. Fixed several mistakes in the ARM instruction set, and added a new label type, the static labels. These are global labels, but they are only valid in the very file that defined them. Not in any file that includes them and not in any file that is included. Therefore these names can be reused in different files. They are defined with a single leading @.
I also started working on PS2 support. This requires many internal changes and will need a lot of good testing. The instruction set is huge, and many of the opcodes are exclusive to the PS2 and not supported by anything else (mostly the vector and mmi instructions).
If anyone's got experience working with PS2 assembly code, it would be great if he could help testing.
Title: Re: armips assembler (v0.7c released!)
Post by: yoshi314 on November 22, 2011, 07:59:44 am
btw, do you have any comprehensive listing of ps2 opcodes?

i have a couple of EE docs, but i am not sure how complete they really are. i stumbled across some unlisted instructions when disassembling a couple of executables, and i wonder if my docs are incomplete, or the tool got confused.
Title: Re: armips assembler (v0.7c released!)
Post by: KC on November 22, 2011, 05:06:22 pm
I'm mostly using the PCSX2 source code to see how all the opcodes are encoded and what format they are in. It's hard to find decent documentation for such an obscure CPU.
Title: Re: armips assembler (v0.7c released!)
Post by: yoshi314 on November 23, 2011, 03:12:32 am
hmm, it would never occur to me to look at pcsx2. thanks for the hint.

i mostly tried using this doc to help me out http://www.herrvillain.com/codebreaker/inst_0e.pdf
Title: Re: armips assembler (v0.7c released!)
Post by: Klarth on November 23, 2011, 01:39:49 pm
Well that's interesting.  I didn't know the FPU had DSP-like multiply-add functions nor about the EE's SIMD-type instructions.  I guess I never paid attention to them in my brief stint.
Title: Re: armips assembler (v0.7c released!)
Post by: Pokeytax on February 10, 2012, 07:12:25 pm
This is a good program, thanks.

I am trying to write raw hex for a table. How on earth do I use the .byte command? I don't know how I'm screwing up something so simple.
Title: Re: armips assembler (v0.7c released!)
Post by: Normmatt on February 10, 2012, 10:32:18 pm
This is a good program, thanks.

I am trying to write raw hex for a table. How on earth do I use the .byte command? I don't know how I'm screwing up something so simple.

.db $56
.db 0x56
.db 86
Title: Re: armips assembler (v0.7c released!)
Post by: Prof. 9 on March 17, 2012, 03:12:50 pm
Small oddity: the following is all happily accepted:

dcb   0x5511111111
.db   0x5522222222
dcw   0x5533333333
.dw   0x5544444444

The above assembles into 11 22 33 33 44 44 44 44, oddly. Anyway, I can't think of a single legitimate use for this, so perhaps it's a good idea to return an error message if the value to be written is too high?

EDIT: This is for the version you gave me in August last year.
Title: Re: armips assembler (v0.7c released!)
Post by: KC on March 17, 2012, 05:08:00 pm
There's no benefit freem restricting that. The whole expression parser is designed to work like in standard C/C++ code, so it would just be logical that such writes do the same. It could be used to store pointers that aren't saved in one consecutive piece, without having to use a bitmask to clear the upper bits all the time.
Such range checks of course can be complicated, too. -1, for example. Technically it fits into 8 or 16 bits, but internally it's just a huge positive 32 bit number, the same as 0xFFFFFFFF.

In other news, I've worked on some bigger internal redesigns and the next version, whenever it will be finished, will be able to load PS2 (and maybe PSP) executables and automatically read the sections from the file to acquire the memory mapping. The R5900 instruction set will of course also be supported. But that will still take quite a while.
Title: Re: armips assembler (v0.7c released!)
Post by: x0_000 on April 01, 2012, 02:21:27 am
Version 0.7c of ARMIPS switches the ldrh and ldsb instruction for GBATEK, in the sense that it compiles

ldrh r1, [r2, r3]

into

ldsb r1, [r2, r3]

and vice versa. I haven't checked the other versions of ldrh for this bug, but it looks like you just switched a case check for that instruction set, none of the other instances of ldrh can be confused with ldsb. Great job with the assembler otherwise, it's pretty awesome! Just need to comb the readme more thoroughly to unlock its FULL POTENTIAL

EDIT: Just noticed this now, the assembler doesn't yell at me when I tell it to assemble

add, r7, r0

it just gives gibberish! D: partially my fault for forgetting how add instructions work :P
Title: Re: armips assembler (v0.7c released!)
Post by: KC on April 01, 2012, 05:02:13 am
Thanks for the bug report.
Trying to assemble "add, r7, r0" results in an error that "add," is not a valid opcode. That's what should happen. "add r7, r0" would be assembled as "add r7,r0,r0".
I couldn't replicate the wrong opcodes, and there have been no changes to them since the last release in 2010. Is that with THUMB or with ARM opcodes?
Title: Re: armips assembler (v0.7c released!)
Post by: x0_000 on April 01, 2012, 05:05:09 am
Sorry, I meant

add r7, r0

does not get assembled into something legal (the GBA disassembler doesn't recognize it) but the assembler doesn't abort/throw an error. The ldrh bug is with THUMB opcodes. For a specific instance,

ldsb r0, [r4, r0]

gets assembled into

ldrh r0, [r4, r0]
Title: Re: armips assembler (v0.7c released!)
Post by: KC on April 01, 2012, 05:18:40 am
It seems that the add is assembled as the "Hi register operation", normally used for changing/reading r8-r15. Technically, it should be legal and it should work (no$gba emulates it correctly as well), but I guess most disassemblers don't expect it there, and would rather like to see the normal add for the lower half of the registers. I'll look into changing that.
But I still can't replicate the other one. no$gba is showing both correctly, and it's just as GBATEK says as well. Are you sure about it?
Title: Re: armips assembler (v0.7c released!)
Post by: x0_000 on April 01, 2012, 05:27:03 am
I'm pretty sure because I assembled some code with a ldrh instruction and I kept getting the wrong output (very wrong!), and when I debugged it in VBA I noticed the ldsb instruction.

Spoiler:
Code: [Select]
.open chivalry-test.gba,0x0

.gba
.thumb

.org 0xded060
push {r4,lr} ; pulls skill from 0x08016764
add r4, r0, 0x0
add r2, pc, 0x8
add r2, 0x1
mov lr, r2
ldr r2, =0x08016765
bx r2
.align

lsl r0, r0, 0x10
lsr r2, r0, 0x10
ldr r0, [r4, 0xc]
mov r1, 0x10
and r0, r1
cmp r0, 0x0
bne rescue ; (checks if unit is rescuing someone)

add r0, r2, 0x0
add r2, pc, 0x8
add r2, 0x1
mov lr, r2
ldr r2, =0x08016099 ;08018b08 bl $08016098 f7fdfac6
bx r2
.align
add r1, r0, 0x0
mov r0, 0x15 ;loads skill
ldsb r0, [r4, r0] ;bug, should be ldrh
b noRescue

rescue:
add r0, r2, 0x0
add r2, pc, 0x8
add r2, 0x1
mov lr, r2
ldr r2, =0x08016099 ;08018b08 bl $08016098 f7fdfac6
bx r2
.align

add r1, r0, 0x0
mov r0, 0x15 ;loads skill
ldsb r0, [r4, r0] ;bug, should be ldrh
ldr r2, [r4, #0x4] ;loads class pointer
ldrb r2, [r2, #0x5] ;loads class ID at 0x5!!!

cmp r2, 0x14
beq chivalry

cmp r2, 0x15
beq chivalry

cmp r2, 0x16
beq chivalry

cmp r2, 0x17
beq chivalry

lsr r2, r0, 0x1f
add r0, r0, r2
asr r0, r0, 0x1
chivalry:
noRescue:
add r0, r0, r1
pop {r4}
pop {r1}
bx r1
.pool

.close

;blank line

This is the code I assembled, the 4th block has a "bug, should be ldrh" comment (there are a few more peppered throughout), but it assembles the ldsb instruction into an ldrh.
Title: Re: armips assembler (v0.7c released!)
Post by: KC on April 01, 2012, 06:07:22 am
According to this: http://vba.cvs.sourceforge.net/viewvc/vba/VisualBoyAdvance/src/armdis.cpp?view=markup
VBA implements it as:
Code: [Select]
// Format 8
{0xfe00, 0x5200, "strh %r0, [%r3, %r6]"},
{0xfe00, 0x5600, "ldsb %r0, [%r3, %r6]"},
{0xfe00, 0x5a00, "ldrh %r0, [%r3, %r6]"},
{0xfe00, 0x5e00, "ldsh %r0, [%r3, %r6]"},
Which is also what I get.
"ldsb r0, [r4, r0]" is assembled as 0x5620, and "ldrh r0, [r4, r0]" as 0x5A20.

Aside from that, I'd recommend to use ".open old,new,address", where old is an existing untouched copy and new a file that will be created by the assembler. You should also use the correct memory address, 0x8000000. Relative branches work either way, but pointers would be incorrect.
Title: Re: armips assembler (v0.7c released!)
Post by: x0_000 on April 01, 2012, 06:23:32 am
...huh. VBA's disassembler *is* disassembling it incorrectly. My bad! Sorry for wasting your time on that  :-[
Title: Re: armips assembler (v0.7c released!)
Post by: Prof. 9 on November 15, 2012, 02:44:48 pm
Is there any chance an .include and .import/.incbin for files relative to the current file could be added (as opposed to relative to where ARMIPS was called)? I'm using ARMIPS for fairly large projects and it seems kind of counterintuitive to have to include the whole path each time, and it also makes it annoying to reorganize things since moving or renaming a folder will break EVERYTHING in that folder. It also destroys any sort of modularity.
Title: Re: armips assembler (v0.7c released!)
Post by: KC on November 15, 2012, 05:23:27 pm
I've sent you a PM with a version that supports it. If it works without errors, I could probably release it to the public, too.
Title: Re: armips assembler (v0.7c released!)
Post by: x0_000 on January 25, 2013, 04:42:09 am
Bug with v0.7c; Doing something like the following:

foo equ 1 + 2
bar equ foo*4

makes bar = 1+2*4 = 9, instead of (1+2)*4 = 12.
Title: Re: armips assembler (v0.7c released!)
Post by: KC on January 25, 2013, 04:50:23 am
equ is a pure text replacement, much like #define in C. You can put parentheses around it though.
Title: Re: armips assembler (v0.7c released!)
Post by: x0_000 on January 25, 2013, 04:54:25 am
Oh, I see. You should clarify that in the readme, I've never used a feature like that while programming :P
Title: Re: armips assembler (v0.7c released!)
Post by: KC on January 25, 2013, 05:01:19 am
It actually does say so there.

Quote
3.4  equ

This works as a text replacement and is defined as follows:

  @@StringPointer equ 0x20(r29)


There has to be a space before and after equ. The assembler
will replace any occurance of @@StringPointer with "0x20(r29)".
Title: Re: armips assembler (v0.7c released!)
Post by: x0_000 on January 25, 2013, 05:07:01 am
Sorry, I meant clarifying that text replacement doesn't have the behavior of variable assignment (which is what I've been using it as!)
Title: Re: armips assembler (v0.7c released!)
Post by: KC on October 12, 2013, 12:08:13 pm
I've done a lot of work on it this week. The major changes include:
-now uses UCS2 internally, can read from UTF8 and UTF16LE/BE through BOM detection, and from SJIS by manually specifying the file encoding. Defaults to UTF8 when neither is found
-basic support for non-relocatable PSP ELFs

I'm still working on getting rid of ugly remnants of old code. I also uploaded the code to Github: https://github.com/Kingcom/armips
Contriutions through pull requests are welcome.
Title: Re: armips assembler (v0.7c released!)
Post by: FAST6191 on October 12, 2013, 12:40:17 pm
As it has yet to fail me and the only things I could want would be the odd esoteric stuff I do not have much I can add and this post will have to be of the cheerleading clutter.

To that end yay more armips.
Title: Re: armips assembler (v0.7c released!)
Post by: CUE on October 13, 2013, 01:53:29 pm
Another nice and useful change is the new ".strn" directive (same as the old ".str" but without adding the final character).  :thumbsup:
Now I no need ATLAS to change the script of many games, ARMIPS is easier to use and I can change the code and the messages with the same tool. :)

I've seen Z80\ in the Archs\ folder. ARMIPS will support Game Boy Architecture in a future? (Say yes, please!!!)  ;D
Title: Re: armips assembler (v0.7c released!)
Post by: KC on October 13, 2013, 03:28:14 pm
It was something I spent two days on and then never continued. Though I wouldn't mind if someone else finished it. The memory mapping could be handled by deriving a custom AssemblerFile class.
Title: Re: armips assembler (v0.7c released!)
Post by: MarkGrass on October 18, 2013, 07:25:53 pm
This application is, by far, the best utility I've ever used for PSone projects... so, many thanks, praise and spanks!

This may be bit of an oxy-moron (aka, dumb question to ask), but is there any chance of disassembling capabilities? For instance, it would be great to dump certain areas of R3000 code to modifiable text.

Furthermore, any chance to add support for PSone PSY-Q symbol format (*.sym files)? It would be great to dis/assemble those, as well.
Title: Re: armips assembler (v0.7c released!)
Post by: KC on January 01, 2014, 06:40:49 am
No disassembler, sorry. I don't know that format, though anyone is free to contribute.

I added another really neat feature in a branch (https://github.com/Kingcom/armips/tree/ObjImport). armips can now import object files generated by a C/C++ compiler for the PSP platform (ie. pspsdk). The object file is parsed, all relevant sections (code, data, bss, etc.) are imported and relocated to the current position, function and data symbols are added to the symbol map and external symbols used by the C code are resolved using existing ones already defined in armips. This way the assembly code can call the compiled code and vice versa.

For example, code using:
Code: [Select]
extern int sprintf_s(char* dest, int maxsize, char* mask, ...);can be properly imported if
Code: [Select]
.definelabel sprintf_s,892BB28hor similar is put somewhere in the assembly code.

It's called with the new .importobj macro.
Code: [Select]
.importobj ndx.o
This'll make writing extensive new routines a lot easier.
Title: Re: armips assembler (v0.7c released!)
Post by: Gemini on January 09, 2014, 02:39:51 pm
For those who don't like technical aspects too much, but prefer eye candy of resulting progress instead, here's a little thing I've worked on for the last three days or so (don't mind the lack of sounds, it's extremely rough):
http://youtu.be/W9hzL_ilJ98

It's a demonstration of the FF4 menu remade entirely from scratch and with very little effort thanks to the C code (C++ should also be usable). A good portion of this menu actually comes from my own engine used in Red Moon, just because the way things can interface are extremely generic and easy to use. Mind you, what took me the most to work wasn't the menu logic itself, but all the weird manners the FF4 data is stored. :P If something as "complex" as a menu can be created this easily (creating a tiny bit of this in assembly took me almost a week and everything was extremely error prone), imagine extensively hacking any other game with whatever is required for a good translation (absurdly structured VWFs, I'm looking at you). Plus everything's portable to multiple systems this way, meaning you don't have to rewrite the same code a million times depending on the machine or the game of your choice. So, hmm, cheers to C injection made easy!

For those who can't open the YouTube video for whatever reason, this is what the remade menu looks like:
(http://i239.photobucket.com/albums/ff233/Geminimewtwo/Final%20Fantasy%20IV/dsmenu1.png) (http://i239.photobucket.com/albums/ff233/Geminimewtwo/Final%20Fantasy%20IV/dsmenu2.png) (http://i239.photobucket.com/albums/ff233/Geminimewtwo/Final%20Fantasy%20IV/dsmenu3.png)

To anyone who's interested, the menu source code I made can be found here (https://mega.co.nz/#!SRsgFArY!O0V_d1mdiUJFV5V1JDpcACrRzTwhPP1sMTQNBWu9CSc), however it doesn't include yet the armips integration bits (which is just a call to Menu_root in the C code).
Title: Re: armips assembler (v0.7c released!)
Post by: Nightcrawler on January 09, 2014, 08:03:16 pm
Hey, that looks really nice. :) What font is that by the way? I'm working on a project that I think it would be perfect for on the menus. Bonus :cookie: if you could upload it to the Fonts section. There's a pretty paltry selection of proportional 8 high fonts.
Title: Re: armips assembler (v0.7c released!)
Post by: Gemini on January 10, 2014, 06:42:41 am
The new font sets come from... well, I don't remember really, it's been such a long time since those have been established for this project. :P IIRC, they come from my FF6 PSX project and I edited them slightly to match better with the FF4 style. I would upload them to the font section, but they are arranged in a not-so-convenient way I might just as well upload the original assets. In fact, here they go:
(http://i239.photobucket.com/albums/ff233/Geminimewtwo/Final%20Fantasy%20IV/Savemod.png) (http://i239.photobucket.com/albums/ff233/Geminimewtwo/Final%20Fantasy%20IV/font16_it.png)
They are organized like that to take advantage of the extra texture cashing the game applies at boot in order to patch the SNES 8x8 set (which isn't used any more).

Meanwhile, I fixed the "To Next Level" hud indicator. Took me a while to figure out how the pointers were already taking into account a character's starting level (also many thanks to pinkpuff for confirming where the upper bits of the EXP counters have been awkwardly stored), but at least now it's working the way it was intended to be. :P Code has been updated to reflect this change.
Title: Re: armips assembler (v0.7c released!)
Post by: Nightcrawler on January 10, 2014, 06:45:43 pm
Thanks. By the way, I like the concept of doing all possible parts in C or C++. I think that type of thing could be a revolutionary step forward on how we hack later generation consoles. When you think about it, there's really no reason to use assembly except where absolutely necessary when it comes to more powerful consoles like this. The majority of it can be done in C and offers the huge benefits you have described. Assembly just becomes more and more unmanageable the larger and more intricate the project.

Nice work Gemini! I enjoy the exploratory type hacking adventures you go on (What ever happened to that Star Ocean project?). Covering new ground is a benefit for us all. :)
Title: Re: armips assembler (v0.7c released!)
Post by: KC on January 11, 2014, 04:38:28 am
Definitely a great demonstration!

Since the last update I've greatly extended this functionality:

It's now merged into the main branch, if someone wants to check it out, and the new usage is:
Code: [Select]
.importlib name[,ctorname]If given it will create a function with the name ctorname as described above.

At the moment there are two things I'm looking into. One is removing unreferenced stuff. Either at the function level or at the very least whole object files. The other is automatic name demangling of C++ symbols, though that comes with quite a few complications.
Title: Re: armips assembler (v0.7c released!)
Post by: KC on March 04, 2014, 12:41:01 pm
PS2 support is enabled now as well. All opcode/regimm/special instructions are supported, and a few of the cop ones. But the former are the most common ones. ELF handling is supported for PS2 as well, but again without relocations. All main executables I've seen were nonrelocatable though.
Title: Re: armips assembler (v0.7c released!)
Post by: Scio on March 04, 2014, 05:31:08 pm
About relocation, do you mean those games that initiate another engine from the main one? If positive, I think Tekken 5 does this.
Title: Re: armips assembler (v0.7c released!)
Post by: KC on March 04, 2014, 05:41:15 pm
Relocation is a feature of the ELF format. They have extra information so that the code can be put anywhere in RAM, not only at a fixed address. Relocatable ELFs have a special type value. IRX modules are relocatable, for example. Those are custom types unfortunately, so I'll either need specs or reverse engineer the BIOS.
Though I just meant most games fortunately don't need them.
Title: Re: armips assembler (v0.7c released!)
Post by: KC on June 11, 2014, 04:58:37 pm
With the latest commit (https://github.com/Kingcom/armips/commit/374a59fa0f94e89caea04b2880aebf1ebff742a8), object files generated by Sony's PsyQ tools can also be imported, probably still with errors so far. Now compiled C code can be imported for all platforms supportd by armips.
Note that you need to compile without debug infos (without -g).
Title: Re: armips assembler (v0.7c released!)
Post by: Gemini on June 12, 2014, 10:20:26 am
And here (https://mega.co.nz/#!3NNCAKZK!aR0otR7NzL4ZgY84fRKO5Bqle-uPSG1E_J0xtQHNqYM) comes a sample of what I did on FF4 with C code. Keep in mind it's just an example, so some things might be missing due to all the data involved, but it should give a nice overview of how to use armips with PSY-Q linkable objects.
Title: Re: armips assembler (v0.7c released!)
Post by: KC on July 04, 2014, 08:55:26 am
As of the latest version (https://github.com/Kingcom/armips/commit/7b79f7b7f4e90600f2c9b8d3d86d94a2f51c3ff2), it can be built and natively run on Linux and probably other Unix platforms.
Title: Re: armips assembler (v0.7c released!)
Post by: KC on November 23, 2014, 08:48:52 am
More changes:
-should now have full support for the PSP instruction set (prefixes so far only supported as separate opcodes, not in their combined form)
-now has an x64 configuration, and builds for it without apparent issues. The x64 build seems to be slightly faster, too
Title: Re: armips assembler (v0.7c released!)
Post by: Xenesis on December 04, 2014, 11:43:05 pm
Ahoy!

I tried to compile this on OSX, but it didn't like a lot when I tried to make it: Link (http://pastebin.com/PZJNeSzq)

I figure it's probably a platform specific thing, but I'm unsure what to do with it.

Title: Re: armips assembler (v0.7c released!)
Post by: KC on December 05, 2014, 09:02:01 am
Hm, all those errors seem to be about implicit data type casts. Visual Studio is very forgiving there, much more than other compilers. I'll clean it up. Though there are probably more in other files.
Title: Re: armips assembler (v0.7c released!)
Post by: Steven Anthony on April 28, 2015, 01:22:57 pm
is program work´s in PS2 ?
Title: Re: armips assembler (v0.7c released!)
Post by: 90s Retro Gamer on May 06, 2015, 02:48:25 pm
Update: PSX and GBA/NDS support is done now. You can download it here (http://www.romhacking.net/utils/635/).

I've worked on this for quite a while now. After multiple rewrites and a longer break, I think it's almost ready to be released. I'm not sure when it will be done, but if everything goes as planned, it should be in the foreseeable future.
It is intended to be a very romhacking friendly assembler for PSX and also GBA/NDS. My main motivation to write this was the lack of virtually any decent assembler for PSX. You can insert and overwrite code into existing files, add cross-references between overlays and insert everything at once.

Currently implemented features:
  • full-fledged C-like infix expression parser
  • opening any file with any given memory offset. The content is not deleted and only the desired changes are applied. You can create/overwrite a file, too, though
  • you can also open multiple files in a row and cross-reference them. This was done in order to support overlays
  • local labels that are only valid until the next global label
  • table support
  • the complete MIPS r3000 instruction set for PSX
  • a couple of hard-coded MIPS macros to make writing code easier:
    • load immediate: li a0,0xDEADBEEF
    • load/write from/to offset: sw a0,0x80001000
    • unaligned load/store: ush a0,(a1)
    • branches: blt a0,0x100,Start
    • rotate: ror a0,a1,8
  • checks for load delay problems. As every load is delayed by 1 cycle, the loaded value is not immediately available. The following code would generate a warning:
       lw   v0,(v0)
       addiu   v0,1h
  • also an optional automatic fix for said problem. If enabled, the assembler will insert a nop whenever it encounters such a problem:
       lw   v0,(v0)
       nop
       addiu   v0,1h
  • optional output of all the labels to a given text file
  • optional output of all the generated code, complete with address in memory and origin, to a given text file
  • user defined macros
  • THUMB instruction set for GBA and NDS
  • complete ARM support for GBA and NDS

Planned features:
  • an area directive that takes amaximum size and generates an error if it's overflown
  • support for N64 and PS2

It would be nice to hear what you think about it, and also further feature requests. I can't guarantee that I will add anything, but I will consider every suggestion.

Amazing! I assume it would be very difficult to make a Sega Saturn assembler (due to it's bizarre architecture)?

In any case, I'm sure this will open a new era of RHDN with more recent games being hacked/translated.
Title: Re: armips assembler (v0.7c released!)
Post by: KC on May 07, 2015, 01:48:15 pm
I see no reason why SuperH assembly would be harder to implement than ARM or MIPS.
Title: Re: armips assembler (v0.7c released!)
Post by: SC on May 07, 2015, 06:41:01 pm
I see no reason why SuperH assembly would be harder to implement than ARM or MIPS.
I think what would be difficult is to write some useful or complex code on it, though. Unless one somehow managed to fully learn how the SS works.

Oh, I'll seize the moment to say: congratulations for creating this extremely useful assembler!!
It has been really useful for me in the past, and I hope it continues to do so in the future.

I used it with a still paused FF7 translation project when I got mad implementing many translation-related things and other new features in menus and battle layout.

And I tried using it with Suikoden II for an assembler-driven text reinsertion, though I later found a problem with text strings on armips and then gave up the project.

I created a dumper program that takes some address' parameters and dumps the text. All fine.
At least I managed to get something useful out of the messy and mixed Suikoden file structures.
Though still could not solve the text redundancy problem, since there's no way for me to know.
Later I tried using armips to reinsert the translated text. But, I could not make multi-line strings work.

Random Example (it's in Spanish):
Code: [Select]
.str "Bueno... ¿nos vamos a la cama?<\n>",7,1,"¿O quieres salir a tomar el aire?<\n>",7,0,"Hace una noche perfecta."Nevermind of the values related to text pausing.
I would have loved to make something similar to this:
Code: [Select]
.str {
"Bueno... ¿nos vamos a la cama?<\n>
<Pause:1>¿O quieres salir a tomar el aire?<\n>
<Pause:0>Hace una noche perfecta." }
Though, maybe those curly braces would not really be needed.
Is there an obscure way to do this, or did I miss something? Maybe it's simply not possible now? Would it be possible in a future release?

I always thought of doing this translation text insertion through armips to save much time on reinsertion irknesses, but...

Also, now that I mention this Suikoden II project:
Do you know or know someone who knows how to change the font's width?
I searched high and low on all relevant files using all kind of searching methods imigining all kind of ways for that information to be stored... to no avail.
I even used debugger and tracing techniques.

While not mandatory for a translation it would still be nice to do it, since the original font is ugly and has some width errors.

By the way, I hope to see more from you in the Tales of Phantasia X and Narikiri Dungeon X for the PSP project soon.

Thank you for your work, sir! :thumbsup:
Title: Re: armips assembler (v0.7c released!)
Post by: KC on May 07, 2015, 07:37:47 pm
I'm glad you find it useful! It wasn't actually meant to be a sophisticated text inserter, so the string commands are somewhat limited. I'm currently working on a new parser though, which would allow you to at least split the text over multiple lines in some way.

Code: [Select]
.str "Bueno... ¿nos vamos a la cama?<\n>",7,1,
"¿O quieres salir a tomar el aire?<\n>",7,0,
"Hace una noche perfecta."

It's still not really ideal, but at least a bit easier to read. Other additions are possible, though I can't say anything about that at this time. I can't help you with your game either, unfortunately.
Title: Re: armips assembler (v0.7c released!)
Post by: x0_000 on May 13, 2015, 04:41:13 pm
A useful feature for larger scale hacking would be some enum support. Basically something like
Code: [Select]
.beginenum
enum0
enum1
enum2
...
.endenum
would be equivalent to writing
Code: [Select]
enum0 equ 0x0
enum1 equ 0x1
enum2 equ 0x2
...
And you could change enum starting points by specify equs within the command, e.g.
Code: [Select]
.beginenum
enum0
enum1
enum2
enum3 equ 20
enum4
enum5
...
.endenum
would be the same as
Code: [Select]
enum0 equ 0
enum1 equ 1
enum2 equ 2
enum3 equ 20
enum4 equ 21
enum5 equ 22
...
The main reason for this is automatically allocating and reallocating indices, e.g. if I'm making events in an RPG and I need to track each one, normally I'd have to write
Code: [Select]
eventChest1 equ 1
eventChest2 equ 2
...
eventChest20 equ 20
eventSwitch1 equ 21
eventSwitch2 equ 22
...
So if I decide to add another chest event for whatever reason, I would have to either update all the eventSwitchX equs, or put the chest right after the eventSwitchXs (which is disorganized and not ideal.) You can also have the -sym output include what each enum gets mapped to.
Title: Re: armips assembler (v0.7c released!)
Post by: MarkGrass on May 14, 2015, 12:14:38 pm
Good idea, x0_000.

@KC - May I ask if you plan to add support for generic c/c++ struct types?

Currently, I have to convert my structs/variables to something that armips can use, but I still have 4,493 lines of structures/variables to convert. Suffice to say that it would truly be a godsend!
Title: Re: armips assembler (v0.7c released!)
Post by: granitor on May 16, 2015, 09:17:07 pm
Good idea, x0_000.

@KC - May I ask if you plan to add support for generic c/c++ struct types?

Currently, I have to convert my structs/variables to something that armips can use, but I still have 4,493 lines of structures/variables to convert. Suffice to say that it would truly be a godsend!

Those last too requests sound more like what a C or Cish compiler would do, not an assembler.

I like the concept of this assembler, a "patching assembler" is what I'd call it, maybe other have similar features but it seems very useful for modifying existing files. I think adding enums and structs is going too far though, that's really a compiler's work.
Title: Re: armips assembler (v0.7c released!)
Post by: MarkGrass on May 17, 2015, 10:05:34 am
Those last too requests sound more like what a C or Cish compiler would do, not an assembler.

I like the concept of this assembler, a "patching assembler" is what I'd call it, maybe other have similar features but it seems very useful for modifying existing files. I think adding enums and structs is going too far though, that's really a compiler's work.

I absolutely agree.

...but just imagine having a 167Kb header file, full of every single structure, enumeration and variable that a certain PSone game uses, only to be be restricted to using it in a c/c++ compiler.

Granted, I could load a structure into a register and access various variables via indexing, but that would still require non-stop commenting just to know what the hell I'm working with.

It's a dumb question/request of KC, but most certainly worth asking for in my scenario.
Title: Re: armips assembler (v0.7c released!)
Post by: KC on May 17, 2015, 12:07:25 pm
It's probably not terribly difficult to add. The new parser is a token based recursive descent parser, so you'd more or less just have to come up with some productions, turn them into a parsing function, and then add the retrieved enum/struct values as (qualified, preferably) labels. Not really one of my priorities, but everyone can contribute, and I'd be ready to answer questions in the RHDN IRC channel.
Title: Re: armips assembler (v0.7c released!)
Post by: KC on October 04, 2016, 09:07:29 am
Some updates from the last year: