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?
Cycle times of common things reference
Moderator: Moderators
Re: Cycle times of common things reference
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.Banshaku wrote:Should hblank be added too? I think it was useful information when timing raster.
- rainwarrior
- Posts: 8734
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
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.)
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.)
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.
Re: Cycle times of common things reference
Thanks, I didn't know that. I was going purely off of what https://www.mediawiki.org/wiki/Help:Redirects demonstrates.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.
Re: Cycle times of common things reference
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.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.
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)
(Expanding PAL's colorburst frequency — 15625 × 1153 ÷ 4 + 25 — is a wild tangent and obfuscatory)
-
- Posts: 1510
- Joined: Thu May 19, 2005 11:30 am
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.
As for PAL, given the terminating decimal fraction, there is no hurt in specifying it as 4,433,618.75 Hz.