I've been looking into the problem with Safari in Letterland a bit more after briefly discussing the issue with James via PM, and I have data explaining why the shaking happens, as well as a possible theory for what the actual fix is. Of course, it's possible that somebody has already tested this aspect of the MC-ACC and my theory is wrong, but I can't think of a better explanation at the moment. :-/
The status bar shakes due to the IRQ firing early on some frames. It is supposed to fire on scanline 205, but occasionally fires on scanline 204 (James pointed out some $2006 updates that occur when rendering; these happen one scanline after the IRQ). It fires on scanline 204 instead due to an extra clock occurring around cycle 300 on scanline 188. That clock happens because the game disables rendering around cycle 276 (putting vramaddr_v onto the address bus), then writes a palette address to $2006 around cycle 300 (putting the $3Fxx address onto the bus). If the vertical scroll value was even at the time rendering was disabled, this triggers an A12 rise. The difference in PPU clocks between when A12 falls and then rises again is between 24 and 30 clocks, clearly more than 15, so the IRQ counter gets clocked.
The only way around this (assuming that the PPU does put the palette address onto the bus and that nothing else is being emulated incorrectly), is to require more time between A12 rises in order to clock the counter. This doesn't seem unreasonable, especially since we already know that the MC-ACC doesn't *quite* behave like an MMC3. The required time between rises must be
at least the same as required by the MMC3, but there's no reason it couldn't be greater. I tried various values and found that a minimum of 39 PPU cycles (or 13 M2 cycles, since the cart doesn't have access to the PPU clock signal) are required to fix the shaky status bar. The actual required time between rises may be larger than this, but there's no way to know what it is without testing an actual MC-ACC.
I've tested this theory in my emulator as well as Nestopia, and the shakes completely disappear (and the status bar looks correct: no scanline missing from the middle). I don't have a clean patch for Nestopia yet though, and simply changing the value of CLOCK_FILTER in NstBoardMmc3.hpp (as I did to test this theory) will definitely break actual MMC3 games. This is all purely academic if my theory is wrong though, so I'm hesitant to create a patch until this is confirmed (if it is confirmed).
