You need to know how the ROM is mapped into CPU address space. That depends on the mapper used by the game. For example, MMC1 (Zelda, Metroid, etc., etc.) divides the ROM into $4000-byte banks. The last bank is mapped to $C000-$FFFF, and any other bank can be mapped into $8000-$BFFF. So, suppose you're looking to break when the byte at 0x13056 is read.
First subtract $10 to account for the iNES header, giving you 0x13046. Divide that by $4000 to get the bank number, which gets you 4. Then, keep subtracting $4000 to get the location
within the bank within question. Stop when you get a number that is less than $4000. (In other words, you want the modulus, i.e. remainder of the division we did.) In this case it will be 3046. Since bank 4 isn't the last bank, it will be mapped in the $8000 region, thus our address is $8000 + $3046 = $B046. If you create a breakpoint for reads on $B064, the emulator will break when you want. (It will also break if the same location is read in a different bank, but that usually doesn't create a problem.)
That might sound like a pretty big headache for every time you need to convert a ROM location to a CPU address, but with some practice you'll get to the point where you can do it in your head in a second. Again, this is just an example using MMC1. Different mappers will use different bank sizes in different configurations. You can look up detailed documentation on sites like NESDev for the various mappers.
How does an assembly opcode read from ROM? Can anyone shed some light on this?
The CPU doesn't know anything about mappers or banks. That's all handled by the cartridge. In effect, every time the CPU accesses the ROM, the cartridge does the above conversion.
Topic: Can fceux have breakpoints on read from ROM? (Read 3190 times)