Well, after all that, I discovered a more mathematical (and thus, to me at least, easier) way to figure all this out.

So...

0,0 on the Overworld Map is loaded into 7F:5C71 (the first byte of Map RAM), and the first row (0,0 through 255,0) is loaded when 7E:0693 is 00.

0,1 on the Overworld Map is loaded into 7F:5D71 (100 hex bytes, or one row's worth, later), and the second row (0,1 through 255,1) is loaded when 7E:0693 is 01.

0,3 on the Overworld Map is loaded into 7F:5E71, and the third row (0,2 through 255,2) is loaded when 7E:0693 is 02.

... And so on in this fashion for the first 64 rows (0,0 through 255,63), or 1/4 of the map.

Now then...

0,64 on the Overworld Map is loaded into 7F:5C71 (the first byte of Map RAM), and the 65th row (0,64 through 255,64) is loaded when 7E:0693 is 40 (hex, which equals 64 in base-10).

0,65 on the Overworld Map is loaded into (you guessed it) 7F:5D71, and the 66th row (0,65 through 255,65) is loaded when 7E:0693 is (you guessed it again) 41 (or 65 in base-10).

... And so on in this fashion for the rest of the second 64 rows.

From here, the pattern is pretty predictable.

So...

To figure out the coding to change a specific point on the map:

First, figure out the hex representation of your map position.

The change will be made when 7E:0693 equals the y value of the point you want to change.

Then, simply add your x value to 7F:5C71 to determine the indexed location in RAM that will be affected.

For example:

If you want a flag to change position 123,204 on the Overworld Map...

first, convert your base-10 position to hex. That's 7B,CC.

You'll be making the change when 7E:0693 equals your y value: CC.

Then add your x value (7B) to 7F:5C71. That's 7F:5CEC.

So the code would look like this (after the flag check comes back true):

`A5 93 LDA $93`

C9 CC CMP #$CC

D0 06 BNE $06

A9 13 LDA #$13

9F EC 5C 7F STA $7F5CEC,X

6B RTL

There it is!

A

*much* quicker process than what I previously posted!