My emulator experiences a disappearing scanline in Mickey's Safari in Letterland during vertical scrolling.
This game is paired with G.I. Joe on the list of
tricky-to-emulate games. But, my emulator is able to run G.I. Joe without issues.
I know this is an MC-ACC MMC3 game. And, it's coded up accordingly.
Does anyone have any recommendations to handle this one? What should I be looking for in a log?
The game sets PPU $2000 to use pattern table #0 for both sprites and background tiles. So, the IRQs are clocked on sprite fetches after PPU cycle 256, when a sprite tile is fetched from PPU $1000. Well, it's supposed to clock just once per line. The shaking is because the time between PPU $1000 risings isn't big enough. Currently, Mickey in Letterland has a glitched scanline (in my emulator) when you scroll up, but the score is perfect. Mickey in Numberland runs here with no problems though.
It's also not even a MMC3. It's the Acclaim version that clocks on falling edges instead of rising edges.
Zepper wrote:
The game sets PPU $2000 to use pattern table #0 for both sprites and background tiles. So, the IRQs are clocked on sprite fetches after PPU cycle 256, when a sprite tile is fetched from PPU $1000. Well, it's supposed to clock just once per line. The shaking is because the time between PPU $1000 risings isn't big enough. Currently, Mickey in Letterland has a glitched scanline (in my emulator) when you scroll up, but the score is perfect. Mickey in Numberland runs here with no problems though.
I think that solved the issue. I extended the IRQ reset delay for MC-ACC games. That fixed the disappearing scanline in the status bar. All the other MC-ACC games still appear to work fine (e.g. The Incredible Crash Dummies title screen does not shake). And, the MMC3 test ROMs still work with the increased reset delay time; though, it will only apply it for MC-ACC games. This is likely a hack. But, it does the job for the games that need it without breaking test ROMs.
Dwedit wrote:
It's also not even a MMC3. It's the Acclaim version that clocks on falling edges instead of rising edges.
The increased IRQ reset delay is being used with the MC-ACC falling edge detection. I suspect that the emulator is just timing the reset incorrectly for falling edge. I'll investigate further.
Dwedit wrote:
It's also not even a MMC3. It's the Acclaim version that clocks on falling edges instead of rising edges.
Is this info available on the wiki? What's written about the pattern table setting and sprite fetching is still valid and true.
Zepper wrote:
Dwedit wrote:
It's also not even a MMC3. It's the Acclaim version that clocks on falling edges instead of rising edges.
Is this info available on the wiki? What's written about the pattern table setting and sprite fetching is still valid and true.
See the bottom of
this section.
The wiki refers to
this thread.
The Nestopia Cart DB covers the list of MC-ACC games.
Sorry, I just split IRQ Specifics into its own section (off of §Hardware) to make it more obvious
Still unclear. This game sets $2000 to use pattern and sprites from PPU low pattern table ($0000), so sprites fetched from PPU $1000 is the way to detect rising edges. What about falling edges? Could someone describe how to do the things?
The practical difference between MC-ACC and MMC3C is only that MC-ACC triggers an IRQ 4 pixels later, which is 1 or 2 CPU cycles later depending on complex things.
Zepper wrote:
Still unclear. This game sets $2000 to use pattern and sprites from PPU low pattern table ($0000), so sprites fetched from PPU $1000 is the way to detect rising edges. What about falling edges? Could someone describe how to do the things?
MMC3 normally triggers an IRQ when address bit A12 transitions from 0 to 1. MC-ACC normally triggers an IRQ when address bit A12 transitions from 1 to 0.
I am having this issue in my emulator as well, and as noted when I change the IRQ to trigger on falling edges, it fixes the shaking.
I have managed this far without having to check rom hashes against a database, but this issues raises the question: is there a heuristic to determine that the MC-ACC A12 behavior should be used, as opposed to the normal rising edge MMC3 behavior?
Well, if what I wrote is correct... and must be A12 1->0, then... What's the inner working of it? Sprites are fetched from PPU cycle 257, from pattern table $1000. So, technically, A12 is 1 during cycles 257~319, and 0 when out of this interval. So, the first clock should occur at cycle 320..?
257-260: Dummy nametable fetch. A12 is low
261-264: Sprite pattern fetch (1 of 8). A12 is high
265-268: Dummy nametable fetch. A12 is low
269-272: Sprite pattern fetch (2 of 8). A12 is high
273-276: Dummy nametable fetch. A12 is low
277-280: Sprite pattern fetch (3 of 8). A12 is high
281-284: Dummy nametable fetch. A12 is low
285-288: Sprite pattern fetch (4 of 8). A12 is high
289-292: Dummy nametable fetch. A12 is low
293-296: Sprite pattern fetch (5 of 8). A12 is high
297-300: Dummy nametable fetch. A12 is low
301-304: Sprite pattern fetch (6 of 8). A12 is high
305-308: Dummy nametable fetch. A12 is low
309-312: Sprite pattern fetch (7 of 8). A12 is high
313-316: Dummy nametable fetch. A12 is low
317-320: Sprite pattern fetch (8 of 8). A12 is high
No way to identify the Acclaim MMC3 other than ROM hash, or specifying NES 2.0 submapper #4. I guarantee you that you won't see any roms marked with the correct NES 2.0 submapper in the wild.
tepples wrote:
257-260: Dummy nametable fetch. A12 is low
261-264: Sprite pattern fetch (1 of 8). A12 is high
265-268: Dummy nametable fetch. A12 is low
269-272: Sprite pattern fetch (2 of 8). A12 is high
273-276: Dummy nametable fetch. A12 is low
277-280: Sprite pattern fetch (3 of 8). A12 is high
281-284: Dummy nametable fetch. A12 is low
285-288: Sprite pattern fetch (4 of 8). A12 is high
289-292: Dummy nametable fetch. A12 is low
293-296: Sprite pattern fetch (5 of 8). A12 is high
297-300: Dummy nametable fetch. A12 is low
301-304: Sprite pattern fetch (6 of 8). A12 is high
305-308: Dummy nametable fetch. A12 is low
309-312: Sprite pattern fetch (7 of 8). A12 is high
313-316: Dummy nametable fetch. A12 is low
317-320: Sprite pattern fetch (8 of 8). A12 is high
My notes are a bit different... but from the wiki anyways.
Code:
/* Cycles 257-320: Sprite fetches (8 sprites total, 8 cycles per sprite)
* 0-3: Read the Y-coordinate(0), tile number(1), attributes(2), and X-coordinate(3)
of the selected sprite from secondary OAM.
* 4-7: Read the X-coordinate of the selected sprite from secondary OAM 4 times
(while the PPU fetches the sprite tile data).
* For the first empty sprite slot, this will consist of sprite #63's Y-coordinate followed by 3 $FF bytes;
for subsequent empty sprite slots, this will be four $FF bytes.
*/
Is this incorrect?
Those are equivalent. Just that your notes for 0-3 are leaving out the dummy nametable fetch, but are including the sprite fetch.
Zepper wrote:
tepples wrote:
257-260: Dummy nametable fetch. A12 is low
261-264: Sprite pattern fetch (1 of 8). A12 is high
265-268: Dummy nametable fetch. A12 is low
269-272: Sprite pattern fetch (2 of 8). A12 is high
My notes are a bit different... but from the wiki anyways.
Code:
/* Cycles 257-320: Sprite fetches (8 sprites total, 8 cycles per sprite)
* 0-3: Read the Y-coordinate(0), tile number(1), attributes(2), and X-coordinate(3)
of the selected sprite from secondary OAM.
* 4-7: Read the X-coordinate of the selected sprite from secondary OAM 4 times
(while the PPU fetches the sprite tile data).
* For the first empty sprite slot, this will consist of sprite #63's Y-coordinate followed by 3 $FF bytes;
for subsequent empty sprite slots, this will be four $FF bytes.
*/
Is this incorrect?
I was describing the activity on the PPU's external video memory bus. You're describing the activity on the internal OAM bus. Both appear correct to me.