Details of composite encoding

The NES PPU generates a composite signal by directly generating square waves delayed by 0 to 11 master clock cycles depending on the hue values from the palette. The Super NES PPU, on the other hand, forms an RGB signal and encodes it to composite. How is this encoding accomplished? Has anyone tried displaying solid colors and running the AV Multi Out into an oscilloscope? Do any Super NES emulators emulate the RGB to composite path in the Super NES and the composite to RGB path in a TV?

The composite encoding is handled by a seperate encoder chip, labelled S-ENC, at U8 in the top right page of the neviksti schematics. (?) are things I'm not terribly clear on.

Analog RGB, and SYNC run to the S-ENC chip, as well as the RED, GREEN, BLUE, and SYNC pins on the AV jack.

Going by the datasheet below, this is rather rube goldberg setup. The chip take analog RGB, and SYNC, and generates YO, (R-Y)O, and (B-Y)O signals from those via a matrix, merging SYNC into YO.

Those three outputs get looped back on the board to YI, (R-Y)I, and (B-Y)I. YO also gets routed to the AV jack V-SV pin (s-video luma)

SYNC, NT/PA, and some voltage refs get fed into a PLL that generates 0 degree, and 90/270 degree phases. Those get multiplied with the (R-Y)I and (B-Y)I signals, as well as the burst signal. The results get summed together, and sent out the CO pin, which runs to the AV jack C-SV pin (s-video chroma).

