nesdev.org

FWIW Nintendulator seems to faithfully reproduce that problem at the start of Scene 4 (N.Y.) in PAL mode, but FCEUX does not.

in a responce to Thefox: Here's a second clip i recorded.

Very similar results to Scene 4
https://www.youtube.com/watch?v=YcZNzuz ... e=youtu.be

Thanks. That's quite interesting. Were you using an original cartridge, or a flash cart?

i was using an Everdrive N8 with a perfectly functional NES. Aside from TMNT 3 (U) Gradius II (JP) and a handful of NTSC games that suffer from similar problems, it works perfectly with any European ROM i throw at it. The hardware i'm using is out of the question. Judging from other responses i think it's an issue with the PAL video standard.

So for Gradius II: How do i change the setup for the VRC IRQ?

Tepples, you said the TMNT games may use cycle counting for the status bar (TMNT 1 uses sprite 0 hits). I read up on Vblank timing so i have a slightly better understanding of how raster effects work but where is cycle counting stored?

VRC mappers always count cycles, not scanlines, though they count cycles in units scaled to an NTSC scanline.

The following is all speculation, seeing as I haven't dumped and disassembled any TMNT game.

If the programmers don't know how to set up multiple IRQs in one frame, it may use MMC3 PIT for the first split and sprite 0 for the second or vice versa. Or if they didn't know the $2006-$2005-$2005-$2006 trick yet, it may use MMC3 PIT to find when to turn off the background for 8 lines, then use timed code to wait for when to write the address of a row of tiles to $2006, then use timed code for when to turn rendering back on.

TR3KT wrote:i was using an Everdrive N8 with a perfectly functional NES. Aside from TMNT 3 (U) Gradius II (JP) and a handful of NTSC games that suffer from similar problems, it works perfectly with any European ROM i throw at it. The hardware i'm using is out of the question.

The hardware could cause problems like that even if it seems to be working otherwise fine, because small issues in the mapper implementation (e.g. IRQ timing) could lead to bigger problems depending on how tolerant the game is for that kind of a thing.

I don't think that's the case here though. I tried the game on my PAL NES with PowerPak and was able to reproduce the same glitches (including the Manhattan rising glitch in the intro). Sorry for polluting the thread.

That's fine. i really should've included footage when starting this thread.

Hi Tepples,

I ran a couple of my own tests last night on my NES: Starting with TMNT 2: The Manhattan Project (JPN). I was surprised it could boot! The glitches were much worse than Gradius II (I guess because they both work on VRC 4.)

I also tried TMNT: Tournament Fighters (U) and when i booted a fight scene the bottom status bar (and maybe the top one too, i couldn't tell) were acting exactly the same way as the Vertical effect scenes in TMNT 3 (U). I can possibly confirm they share the same status bar system. Konami fixed this issue when releasing TMHT: Tournament Fighters (E). Could i possibly reverse engineer both versions of Tournament Fighters to see what Konami did to fix the status bar? and then replicate the system on TMNT 3 (U) (They both use the same mapper)