It is currently Sun Dec 17, 2017 10:53 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 44 posts ]  Go to page 1, 2, 3  Next
Author Message
 Post subject: Overscan/HBlank
PostPosted: Tue Dec 27, 2005 10:49 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 332
It is known that there are 340/341 PPU cycles each scanline, with 256 cycles producing rendered pixels, and 84/85 cycles "horizontal blanking".

If you look at video-captured screenshots, you'll see there's some picture visible to the left and to the right of the 256 rendered pixels (overscan), which doesn't appear as black, but as whatever bg palette color 0 is set to.

This area must be taken into account when doing aspect ratio correction --- the stretching factor would not be 320/256 (if one wants to correct for a 320x240 surface), but more like 320/272 or a something like that.
It's also relevant for proper composite dot-crawl emulation.

So, how many of the 84/85 hblank cycles are occupied by this overscan area?


Top
 Profile  
 
 Post subject:
PostPosted: Tue Dec 27, 2005 7:58 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19353
Location: NE Indiana, USA (NTSC)
The "color clock" is the period of the NTSC color subcarrier, or 3.5795̅4̅ MHz.

CCIR specifies that the NTSC picture area is 176 color clocks wide by 240 pixels tall. Now, one CPU clock = 2 NTSC color clocks = 3 pixels, so 176 color clocks is 264 NES pixels. The picture area of a field is still 240 lines tall, so the area that you have to stretch to 4:3 is 264x240.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Dec 27, 2005 8:32 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 332
Quote:
CCIR specifies that the NTSC picture area is 176 color clocks wide by 240 pixels tall
What specific document would that be? The CCIR 601 recommendation, now renamed to ITU-R BT.601-05 (recent version), makes no mention of 176 color clocks; it mentions 720 horizontal samples for the luminance and 360 for each chrominance channel for the active area. I have seen no mention of the 'left and rightmost 8 pixels being blank, thus reducing the horizontal resolution to 704' in this 16-page document. That 704 might be the "effective" horizontal resolution in the same sense that 224 might be the "effective" vertical resolution of the NES (because of what the TV cuts off) is probably true, but shouldn't matter for the aspect ratio.
If I start from 720 pixels rather than 704, using your calculation method, the proper stretching would be from 270 pixels, not from 264.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Dec 27, 2005 10:47 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19353
Location: NE Indiana, USA (NTSC)
NewRisingSun wrote:
Quote:
CCIR specifies that the NTSC picture area is 176 color clocks wide by 240 pixels tall
What specific document would that be?

I had originally posted references at some web board that I'm now completely banned from (even reading gives a 403 Forbidden).

Quote:
The CCIR 601 recommendation, now renamed to ITU-R BT.601-05 (recent version), makes no mention of 176 color clocks; it mentions 720 horizontal samples for the luminance and 360 for each chrominance channel for the active area.

I looked at this document and maybe neither of us is 100% right. The 720 pixel area sampled under CCIR 601 is wider than the actual picture area in order to provide enough headroom on the sides to capture the whole scanline even if the sync signal is wobbly. It turns out that an actual 4:3 picture is 710.85x486. (True NTSC has 486 scanlines, not 480, but digital systems usually work with only the center 480 of those lines.)

VCD runs at a resolution called CIF, which is 352x240 pixels wide in NTSC. DVD runs at CIF, interlaced CIF (352x480), cropped CCIR 601 (704x480), or full CCIR 601 (720x480). In the prior analysis, I had assumed that the CIF screen's aspect ratio was 4:3, leading to a 10/11 (0.90909) pixel aspect ratio and a width of 264.00 pixels for the NES picture. But the document seems to indicate that 4320/4739 (0.91158) is the correct pixel aspect ratio for DVD, VCD, Apple II, Sega Genesis, and other devices that run at a half-601 pixel clock rate. This means a 4:3 picture whose height is 480 pixels has a width of 480*(4/3)*(4739/4320) = 702.07 pixels.

