Author Topic: armips assembler (v0.7c released!) (Read 55152 times)

KC · « **Reply #60 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.

FAST6191 · « **Reply #61 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.

CUE · « **Reply #62 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).

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

KC · « **Reply #63 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.

MeganGrass · « **Reply #64 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.

KC · « **Reply #65 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. 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.

Gemini · « **Reply #66 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.

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:

To anyone who's interested, the menu source code I made can be found here, however it doesn't include yet the armips integration bits (which is just a call to Menu_root in the C code).

Nightcrawler · « **Reply #67 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

if you could upload it to the Fonts section. There's a pretty paltry selection of proportional 8 high fonts.

Gemini · « **Reply #68 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.

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:

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.

Code has been updated to reflect this change.

Nightcrawler · « **Reply #69 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.

KC · « **Reply #70 on:** January 11, 2014, 04:38:28 am »

Definitely a great demonstration!

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

it now supports both MIPS for PSP and ARM for GBA and NDS (on GBA you cannot write to global data variables, as the ROM is read-only. Though that is not enforced yet)
can import whole libraries (.a)
it can optionally create a function that calls all constructors of the imported library/object file. The user would have to call this function appropriately early

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.

KC · « **Reply #71 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.

Scio · « **Reply #72 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.

KC · « **Reply #73 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.

KC · « **Reply #74 on:** June 11, 2014, 04:58:37 pm »

With the latest commit, 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).

Gemini · « **Reply #75 on:** June 12, 2014, 10:20:26 am »

And here 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.

KC · « **Reply #76 on:** July 04, 2014, 08:55:26 am »

As of the latest version, it can be built and natively run on Linux and probably other Unix platforms.

KC · « **Reply #77 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

Xenesis · « **Reply #78 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

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

KC · « **Reply #79 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.