Nestopia and Ninja Gaiden/Burai Fighter

[Zepper]

This is not the right way to fix it. You will break other games.

Obviously. Well, I don't know what's wrong with Burai Fighter, and that was the only "hint" I could get for the problem.

[James]

MMC3 IRQ counter should not be clocked by accesses >$2FFF. Filter those in your mapper or ppu code and burai fighter should work correctly.

[Zepper]

I already did without success.

[*Spitfire_NES*]

Ninja Gaiden .....
FetchAttribute?

yes but how to fix is very hard to pinpoint.

@James

Interesting, i never knew about that. After checking im sure nestopia is doing that too. So it seems like this is potential solution or problem. lol. Is there no way to add an exception for this without breaking the other games? Obviously i want to do this the right way if i can and im sure the same for zepper too.

I just find it amusing both emus have the same issue. zxbdragon id like to add the source change you tried to fix burai fighter if you dont mind posting it just to see what breaks other games. As for ninja gaiden i dont know how to track the ppu bug in the table.

[zxbdragon]

Ninja Gaiden .....
FetchAttribute?

yes but how to fix is very hard to pinpoint.

@James

Interesting, i never knew about that. After checking im sure nestopia is doing that too. So it seems like this is potential solution or problem. lol. Is there no way to add an exception for this without breaking the other games? Obviously i want to do this the right way if i can and im sure the same for zepper too.

I just find it amusing both emus have the same issue. zxbdragon id like to add the source change you tried to fix burai fighter if you dont mind posting it just to see what breaks other games. As for ninja gaiden i dont know how to track the ppu bug in the table.

Both BUG, I have not corrected the problem only preliminary know , they did not know where the solutions in nestiopia!

[Zepper]

MMC3 IRQ counter should not be clocked by accesses >$2FFF. Filter those in your mapper or ppu code and burai fighter should work correctly.

This fix on PPU $2006 second write makes Mickey in Letterland to work correctly, its scorebar has the correct position now. Even puNES has a bad scorebar for that game.
About Burai Fighter, I have no clue - I already did what you said, but nothing happened. The IRQ is clocked like blargg explains in his test ROMs - during the HBlank on cycles 260,268... when BG is at $0000 and sprites at $1000 (standard). Any other setting I put on IRQs to try a fix for Burai Fighter messes up the game.

[*Spitfire_NES*]

MMC3 IRQ counter should not be clocked by accesses >$2FFF. Filter those in your mapper or ppu code and burai fighter should work correctly.

This fix on PPU $2006 second write makes Mickey in Letterland to work correctly, its scorebar has the correct position now. Even puNES has a bad scorebar for that game.
About Burai Fighter, I have no clue - I already did what you said, but nothing happened. The IRQ is clocked like blargg explains in his test ROMs - during the HBlank on cycles 260,268... when BG is at $0000 and sprites at $1000 (standard). Any other setting I put on IRQs to try a fix for Burai Fighter messes up the game.

hey james, with this being said, is there something else the both of us could be missing here you think? Seems like it would and should work. Very odd to say the least...

[James]

You're going to have to get your hands dirty. Run it in a debugger and break on any PPU accesses >= 0x3000 then trace it out from there.

[Zepper]

Let me recap the IRQ thing (assuming the standard PPU setup):

- the standard setup is background tiles at PPU $0000 and sprites at PPU $1000;
- this makes A12 rising during the HBlank at every 8 cycles, starting at 260th;
- according to the test ROMs, A12 should rise at PPU dot 260.

Also, the IRQ counter is clocked when $2006/2007 is accessed.

Well, my emu uses a different gfx engine - that's might be the problem, but I dunno.

[James]

You should use the following logic: clock the IRQ counter when A12 transitions from low to high after being low for a sufficient period of time (I use 5 CPU cycles). This will generally happen at PPU cycle 260, but it's easier to deal with the edge cases by simplifying the conditions for clocking the counter.

This means, of course, that you need to make sure that you're accessing PPU memory at all of the right times: PPU fetches during rendering (especially sprite fetches starting at cycle 260) and accesses via $2006/$2007.

[Zepper]

Blocking the IRQ if the PPU address is >= 0x3000 breaks all the games here in my emu.

[tepples]

