blargg wrote:
Kevin Horton's information definitely seems wrong. At the very least, I had no problem clocking the IRQ manually by toggling VADDR bit 12 even when PPU rendering was off, which is very clearly claimed to not work. I have a feeling some of the inaccuracy in descriptions of mapper hardware are due to misinterpretation of logic-analyzer results (probably a lot easier to overlook something when it's so raw). By running normal 6502 code, that error isn't possible.
I was using CopyNES to do the reverse engineering work; specifically using bankwatch (the NES register debugger add-on) and real live carts with a real live PPU. It might have been something odd with my NES that I used... I'm not really sure. Even I was mystified at to why I couldn't do it manually... since it *should* have worked. When I make some more copyNES units for pople, I will give it another try. AFAIR I tried a couple different carts too with different MMC3's.
I'm wondering if there is some kind of "filtering" going on in the MMC3... like it only responding to an edge every N M2 clocks or something, otherwise it'd trigger multiple times a scanline (for each sprite fetch).
I have another little add-on I use for RE'ing IRQs called "IRQ master". It's a small 8 digit hex counter that counts M2 cycles between a start trigger and the falling of /IRQ. Knowing the number of cycles it takes from trigger to IRQ then can be used to determine how long it took.