... at least this is what vbl_timing/frame_basics tells me.
When measuring the PPU clocks between consecutive calls to blarggs 'delay_119121' sub routine I'm always 200/201 cycles short ... and so the test fails.
See here:
'S' is the scanline (0 is idle before, 241 is idle after, 242 is vblank start), C is pixel clock (0 == start of active pixel area).
$e118 is begin_and_wait where it waits for vsync and then calls the delay routines ($e111)
When measuring the frame length in PPU clocks I get exactly 89342 and 89341 clocks.
Anybody got a clue why there are 200 clocks missing?
Is there something 'suspending' the PPU going on in the real NES?
Instruction and instr_timing is all testing as Ok.
Edit: It's only 50 PPU clocks per frame as the delay waits for 4 frames.
When measuring the PPU clocks between consecutive calls to blarggs 'delay_119121' sub routine I'm always 200/201 cycles short ... and so the test fails.
See here:
Code:
S242 C 65 E187 20 : 08 00 00 FF 00100001 JSR $e118
S242 C 19 E11D 20 : 08 00 00 FD 10100001 JSR $e111
S242 C220 E120 20 : ED 00 00 FD 00100011 JSR $e111
S243 C 80 E123 20 : ED 00 00 FD 00100011 JSR $e111
S242 C 19 E11D 20 : 08 00 00 FD 10100001 JSR $e111
S242 C220 E120 20 : ED 00 00 FD 00100011 JSR $e111
S243 C 80 E123 20 : ED 00 00 FD 00100011 JSR $e111
'S' is the scanline (0 is idle before, 241 is idle after, 242 is vblank start), C is pixel clock (0 == start of active pixel area).
$e118 is begin_and_wait where it waits for vsync and then calls the delay routines ($e111)
When measuring the frame length in PPU clocks I get exactly 89342 and 89341 clocks.
Anybody got a clue why there are 200 clocks missing?
Is there something 'suspending' the PPU going on in the real NES?
Instruction and instr_timing is all testing as Ok.
Edit: It's only 50 PPU clocks per frame as the delay waits for 4 frames.