Feedback wanted on SVG PPU frame timing diagram

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

User avatar
ulfalizer
Posts: 349
Joined: Fri Mar 08, 2013 9:55 pm
Location: Linköping, Sweden

Re: Feedback wanted on SVG PPU frame timing diagram

Post by ulfalizer »

proxy wrote:So I know that there is some curiosity about why you've observed pixel rendering being delayed about 4 dots. I have a theory which may or may not make sense, but here it goes :-).

The pattern of behavior for the PPU is basically the following:

dots: 0-64 = clear S-OAM
dots: 65-256 = fill S-OAM with data for next scanline.

at the same time:

dots 0-256 = render background and sprite pixels for the current scanline.

But, as far as I understand that means that there is a possible conflict if this is done naively. If sprite 0's x position is say 32 pixels into the scanline, that means that its data will be overwritten with $FFs well before it is rendered, making it end up as garbage!

My hypothesis is that the 4 pixel delay for rendering is enough to allow an algorithm (which I have not thought of the specifics yet) to avoid this conflict.

Thoughts?
Like tepples said, the contents of secondary OAM doesn't matter while sprite zero hit detection is taking place. There are eight internal sprite output units (my terminology - can't think of anything clearer :P) that handle the actual sprite drawing - the secondary OAM is just a list of sprites with which to initialize them (during ticks 257-320).

What I suspect is going on is that the first pixel leaves the shifters at h=2. The palette entry for the pixel then needs to be looked up, which takes another two ticks, so that the first pixel is drawn at h=4. (Sprite zero hit detection only needs to know whether the pattern bits are both zero, and so doesn't need the palette lookup.)

Edit: "Sprite drawing units" would be a bit clearer. :P
User avatar
ulfalizer
Posts: 349
Joined: Fri Mar 08, 2013 9:55 pm
Location: Linköping, Sweden

Re: Feedback wanted on SVG PPU frame timing diagram

Post by ulfalizer »

The reloading ticks were off by one. The shifters are actually reloaded at ticks 9,17,25,...,257 and not 8,16,24,...,256.
Attachments
ppu.png
fred
Posts: 67
Joined: Fri Dec 30, 2011 7:15 am
Location: Sweden

Re: Feedback wanted on SVG PPU frame timing diagram

Post by fred »

The background shift registers shift during each of dots 2...257 and 322...337, inclusive.
I'm trying to make sense out of visual 2C02 and was wondering about this. If I understand this correctly, tile_l0 - tile_l15 would be the low BG shift register, and new data gets placed in 8-15.
Now, if i put 0x01 at 0x0000, I can see that it arrives in the shift reg at the dots mentioned in the diagram (9, 17, 25 etc), but isn't the shifting part off? Going from pixel 1 to pixel 2 shifts the register, and going from 257 to 258 does not from what I can tell. If dots, ticks and what the simulation calls "Pixel:" are the same thing (...), isn't this off by one? Shouldn't it be 1-256, 321-336?
User avatar
ulfalizer
Posts: 349
Joined: Fri Mar 08, 2013 9:55 pm
Location: Linköping, Sweden

Re: Feedback wanted on SVG PPU frame timing diagram

Post by ulfalizer »

fred wrote:
The background shift registers shift during each of dots 2...257 and 322...337, inclusive.
I'm trying to make sense out of visual 2C02 and was wondering about this. If I understand this correctly, tile_l0 - tile_l15 would be the low BG shift register, and new data gets placed in 8-15.
Now, if i put 0x01 at 0x0000, I can see that it arrives in the shift reg at the dots mentioned in the diagram (9, 17, 25 etc), but isn't the shifting part off? Going from pixel 1 to pixel 2 shifts the register, and going from 257 to 258 does not from what I can tell. If dots, ticks and what the simulation calls "Pixel:" are the same thing (...), isn't this off by one? Shouldn't it be 1-256, 321-336?
Bit busy with moving at the moment, but I'll leave a quick reply for now without double-checking stuff in Visual 2C02.

When I say that the shift registers shift "during" a particular dot, I mean that the effect of the shift is seen at that dot (in the real thing there'd also be a short transition period at the beginning of the dot before things settle down). Dot 2 is the earliest tick where you see the shift registers shift, and dot 257 is the last tick. If you completely ignore transition delays (like the simulator usually does), I guess it would be most accurate to say that the shift registers shift between dot 1 and dot 2, etc.

Suggestions for how things could be rephrased to be less ambiguous would be welcome. I'm primarily a SW guy, so it's possible that I'm missing some standard terminology.

(Note that the above usage is consistent with things being loaded or cleared "at" a particular dot meaning that they change at that dot, etc. Perhaps it would be clearer to use "at" instead of "during" for the shifts too.)
fred
Posts: 67
Joined: Fri Dec 30, 2011 7:15 am
Location: Sweden

Re: Feedback wanted on SVG PPU frame timing diagram

Post by fred »

Ah, I see how you mean. I didn't think of it that way! But it is true that the effect of the shift is first seen at dot 2. Hmm.
Post Reply