Unpatching Heinous Older Versions of Ignore Defense by Drakkhen

A better title of this thread would be "Ignoring the Revert Ignore Ignore Defense Patch while Unpatching the Ignore Defense Patch, the Ignore Ignore Defense Patch, and the Ignore Ignore Defense for Characters Patch for older versions"

If you're like me, you like sex.  But you also don't like it when great ROM patches are so poorly documented that even fascists won't let you on the train.  If you can see these contradictions, then you can understand how terrible they really are.  Drakkhen's earlier versions of Ignore Defense and Ignore Ignore Defense ("IID") patches are just the type of patches we're terrified of.

I know, ID and IID are some of the best patches in the world.  The thing is, they apparently get right in your way of hacking and changing special effects.  And if you're like me, you like sfx.

Unfortunately, Drakkhen was even kind enough to benefit us with a reversion patch to undo previous ignore ignore defense patches, prior to putting on his brand new patches, which we should all enjoy.  This quickly caused my game to crash during each combat initiation.  So, we do what we always do---look for the changed code in the readme.  This is where the fascists come in.  Drakkhen, the high-flying playboy that he is, doesn't have time for all the notes of changed code, especially if he's already giving us his patches, his genius, and to the women--his charms. 

So what do we have?  We have the old IPS patches with code in it, although I don't know how to read which addresses the code will be placed on.  We have the new reversion patch with code in it.  And we have backup copies of the ROMs, which is what we'll use.  So we start WindHex to compare files and see the differences of a fresh new ROM and the old patches we applied.  At this point we could probably create a patch of the differences, then apply it to our playable ROM, but patches have failed us so far, so let's make damn sure we do it right this time.

We take the original code of the pure ROM at each address that's been changed according to WindHex, all the while verifying the code you're noting versus the C2 bank disassembly, just to be much too sure we're correct.  Then we take the code that's at the same locations in our patched ROM (which is defunct) and note those.  We verify this code against what code is provided by Drakkhen's sparse notes, which reads like sanskrit raping cuneiform.  Now we replace all the latter with the former, and we have, at last, enough documents to get on the bloody train:

Code:

HEADERLESS ROM 1.0 PATCHED WITH ID, IID, IIFC v1.81

DIFFERENCES FOUND VIA COMPARE FROM WINDHEX

PATCHED VERSION

THIS IS THE DATA THAT GETS PATCHED ONTO THE ROM

00020C9E:  4C 4B 67 (jsr 674b?)
00020CA8:              4C 00   67 FA 20 32 67 AD
    A2 11 89 20 F0 0C 20 3D 67 08    A9 FF 80 29 20 32
    67 FA 20 3D 67 08 B9 B9 3B 90   03 B9 B8 3B 85 E8
    1A F0 14 EA EA EA EA

00023950:
    80 31 EA EA

0002397F:
                               01
    0C A4 11 A9 20 0C A2

