PPU rendering

[Muhammad_R4]

I have some questions about the way PPU render both sprites and background

I knew that for every scanline , the 256 px is feed from the sprite and background buffer ( after being multiplexed on priority ) such that a px come out each PPU clock

here I have two questions :
1 - Does the rendered graphics in both buffers are fetched in the same 341 PPU clock of the same scanline ?
i.e : does the rendered graphics appearing now on scanline M are fetched immediately before rendering or they are fetched at the end of scanline M-1 and rendered on the screen on scanline M ( who comes first rendering now then fetch the next or fetch now and render now )

2 - Does both Image rendering engine and Background rendering engine work in parallel ? or sequentially ?

I hope I explained my questions well.

Thank's in advance

[Myask]

Most of the information you want is here. Here's a (too-)brief summary/interpretation.

Rendering is fetched eight BG pixels at a time, as follows:

1. Nametable fetch
2. Attribute table fetch (which palette)
3. Pattern table fetch, plane 0
4. Pattern table fetch, plane 1

Every cycle, the 8 x-position counters for the sprites are decremented by one. For each sprite, if the counter is still nonzero, nothing else happens. If the counter is zero, the sprite becomes "active", and the respective pair of shift registers for the sprite is shifted once every cycle.

Sprites are checked to see which eight (the first eight found) should appear on the next scanline. This happens concurrently with the BG fetches. This covers this in detail. Note that, as they don't do this on the pre-render scanline, sprites get 1 added to their Y position and can't appear on line 0.

[Muhammad_R4]

Sorry I didn't get it

I know how render stages flow for both BG and sprites, but I am confused how if they are parallel they access the memory both in the same time

also if now I am in scanline 4 , do I in the last steps in 4 fetch graphics for scanline 5 ( next scanline ) then start scanline 5 by rendering
or when I am in scanline 5 I fetch then Render to screen

[Quietust]

They don't access the same memory at the same time - background memory fetches happen during cycles 0-255 and 320-335 (and go into a 4x16 shift register), and sprite memory fetches happen during cycles 256-319 (and go into eight separate 2x8 shift registers).

[Myask]

Sprite OAM (where sprite priority, flip, and positions) is on its own bus, so can happen in parallel with the BG rendering.

Sprite pattern fetches…I had to look it up. It's in this diagram ("sprite tile fetch", each scanline, cycles/dots 257-320)

[Muhammad_R4]

As I understood from you now and from search ( and tell me If I am right or not )

- sprites for scanline 4 was ready in the buffers by the end of scanline 3 and the shift registers out them from clock 0 -> 256 in scanline 4

- sprites memory has its own bus so both background and sprites can be fetched in parallel.

That's OK but there is another confusing matter

I have read here ( page 19 ) ( http://ece545.com/F15/reports/F07_NES.pdf ) that rendering to screen occurs in clocks form 0 -> 256

that is very nice with sprites as they were ready in the buffers from the previous scanline
but what about the backgrounds ?

It will be very nice if the fetched background bytes in scanline 3 will be used in scanline 4

Am I ture ?

[tepples]

With backgrounds, the bytes fetched during scanline 3 are used during scanline 3.

With sprites:
The OAM is scanned for sprites that intersect scanline 3 during scanline 3.
The corresponding pattern bytes are fetched during the horizontal blanking between scanline 3 and scanline 4.
The pattern bytes are used during scanline 4.
This 1-line delay between scanning OAM and actually displaying the sprites is responsible for sprites appearing a line below their actual position.

[lidnariq]

No, background tiles are fetched just in time, approximately 16ish pixels before they're displayed.

[Muhammad_R4]

So that's why it fetches th 1st two tiles of scanline 4 by the end of scanline 3 ?

Will it differ a lot if I implemented it in a shifted way ( ie : rendering on the screen in the last 256 clock , filling the sprite buffers and fetching background data from clk 0 to clk (340-265 ) ?

[Quietust]

Will it differ a lot if I implemented it in a shifted way ( ie : rendering on the screen in the last 256 clock , filling the sprite buffers and fetching background data from clk 0 to clk (340-265 ) ?

Some NES games perform mid-scanline bank switching, so changing the times at which background/sprite tiles are fetched will cause graphical glitches in those games.

[tepples]

Five games I can think of that perform mid-scanline bankswitching are Pirates, Marble Madness, Punch-Out!!, Fire Emblem, and Famicom Wars.

[Quietust]

Five games I can think of that perform mid-scanline bankswitching are Pirates, Marble Madness, Punch-Out!!, Fire Emblem, and Famicom Wars.

The first two, along with Mother (J), are the important ones because their mid-scanline bank switches are cycle-timed - the others (Punch-Out, Fire Emblem, and Famicom Wars, which the MMC2 and MMC4) have their bankswitches triggered by tile fetches, so as long as it happens in the correct order they'll work fine.