NTSC pixel aspect, DMC DAC

NTSC pixel aspect, DMC DAC
by kyuusaku on 2012-06-06 (#95130)

(This thread is somewhat in jest, I needed my own accuracy thread)

After seeing the NTSC borders thread, I thought I'd bring this up: I don't think anybody is using the correct pixel-aspect ratio.

I have determined the square pixel scaling to be 293 x 240. Originally I thought it was 292, which I see has been proposed in another thread, but I came to that conclusion assuming a TV could adaptively vary the speed/horizontal width based on line timing in order to keep active video centered at different line frequencies. After diving deeper into TV circuits I see that they cannot, the angle of integration on the deflection sweep is fixed which means that NES video still sweeps at the same speed as standard NTSC video.

The justification is that TVs are calibrated for a 4:3 aspect with 52 + 59/90 us of active video by 486 lines which is the most agreed upon historical line count.

486 * (4/3) makes a square pixel resolution of 648 x 486. Since we're dealing with progressive video it's technically 324 x 243. The 3 missing vertical lines are irrelevant since they don't affect the pixel aspect.

The NES' active video period is 47.678306878306878306878306894438 us

(47.678306878306878306878306894438 us) / (52 + 59/90 us) * 324 = 293.37400898320923642721490378595 square pixels to active NES video, which leads to a pixel aspect of ~1.146. The aspect ratio is 293.374:240, or ~1.222.

Despite practically all of the border pixels (and a slight amount of front porch) falling into the active video area, if you emulate the 26 border pixels, do note that they cannot fit into 320, 640 etc. fixed square pixel screens without reducing the vertical resolution. You will have to drop 3.1698 of them. That is, unless you emulate a display calibrated to 480 lines in which case you can scale the 282 border and active pixels directly to your horizontal resolution (in a 4:3 aspect) because it will fall within 1 pixel tolerance, pretty cool. A "480" calibrated display will scale 256 NES pixels to ~290 square pixels. (320 / approx. 282 * 256)

-----

Don't hold me to this because it's been a long time since I looked at the 2A03 layout, but from memory, something else I haven't seen documented is that the DMC DAC's two least significant bits carry the same weight, which perhaps could explain the mixer "non-linearities".

by tepples on 2012-06-06 (#95132)

I think I know where the 292 came from:

For NTSC video, Rec. 601 specifies 10:11 PAR at 13.5 MHz. In 240p, that rate produces pixels of 5:11 PAR. Square pixels by the Rec. 601 definition would be
Fsquare = 13.5 MHz * 5/11 ~= 6.136 MHz

The TMS9918 dot rate, used by the SMS, NES, Genesis in 256px mode, and Super NES, is
F9918 = 3/2 * Fsc = 3/2 * 315/88 MHz ~= 5.369 MHz

This means the NES pixels are slightly wider than they are tall.
Fsquare / F9918 = 13.5 * 5/11 / (3/2 * 315/88) = 8/7
Pixels are about 1.143 scanlines wide.

Multiply the width of a pixel in scanlines by the width of the NES image in pixels:
8/7 * 256 ~= 292.57
Round to nearest integer is 293. Round to nearest multiple of four (for implementation ease) is 292. But the easiest way to get it exact is to actually render the entire 280-pixel-wide clean aperture and then scale that to 320, 640, 704, or however wide your particular video chip wants.

Are there any tests for the lowest 2 bits of the DAC carrying the same weight? That'd be equivalent to dividing by 2 and rounding up, and it'd simplify the design of high-fidelity audio codecs that play back on the NES if it were guaranteed that only 64 levels are possible.

by kyuusaku on 2012-06-06 (#95137)

I see, well

480 * (4/3) * (1/(10/11)) = 704 BT.601 pixels, which is widely cited

Since 486 lines yields 712.8 pixels, 480 line calibration
must be implied. Also it means that the active period is
now 704 * (1/13500000) or 52+4/27 us opposed to 52+59/90 us.

Quite a dilemma when considering which aspect to use, pre or post-BT.601.

---

By "entire 280-pixel-wide clean aperture" do you mean all pixels rendered
within the active period?

One reason I believe pre-BT.601 aspect should be used is that NES line timing aligns with pre-BT.601 NTSC probably to the best of the pixel clock's ability. And in that case the 282 game/border pixels can be scaled to the desired width as you say.

---

Assuming pre-BT.601 line timing, something people might want to consider is shifting video right ~3.2358 NES pixels (if they emulate cropped border pixels or the frame is pilarboxed/matted). The reason behind this is that the 256 game pixels are not centered as active video should should be. An instance where this could matter is if a game designer placed a game object directly in the center of their calibrated display, rather than in the center of NES video. Or perhaps if a peripheral were developed that clamped onto the display and needed precise positioning...

This could be worked out for BT.601 timing too, but I'm too lazy to.

---

BTW, the Genesis and PlayStation's 320 (and 640) modes (I guess PS2 as well,) use the same active video period (2560 master clocks) so to correct their aspect one must squeeze 320x240 into 293x240 square pixels and 640x480 into 587x480 etc.

by tepples on 2012-06-07 (#95148)

As for the use of pre- or post-601 aspect ratios, there are a couple factors. The Famicom came out in 1983, after the first version of CCIR 601 had been published in 1982. But a lot of TVs used with the console were manufactured pre-601. The Super Famicom's release in 1990 complicates things, as it uses the same pixel rate but is more clearly within the post-601 era.

kyuusaku wrote:
By "entire 280-pixel-wide clean aperture" do you mean all pixels rendered
within the active period?

Yes. Clean aperture is defined as more or less synonymous with the active period. The 720-pixel BT.601 signal consists of the 704-pixel clean aperture plus some "nominal analog blanking" border on the left and right that is not part of the active period, which can be used to realign a digitized signal later.

Quote:
Assuming pre-BT.601 line timing, something people might want to consider is shifting video right ~3.2358 NES pixels (if they emulate cropped border pixels or the frame is pilarboxed/matted).

I alluded to this in my writeup on the issue, which refers to "a quirk of the NES PPU's sync generation that places the image roughly two pixels to the right of center". I didn't know the exact displacement; that value just stuck in my head from when NTSC filtering was first being figured out. This appears to have been fixed in the Super NES PPUs, however.

Quote:
BTW, the Genesis and PlayStation's 320 (and 640) modes (I guess PS2 as well,) use the same active video period (2560 master clocks) so to correct their aspect one must squeeze 320x240 into 293x240 square pixels and 640x480 into 587x480 etc.

And the resulting 32:35 PAR of the Genesis (again, by BT.601 rules) is a hair wider than the 10:11 of BT.601 NTSC. But where do you get the PS1's 320 pixel mode necessarily having the Genesis PAR instead of the BT.601 PAR or square pixels? Is there a PS1 video document that you recommend?

by kyuusaku on 2012-06-07 (#95154)

The PS contains a CB x 15 (12 for PAL) oscillator like the Genesis. Apparently it can also divide by 7 for a 7.67 MHz clock, maybe others. For 256/320 modes the period must be the same. The timing is programmable however so games may offset video arbitrarily.

I don't think the PS can generate BT.601 video, but I would assume the PS2 certainly does for DVD playback. Also the Saturn must since most games run at 352/VCD resolution, and it supports VCD cards. 3DO probably does as well for the same reason. I know that the Gamecube *only* supports BT.601 video since that's how video is delivered to the DAC.

---

N64 must use the Gen/PS pixel clocks as well, though it generates them with a 14.318 oscillator. I think so because the DAC takes 4 ~50 MHz clocks per pixel which would correspond to 6.71 x 2. Since the DAC is clocked directly by the clock generator, the only way to achieve 5.37 modes is to delay the update one tick which wouldn't work with other 320/640 pixel clocks.