FF5 event data question - unlocking the mapview function

[Tzepish]

In Final Fantasy 5, pressing the Y button does nothing until you have found the map; afterwards, pressing Y brings up the map.  Clearly, the Y button kicks off an event that checks a flag (has the player acquired the map?) and then does nothing or shows the map dependent on the result of that check.  I'd like to award the map to the player earlier, or bypass the check entirely, so that he always has the map.  If this were FF6, such a thing would be easy due to all the event data disassemblies out there, but I'm not aware of the same info being available for FF5.  Does anyone have some insight into this problem?

[Lenophis]

It took me a while to find, but you asked this once before. Upon reading what I said to insert to give you the map...

Code Select Expand

LDA #$02      (bit for the world map)
TSB $0A4D      (one of the rare item bytes)
...you can simply put a read breakpoint on 7E/0A4D to see when the Y press reads this.

[Tzepish]

Oh yeah, I had dropped this issue back then and decided to return to it now, 4 years later :-).  I confess that your replies assume a level of proficiency I don't posses.  I don't know where to put your code, and while I'm familiar with the concept of breakpoints from scripting in Lua, I wouldn't know how that knowledge translates into what to do on the SNES.  Is 7E/0A4D a location that 's tied to the Y button?

[STARWIN]

in a hex editor, search the ROM for:

C9 00 F0 15

and change this to:

C9 00 EA EA

it should always choose the map codepath now. this only eliminates the branch, the calculations that determine it still occur. but i guess there can't be any side-effects with viewing a simple map, right? (just joking, there could always be side-effects)

the world map rare item seems to be irrelevant as far as Y is concerned. i didn't check the relation between the item and the Y button.

[KingMike]

That would be address $22D in a non-headered ROM.
You could just go ahead and remove the C9 00 as well (change to EA), I'd suspect. Since you're removing the branch, might as well remove the condition check.

[STARWIN]

might as well remove the condition check.

in general, if the related code is not understood well, it is always best to alter as little as possible: 1. less work 2. less chance for side-effects

as a theoretical example, three code paths:

if (a==b) {path1;}
if (a>b) {path2;}
path3;

if you don't want to take path1 and remove the comparison, you might get:

if (x>y) {path2;}
path3;

, where x and y depend on the earlier comparison made by the processor

[Tzepish]

Thanks, STARWIN!

And yeah, if there's one thing I've learned working on games professionally, it's that it's always safer to leave stuff in than to take it out, which is why things like Hot Coffee remained to be discovered (and why we find nonsensical things in the code of released games sometimes :-)

[FinS]

in general, if the related code is not understood well, it is always best to alter as little as possible: 1. less work 2. less chance for side-effects

as a theoretical example, three code paths:

if (a==b) {path1;}
if (a>b) {path2;}
path3;

if you don't want to take path1 and remove the comparison, you might get:

if (x>y) {path2;}
path3;

, where x and y depend on the earlier comparison made by the processor

If you look ahead only a few operations you will see that either way the flags are reset for both paths before any new branch commands so there is no worry about getting a wrong comparison between x and y.

[STARWIN]

i can make the example harder then:

if (a==b) {path1;}
stuff;
if (a>b) {path2;}
path3;

now it is no longer enough to look ahead only "a few" operations 

[FinS]

I'm not sure you understand what I'm saying.

Your examples do not pertain to this situation because the negative and zero flags are adjusted by a load A operation on either path thereby making the cmp #00 irrelevant beyond the initial branch if equal. The carry flag would not be used from a cmp #00 because it would be on either way.

[STARWIN]

yes. i was only justifying the practice in a general case, as practices by definition are not case-by-case.