News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Author Topic: MMC3 IRQ Problem  (Read 1609 times)

darkmoon2321

  • Jr. Member
  • **
  • Posts: 59
    • View Profile
MMC3 IRQ Problem
« on: September 19, 2018, 02:39:15 am »
As part of the Deadpool hack of Ninja Gaiden, I've converted the game from MMC1 to MMC3 and am now using IRQs to trigger the split screen effects rather than sprite 0 hit detection.  For the most part, things are working fine.  However, in one stage I implemented parallax scrolling, which looks perfect in FCEUX but has issues on more accurate emulators and on real hardware with an Everdrive/Powerpak.  The problem is that sometimes the screen will appear to shake, shifting up and down by a single pixel.  With some help from the beta testers I was able to determine that the shifting coincides with a palette change.  Regarding the MMC3 IRQ counter, from Nesdev:

Quote
The counter is clocked on each rising edge of PPU A12, no matter what caused it, so it is possible to (intentionally or not) clock the counter by writing to $2006, regardless of whether PPU is/is not rendering.

It is normal for the game to write to $2006 during NMI when setting the address to update for the status bar on that frame.  But sometimes I write to $2006 when manually updating specific tiles or palettes during NMI also.  Will doing this always result in the IRQ triggering a scanline early?  Also, is there a fix for this other than going back to a sprite 0 hit?  I could also create a "hacky" fix that changes the IRQ reload counter based on whether I'm transmitting other data to the PPU on that frame.  However this will probably cause the screen shaking to occur when playing on FCEUX instead.  Also, I don't notice any additional screen shaking due to scrolling, despite the fact that loading new level data results in several writes to $2006.

Disch

  • Hero Member
  • *****
  • Posts: 2746
  • NES Junkie
    • View Profile
Re: MMC3 IRQ Problem
« Reply #1 on: September 19, 2018, 10:55:06 am »
Quote
But sometimes I write to $2006 when manually updating specific tiles or palettes during NMI also.  Will doing this always result in the IRQ triggering a scanline early?

If you are making A12 rise, yes.  That is what "clocks" the IRQ counter.

Really, you should do all of your drawing in VBlank first, then set your screen scroll values to whatever they need to be, then set up your IRQ counter dead last, but before rendering actually starts.  This will ensure that no matter how you muck up the IRQ counter with $2006, you'll be resetting it immediately afterwards so it doesn't matter.
« Last Edit: September 19, 2018, 11:03:27 am by Disch »

darkmoon2321

  • Jr. Member
  • **
  • Posts: 59
    • View Profile
Re: MMC3 IRQ Problem
« Reply #2 on: September 19, 2018, 12:09:13 pm »
Really, you should do all of your drawing in VBlank first, then set your screen scroll values to whatever they need to be, then set up your IRQ counter dead last, but before rendering actually starts.  This will ensure that no matter how you muck up the IRQ counter with $2006, you'll be resetting it immediately afterwards so it doesn't matter.

Thank you! For some reason, I had stupidly gotten it into my head that having different amounts of data being transmitted to the PPU would interfere with the timing of the IRQ, not realizing that the counter normally won't decrement during vblank (outside of writes to $2006, obviously).