On NTSC, 1 CPU clock = 2 color clocks = 3 NES pixels = 8 CCIR 601 pixels. This means a 4:3 picture whose height is 480 pixels has a width of 480*(4/3)*(3/8)*(4739/4320) = 263.28 NES pixels. But given that it's this close, the 264 that I got before should still be good enough, especially that we're now probably well within the tolerances of consumer TV set calibration.

And we still haven't touched on overscan. The TVs popular in the NES era did not have square edges like those of modern flat screen TVs. For instance in Super Mario Bros., the "WORLD" in the center might show up cleanly with about 4 pixels of margin, but the very top of "MARIO" might get partly cut off. Let's just assume that overscan simulation will be provided by a textured quad to be drawn over the emulated TV signal, which is another textured quad resized from a 264x240 texture to 640x480.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Dec 28, 2005 9:11 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 332
Quote:
The 720 pixel area sampled under CCIR 601 is wider than the actual picture area in order to provide enough headroom on the sides to capture the whole scanline even if the sync signal is wobbly.

No. The 720 pixel area is the "active area". The "headroom" you mention is the "back porch" and the "front porch". Back porch, front porch and sync pulse are the blanking area. Rec. ITU-R BT.601-5 captures 858 pixels horizontally, with 720 pixels for the active (visible) area and 138 for the blanking area, including the sync pulse and that "headroom".
You don't need to take additional headroom from the active area so that the whole scanline is captured even if the sync signal is wobbly, because in Rec. ITU-R BT.601-5 the sync signal itself is captured, which is why you have 858 pixels total and not 720.

I have read that document you linked to, I have never ever heard of anything like that. Maybe one day I'll read through all of his documents and look into it a little bit closer.

As for now and the NES, it doesn't stand the empirical test either:
If the NES has 264 pixels (assuming 704 NTSC luma pixels and 176 color cycles), you need to add 8 pixels, presumably 4 to the left and 4 to the right. Stretching these 264 pixels to 640 gives you this:
Image

However, if the NES has 270 pixels as I claimed (assuming 72 NTSC luma pixels and 180 color cycles), you need to add 14 pixels, presumably 8 to the left and 6 to the right. Stretching these 270 pixels to 640 gives you this:
Image

