- the languagehttp://wiki.nesdev.com/w/index.php/CPU_memory_map
- what memory locations mean in NEShttp://wiki.nesdev.com/w/index.php/MMC1
- details about how it swaps content of memory blocks after addresses 8000 and C000, shallow knowledge sufficienthttp://www.fceux.com/web/download.html
- what buttons mean in ithttp://www.romhacking.net/documents/671/
- a high level description of the game contents
maybe there is a well-commented disassembly somewhere that covers this, maybe not.. uncommented disassembly is worthless in this case.http://datacrystal.romhacking.net/wiki/Final_Fantasy:World_map_data
- a low level description of map data
Set exec breakpoint at BC00 and open the map, it then pauses at the first instruction (LDA 9) of the procedure that does all world map drawing. This routine or something that it calls does what you don't like. Well, that is just an example to show what this is about. What you really want to do to find the place where something interesting happens is either to set a read breakpoint at map data that works/doesn't work as intended and compare, or figure out at as small scale as possible where what is interesting happens, and then do two trace logs that cover good/bad cases.
Actually solving the problem is probably easier than finding where it is (in this case). Hopefully there is some check (branch instruction) that you can either remove (turn into NOPs) or make always happen (change to whatever works) that solves it. Alternatively it uses a table of some kind to decide when to go blue mode, and then you could fix the data instead of changing the code.
The constant 17 (#$17 formally - # meaning constant instead of reference and $ meaning hex instead of decimal) in various places in the code most likely refers to ocean tile, and it perhaps uses that to set the screen pixels blue when needed.
It may also be too much work if you don't intend to use these skills anywhere else or elsewhere within this project. If you will, though, this is pretty perfect as a learning task.