Hi all,
I am trying to pass the NMI_Sync test, but the middle line is 2 pixels too short. At this point I can pass every other blargg test out there, so there really isn't anything in the NMI / VBL timing I can change to try to make this test work.
I came across http://wiki.nesdev.com/w/index.php/PPU_rendering and specifically this: Actual pixel output is delayed further due to internal render pipelining, and the first pixel is output during cycle 4.
I can't find any more details about the rendering pipeline though. If I delay the EMU's pixel output by 2 ppu clocks and do the $2001 greyscale check that the test is doing there, then the test passes as expected, but I'm not sure if this is a correct implementation.
So, is there any documentation about where different checks are made in the rendering pipeline? Does anyone know if my implementation is accurate?
Thanks!
I am trying to pass the NMI_Sync test, but the middle line is 2 pixels too short. At this point I can pass every other blargg test out there, so there really isn't anything in the NMI / VBL timing I can change to try to make this test work.
I came across http://wiki.nesdev.com/w/index.php/PPU_rendering and specifically this: Actual pixel output is delayed further due to internal render pipelining, and the first pixel is output during cycle 4.
I can't find any more details about the rendering pipeline though. If I delay the EMU's pixel output by 2 ppu clocks and do the $2001 greyscale check that the test is doing there, then the test passes as expected, but I'm not sure if this is a correct implementation.
So, is there any documentation about where different checks are made in the rendering pipeline? Does anyone know if my implementation is accurate?
Thanks!