NTSC Color Generator

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

beannaich
Posts: 207
Joined: Wed Mar 31, 2010 12:40 pm

NTSC Color Generator

Post by beannaich »

While looking through the wiki, I came across this paragraph:
The color generator is clocked by the rising and falling edges of the ~21.48 MHz clock, resulting in an effective ~42.95 MHz clock rate. There are 12 color square waves, spaced at regular phases. Each runs at the ~3.58 MHz colorburst rate
That all makes sense, except for one part. If the color generator receives a ~42.95 MHz clock, doesn't that only allow for 8 samples of the signal at the sub-carrier frequency? If so, how does one align the sub-carrier at 12 different phase offsets with only 8 samples to "wiggle" in? Wouldn't this cause some level of aliasing?

If I've grossly misunderstood this, please enlighten me.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: NTSC Color Generator

Post by lidnariq »

beannaich wrote:doesn't that only allow for 8 samples of the signal at the sub-carrier frequency?
Yup.
If so, how does one align the sub-carrier at 12 different phase offsets with only 8 samples to "wiggle" in?
You can't "align" it at all; as far as NTSC is concerned the phase is the hue.
Wouldn't this cause some level of aliasing?
Yup. That's the source of the NES's characteristic chroma↔luma crosstalk.
beannaich
Posts: 207
Joined: Wed Mar 31, 2010 12:40 pm

Re: NTSC Color Generator

Post by beannaich »

lidnariq wrote:You can't "align" it at all; as far as NTSC is concerned the phase is the hue.
By "align" I meant phase shift. I think I may have misunderstood the page in any case :D So the 8 samples would not have an (approximately) ideal square wave represented in them at all, but would instead have ramps from low to high amplitude as well?
lidnariq wrote:Yup. That's the source of the NES's characteristic chroma↔luma crosstalk.
I see, thanks for the quick response!
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: NTSC Color Generator

Post by lidnariq »

I mean, to get deep into engineer math, you can think of a scanline as containing a phasor where the I and Q (or U and V) components contain the picture data, but the instantaneous value at any given nanosecond is rotating between measurable (real-valued) and not (imaginary-valued) in a continuous manner.

The actual emission from the 2C02 is still a pulse wave, where each ≈20ns is one of ≈11 different voltages, and the analog multiplexers inside the PPU dynamically select one of the 55 possible emited phasor/DC combinations. (The TV, in turn, is what converts any given phasor into color data.)

Because of these phasors (=QAM), the exact nanosecond in a scanline when the instantaneous voltage received changes determines the color that's being displayed. (Hence american football referee shirts turning rainbow-colored in the bad old broadcast NTSC days)

So, no, the output is not intentionally made of ramps: there's lots and lots of high-frequency components that are subsequently lowpassed away. (Look at HardWareMan's pictures in these threads: , )
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: NTSC Color Generator

Post by tepples »

In each pixel period (8 master clock half-periods), there is still at least one transition from high to low or vice versa, enough to perfectly recover the phase/hue in theory. But you often get more of the low voltage than the high or vice versa in any given pixel period. And because the TV doesn't try to align its QAM decoder to the PPU's pixel clock, this produces raggedness on vertical edges and diagonal stripes on checkerboard patterns.
beannaich
Posts: 207
Joined: Wed Mar 31, 2010 12:40 pm

Re: NTSC Color Generator

Post by beannaich »

tepples wrote:In each pixel period (8 master clock half-periods), there is still at least one transition from high to low or vice versa, enough to perfectly recover the phase/hue in theory. But you often get more of the low voltage than the high or vice versa in any given pixel period. And because the TV doesn't try to align its QAM decoder to the PPU's pixel clock, this produces raggedness on vertical edges and diagonal stripes on checkerboard patterns.
I guess what I'm getting at is, should the waveform samples be more like (2x resolution for clarity):

Code: Select all

1.0 ++++++
0.8 +    +
0.6 +    +
0.4 +    +
0.2 +    ++++++
0.0
or more like:

Code: Select all

1.0   ++++
0.8  +    +
0.6 +      +
0.4 +      +
0.2 +       ++++
0.0
Otherwise I'm not seeing how some of those phase offsets can be differentiated from at all given the aliasing. With slight sinusoid forms the signals would still be somewhat distinct.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: NTSC Color Generator

Post by lidnariq »

Does following along with my manual modulation and demodulation in the 2C02 and an NTSC TV explain anything?
beannaich
Posts: 207
Joined: Wed Mar 31, 2010 12:40 pm

Re: NTSC Color Generator

Post by beannaich »

lidnariq wrote:Does following along with my manual modulation and demodulation in the 2C02 and an NTSC TV explain anything?
I'll list what I understand so far about the color generator, taken from the screen shots, the wiki, and a little from NTSC signal descriptions found on the web:

