Feedback wanted on SVG PPU frame timing diagram

[beannaich]

Here's an updated version that points out that the last tile fetch is unused and adds a note about fine x.

The part about the shift registers is wrong. Fine X indexes into the upper 8-bits, inversely (15-fine x). They shift left, every 8 dots the lower 8-bits are reloaded with the fetched data.

[ulfalizer]

Here's an updated version that points out that the last tile fetch is unused and adds a note about fine x.

The part about the shift registers is wrong. Fine X indexes into the upper 8-bits, inversely (15-fine x). They shift left, every 8 dots the lower 8-bits are reloaded with the fetched data.

See the edit I made just before you posted that.

Edit: Or slightly after I guess.

[beannaich]

See the edit I made just before you posted that.

Edit: Or slightly after I guess.

Well played There may be some new info on OAM today, I wrote a test for it, just need someone with a TV with overscan and a powerpak to test it for me.

[ulfalizer]

If I wanted to link the diagram from the wiki, would it be best to just link directly to the forum, or is there some possibly more permanent place I could put it? (Don't have any 24/7 servers myself. :/)

[tepples]

In that case, it'd be best to upload the diagram to the wiki. I've added the "trusted" group to your account, so you don't need to wait to become autoconfirmed. MediaWiki is supposed to support rendering SVGs to PNG at display time, as it does on Wikimedia Commons and WIkipedia. But MediaWiki relies on external programs for this rendering, and those might not be correctly configured on the server. I'd recommend uploading the SVG and the PNG, and then if you get an error about running "convert" after uploading the SVG, report it in the wiki section of the BBS.

[ulfalizer]

Linked it from a few different relevant spots on the wiki. I know some browsers still don't scroll nicely through large SVG files, so I made the PNG the primary link.

[beannaich]

Linked it from a few different relevant spots on the wiki. I know some browsers still don't scroll nicely through large SVG files, so I made the PNG the primary link.

On the rendering section it says dot 0 outputs the first pixel of the scanline. Is that right? Wouldn't that cause a missing column of color at pixel 16?

Code: Select all

clock 340: 1111 1111 1111 1111
clock   0: 1111 1111 1111 1110
...
clock   7: 1111 1111 0000 0000
clock   8: 1111 1110 1111 1111
                   ^
missing pixel -----+

Or is there some race condition i'm unaware of?

[ulfalizer]

Linked it from a few different relevant spots on the wiki. I know some browsers still don't scroll nicely through large SVG files, so I made the PNG the primary link.

On the rendering section it says dot 0 outputs the first pixel of the scanline. Is that right? Wouldn't that cause a missing column of color at pixel 16?

Code: Select all

clock 340: 1111 1111 1111 1111
clock   0: 1111 1111 1111 1110
...
clock   7: 1111 1111 0000 0000
clock   8: 1111 1110 1111 1111
                   ^
missing pixel -----+

Or is there some race condition i'm unaware of?

I assumed it worked that way from some previous discussion in #nesdev but haven't actually checked in Visual 2C02. Tick 8 would have to both reload the lower shift reg and then shift it once into the upper one if the first pixel is output at dot 0 it seems, which does sound a bit weird.

[ulfalizer]

If the first pixel is output at dot 1, then maybe the updated timing is identical to the old one, only we've renamed dots according to the internal PPU counters.

[beannaich]

Did some initial poking around in visual2C02, what I saw was ... strange.

tile_l appeared as $00ff during pre-render, and ROR'd starting at dot 76, ROR'ing one bit at a time until it's value was $f807. The next clock was not $fc03 as you'd expect, it was instead $ff03. tile_h appears to follow a similar pattern, but delayed by about 6 dots.

The condensed version of this behavior (intermediate cycles removed, each line represents a single dot) is:

Code: Select all

h   v   t_l  t_h
04b 105 00ff ffff
04c 105 807f ffff
04d 105 c03f ffff
04e 105 e01f ffff
04f 105 f00f ffff
050 105 f807 ffff
051 105 ff03 00ff
052 105 ff81 807f
053 105 ffc0 c03f
054 105 ffe0 e01f
055 105 fff0 f00f
056 105 fff8 f807
057 105 fffc fc03
058 105 fffe fe01

EDIT: Both high and low tiles fetches were $ff from the chr-rom area.

EDIT: After more poking around, I got a single tuple access pattern, I was correct about it not being clocked at dot 0. I was however wrong about them being left shift.

Code: Select all

h   v   t_l  t_h  t_buf
000 000 aaaa aaaa aa
001 000 aaaa aaaa aa
002 000 d555 5555 aa
003 000 eaaa 2aaa aa
004 000 f555 1555 aa
005 000 faaa 0aaa aa
006 000 fd55 0555 aa
007 000 feaa 02aa aa
008 000 ff55 0155 aa
009 000 aaaa aaaa aa

Note about the above, t_h is inverted, so I un-inverted it for clarity. Clocks begin at the beginning on dot 2, with data being clocked in on dot 9.

[ulfalizer]

Figured out what's going on with the right-shifting. Turns out the pattern stored in tile_l is both reversed and bit-flipped, so that e.g. $01 turns into $7F. $AA was an unlucky choice of test data, as that turns into $AA.

Here's some related Visual 2C02 "bug reports":

- "// lower pattern bit shift register, NOT inverted!" in nodenames.js should probably say something like "// lower pattern bit shift register, reversed and inverted ($01 -> $7F)". Haven't checked what holds for tile_h yet, but it might be wrong too.

- If you watch just tile_l1, it ends up with non-0/1 values like 3E and 3F. That's probably a bug. The other bits always get 0/1 at least.

Edit: tile_h seems to be reversed but *not* inverted. Maybe the nodes could be renamed to turn the shift registers into left-shift instead.

[ulfalizer]

Some quick question:

Do changes in pixel_color correspond immediately to changes in what's currently being drawn? The waveform graph seems to lag a bit behind it, but maybe that's just due to the way its drawn.

Does pixel_color include sprites? If so, the "BG pixel color, sent to EXT pins" comment seems a bit misleading.

[beannaich]

Starting a miniature documentation on sprites. So far:

Dot 1-64 with rendering enabled: reading $2004 gives $FF.
Dot 65 with rendering enabled: start of evaluation as previously observed.
Dot 65-256 with rendering enabled: reading $2004 gives the currently fetched byte from OAM, that is, the byte being used by OAM evaluation.
Dot 257 with rendering enabled: $2003 is reset to 0.

Unanswered questions: Is $2003 driven to 0 after dot 257? If not, is it possible to write $2003 after 257 and what is the effect of this on OAM evaluation? What happens when enabling rendering at random points during a scanline (Particularly, dots 1-64)?

[ulfalizer]

I'm pretty sure the first pixel is output during dot 2 now. Putting $FF in $0000 and $0001 (second one needed to get a sprite zero hit during scanline 1) and disabling the $2003/$2004 writes so you get an all-0 OAM entry for sprite 0 you can see the following:

- the tile_l/h shift registers are shifted at dot 2
- pixel_color changes at dot 2
- the sprite 0 flag goes high during dot 2 (of scanline 1)

I tried using $7F, $7F and $3F, $3F for the pattern as well, and the sprite 0 flag gets set during dot 3 and dot 4 like you'd expect. The sprite 0 flag seems to go high during the second half of the PPU tick btw...

For future reference, here's some interesting signals to trace: spr0_hit, tile_l/h, pixel_color, vid_

[ulfalizer]

OK, this is how it seems to work (though I don't know why):

Sprite zero hits take effect as if the image starts drawing at h=2 (the third PPU tick on the scanline). The actual pixel/dot corresponding to that point is output two PPU ticks later though, at h=4 (and the last pixel is correspondingly output at h=260).

Any idea why the PPU delays the pixels like that?