It is currently Sun Oct 22, 2017 5:13 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 24 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: NTSC Color Generator
PostPosted: Mon Mar 07, 2016 7:30 pm 
Offline

Joined: Wed Mar 31, 2010 12:40 pm
Posts: 207
While looking through the wiki, I came across this paragraph:

Quote:
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.


Top
 Profile  
 
 Post subject: Re: NTSC Color Generator
PostPosted: Mon Mar 07, 2016 7:38 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6294
Location: Seattle
beannaich wrote:
doesn't that only allow for 8 samples of the signal at the sub-carrier frequency?
Yup.
Quote:
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.
Quote:
Wouldn't this cause some level of aliasing?
Yup. That's the source of the NES's characteristic chroma↔luma crosstalk.


Top
 Profile  
 
 Post subject: Re: NTSC Color Generator
PostPosted: Mon Mar 07, 2016 7:56 pm 
Offline

Joined: Wed Mar 31, 2010 12:40 pm
Posts: 207
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!


Top
 Profile  
 
 Post subject: Re: NTSC Color Generator
PostPosted: Mon Mar 07, 2016 8:26 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6294
Location: Seattle
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: , )


Top
 Profile  
 
 Post subject: Re: NTSC Color Generator
PostPosted: Mon Mar 07, 2016 8:33 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19115
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
 Post subject: Re: NTSC Color Generator
PostPosted: Mon Mar 07, 2016 9:14 pm 
Offline

Joined: Wed Mar 31, 2010 12:40 pm
Posts: 207
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:
1.0 ++++++
0.8 +    +
0.6 +    +
0.4 +    +
0.2 +    ++++++
0.0


or more like:

Code:
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.


Top
 Profile  
 
 Post subject: Re: NTSC Color Generator
PostPosted: Mon Mar 07, 2016 9:25 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6294
Location: Seattle
Does following along with my manual modulation and demodulation in the 2C02 and an NTSC TV explain anything?


Top
 Profile  
 
 Post subject: Re: NTSC Color Generator
PostPosted: Mon Mar 07, 2016 9:55 pm 
Offline

Joined: Wed Mar 31, 2010 12:40 pm
Posts: 207
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).


Top
 Profile  
 
 Post subject: Re: NTSC Color Generator
PostPosted: Mon Mar 07, 2016 10:18 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6294
Location: Seattle
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)


Top
 Profile  
 
 Post subject: Re: NTSC Color Generator
PostPosted: Mon Mar 07, 2016 10:22 pm 
Offline

Joined: Wed Mar 31, 2010 12:40 pm
Posts: 207
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 :)


Top
 Profile  
 
 Post subject: Re: NTSC Color Generator
PostPosted: Tue Mar 08, 2016 7:59 pm 
Offline

Joined: Wed Mar 31, 2010 12:40 pm
Posts: 207
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°.


Top
 Profile  
 
 Post subject: Re: NTSC Color Generator
PostPosted: Tue Mar 08, 2016 8:16 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6294
Location: Seattle
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...


Top
 Profile  
 
 Post subject: Re: NTSC Color Generator
PostPosted: Tue Mar 08, 2016 8:32 pm 
Offline

Joined: Wed Mar 31, 2010 12:40 pm
Posts: 207
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


Top
 Profile  
 
 Post subject: Re: NTSC Color Generator
PostPosted: Tue Mar 08, 2016 8:43 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6294
Location: Seattle
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.


Top
 Profile  
 
 Post subject: Re: NTSC Color Generator
PostPosted: Tue Mar 08, 2016 9:04 pm 
Offline

Joined: Wed Mar 31, 2010 12:40 pm
Posts: 207
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.


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

All times are UTC - 7 hours


Who is online

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