nesdev.com

Cycles 1-64: Secondary OAM (32-byte buffer for current sprites on scanline) is initialized to $FF - attempting to read $2004 will return $FF. Internally, the clear operation is implemented by reading from the OAM and writing into the secondary OAM as usual, only a signal is active that makes the read always return $FF.

When rendering is in progress, reading $2004 returns what in OAM the PPU itself is looking at. And during x=1 through 64, that's secondary OAM.

Internally, the clear operation is implemented by reading from the OAM and writing into the secondary OAM as usual, only a signal is active that makes the read always return $FF.

I really don't get it, please help, what does this mean?

Cycles 65-256: Sprite evaluation
On odd cycles, data is read from (primary) OAM
On even cycles, data is written to secondary OAM (unless secondary OAM is full, in which case it will read the value in secondary OAM instead)
1. Starting at n = 0, read a sprite's Y-coordinate (OAM[n][0], copying it to the next open slot in secondary OAM (unless 8 sprites have been found, in which case the write is ignored).
1a. If Y-coordinate is in range, copy remaining bytes of sprite data (OAM[n][1] thru OAM[n][3]) into secondary OAM.

Does it take 2 cycles reading Y coordinate and THEN copying it in SECONDARY OAM?
So, if it's IN RANGE does it take 6 CYCLES more to copy remaining data?

And when rendering is disabled, reading $2004 returns OAM[spriteaddr]. Is this correct?

Starting at m = 0, evaluate OAM[n][m] as a Y-coordinate.
3a. If the value is in range, set the sprite overflow flag in $2002 and read the next 3 entries of OAM (incrementing 'm' after each byte and incrementing 'n' when 'm' overflows); if m = 3, increment n
3b. If the value is not in range, increment n and m (without carry). If n overflows to 0, go to 4; otherwise go to 3
The m increment is a hardware bug - if only n was incremented, the overflow flag would be set whenever more than 8 sprites were present on the same scanline, as expected.