This game writes to $2006 and it's causing the IRQ to clock more than once per scanline. If I filter such raises (leaving only raises from cycle 260 - sprite fetches), the game score is fine.
Any help???
EDIT: log of IRQ counter only. Format is Line, Cycle, Counter OR state.
The Talk page for MMC3 says that the MMC3 logic is:
* Assume a latch "L" and a small counter "C"
* Set the latch "L" on a rising edge of PPU A12 and clear the counter "C"
* If PPU A12 is low, increment the counter "C" on a rising edge of M2.
* Clear the latch "L" if the counter "C" becomes 2.
* Decrement the IRQ counter on a rising edge of the latch "L".
Does that help at all? It sounds subtle enough that it seems unlikely...
M2 is a signal that rises once every CPU cycle and indicates to the Game Pak that the address on A14-A0 is valid. It's similar to the Phi2 (second clock phase) output of an ordinary 6502, though M2 (modified Phi2) rises slightly earlier.
It looks fine for a hardware point of view, but not for me.
How is this translated into emulation, in CPU cycles, read/write...?
Zepper wrote:
tepples wrote:
M2 is a signal that rises once every CPU cycle
It looks fine for a hardware point of view, but not for me.
How is this translated into emulation, in CPU cycles, read/write...?
M2
is the CPU clock, as far as the mapper is concerned.
Back to the topic, well... The game is fixed if the IRQ is only clocked if sprites or background are enabled, but is this correct? Kevtris said that "nothing can stop the IRQ counter, as far as A12 toggles". Hmm....
MMC3 test gives an immediate error regarding PPUADDR ($2006), which the IRQ should be clocked.
Plus, this game has an unusual IRQ setup, since BG and SPR are fetched from PPU pattern #0, so it's clocked when using sprites 16x8 while fetching tiles from cycle 260.
Zepper wrote:
Back to the topic, well... The game is fixed if the IRQ is only clocked if sprites or background are enabled, but is this correct? Kevtris said that "nothing can stop the IRQ counter, as far as A12 toggles". Hmm....
You can stop the counter by stopping the PA12 toggles, and turning off rendering entirely stops the PA12 toggles.
Quote:
Plus, this game has an unusual IRQ setup, since BG and SPR are fetched from PPU pattern #0, so it's clocked when using sprites 16x8 while fetching tiles from cycle 260.
As far as I can tell, the sprite pattern table bit in PPUCTRL is ignored when the 8x16 bit is true.
tepples wrote:
(...)and turning off rendering entirely stops the PA12 toggles.
That's
not what the test ROM displays. I added a check on $2006/7 writes to assert BG or SP enabled.
Quote:
As far as I can tell, the sprite pattern table bit in PPUCTRL is ignored when the 8x16 bit is true.
True. My bad.
I fixed the game, working fine.
Now I need a solution for Rockman 5 and Kick Master. If I delay the IRQ by more than 1 cycle, it fixes. But the test ROM fails. Both have flickering.
* Bump *
@Zepper, how did you fix it?
Right now I'm having problems with the same game (Mickey in Letterland) in my emulator. The symptoms are different though.
After I select a stage and the scene where goofy picks you up in the jeep passes, all my emu shows is a black screen (The game does not hang, since when I press select, the stage selection screen shows up). If I disable the IRQ counter, I don't get the black screen but obviously graphics are messed up (same thing happens with Startropics and Startropics 2).
Any ideas on how to tackle this?
Thanks a lot in advance.
Short answer - I don't know. I still have doubts about how this game handles PPU IRQs with an unusual BG/SPR bank setting. I'm still investigating it... Sorry.
The "solved" wasn't solved after all.
Zepper wrote:
Short answer - I don't know. I still have doubts about how this game handles PPU IRQs with an unusual BG/SPR bank setting. I'm still investigating it... Sorry.
The "solved" wasn't solved after all.
No problem at all. If I find out anything useful, I'll let you all guys know.
Thanks a lot!