Amazing as always, abw. I compared yours side by side with the original and against mine, and I see how you managed to get that space. Clever use of rearranging conditionals to clear allowed you to essentially compress the entire other subroutine into the one above it. Now I definitely have to list you as the main credit for this patch. It looks awesome though, plus then we don't have to eat into any of our free space chunks yet! Which is good, because I have a pretty ambitious intention for some of those...
So do you think that for my counter solution, the better choice is to use 6x 11 byte subroutines? I don't even know how to begin looking for where those table and pointer setup routines are in the disassembly, but I'm guessing that they simply don't exist for the addresses we want if they were using absolute addressing. Do you have an idea how many bytes it would take to create something like that for our counters, and at that point, is it better for me to just make 6 almost identical subroutines like my mockups in free space?
Looking at the RNG fix now. And yes, the idea was to make a fair RNG that gives all 4 characters as close to an equal chance of being targeted as possible. If this does indeed cause a more uniform distribution as opposed to what before could be described as 12.5% (0-63), 37.5% (64-127), 37.5% (128-191), 12.5% (192-255), then it should solve the problem outright. I can't imagine it will harm any other mechanics in the game, as RNG should aim to be uniform anyway in this game's combat systems. Would you like to keep this under review as per your notes about avoiding that free space, or do you want me to slap it on the first post?
Replace each INC $7xxx,X with a JSR to separate routines, or same routine if some clever addressing can be worked out.
0x031478|$0C:$9468:FE F3 7C INC $7CF3,X ; Character #1 physical attack counter
0x031E68|$0C:$9E58:FE F7 7C INC $7CF7,X ; Character #1 spell slot #1 battle use counter
0x031E75|$0C:$9E65:FE 3F 7D INC $7D3F,X ; Character #1 black magic use counter
0x031E7A|$0C:$9E6A:FE 43 7D INC $7D43,X ; Character #1 white magic use counter
0x03257B|$0C:$A56B:FE 37 7D INC $7D37,X ; Character #1 counter for times physically attacked by enemy
0x03261D|$0C:$A60D:FE 3B 7D INC $7D3B,X ; Character #1 counter for times magically attacked by enemy
BD F3 7C LDA $7CF3,X <<< this is the crux of whether we can use a single sub-routine or need 6
C9 08 CMP #$C8 <<< cap counter at 200 so overflow won't happen in any scenario
B0 03 BCS +3
FE F3 7C INC $7CF3,X <<< this too
66 for 6 11-byte sub-routines similar to the above. If indirect addressing can be used, it becomes 9, bringing us to 57 as the magic number. Based on Jiggers's statement about the way the data table would be laid out if we needed to make a new table, we'd be looking at 7C F3 7C F7 7D 37 7D 3B 7D 3F 7D 43... That's another 12, bringing us to 45. So if the code for indirect addressing can be fit into 45 bytes, then that would be the optimal way to approach this fix. I just have to find an example of how it works in the disassembly. Just searching the HEX in the ROM I already know no table already exists for these addresses, as 7C F3 in that order only occurred twice and they didn't seem relevant based on the surrounding bytes.