1. the sub-carrier used in the color burst portion is the 8th phase-shifted sub-carrier signal of the 12.
2. the upper 2 bits of the palette color is used to select the DC offset for the next 8 samples from the color generator.
3. the lower 4 bits of the palette color is used to select one of the 12 phases (with some values not selecting an AC signal, but instead a DC signal of +0 for greyscale values)
4. the DC offset is added to the phase-shifted carrier (or +0 DC signal) to form the signal that is sampled 8 times for that pixel.
5. the above, along with other samples (front/back porch, sync pulses, etc) form the NTSC output of the color generator (aka encoder).
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: NTSC Color Generator

Post by lidnariq »

That seems to be an accurate description of how the 2C02 generates video, yes; any given scanline can be divided into 2728 half-master-clock periods.

(Except one, which is one pixel / 8 half-master-clock periods short due to the missing pixel)
beannaich
Posts: 207
Joined: Wed Mar 31, 2010 12:40 pm

Re: NTSC Color Generator

Post by beannaich »

lidnariq wrote:That seems to be an accurate description of how the 2C02 generates video, yes; any given scanline can be divided into 2728 half-master-clock periods.

(Except one, which is one pixel / 8 half-master-clock periods short due to the missing pixel)
Right. I guess I'll try and make an encoder/decoder and see how it turns out. I'll post my results back in this thread!

Thanks for the help so far :)
beannaich
Posts: 207
Joined: Wed Mar 31, 2010 12:40 pm

Re: NTSC Color Generator

Post by beannaich »

I have managed to encode the frame into a NTSC signal:

Image

Now to read up further on NTSC decoding. In particular, determining which part of the signal you're looking at so I can begin separating the luma/chroma. Any advice? I've read that low-pass filtering the signal to 0.5 MHz makes this a lot easier.

One thing I've already noticed is that the crosstalk pattern in my image is at a -45° while lidnariq's is at +45°.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: NTSC Color Generator

Post by lidnariq »

If your working model is "generate a 2728x262 frame image and decode it" (as it looks), you're not generating the colorburst. The colorburst reference is required by the decoder for phase (and maybe for amplitude).

As far as the other point ... because the PPU generates 227+⅓ colorburst periods per scanline, so each scanline should be earlier by ⅓ of a period...
beannaich
Posts: 207
Joined: Wed Mar 31, 2010 12:40 pm

Re: NTSC Color Generator

Post by beannaich »

lidnariq wrote:If your working model is "generate a 2728x262 frame image and decode it" (as it looks), you're not generating the colorburst. The colorburst reference is required by the decoder for phase (and maybe for amplitude)
I was generating it, but due to a double->uint8_t conversion it was being forced to 0.. d'oh!

Image
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: NTSC Color Generator

Post by lidnariq »

Anyway, the 2C02's phasors are generated using two six-bit Johnson counters, one clocked on falling edges and one clocked on rising edges. (Visual2c02 nodes 193-198 and 224-230). They don't restart on each scanline.

Decoding NTSC works by waiting a certain amount of time after hsync starts/ends (I forget) and capturing the phase of the colorburst. For NTSC, the colorburst is pure hue -U; either use that to generate sinusoids at hues U and V, or hues I and Q. The rest I stated in my pictorial demodulation.

edit: I think you're not generating the "pulse" (the rarely missing) pixel correctly; phase 0 is always brighter than anything else on the same row in the 2C02 palette.
beannaich
Posts: 207
Joined: Wed Mar 31, 2010 12:40 pm

Re: NTSC Color Generator

Post by beannaich »

lidnariq wrote:Anyway, the 2C02's phasors are generated using two six-bit Johnson counters, one clocked on falling edges and one clocked on rising edges. (Visual2c02 nodes 193-198 and 224-230). They don't restart on each scanline.
Interesting. I'm currently just doing it the naive way of incrementing 12 integers through a 12-step cycle every sample. If they're less than 6, they're high, otherwise they're low. And they are initialized with incrementing values from 0-11.
lidnariq wrote:Decoding NTSC works by waiting a certain amount of time after hsync starts/ends (I forget) and capturing the phase of the colorburst. For NTSC, the colorburst is pure hue -U; either use that to generate sinusoids at hues U and V, or hues I and Q. The rest I stated in my pictorial demodulation.
Right, I just need a genlock of sorts for timing control. I'm planning to make the decoder/receiver usable by more than just an NES, so I don't want to get too reliant on it's specific timings.
lidnariq wrote:edit: I think you're not generating the "pulse" (the rarely missing) pixel correctly; phase 0 is always brighter than anything else on the same row in the 2C02 palette.
Do you mean the pixel between the black and left border at h:329? If so, I am currently sending it out as DC, but perhaps AM would be more appropriate.
Post Reply