I am operating my TV in underscan mode, and while that may not be as accurate as I need (it's still a consumer set after all), the colored border is at least as wide as in the 270 picture, not as slim as in the 264 picture. Also, if you look at the video-captured SMB1 shot on MobyGames, you'll find that it's much closer to the 270 shot than to the 264 shot:
http://www.mobygames.com/game/nes/super ... tId,31489/


Top
 Profile  
 
 Post subject:
PostPosted: Wed Dec 28, 2005 12:46 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19353
Location: NE Indiana, USA (NTSC)
A lot of consumer and even prosumer video capture devices are not close to CCIR 601 compliant.

Want me to put Balloon Fight in my NES, connect it to my TV, and use a tape measure?


Top
 Profile  
 
 Post subject:
PostPosted: Wed Dec 28, 2005 1:20 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 332
Quote:
A lot of consumer and even prosumer video capture devices are not close to CCIR 601 compliant.
Closer than that page you linked to certainly. And again, those screenshots are only an illustration of the relevant point, that the active horizontal area is 720 pixels wide --- just as the ITU 601 states, not 704, 710 or anything else.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Dec 28, 2005 2:00 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19353
Location: NE Indiana, USA (NTSC)
NewRisingSun wrote:
And again, those screenshots are only an illustration of the relevant point, that the active horizontal area is 720 pixels wide --- just as the ITU 601 states, not 704, 710 or anything else.

True, there may be 720 pixels, but are you sure that the 720x480-pixel area is exactly 4:3? If it were, the pixel aspect ratio under 601 would be 480/720*4/3 = 8/9 = 0.88889, and the NES pixel aspect ratio would be 480/720*4/3*4/3 = 32/27 = 1.18519.

EDIT: I connected my NES to the family's main TV, turned on an NES game, and measured a 144x144 pixel area. It ended up as 11+15/16 inches by 10+5/8 inches on one TV. This implies a pixel aspect ratio of 191/165 or 1.15758, which is even narrower than the ratio suggested by your calculation.

On the same TV, a Game Boy Player (which runs in a GameCube video mode intended by Nintendo as a square-pixel mode) produces a 240x160 pixel image measuring 17+1/2 inches by 11+3/4 inches. This implies a pixel aspect ratio of 160/240*280/188 = 0.99291. As all inch measurements in this post are plus or minus 1/16 inch, this is close enough to 1.

Finally, I tried a test pattern in Mario Paint. (The NTSC Super NES in non-"hi-res" video modes has the same pixel clock rate as the NTSC NES.) I made a filled rectangle 96 pixels tall and 80 pixels wide. Then I made a 1x16 pixel stamp, used it to extended the box in 16-pixel-tall bands to 81, 82, 83, 84, and 85 pixels wide, and saved it to the game's SRAM. Then I plugged it into different TVs, loaded, and measured. On a TV that follows 720x480 = 4:3, the 81-pixel-wide row would be as wide as the box is tall.

On one TV I got somewhere around 85x96 pixels for a square; on another, 80x96 pixels. This indicates that there's a pretty big margin of difference among the aspect ratios of actual television sets.

Conclusion: It might be best to render to a texture whose size is 256x240 pixels (or multiples thereof) and then let the user adjust the horizontal scale factor between, say, 1.15 and 1.25, using a "horizontal size" knob.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Dec 28, 2005 3:44 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 332
That probably is a very good solution for the aspect ratio problem. Unfortunately, I need to get this right for another reason: unless I get the horizontal resolution properly nailed down, I won't get the composite dot crawl pattern right.

I just fiddled around with the horizontal centering of my Sony TV, shifting the picture so I can actually see the sync pulse, back porch and color burst.

First of all: it's very interesting to see the color burst "crawl" upwards whenever the BG is turned off, then suddenly stop crawling once the game turns the BG back on. Just as Bregalad described! :)

But more importantly: This area left and right of the rendered 256 pixels, where color 00 is displayed (let's call it "overscan area" for lack of a better word) is even wider than I thought: after the back porch ends (which seems to be at the same spot where it ends for a normal NTSC TV picture by the way), there's a gray line, about one to two NES pixels thick, then about 16 pixels of color 00 (I'm going by eyesight here), then the 256 playfield pixels, then about 8-10 pixels of color 00 again, then the front porch begins. That would make 16+256+8=280 horizontal pixels in the 720-pixel active area... that doesn't seem right. :-(


Top
 Profile  
 
 Post subject:
PostPosted: Wed Dec 28, 2005 7:05 pm 
Offline

Joined: Tue Nov 23, 2004 9:35 pm
Posts: 634
Quote:

Conclusion: It might be best to render to a texture whose size is 256x240 pixels (or multiples thereof) and then let the user adjust the horizontal scale factor between, say, 1.15 and 1.25, using a "horizontal size" knob.


This is the one reason why I still have FCE Ultra installed on my computer, it allows you to scale integrally in custom resolutions. My LCD has a native resolution of 1280x1024 and by using the 1280x960 with a 5:4 pixel ratio, I get a picture thats sharp as a knife and reasonably close to the NES's pixel aspect ratio on a TV.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Dec 28, 2005 7:30 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19353
Location: NE Indiana, USA (NTSC)
NewRisingSun wrote:
Unfortunately, I need to get this right for another reason: unless I get the horizontal resolution properly nailed down, I won't get the composite dot crawl pattern right.

Dot crawl has absolutely nothing to do with the aspect ratio. Instead, the dot crawl is synchronized to color burst.

The color subcarrier of NTSC is 3.579545 MHz. The NES system clock is six times color, or 21.47727Mhz. But because the NES PPU's color generator actually uses a double-pumped counter to generate 12 phases (hues) out of 6 cycles, you have to sample at twice this, or 42.95455 MHz. As the NTSC pixel clock is 1/8 of this (5.36932 MHz), each pixel will be spread across 8 phases. After a low-pass filter at about 4.5 MHz, this is the signal that the NES outputs on the composite video RCA connector at the side of the toaster. At this point you're allowed to downsample the composite signal by a factor of 6 to CIF (7.1591 MHz).

Now you have to do a TV emulation. Converting composite to RGB takes three steps:
  1. Convert to S-video by using a a low-pass filter (0 to 2.7 MHz) to get the luma signal and a band-pass filter (2.7 MHz to 4.5 MHz) to get chroma.
  2. Convert to component video by QAM-decoding the U and V channels. Use the color burst and the tint control to find the starting phase of U.
  3. Optional: Run a comb filter to clean up the chroma signal. It's a weighted sum of the chroma signal in the previous, current, and next scanlines.
  4. Convert to RGB by running through a decoder matrix. As TVs in USA and Japan are tweaked to make each region's typical flesh tones look better, it'd be a good idea to provide standards-compliant, USA, and Japan settings for the decoder matrix.
Only after you have the signal in RGB do you need to worry about pixel aspect ratio.

Quote:
But more importantly: This area left and right of the rendered 256 pixels, where color 00 is displayed (let's call it "overscan area" for lack of a better word) is even wider than I thought: after the back porch ends (which seems to be at the same spot where it ends for a normal NTSC TV picture by the way), there's a gray line, about one to two NES pixels thick, then about 16 pixels of color 00 (I'm going by eyesight here), then the 256 playfield pixels, then about 8-10 pixels of color 00 again, then the front porch begins. That would make 16+256+8=280 horizontal pixels in the 720-pixel active area... that doesn't seem right. :-(

Because the NTSC NES dot clock is exactly 3/8 of the 601 pixel clock, the 720-pixel area of 601 will have 270 NES pixels by definition. What you're seeing is that the NES might not actually blank the signal for the entire horizontal-blanking time.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Dec 28, 2005 7:40 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 332
Quote:
Dot crawl has absolutely nothing to do with the aspect ratio. Instead, the dot crawl is synchronized to color burst.
... relative to the NES' pixel clock, yes. I already have it finished except for the exact color burst shift between odd/even fields. :)

Quote:
What you're seeing is that the NES might not actually blank the signal for the entire horizontal-blanking time.
Yes, I think the colored overscan area extends into the back porch area.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Dec 28, 2005 9:57 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19353
Location: NE Indiana, USA (NTSC)
NewRisingSun wrote:
Quote:
Dot crawl has absolutely nothing to do with the aspect ratio. Instead, the dot crawl is synchronized to color burst.
... relative to the NES' pixel clock, yes. I already have it finished except for the exact color burst shift between odd/even fields. :)

That would be 1/3 color clock worth of shift.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Dec 29, 2005 9:17 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 332
Quote:
That would be 1/3 color clock worth of shift.
That's what I thought too, but it doesn't look right. Maybe I'm doing something else wrong. If you want to take a look:

even field


odd field


Obviously you need to look at them in 60 Hz succession... aside from the colors (I'm just guessing the four luma offsets and the chroma amplitude for now) and the aspect ratio (I'm sticking with 720 for this purpose), the dithered pattern at the bottom of the vitamin pill does have the same "diagonal" look as on my TV; all in all however, there seems to be less artifacting on my TV.


Last edited by NewRisingSun on Fri Feb 10, 2006 6:14 pm, edited 1 time in total.

Top
 Profile  
 
 Post subject:
PostPosted: Thu Dec 29, 2005 2:47 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19353
Location: NE Indiana, USA (NTSC)
NewRisingSun wrote:
but it doesn't look right. Maybe I'm doing something else wrong. If you want to take a look:

even field
odd field

Combined:
Image

Quote:
Obviously you need to look at them in 60 Hz succession... aside from the colors (I'm just guessing the four luma offsets and the chroma amplitude for now)

The color signal for $x1 through $xC is thought to alternate in a square wave between the value for $x0 and $xD.

Quote:
and the aspect ratio (I'm sticking with 720 for this purpose), the dithered pattern at the bottom of the vitamin pill does have the same "diagonal" look as on my TV; all in all however, there seems to be less artifacting on my TV.

That's due to your TV's "2D comb filter". More expensive TVs will use a weighted average of the previous, current, and next scanlines' chroma signals.


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 8 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