The CO signal also gets summed with YI, with some control from the pedestal clamp pulse and burst flag pulse inputs (tied together, come from some line on the PPU I didn't trace down yet, probably a HSYNC related output). That result gets amped, and fed out the VO pin, which runs to the AV jack VIDEO pin, and the RF modulator (composite video).

http://nfggames.com/forum2/index.php?topic=3525.0 has a pile of info regarding the SNES/N64 encoders
http://console5.com/techwiki/images/e/e6/BA6592F.pdf is a pdf for the BF6592F, which appears to be pin compatible with the S-ENC. From the discussion on the above page, it sounds like the S-ENC is a BF6592F with a builtin amplifier.

I believe blargg's snes-ntsc lib does as good a job as could be expected for this. The chip's already modulating the color difference signals against the I/Q phases, and generating the chroma signal from that, which suggests that it would not have the same color fringing artifacts the NES runs into from generating pixels faster than the chroma signal can resolve them. Effectively, the S-ENC chip prefilters the chroma for it. Also, given the usual sort of art, the difference outputs from the matrix aren't as likely to jump around as much as they do on the NES.

Theoretically, it might be possible to rig up component video from an snes, but it'd probably need some amplification or level shifting.

It's not filtered all the way though. Case in point: Get out your mouse, put your Mario Paint cartridge into an authentic Super NES, and fill the screen with a checkerboard pattern of black and dark blue. See the same diagonal stripes that one sees on an NES. Or maybe that's a peculiarity of launch units (version 1/1/1) like mine. Do you want me to do it on my TV and take a picture?

Ultimately, I'd like to see several test patterns in an oscilloscope. But I know that costs the time of people who have the equipment, and I want to get the cheapest tests with the most obvious results out of the way.

More a peculiarity of NTSC in general. Does it happen on svideo as well?

The chip still takes it's cues regarding sync and when to emit the colorburst from the PPU, which is still generating that bit the same way as the NES. Given the nature of PLLs, I imagine the two phases coming out of the VCXO block, that get multiplied with R-Y and B-Y, are square waves, which is going to have an effect similar to downsampling on the difference signals. Since the SNES is still going to have higher frequency components than the colorburst, there will be some aliasing going on, causing some artifacting. The dot rate is the same as the NES, so shifting a pixel every scanline, hence the diagonal jitter in intensity.

Pretty much no. Y/C has zero Y/C crosstalk, since the signals are kept separate. Simply from having played SMW on a first-gen SNES (specific revision unknown) connected via Y/C, I can assure you that there are no such artifacts in the image. The only real difference between Y/C and RGB is the color bleed. Luma is sharp and detailed unlike composite.

Ah, right. Forgot about that little quirk of the stairstepping.

If they filtered it all the way, it probably would be extremely blurry.

The Wii's composite encoder appears to filter it all the way. Emulators running on Wii have a lot more chroma blurring, but luma is still reasonably sharp, and there's little or no crosstalk between luma and chroma.

I remember noticing a rainbow artifact on one of the mine cart levels in "Donkey Kong Country Returns" when the camera moved along at just the right speed, and also on the VC download of "Wild Guns" on a level with dithered floor tiles. I can't remember if the rainbow on "Wild Guns" was vertical, like broadcast TV, or diagonal like a real SNES would.

A little bit of musing:

1- Because the SNES offers a 15-bit colorspace instead of the NES's ~6-bit one, it's easier to draw things that don't exceed the permissible chroma bandwidth.
2- Modern NTSC generators can (and do) prefilter the chroma bandwidth before modulation to prevent (most of) demodulation crosstalk.
3- I'm betting the S-ENC and S-RGB naively assume chroma bandwidth isn't exceeded, or maybe rely on a simple passive first order lowpass filter. This isn't good enough for the NTSC specification, which requires something like 20dB of rejection after ⅓ of a decade. Regardless, it modulates in the YUV space, not YIQ, so the disparate bandwidths for I and Q are definitely not enforced.

PS: my SNES has a BA6592F inside instead of a Nintendo-branded part.

Something that I don't see talked much about, is the luma frequency range from 4 Mhz to 4.2 Mhz. Does the SNES or NES composite/RF output have any luma information in that range? How does it effect how the pixels look like?

I'm pretty certain that the RF demodulation step will limit it hard to 4.2MHz, even though the NES (and probably the SNES?) generates content above there.

Visually, the maximum horizontal spatial frequency out of the NES is f_pixel/2, or ~2.7MHz; a very sharp lowpass filter at 4.2MHz should remove all of its (all odd) overtones, so spatially I believe it would appear as a sine wave before the gamma correction of the TV.

I'm not certain how visible that will be; with old CRT sets you'll probably run into the finite dimensions of the cathode ray itself. On an LCD TV the effect will probably be slightly more visible.

Today I just thought of what a couple "qualifications" of an ideal luma filter.

-On an NTSC/PAL television it is mathematically impossible to have a black and white checkered pattern, at more than 1/2 color carrier frequency, without rainbow artifacts. The only way to filter the rainbow artifacts completely is to filter the black and white pattern, into a solid grey. If the system is displaying alternating black and white pixels, it will generate a square wave luma signal. A square wave with it's harmonic frequencies filtered out would be a sine wave with an amplitude of 1.273x the amplitude of the square wave. Therefore, a filter with an amplitude of .758 at 1/2 dot clock frequence, would output a sine wave that goes all the way to black and all the way to white, but produces rainbow artifacts at only .758x the saturation.

-Unlike alternating black and white dots, a single black dot on a white background, or a single white dot on a black background can be filtered so that the artifact colors are gone. If you add the luma output signal with a delayed version of itself, that is 1/2 a color carrier cycle apart, the artifact colors will cancel eachother out in the middle of the pixel.

Depending on the exact demodulation mechanism, that's not entirely true:

1- Full YIQ demodulation (instead of YUV demodulation) actually will have limitations of (3.6 - 1.5)MHz or (3.6 - 0.6) MHz depending on the exact phase of the black/white pixels, so depending on a lot of very specific and seemingly random details, checkerboard pixels might be visible

2- 3D demodulation (which often uses an deinterlacing temporal chroma demodulation of something like [0 1 0 1 0][1 0 2 0 1][0 1 0 1 0]) can demodulate this specific image just fine, because when parsed as luma the checkerboard doesn't change and when parsed as chroma it'd be off by 180° each vsync.