Perhaps the MMC3 can see accesses to $3000-$3EFF (mirror of nametables) but not $3F00 through $3FFF (palette, in internal CGRAM)

[perilsensitive]

I've been lurking on this thread a while due to having these same issues in my emulator. I've resolved the glitch in Burai Fighter (using a completely different fix than the one described previously) and Ninja Gaiden, but I'm still having trouble with Safari in Letterland and Goal! Two, which also has a shaky status bar that seems to be dependant on the last fine vertical scroll value when vblank starts.

Perhaps the MMC3 can see accesses to $3000-$3EFF (mirror of nametables) but not $3F00 through $3FFF (palette, in internal CGRAM)

I tested this in Visual 2C02, and it puts bits 0-13 of loopy_v (or vramaddr_v as Visual 2C02 calls it) on the address bus for any read or write via $2007 when not rendering no matter what the value of loopy_v is (while rendering the bus is controlled by the rendering logic, and therefore not directly affected by the change to loopy_v). This also happens when setting loopy_v via $2006 (again, only when not rendering), when rendering is disabled via $2001, and after rendering ends (cycle 0 of scanline 240). If this reflects the PPU's actual behavior, then palette accesses can clock the IRQ counter.

I had to fix my code so that $2006 and $2007 only touched the address bus when the PPU wasn't rendering (Nestopia doesn't do this correctly either). I also had to change the behavior of $2007 accesses while rendering so that the horizontal and vertical scroll were both always incremented (Nestopia UE increments one or the other based on bit 2 of $2000). ulfalizer traced Visual 2C02 and figured out why this happens here and documented it in the wiki.

I've modified Nestopia UE to address the above issues and Burai Fighter works correctly. You can see the diff of my changes in my github fork.

The glitch in Ninja Gaiden's intro is caused by extra $2007 reads due to DPCM DMA. I had this exact same glitch in my emulator, and disabling the extra reads for $2007 "fixed" it. I got the same results in Nestopia with a similar change to Apu::Dmc::DoDMA() in NstApu.cpp. I haven't dug any further into this one yet.

[zxbdragon]

I've been lurking on this thread a while due to having these same issues in my emulator. I've resolved the glitch in Burai Fighter (using a completely different fix than the one described previously) and Ninja Gaiden, but I'm still having trouble with Safari in Letterland and Goal! Two, which also has a shaky status bar that seems to be dependant on the last fine vertical scroll value when vblank starts.

Perhaps the MMC3 can see accesses to $3000-$3EFF (mirror of nametables) but not $3F00 through $3FFF (palette, in internal CGRAM)

I tested this in Visual 2C02, and it puts bits 0-13 of loopy_v (or vramaddr_v as Visual 2C02 calls it) on the address bus for any read or write via $2007 when not rendering no matter what the value of loopy_v is (while rendering the bus is controlled by the rendering logic, and therefore not directly affected by the change to loopy_v). This also happens when setting loopy_v via $2006 (again, only when not rendering), when rendering is disabled via $2001, and after rendering ends (cycle 0 of scanline 240). If this reflects the PPU's actual behavior, then palette accesses can clock the IRQ counter.

I had to fix my code so that $2006 and $2007 only touched the address bus when the PPU wasn't rendering (Nestopia doesn't do this correctly either). I also had to change the behavior of $2007 accesses while rendering so that the horizontal and vertical scroll were both always incremented (Nestopia UE increments one or the other based on bit 2 of $2000). ulfalizer traced Visual 2C02 and figured out why this happens here and documented it in the wiki.

I've modified Nestopia UE to address the above issues and Burai Fighter works correctly. You can see the diff of my changes in my github fork.

The glitch in Ninja Gaiden's intro is caused by extra $2007 reads due to DPCM DMA. I had this exact same glitch in my emulator, and disabling the extra reads for $2007 "fixed" it. I got the same results in Nestopia with a similar change to Apu::Dmc::DoDMA() in NstApu.cpp. I haven't dug any further into this one yet.

Great , so you are nestopia

[perilsensitive]

Great , so you are nestopia

rdanbrook maintains Nestopia UE, not me. I do use it on occasion however, so I created a github fork for sharing any fixes to bugs I might find. I don't do any real development on it. The main repository is at https://github.com/rdanbrook/nestopia. My own emulator is currently unnamed and unreleased, although I expect that to change Real Soon Now.