00026700: 27 BYTE STRING
0002671C: 68 BYTES STRING (ISN'T THIS RIGHT AFTER 26700?? YES)

================================================
Actual Original Values from C2 Bank Disassembly Document for 1.0 Unheadered

C2/0C9E: 08           PHP
C2/0C9F: C2 20        REP #$20

Then 47 bytes
C2/0CA8: AD 14 34     LDA $3414
C2/0CAB: D0 03        BNE $0CB0
C2/0CAD: 4C 3B 0D     JMP $0D3B   (Exit if $3414 = 0)
C2/0CB0: 20 5A 4B     JSR $4B5A   (Random number 0 to 255)
C2/0CB3: 09 E0        ORA #$E0    (Set bits 7,6,5; bits 0,1,2,3,4 are random)
C2/0CB5: 85 E8        STA $E8     (Random number [224..255])
C2/0CB7: 20 3D 0D     JSR $0D3D   (Damage randomness)
C2/0CBA: 18           CLC
C2/0CBB: AD A3 11     LDA $11A3
C2/0CBE: 30 04        BMI $0CC4   (Branch if Concern MP)
C2/0CC0: AD A2 11     LDA $11A2
C2/0CC3: 4A           LSR
C2/0CC4: AD A2 11     LDA $11A2
C2/0CC7: 89 20        BIT #$20
C2/0CC9: D0 57        BNE $0D22   (Branch if ignores defense)
C2/0CCB: 08           PHP
C2/0CCC: B9 B9 3B     LDA $3BB9,Y (Magic Defense)
C2/0CCF: 90 03        BCC $0CD4   (Branch if concern MP or Magical damage)
C2/0CD1: B9 B8 3B     LDA $3BB8,Y (Defense)
C2/0CD4: 1A           INC
C2/0CD5: F0 10        BEQ $0CE7   (If = 255)

Then 4 bytes

C2/3F50: A9 1C        LDA #$1C
C2/3F52: 80 D0        BRA $3F24

7 Bytes
Recover HP - Heal Rod

C2/3F7E: A9 [start here]--> 20        LDA #$20
C2/3F80: 0C A2 11     TSB $11A2   (Sets attack to ignore defense)
C2/3F83: A9 01        LDA #$01
C2/3F85: 0C <--[SHOULD end here but the A4 after this was A2 instead! Changed it. Maybe FF3usMe? Other Patch?] A4 11     TSB $11A4   (Sets attack to heal)
C2/3F88: 60


Then FF FF to all 6700 - 677F block

And with that, we've got it back to normal.  And we can get on with our sfx business as we please, and even use Drakkhen's new patches.  But why would we do all this, and why this way?  Well you see, there are still faint glimmers of civilization left in this barbaric slaughterhouse that was once known as humanity.  Now we have graduated from sanskrit raping cuneiform to at least a mild form of dyslexic braille.  This can now be shared for other people--And there's a lot left to do in the world.  And we shouldn't let anyone stop us from getting on that train.

I have no clue if this was purely meant to be for the community... or if 90% was to bash on that other guy, ...anyways.... good job?

I thought it was actually quite complimentary for the most part. Patches are more important than code notes after all, and if you look at what Drakkhen has done for the world, it's quite something.

I should also add that my game crashed when trying to use a revert patch from Assassins capure weapon fix also, so it's 99% likely that it's my base ROM, FFVI: Is the Best Game Ever, at fault.

If you open an ips patch file in a hex editor, it spells it out quite nicely for you.

First 5 bytes: PATCH (this is in ASCII text)
First record:
3 byte address (CPU format; 00 00 00 would be the beginning of the ROM, or the header, if you have one. This is why headers matter in patches, by the way).
2 bytes length. (Just how long this particular record is)
N bytes ( From the length ... This is the payload. It tells you the new bytes to write over whatever is there).
Second record: (if there is one. Same format as first record. AA AA AA LL LL PP PP PP PP .... where A is address, L is length, P is payload)
After the last record, you'll see the letters EOF (this is in ASCII text) meaning end of file.

----------
Caveats:
1. If the address to patch were actually at 0x464F45 (=ASCII EOF) in the file (again, this has nothing to do with SNES CPU addresses, but merely the byte within the file), ips will die a horrible death. Thankfully SNES ROMs aren't that big, but it could be an issue with bigger files.
2. The format obviously means that you can't change more than 65536 bytes in a single record, although multiple records are fine.
3. There is a variation on ips that allows RLE (run-length encoding). In the case of an RLE, you'll see that the length portion of the record is 00 00, which will then be followed by 2 more bytes that are the true length, and one byte of payload. It means that the single payload byte is repeated from the offset a "true length" number of times. Useful for filling up a chunk with 00 or FF.
-----------
All this means that a patch that changes one byte will be 14 bytes long. PATCH111223EOF, where 1 are address bytes, 2 are lengths, and 3 is the byte you're changing it to.

There's a program called ips peek that lets you see ips file contents more plainly. Could use that if you're trying to reverse engineer code.