nesdev.com
http://forums.nesdev.com/

Cycle times of common things reference
http://forums.nesdev.com/viewtopic.php?f=2&t=18054
Page 2 of 2

Author:  Sumez [ Tue Nov 20, 2018 12:31 am ]
Post subject:  Re: Cycle times of common things reference

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?

Author:  koitsu [ Tue Nov 20, 2018 12:36 am ]
Post subject:  Re: Cycle times of common things reference

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.

Author:  rainwarrior [ Tue Nov 20, 2018 2:18 am ]
Post subject:  Re: Cycle times of common things reference

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.)

Author:  tokumaru [ Tue Nov 20, 2018 2:23 am ]
Post subject:  Re: Cycle times of common things reference

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.

Author:  koitsu [ Tue Nov 20, 2018 2:27 am ]
Post subject:  Re: Cycle times of common things reference

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.

Author:  Bregalad [ Tue Nov 20, 2018 2:44 am ]
Post subject:  Re: Cycle times of common things reference

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.

Author:  lidnariq [ Tue Nov 20, 2018 11:56 am ]
Post subject:  Re: Cycle times of common things reference

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)

Author:  NewRisingSun [ Tue Nov 20, 2018 12:04 pm ]
Post subject:  Re: Cycle times of common things reference

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.

Page 2 of 2 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/