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

What makes it so difficult to adapt PSX ASMs to work on the PSP?

Started by Quantumpencil, February 03, 2018, 06:41:05 pm

Quantumpencil

Hello everyone,

In defiance of what seems to be the general consensus in these parts, I strongly prefer the war of the lions version of the game (especially its translation) and am interested in attempting to port some ASM hacks from the PSX version to WotL. I don't know MIPS R3000, but I do know x86 and I think I can figure it out. Rather than individually port the hacks, I'd like to first see if it's possible to write a program capable of adjusting PSX ASMs to work for the WotL ISO.

I found a few threads around here from a long time ago which seemed to suggest that WotL actually contains the original Japanese PSX code (structurally untouched) within it though things have been moved around, so offsets & addresses for a given piece code might be different between the two versions.

If these are the only differences, it seems to me it should be possible to match bytestrings on only opcodes (by zeroing out all the address values in both games) in order to search for sections of code which have the same "structure".  Provided one can identify the opcodes/addresses present in a code block (Using a dissassembler) it should be possible to map the address values used to certain in game variables between their PSX and PSP versions.

Given that no one has done this, I feel like it's probably not as easy as I'm imagining it (and I'll find out soon enough when I attempt to do so with some simple ASM hacks), but has anyone attempted anything like this before, or does anyone have any knowledge about the structure of the PSP ISO that would preclude such a solution in principle, or expedite the process of creating one?

Thank you,
QP
  • Modding version: WotL
Modding version: WotL

Nax

It's a bit more complicated than that.

1. Some of the code in the PSP version is totally different (like the graphical system, but also file loading and stuff like that)
2. Some of the code has been altered, to implement the new items, jobs...
3. Ignoring the two precedent points, you would still only be able to relocate very simple hacks. Any ASM that need to add code will be complicated to relocate automagically.
4. Even if you could do all that, it's still a different game. The old ASM hacks could (and will) cause issues, for example, bad interactions with the new items (because of uint8s)/the new jobs, the spritesheet issue, etc etc.

You would definitely succeed with simple asm hacks, but for the simple ones, it may be easier to just port them by hand. For the most complex ones, you would want to port them by hand anyway to make sure they're correct.

However, you're right about one thing: it is viable to grep for matching binary sequences to find some offsets. That would help you find some matching offsets before exploring the differences and patching by hand, essentially leveraging the PSX documentation.

Quantumpencil

Ah, that makes sense. Looking at the current set of patches in FFTorgASM there seem to be quite a few which *appear* relatively simple to port (smaller formula changes, PA multi-hit formula, rewrite of the axe formula, fix shirahadori), provided no unforeseen interaction with the new code.

I shall get to it and see what happens.
  • Modding version: WotL
Modding version: WotL

Angel

Another thing worthy of mention: both the PSP and mobile versions of WotL are actually running an emulation layer of the Japanese 1.0 PlayStation release. Part of the reason most ASM won't work is because the emulation is high level, meaning that it's not so much a PlayStation emulator as it is a Final Fantasy Tactics emulator, and that emulation layer is ignorant to low level functions of the PlayStation hardware.

To put it another way, it's like someone who is fanatical about Skyfall, and can recite every line of dialogue from the movie, but has never seen a single other James Bond film or knows anything that's happened in any of them, much less read the original Ian Flemming stories. You'll start talking about The Spy Who Loved Me, and this person looks at you like you have three heads and just hastily ends the conversation and walks away.
  • Modding version: PSX
* Angel should quit being a lazy bitch
<@Elric> I agree to that as well

nyanyame nyanyajuu nyanyado no nyarabide nyakunyaku inyanyaku nyanyahan nyanyadai nyannyaku nyarabete nyaganyagame
At the end of the day, are we not all trapped inside lemons?

Quantumpencil

Is that so? I'm interested in a more detailed description of how the emulation layer might complicate modding. I haven't gotten that far into it (because I'm having to learn MIPS r3000) but I did manage to track a few formulas and make some simple changes in BATTLE.BIN (modifying 5E to use PA) as a POC, which seem to be working.

I'll try to get shirahadori only working on melee weapon types once I've improved my comfort with this instruction set & explored some more, but I've seen no evidence of this emulation in memory dumps (I don't know what to look for though, admittedly)

Feel free to throw the most technical explanation you feel like writing at me; I don't shy aware from it.

EDIT: Actually, this doesn't work -- I tried modifying 5E to use PE evasion routine instead of the MA one it normally uses, and there was no effect. There's also appears to be no effect in simply replacing the address after the jal opcode with all 0's, which leads me to think that somehow the formulas in BATTLE.BIN aren't even used on the PSP version (is this possible?)

EDIT2: So this approach was awful, but I've sense then being reverse engineering the WOTL battle mechanics; I have found most of the formulas (they're in EBOOT.bin) and have verified that changes to them work. Nax and I are working together disassembling the game/labelling the data structures/subroutines and I intend to start porting hacks in the next few weeks.
  • Modding version: WotL
Modding version: WotL