It is currently Sun Oct 22, 2017 1:27 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 58 posts ]  Go to page Previous  1, 2, 3, 4  Next
Author Message
PostPosted: Wed Feb 17, 2016 2:11 pm 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
On that graphic, cycles [1..256] are the ones that render pixels. Cycle 0 and cycles 257+ do not. So in your example if you start at cycle 0 scanline 0 and do a NOP, only 5 pixels will be rendered.


EDIT:
I always thought it was easier to use the other numbering system (where pixels start at cycle 0), before it switched to the 2C02 numbering system. If you want to do that, simply shift that entire chart over to the left one space. You'll find that when you do that, more things align with 0, and with multiples of 8... which generally makes them easier to deal with.


Top
 Profile  
 
PostPosted: Thu Feb 18, 2016 12:50 am 
Offline
User avatar

Joined: Sun Mar 19, 2006 3:06 am
Posts: 583
Location: Gothenburg/Sweden
Ok, so the "skipped on bg-odd" and "idle" boxes counts as an entire PPU cycle in the chart then?

_________________
http://nes.goondocks.se/


Top
 Profile  
 
PostPosted: Thu Feb 18, 2016 10:16 am 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
Yes. Every square box is a PPU cycle. 341 per scanline * 262 scanlines


Top
 Profile  
 
PostPosted: Thu Feb 18, 2016 12:37 pm 
Offline
User avatar

Joined: Sun Mar 19, 2006 3:06 am
Posts: 583
Location: Gothenburg/Sweden
The terminology confuses me here.
You mentioned one "box" is one PPU cycle but as mentioned elsewhere "One CPU cycle = Three PPU cycles", it should be like 24 PPU Cycles then to be correct?
The diagram groups the PPU cycles and calls them "VRAM fetch".
Is "One CPU cycle = 3 VRAM fetch" (group of 8 PPU cycles) more correct? However that sounds a bit strange. :)

EDIT: I've tried designing some primitive psuedocode on paper for a pixel-renderer (Yes I like psuedocode, Disch knows what I mean :)), but things tends to get very compact and very difficult to grasp. I try to break it down in very small steps but it's still not entirely trivial..
However I must admit a pixelrenderer probably solves alot of other problems compared to a scanline-version (and I don't only mean advanced raster-effects), so a pixel-version is probably the way to go in the end.

_________________
http://nes.goondocks.se/


Top
 Profile  
 
PostPosted: Thu Feb 18, 2016 6:51 pm 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
Quote:
You mentioned one "box" is one PPU cycle but as mentioned elsewhere "One CPU cycle = Three PPU cycles", it should be like 24 PPU Cycles then to be correct?


On this diagram: http://wiki.nesdev.com/w/images/d/d1/Ntsc_timing.png

One square box = 1 PPU cycle.

On NTSC, 1 CPU cycle = 3 PPU cycles. So 1 CPU cycle would take 3 boxes worth of time. The PPU runs 3x as fast, so there are 3 PPU cycles to every 1 CPU cycle.

I don't know where you got "24 PPU Cycles" from, but no.

Quote:
The diagram groups the PPU cycles and calls them "VRAM fetch".



A VRAM fetch takes 2 PPU cycles, hence why 2 boxes are grouped together.

According to Brad Taylor's original 2C02 doc ( http://nesdev.com/2C02%20technical%20reference.TXT ), the reason it takes 2 cycles is because it updates the address lines on the 1st cycle, then actually performs the read and moves the data off the bus on the 2nd cycle:

Quote:
At the beginning of the access cycle, PPU address lines 8..13 are updated
with the target address. This data remains here until the next time an
access cycle occurs.

The lower 8-bits of the PPU address lines are multiplexed with the data bus,
to reduce the PPU's pin count. On the first clock cycle of the access,
A0..A7 are put on the PPU's data bus, and the ALE (address latch enable)
line is activated for the first half of the cycle. This loads the lower
8-bit address into an external 8-bit transparent latch strobed by ALE
(74LS373 is used).

On the second clock cycle, the /RD (or /WR) line is activated, and stays
active for the entire cycle. Appropriate data is driven onto the bus during
this time.




Quote:
Is "One CPU cycle = 3 VRAM fetch" (group of 8 PPU cycles) more correct? However that sounds a bit strange.


No.

1 CPU cycle = 3 PPU cycles
1 VRAM fetch = 2 PPU cycles


Top
 Profile  
 
PostPosted: Thu Feb 18, 2016 7:31 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19115
Location: NE Indiana, USA (NTSC)
Also:
1 PPU cycle = 4 master clocks (NTSC, RGB) or 5 master clocks (PAL NES, Dendy)
1 background column fetch = 8 PPU cycles (1-8, 9-16, 25-32, ...)
1 sprite pattern fetch = 8 PPU cycles (257-264, 265-272, ..., 313-320)

Jailbars, on Control Decks that suffer from them, align with the 8-dot fetch pattern.

EDIT: dot numbers might help others understand


Top
 Profile  
 
PostPosted: Thu Feb 18, 2016 7:36 pm 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
Wait what? That's even confusing me and I know how all this works =P

How do you figure 8 cycles for a "column fetch", and what even is a column fetch?


EDIT:

Oh wait I think I get what you're saying. Nevermind.


Top
 Profile  
 
PostPosted: Thu Feb 18, 2016 11:35 pm 
Offline
User avatar

Joined: Sun Mar 19, 2006 3:06 am
Posts: 583
Location: Gothenburg/Sweden
Quote:
On that graphic, cycles [1..256] are the ones that render pixels. Cycle 0 and cycles 257+ do not. So in your example if you start at cycle 0 scanline 0 and do a NOP, only 5 pixels will be rendered.

Disch, the above must be wrong then?
1 CPU Cycle = 3 PPU cycles (NOP = 6 PPU cycles)
Since pixels are usually rendered every 8:th PPU cycle, there can't be 5 rendered pixels on 2 CPU cycles?

NOP (2 CPU cycles) = 6 PPU Cycles, there's a chance there's not even a single pixel rendered here?

Check my attachment:
Red checkmarks = 1 PPU cycle
Green circles = 1 CPU cycle
Am I getting it right this time? :)


