I'd like to compile a list of common time measurements to serve as a programming reference.
Code:
NTSC Scanline = 113.667 CPU cycles
NTSC NMI = 2273 CPU cycles
NTSC Frame = 29780.667 CPU cycles
NTSC PPU cycles / CPU cycles = 3
PAL Scanline = 106.5625 CPU cycles
PAL NMI = 7459.375 CPU cycles (too low?)
PAL Frame = 33247.5 CPU cycles
PAL PPU cycles / CPU cycles = 3.2
OAM DMA = 513 cycles (+1 on odd CPU cycles)
Do these numbers look right? Most of them I had to calculate myself because I couldn't find them on the wiki, and I'm pretty sure I made mistakes.
I'd also like to include a reference to the delay DMC can add, but I've had a real tough time finding information on this. I think in the worst case it can add 4 cycles every 432 cycles? Is that correct?
The only pages that mention CPU cycle correlations are these:
https://wiki.nesdev.com/w/index.php/PPU#Noteshttps://wiki.nesdev.com/w/index.php/Con ... ronizationhttps://wiki.nesdev.com/w/index.php/PPU_frame_timingOther places are nesdev forum threads, which are not as helpful (re: not as organised). We really should have a cycle breakdown chart somewhere (i.e. I'm sorry you had to calculate these by hand).
I'd say that that information is all
here, but since these are mostly properties of the PPU we expressed them there in terms of pixels and scanlines, not CPU cycles.
Yeah it would be a really good idea to expand that list with exact cycle counts. Or create a dedicated page for that. It's something I need a lot, and I always forget where to look.
I spent awhile digging through the wiki when I first started a couple years ago, and was bummed that this didn't exist in a page. Thanks for putting it in one place.
lidnariq wrote:
I'd say that that information is all
here, but since these are mostly properties of the PPU we expressed them there in terms of pixels and scanlines, not CPU cycles.
Not to mention, only two pages on the entire Wiki reference that "Clock rate" page:
https://wiki.nesdev.com/w/index.php/NES_reference_guide -- "Clock rate of various components in different variants of NES"
https://wiki.nesdev.com/w/index.php/Detect_TV_system -- "A game can use it to compensate for differences in clock rate among various NES models."
Nothing else links to it, not even in References or See also or Notes or anything. It's no wonder nobody can find this page of super useful info! :-) (I've seen that page a couple times but I never remember where to find it either.)
And yes, having correlating CPU cycle counts (or at what particular CPU cycle something happens at from start of VBlank) would be super useful, as coders are going to need to know exactly this. I don't know if such information should go into the "Clock rate" page, or a separate page.
Sumez wrote:
Yeah it would be a really good idea to expand that list with exact cycle counts. Or create a dedicated page for that. It's something I need a lot, and I always forget where to look.
I would say that "Clock rate" is already the dedicated page for it. The problem is more about naming and discovery.
My question would be: what name for such an article would have permitted you to find it? What search terms did you use when looking for it?
It could be accessible from the nes reference guide and could be created as a link under clock rate. The name could be something like "cycle reference chart", which an explanation after the link that say it explain this is contains a chart for CPU cycle for specific task on the nes.
It could be a start and the naming (and english) could be improved later.
edit:
created place holder, always wanted a page like that:
http://wiki.nesdev.com/w/index.php/Cycl ... ence_chart
If this is supposed to be accurate, I don't think we should be rounding numbers.
Sure, this is why it's a place holder and we can improve it anyway we like. It just a start and we now have a page for it
I think that page should either redirect to the
Clock rate article or the other way around, rather than create two parallel articles with subtly different sets of the same information. "Cycle reference chart" is probably the better name, so my vote is to make "Clock rate" the redirect.
This is perfectly fine too. For some reason the clock rate never got my attention by the title only so I never thought of looking there ^^;;
The goal was to get the ball rolling so now it is! The new chart is basically more some reference so developer knows what to do with their code so it could be an addendum to the current article with a proper link at the top so it could this be easily found.
What I would like to make someday (which I was hoping to do 10 years ago) is a section with simple "how-to" for dev and I think that chart is one of those since it's not specifically technical on "how" it happen behind the scene but more on "how much" a unit take time, which is very useful for timing code.
No rush to move it yet but will check the clock rate later to see how to incorporate it inside.
I'll take care of merging the two pages, and making "Clock rate" redirect to the new page.
All done. I fixed some typos, properly made references, and added Dendy details.
I'm still in the process of cleaning up redirections on all the other pages (I know I don't have to do this, but consistency is good).
Edit: all pages have been updated, excluding the Talk pages, which I opted to leave alone for obvious reasons.
All in one table, even better now.
Should hblank be added too? I think it was useful information when timing raster.
This is great!
hblank length could be useful, but more than anything I think what's useful is how to time a PPU write guaranteed to hit hblank in combination with something like the MMC3 scanline counter. I think such examples already exist on the Wiki?
Banshaku wrote:
Should hblank be added too? I think it was useful information when timing raster.
Most definitely; there have been a couple threads where this has come up (to do something like palette changes, IIRC). I've
added a (blank) row for HBlank if someone wishes to fill that out.
Just FYI, when creating a redirect, you can use # in the redirect link if you want it to go to a subsection of the target article, you don't have to update every single link to it elsewhere in the wiki to accomplish that.
Normally when a page is moved on a wiki, the only links you need to fix are "double redirects", i.e. links to an article that already redirected to the one you're now replacing with a redirect. Regular links that went straight to that article don't need to be updated. ("Clock rate" didn't have any prior redirects though, so there wasn't any possible of double redirects here. You can click "what links here" on the left hand sidebar to check.)
I think it's important to note that hblank is *NOT* idle PPU time that can be used for all kinds of raster effects indiscriminately. The PPU is very much busy during hblank, updating the VRAM address, fetching sprite patterns, fetching data to start drawing the background... Depending on what kind of raster effect you want to pull off, you need to "dodge" these operations accordingly.
rainwarrior wrote:
Just FYI, when creating a redirect, you can use # in the redirect link if you want it to go to a subsection of the target article, you don't have to update every single link to it elsewhere in the wiki to accomplish that.
Thanks, I didn't know that. I was going purely off of what
https://www.mediawiki.org/wiki/Help:Redirects demonstrates.
pubby wrote:
Do these numbers look right? Most of them I had to calculate myself because I couldn't find them on the wiki, and I'm pretty sure I made mistakes.
To be honnest, I think you should use fractions rather than floating points value, whenever possible. For instance, 133+2/3 is the exact amount of CPU cycles per NTSC scan line is the correct value, 133.666 is only an aproximation and looks ugly. Same for PAL CPU cycles / PPU cycles which should be 16/5 instead of the confusing 3.2 value. Same for all other values.
With the exception of 3.2, where the decimal value is as clear and also shorter, the frame rates, and the NTSC & PAL clock references rates where the decimal expansion is the industry-preferred version, I have converted the rest to fractions.
(Expanding PAL's colorburst frequency — 15625 × 1153 ÷ 4 + 25 — is a wild tangent and obfuscatory)
The NTSC color burst frequency is defined in SMPTE 170M as 5 MHz * 63/88, not as 3.58 MHz, so it's not obfuscatory to state it exactly. It's desirable since the exact value is a periodic decimal fraction.
As for PAL, given the terminating decimal fraction, there is no hurt in specifying it as 4,433,618.75 Hz.