Please login or register.

Login with username, password and session length
Advanced search  


Use of ePSXe before 2.0 is highly discouraged. Mednafen/RetroArch is recommended for playing/testing, pSX is recommended for debugging.

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Glain

Pages: [1] 2 3 ... 28
The Lion War / Re: ASM conflict problem
« on: January 13, 2020, 07:26:13 PM »
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.

Help! / Re: FFX FFT; breakpoints not working in formation menu
« on: January 09, 2020, 02:25:53 AM »
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).

Help! / Re: FFX FFT; breakpoints not working in formation menu
« on: January 08, 2020, 08:22:18 PM »
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...

PSX FFT Hacking / Re: Any ASM tutors available?
« on: January 03, 2020, 02:10:12 PM »
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.

PSX FFT Hacking / Re: Any ASM tutors available?
« on: January 02, 2020, 12:42:36 AM »
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:

Documentation for MIPS32 release 2:
PSP emulator source code:

PSX FFT Hacking / Re: ASM Requests
« on: November 11, 2019, 11:13:27 PM »
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.

Code: [Select]
   lhu r17, 4(r3)
   beq r17, r0, 0x0018cfd0      # Branch to end if No HP damage was dealt

Code: [Select]
   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?).

PSX FFT Hacking / Re: ASM Requests
« on: November 08, 2019, 05:22:36 AM »
Just eyeballing it, you also need to copy the HP damage into r2.  Also, why remove the branch?

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:

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.

War of the Lions Hacking / Re: Are multiple custom jobs now possible?
« on: October 26, 2019, 11:11:05 PM »
Check this post/thread:

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

Help! / Re: Help installing "The Lion War" with slight modification
« on: October 09, 2019, 04:53:20 AM »
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)

PSX FFT Hacking / Re: ASM Requests
« on: July 31, 2019, 03:26:59 PM »
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.

PSX FFT Hacking / Re: ASM Requests
« on: July 31, 2019, 04:16:02 AM »
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.

Help! / Re: Excising FMV to Save Space (PSX Version)
« on: July 25, 2019, 11:36:32 PM »
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.

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.

Help! / Re: Routines that determine Move/Act CT costs
« on: May 30, 2019, 01:09:22 PM »
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).

Help! / Re: Gender Byte
« on: May 21, 2019, 11:09:29 PM »
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.

You should be able to just remove the branch by changing BATTLE.BIN at offset 0xD90BC (4 bytes) from 02 00 40 10 to 00 00 00 00.

Patch that does it:

According to the Wiki, the relevant routine seems to be this one.  The only thing that really catches my eye at first glance is that it seems to sometimes skip setting the red flashing status if the action is immediate (no charge time), based on the branch at 0x1400bc.

No problem, glad to hear the hit % looks right!

Right, so we've calculated the hit % but never applied it in the actual formula code.  There is a bunch of code related to actually making the hit % work that could be inserted, but I think it's easier if we make use of one of the existing routines.  We can do that by storing our Hit % value into the ability's X value instead of the action's hit % (assuming you aren't using X for something else, or have already made use of it in the formula and don't need it anymore).  The way it would work is that we would change the bottom of our new routine (the "end" section) to this:

Code: [Select]
                    lui     t0, 0x8019
                    jr      ra
                    sb      v0, 0x38f9(t0)  #   Store Hit% as X

Then in the calling (formula) routine...

Code: [Select]
#   Evade section up here (if necessary)

#   Custom tame hit % section
jal     @find_monster_tame_hit_percent
jal     0x80184360
bne     v0, zero, formula_end_section       #   Replace "formula_end_section" with the appropriate address (same address as evade would branch to on a miss)

#   Rest of the formula code (...)

I think that should work to get the Hit % actually applying.

Pages: [1] 2 3 ... 28