Yeah yeah... lots of topics about this troublesome mapper. Oddly the most common mapper, yet one of the hardest to emulate (I'd put it as the 2nd hardest -- right behind mapper 90)
I understand about the A12 rises and how the counter works and all that. My issue is with the timing.
I have Blargg's MMC3 tests passing, as well as the titlescreen of Kick Master and in-game Wolverine working glitch-free (have yet to test some other problem points in Kick Master -- but I'm confident they'll be fine). It's HOW I got them working that concerns me...
I understand that A12 rises on the 5th cycle of every 8 fetch cycles (4, 12, 20, 28, etc for BG fetches if BG uses $1xxx.... 260,268, etc for Sprite fetches when they use $1xxx)
I built my emu to clock the counter at these times, then ran the test ROMs. Blargg's gave me a "too early" error, so I pushed it back a few cycles (I figured it was due to my PPU/CPU sync method -- perhaps it would have to go THROUGH the cycle rather than up to the cycle or something like that -- making an off-by-1 error likely (and even expected)).
However I was concerned when I found out I had to push the time back THREE ppu cycles from the norm in order to get a passing result in blargg's test. And even more (9!) to get Wolverine and Kick Master working without jitters -- and even up to 11! (where I have it now) to clear some garbage that appears on the right-hand side of the screen in Wolverine. (blargg's tests seem to pass when I adjust 3-11 cycles inclusive, but fail outside of that)
There's no way my calculations could be 11 cycles off... that's too big of a gap to chalk it up to ppu/cpu/mapper sync issues. But then this made me think back to an issue I had with APU IRQs... and how when I tripped an IRQ exactly when the frame IRQ flag raised, I got errors. I ended up solving the problem by adding a delay of 2 CPU cycles between when the IRQ flag raised and when the IRQ actually happened. Currently I only do that for APU Frame IRQs... but is that the case for EVERY IRQ? That might explain the 11 cycle offset -- 2 CPU cycles would eat at least 6 cycles of that. But that still leaves 5 ppu cycles of "adjust" time in my MMC3 code (could it be a 3 CPU cycle delay?)
I'm going to mess around with this some more and will probably report back with more crap. This whole thing of delays and stuff is a pain... why can't IRQs just happen immediately ;_;
While I'm on the subject -- anyone have any good recommendations for MMC3 problem games which make good test ROMs? My list is basically:
- Mega Man 3 (it has BG and sprites both use the $1xxx pattern table for the pause-status bar -- Pausing in the first half of Gemini Man's stage will glitch if you don't handle that properly)
- Crystalis (scanline -1 checking -- otherwise the screen shifts when you talk to people and there's that garbage line as you scroll on the map)
- Kick Master, Wolverine (both just generally very picky about timing -- Kick Master also does weird things and will deadlock if IRQs trip when they shouldn't (end of stage 2))
I'd really like some games which use a backwards setup (BG uses $1xxx, sprites use $0xxx) or other weird behavior like that so I can test. If anyone can recommend some like that or just some they have trouble with I'd be grateful.
EDIT-
Added the 2 cpu cycle delay between IRQ flag raise and actual IRQ tripping. Still need to adjust my MMC3 code by 3 ppu cycles (which is what I expected -- but that still seems like too much... 1 cycle if any, should be enough). If I up the delay to 3 CPU cycles, then my Frame IRQs come in too late according to blargg's tests.
Could MMC3 IRQs somehow be slower to register than APU IRQs? Is it possible there's a 3 CPU cycle gap for MMC3 but only a 2 cycle gap for APU Frame IRQs?
gah my brain!
EDIT AGAIN -
Bah it just dawned on me that 3 PPU cycles = 1 CPU cycle -- and it being off by 3 PPU cycles is explained by the PPU/CPU sync issue (it has to go THROUGH the cycle rather than just UP TO the cycle). So I guess I answered all of my questions then XD. Although I'd still like test ROM recommendataions -- plus this post might help someone else *shrug*
^^;
I understand about the A12 rises and how the counter works and all that. My issue is with the timing.
I have Blargg's MMC3 tests passing, as well as the titlescreen of Kick Master and in-game Wolverine working glitch-free (have yet to test some other problem points in Kick Master -- but I'm confident they'll be fine). It's HOW I got them working that concerns me...
I understand that A12 rises on the 5th cycle of every 8 fetch cycles (4, 12, 20, 28, etc for BG fetches if BG uses $1xxx.... 260,268, etc for Sprite fetches when they use $1xxx)
I built my emu to clock the counter at these times, then ran the test ROMs. Blargg's gave me a "too early" error, so I pushed it back a few cycles (I figured it was due to my PPU/CPU sync method -- perhaps it would have to go THROUGH the cycle rather than up to the cycle or something like that -- making an off-by-1 error likely (and even expected)).
However I was concerned when I found out I had to push the time back THREE ppu cycles from the norm in order to get a passing result in blargg's test. And even more (9!) to get Wolverine and Kick Master working without jitters -- and even up to 11! (where I have it now) to clear some garbage that appears on the right-hand side of the screen in Wolverine. (blargg's tests seem to pass when I adjust 3-11 cycles inclusive, but fail outside of that)
There's no way my calculations could be 11 cycles off... that's too big of a gap to chalk it up to ppu/cpu/mapper sync issues. But then this made me think back to an issue I had with APU IRQs... and how when I tripped an IRQ exactly when the frame IRQ flag raised, I got errors. I ended up solving the problem by adding a delay of 2 CPU cycles between when the IRQ flag raised and when the IRQ actually happened. Currently I only do that for APU Frame IRQs... but is that the case for EVERY IRQ? That might explain the 11 cycle offset -- 2 CPU cycles would eat at least 6 cycles of that. But that still leaves 5 ppu cycles of "adjust" time in my MMC3 code (could it be a 3 CPU cycle delay?)
I'm going to mess around with this some more and will probably report back with more crap. This whole thing of delays and stuff is a pain... why can't IRQs just happen immediately ;_;
While I'm on the subject -- anyone have any good recommendations for MMC3 problem games which make good test ROMs? My list is basically:
- Mega Man 3 (it has BG and sprites both use the $1xxx pattern table for the pause-status bar -- Pausing in the first half of Gemini Man's stage will glitch if you don't handle that properly)
- Crystalis (scanline -1 checking -- otherwise the screen shifts when you talk to people and there's that garbage line as you scroll on the map)
- Kick Master, Wolverine (both just generally very picky about timing -- Kick Master also does weird things and will deadlock if IRQs trip when they shouldn't (end of stage 2))
I'd really like some games which use a backwards setup (BG uses $1xxx, sprites use $0xxx) or other weird behavior like that so I can test. If anyone can recommend some like that or just some they have trouble with I'd be grateful.
EDIT-
Added the 2 cpu cycle delay between IRQ flag raise and actual IRQ tripping. Still need to adjust my MMC3 code by 3 ppu cycles (which is what I expected -- but that still seems like too much... 1 cycle if any, should be enough). If I up the delay to 3 CPU cycles, then my Frame IRQs come in too late according to blargg's tests.
Could MMC3 IRQs somehow be slower to register than APU IRQs? Is it possible there's a 3 CPU cycle gap for MMC3 but only a 2 cycle gap for APU Frame IRQs?
gah my brain!
EDIT AGAIN -
Bah it just dawned on me that 3 PPU cycles = 1 CPU cycle -- and it being off by 3 PPU cycles is explained by the PPU/CPU sync issue (it has to go THROUGH the cycle rather than just UP TO the cycle). So I guess I answered all of my questions then XD. Although I'd still like test ROM recommendataions -- plus this post might help someone else *shrug*
^^;