Attachments:
PPUstuff.png
PPUstuff.png [ 27.97 KiB | Viewed 758 times ]

_________________
http://nes.goondocks.se/
Top
 Profile  
 
PostPosted: Thu Feb 18, 2016 11:46 pm 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
Quote:
Disch, the above must be wrong then?


Nope... what I said before looks right.

Quote:
1 CPU Cycle = 3 PPU cycles (NOP = 6 PPU cycles)


NOP = 6 PPU cycles. That is correct. But there are 341 PPU cycles per scanline, and only 256 of those cycles render pixels. So some cycles will not render pixels.

If you start at cycle 0 and run for 6 cycles, you will only render 5 pixels, because cycle 0 does not render a pixel, but cycles 1-5 do.

Quote:
Since pixels are usually rendered every 8:th PPU cycle, there can't be 5 rendered pixels on 2 CPU cycles?


I don't know where you got that 8th PPU cycle from, but that's not the case.

Each cycle between cycles [1..256] render 1 pixel each (in addition to doing some other stuff). 1 pixel = 1 cycle.

Quote:
NOP (2 CPU cycles) = 6 PPU Cycles, there's a chance there's not even a single pixel rendered here?


Yes, but not because of the 8th cycle thing.

Cycles 257-340 do not render any pixels.


EDIT:

Just saw your attachment. We must be online at the same time.

Yes @ checkmarks & circles.


But again note that this 3:1 ratio will only work for NTSC. If you are planning to add PAL support, it might help to think of the ratio as 15:5 instead because the PAL ratio is 16:5.


Top
 Profile  
 
PostPosted: Thu Feb 18, 2016 11:55 pm 
Offline
User avatar

Joined: Sun Mar 19, 2006 3:06 am
Posts: 583
Location: Gothenburg/Sweden
Quote:
If you start at cycle 0 and run for 6 cycles, you will only render 5 pixels, because cycle 0 does not render a pixel, but cycles 1-5 do.

Aha! I thought only every 8:th PPU cycle (the red ones) rendered a pixel, this is why I am getting it all wrong.
So all PPU cycles renders a pixel (when in "camera-range" of course, and not the skip/idle-ones)..

And yes, I'm aware of PAL differences, but I'll focus on NTSC for now..

_________________
http://nes.goondocks.se/


Top
 Profile  
 
PostPosted: Fri Feb 19, 2016 12:14 am 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
Quote:
So all PPU cycles renders a pixel (when in "camera-range" of course, and not the skip/idle-ones)..


"in camera range", yes.

scanlines [0..239] and cycles [1..256]. As long as both of those are true, the PPU is outputting a pixel.


Top
 Profile  
 
PostPosted: Fri Feb 19, 2016 12:45 am 
Offline
User avatar

Joined: Sun Mar 19, 2006 3:06 am
Posts: 583
Location: Gothenburg/Sweden
So, which pixels are actually drawn every PPU cycle? I notice that 2 tiles are fetched on line 261 to be the first displayed on top of screen. But PPU Cycles 1,2,3.. they fetch data that are displayed "a little bit later then"? There's some kind of 2 tile buffering going on here, kind of?

EDIT:
Disch, I can hardly ask of you to help me out anymore here (I'm still extremly grateful for the help with audio psuedocode!), but if possible for you, or anyone else here with the skills, could help out, atleast with the basics of some pixelrender-psuedocode here, a push in the right direction.. It would be awesome..
I've tried myself on paper a few times but I tends to do it (probably) alot more complex than it needs to be, so..

_________________
http://nes.goondocks.se/


Top
 Profile  
 
PostPosted: Fri Feb 19, 2016 8:19 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19115
Location: NE Indiana, USA (NTSC)
The two background fetches at the end of horizontal blanking (321-328 and 329-336) are buffered to set up the pixel pipeline. The fetched background pattern bytes are first fed through a pair of 8-bit parallel in serial out (PISO) shift registers, which decode the pattern bytes into 2-bit pixel values. Then they and the attribute value are fed through a set of four 8-tap delay lines, which implement fine horizontal scrolling (bits 2-0 of first $2005 write). Do you need an illustration in order to understand this phase?


Top
 Profile  
 
PostPosted: Fri Feb 19, 2016 1:10 pm 
Offline
User avatar

Joined: Sun Mar 19, 2006 3:06 am
Posts: 583
Location: Gothenburg/Sweden
Does this mean there's a slight delay here.. PPU Clocks 1,2,3 etc. are actually displayed 16 pixels later?

_________________
http://nes.goondocks.se/


Top
 Profile  
 
PostPosted: Fri Feb 19, 2016 1:30 pm 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
The delay comes between when the CHR for the tiles is fetched, and when those pixels are actually output.

The tiles are loaded between ~9 and ~16 cycles before they're actually output


EDIT:

To clarify... assuming the fineX scroll is 0, the CHR being fetched on PPU cycles 5-8 will not be displayed until PPU cycle 17. fineX scrolling will make it display sooner than that due to the way that works.

The pixels being rendered on cycles 1-16 are the tile data fetched at the very end of the PREVIOUS scanline. This is part of the reason why there has to be a pre-render scanline before the actual displayed scanlines.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 58 posts ]  Go to page Previous  1, 2, 3, 4  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: Google Adsense [Bot] and 12 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group