Here's how my emulator handles such IRQs: It does not check the VRAM address (PPU registers) for an A12 rising edge. What it does is it checks for the address of the pattern tables themselves, selected by $2000 I believe. So, if the bg pattern address is set to $0000, and sp pattern address is set to $1000, then an IRQ will occur. I don't think this is the correct way of emulating the interrupts, but it sure makes Crystallis and Kick Master work. I too thought of A12 being the fine vertical scroll value, which is incremented at the end of every scanline. Following the current logic on how the IRQs work, the registers would have to be stored elsewhere, since right on cycle 260 the PPU starts fetching object data for the next scanline. Am I missing something, or is there some other sort of address controller I am not thinking about?
Here are other issues I've come accross with throughout the last few months: It seems like the fine vertical counter is not incremented at PPU cycle 256. I've tried incrementing the counter at different times, both before and after cycle 256, and it seems like the incrementation takes place *before* cycle 256. My guess is that it takes place right on cycle 251, since by incrementing it there, games like Crystallis and Wolverine will work just fine. Nestopia can't handle the status bar display in Wolverine correctly (it shakes), and so couldn't my emulator; but when I played around with the cycle number at which the counter should be updated, the game began to work correctly. Cycle 256 seems to be when the horizontal counters get updated.
One last thing: someone needs to clarify the precise behaviour of the OAM address during the data fetching/rendering process: does it change at all, and if so, is it predictable?