Final Fantasy Hacktics

The files are ENTD1.ENT through ENTD4.ENT in the BATTLE directory of the disc image.  Only the current ENTD entry is kept in RAM for any length of time (which is why GS codes for them can't really be generated, at least without a ton of conditionals).

That's 0x5FE74, not 0x5EE74.  Location in file is 0x50674, not 0x4F674.

I think the codes starting with 7 are conditional codes, although I don't know if that's proper form for the Gameshark.  It should probably be D instead of 7.  So essentially, if the value at 0x14E61C == 0xF400, run the next code.  This is probably a test to see if BATTLE.BIN is loaded (and that's the binary file you're looking for).

Glancing at the Data/Table locations page, here's the memory range being edited:
801b63f0 - Ability Effect (2 bytes each, 0x1c6 total)

Hmm.  Is that definitely the latest version of the apply defense patch?  0xF2130 should be the earliest write location.

You can get the latest version of my XML from this thread.

Use an execute breakpoint, not a memory read breakpoint.  The former breaks when the instruction at that address is executed; the latter breaks when the value from that RAM location is read (by a different instruction somewhere).

You can hit breakpoints in the formation screen just fine.  It also doesn't make sense that the breakpoint would fire after BATTLE.BIN is loaded because that should overwrite the breakpoint (due to the way pSX handles execute breakpoints).  Are you sure you have the address right?  Your screenshot shows no breakpoint...

As an aside, if you're looking for specific data in the PSX version, we've documented a lot of it in the Data/Table Locations page on the Wiki.

You would have more success asking more specific questions...

"What operations do what" and "how to look for specific things" doesn't exactly give much to go on.  What specific things?  The location of party data in RAM?  The location of the subroutine that levels a unit up in the game code?  For the PSP version, we don't have much of that mapped out.  That means this will be something of a pioneering effort, and you'll need to use a debugger.  You were already, seemingly, on the right track with that, using PPSSPP.  CWCheat codes might also give you a clue as to where certain values are in RAM (and those can be generated with FFTPatcher).  There are also a few relevant threads in the PSP hacking section.  I would think you would have at least looked at this one.

And what do you mean by "operations"?  That does read like you mean low-level instructions, as in arithmetic/logical operations.  If that's not it, what do you actually mean?  Again, we don't have most of the subroutines mapped out for the PSP version, at least as of yet...

The PSP CPU is called Allegrex. The architecture it uses is MIPS32 release 2 (32 bit), and it also has some custom instructions/encodings.

When I was adding the PSP instructions into MassHexASM/LEDecoder, I was able to look up most of the instructions in the general MIPS32r2 documentation, and I found the rest in the source code of a PSP emulator.

Take a look at the replies in this thread: http://ffhacktics.com/smf/index.php?topic=7758.0

Documentation for MIPS32 release 2: http://personal.denison.edu/~bressoud/cs281-s10/Supplements/ISA_Vol_2.pdf
PSP emulator source code: http://code.google.com/p/pspemu/source/browse/trunk/src/pspemu/core/cpu/tables/Table.d?r=315

Actually, looking at this again, there would be a load delay issue with trying to copy the r17 value into r2 here.  While that could be avoided by loading r17's value earlier, there's no need to copy the value into r2 at all.  Just use r17 in the relevant locations.


   (...)
   lhu r17, 4(r3)
   nop
   beq r17, r0, 0x0018cfd0      # Branch to end if No HP damage was dealt


0x18cfcc:

   sh  r17, 0x0026(r3)


0x18cfc4 becomes free and could just be replaced with a nop (or a call to a routine in free space for a calculation?).

Just eyeballing it, you also need to copy the HP damage into r2.  Also, why remove the branch?

(...)    lhu r17, 4(r3)    (...)                                        # <-- Would need intermediate instruction here to avoid load delay    move r2, r17    beq r2, r0, 0x0018cfd0         # Branch to end if No HP damage was dealt

Then look at what's happening at 0x18cfc4.  In the current modification, it's taking the HP damage, interpreting it as a RAM address and loading from it.
Instead, once again, just copy the HP damage into r2:

move r2, r17

This would just try to absorb the full HP damage.  If you want to do a calculation like (dmg * 20 / maxHP) then you would need some more code space, and may need to use some free/kanji space.

Check this post/thread: http://ffhacktics.com/smf/index.php?topic=9776.msg189499#msg189499

I suspect he actually found the correct locations for WOTL in this post, but I never looked into it myself...

0x1179a4 in BATTLE.BIN would be the correct address, because the game loads that file into RAM at address 0x67000, so the location of its code in RAM is offset by that same amount.  That instruction would be at RAM address 0x17e9a4 at runtime.  (In fact, BATTLE.BIN isn't even big enough to have an offset 0x17e9a4)

Yep.  This is a handy reference.  At first glance, the appropriate routine seems to be this one.

To get the AI to not spend JP, you could probably nop out the instruction at either 0x5d010 or 0x5d018.

It only applies when learning an ability from the formation screen.

Are you asking if AI units would still spend JP to learn their skills?  They would.  Perhaps the title of the patch could be a bit more specific.

Regarding what is actually playing the FMVs at the titlescreen, the code in OPEN.BIN probably controls that, but it needs more investigation.  I did document some of it, starting with the main routine here.

Quote from: Neophyte Ronin on July 25, 2019, 04:22:27 pm
if the registers got expanded

Haha what?  They're 32 bits wide at the hardware level.

Formula 0x38 is actually unique in that it doesn't have its own function and the formula table links directly to the status applying routine instead.  If you want to alter what the formula does without changing the status application routine, you have to change where it points.

At address 0x8018f610 in RAM (0x128610 in BATTLE.BIN) is the formula table.  Each entry is a 4-byte pointer to the function to call when that formula is used.  Entry 0x38 is at address 0x8018f6f0 in RAM and offset 0x1286F0 in BATTLE.BIN.  You would need to change that entry (from 0x80187f24) to the address of your custom function in free/kanji space.

This routine looks like the right one.

As for a breakpoint that could determine this?  That would be a write breakpoint on a unit CT value (offset 0x0039 from the start of the unit's in-battle data - array starting at 0x801908cc - see this reference).

Those are two different arrays of unit data.  The first is the main party data, and the second is the unit data used in the formation screen.  I actually have a more detailed definition of that data structure in the Data/Table Locations page.  (Search for "801c8638 (WORLD.BIN)")

In the case of formation screen unit data offset 0x70, it's copied from party data offset 0x04, so those should have the same value. (This routine is the one that copies the data.)

As for why they sometimes used 2-byte fields when 1-byte fields would suffice, it probably wasn't a conscious decision.  They probably used a short data type instead of a char data type in their C source code, or something along those lines.

I had glossed over the palette thing without really looking into what it represented.  That value, offset 0x04 from unit data, as far as I am aware, is actually the unit's team ID (i.e. whose side it's on).  It just so happens that for human enemies that would also affect the palette, but for monsters it's different.  If you were thinking of it in the sense of lower tier vs. higher tier monsters, I think that should just be checked via job ID since each tier is a unique job.

Expanding the first table to check the job IDs is the way I would have handled it, so that looks good to me!

As for the status checks, I found a logic error in the code, on this line:

addu    t7, t3, t4      #   Status byte pointer

It should be:

addu    t7, t2, t4      #   Status byte pointer

Edit - I wouldn't think of the 0x80184360 routine as the Dance/Song Hit% routine.  It's the Hit X% routine and apparently only dance and song use it in the base game.