Ah right, I forgot to check MMC5, since not many games ever used it. I also remembered that big list of mapper info in the NES Specifications page and skimmed over that, and while there's a few other small-time ones which don't matter, it seems MMC5 and Namco106 are the only ones to worry about.
I planned to "detect" real cartridges anyway, so I can probably alter that aspect to actually disable my additions to the system entirely upon detection of one.
Bregalad wrote:
Now I'm not exactly sure how does cart do watch writes and decode them.
My initial plan was to actually do all this decoding from the cartridge connection, which I figured was possible by starting out using an LS139, similar to how the NES itself does it, except in this case, using /CE instead of an A15 line would result in the output being swapped. $8000-FFFF should be active when the clock is high and /CE is low, and $0000-7FFF should be active when clock is high and /CE is high.
Decoding down to 8k segments would require the other half of the LS139 (also like how the NES does it AFAIK), and then decoding down more precisely than that is going to require a bit more complexity, especially to filter out NES registers at $4000-4020, and also provide gaps for my own registers. But I've gotten logic figured to have a memory map along the lines of:
$4000-41FF = NES registers (much space being wasted, but saves from using more decoding logic)
$4200-43FF = My registers (again, more wasted space)
$4400-45FF = Other registers or ram
$4600-47FF = ram
$4800-5FFF = rom
Normally I'd just try to use $5000-5FFF since it's simpler to decode, but I realized that I need to store some font tiles and such in with the code, and need to squeeze in as much space as possible. And if necessary, I can break those 512 byte pieces down a little further if I need many registers, but I think one or two will do it.
This may have been answered elsewhere, but did anyone ever figure out an accurate method for detecting a reset of the console?