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 RTLThere it is!
A
much quicker process than what I previously posted!
