Suggestion: Don't enable rendering mid-scanline for the Read 2007 stress test

[alyosha-tas]

I'm currently struggling through this test and the errors I'm getting don't make sense, I think because I'm actually doing something wrong with VRAM address when rendering is enabled midscanline, but currently I'm not sure what.

The test enables rendering part way into scanline 0, the test would be more isolated / testing only read 2007 behavior if it was enabled in vblank.

Also as an aside it looks like there is an error in the logic to shift the results by one, as the compare has no effect here:

	LDA $502
	CMP #$C0                           ; Address $502 is correct, but $504 wasn't, then we were off by one. Just fix that real quick...

Thanks for the continued NES testing.

[100thCoin]

I'm specifically waiting for scanline 0 to enable rendering, otherwise the skipped dot at the end of the pre-render line would interfere and make it more difficult to read from every dot of the scanline for the test.

You are right about that CMP though, I forgot to make it branch away if it doesn't match! That might be contributing to the resulting data being confusing, since it has been shifting the data over unnecessarily.

[alyosha-tas]

In that case it would be helpful to have a 'when does VRAM address increment when rendering is enabled midscanline' test as a per-requisite to this one. I think I have everything else working correctly but I'm reading from the wrong address.

[100thCoin]

I'm currently going through and adding more comments. I found out I was slightly incorrect in the timing of the state machine, so I added some diagrams and tables to explain exactly what's going on.

Is your issue surrounding when v is incremented during the background fetch, or the timing of when v is incremented at the start of HBlank to increment it for the next scanline and "horizontally reset" it?

[alyosha-tas]

I don't know exactly, all I know for sure is that I get the same results in your table except that they are shifted to the right by 6 places, i.e. 6 ppu cycles or 2 cpu cycles. So clearly I am reading the wrong address. I believe I am otherwise following NESDev documentation.

EDIT: I also verified in the trace logs that I properly syncing to the correct spot in the scnaline, matching TricNES except for what value is read.

[100thCoin]

This could just be an issue on when exactly you are updating the PPU Read Buffer. If you are off by 6 ppu cycles, then it sounds like you are updating the ppu read buffer on the same cycle as the CPU reads from $2007? Yesterday I pushed some changes adding a table to show the timing of the state machine: Once the CPU read from $2007 ends, and the ppu clock goes high, it takes 4 more ppu cycles.

It seems to take about 5 to 5 and a half ppu cycles, and perhaps and additional one could be due to clock alignment behavior? That seems to match the 6 ppu cycles that you are off by.

[alyosha-tas]

The thing is simply delaying doesn't work because the later values come from reads where the ppu was turned on at a later time that skipped a 'Inc. hori(v)' (using the terminology of the nesdev rendering diagram: https://www.nesdev.org/wiki/File:Ppu.svg) so they don't represent reading the same values.

So it must be that the trigger for those operations isn't where I think it is, but I currently don't know how to fix it. That's why a separate test for incrementing v timing / conditions midscanline would be a helpful pre-requisite and isolate failure modes.