How does the propeller chip video generator really work?

wpd

OK, I'm way off the beaten track for how I want to use my propeller chip, and it seems like this should have been beaten to death a million times, but I can't find the specific answer to my specific question:

How does the propeller chip video generator really work?

I have a reasonable, if theoretical, grasp of the fundamentals of NTSC composite video signals.
I understand the use of the VSCL and VCFG registers, they are well documented in the propeller manual.
I understand the difference between 2 bits per pixel and 4 bits per pixel and how that affects the use of the values in the "colors" field of the waitvid instruction.
I understand how VGA mode works, and how I could use it to output parallel data on 8 pins at high speed, if I really wanted to.
I understand how I could use composite mode as a 3 bit (luminance) DAC as an arbitrary (8 level) waveform generator if I really wanted to, but it seems like I'd be just as well off using VGA mode if that was all I needed to do.
What I don't understand is how chroma really works, under the hood. I don't understand (and don't see documented in the propeller manual) how the 4 bits that determine the phase angle do whatever it is they are supposed to do.

I've parsed through 2 example TV drivers (TV.spin, and a custom one) and I see that the PLL is configured for twice the color burst frequency, but no explanation as to why.

I have also seen examples somewhere (I've been googling a _lot_ this evening instead of working on the project I am supposed to be working on, just because this has distracted me so much) that the color burst signal is generated with a 180 degree phase shift (i.e. bits 3..0 (or 4..7, depending on how you count them) of the color register are 00). If the color burst signal is simply the output of CTRA, why should it matter whether I start every line 180 degrees out of phase wrt CTRA? I guess I would have chosen, I don't know, say 0 for my reference color burst phase.

I have also seen references that state that only luminance values between 1 and 6 are legal. Another one said 3 to 6. (Perhaps that's because 1 and 2 are reserved for the blanking level and the sync pulses.)

I found this question seems to have been asked before at http://www.savagecircuits.com/forums/showthread.php?157-Learning-the-Propeller-Video-functions, and one of the answers referred to broken links in the forum:
http://forums.parallax.com/forums/default.aspx?f=33&m=419583
and
http://forums.parallax.com/forums/default.aspx?f=33&m=288732

Perhaps the answers to my questions are there, but I can't figure out how to search the forums to find those particular threads.

Anyway, I am curious to learn how the underlying hardware in the video generator really works... not because I have an immediate need to use it (and if I did, I'm sure I could use one of the various different drivers to do whatever I needed to do), but because my curiosity has gotten the best of me and won't let go :-)

Thanks for any tips folks can point me at.

--wpd

Duane Degn

I can't help much with how the video generator works but I can find your missing threads.

Here's the first one:

http://forums.parallax.com/showthread.php?119301-Video-squashed-sprite

Here's the other one:

http://forums.parallax.com/showthread.php?106036-Multi-Cog-Tile-Driver-Tutorial...

If you use "forums.parallaxinc" instead of "forums.parallax" in the original links you'd find the threads in the old forum. I just used Google to find them in the new forum after finding them in the old one. (I'm pretty sure there's an easier way of finding the posts in the new forum from the old address but I don't remember how.)

potatohead

The phase difference between the chroma output at pixel time and the color reference value determines the hue of the pixel. The brightness of the pixel is determined by the luma value of the pixel, and the saturation is determined by the chroma signal level.

Propellers have fixed saturation, there is no control over that component with the built in video generator, save for the sets of high saturation colors outside the standard palette. http://propeller.wikispaces.com has the info in an article titled "How Many Colors Can A HYDRA Produce?" I did a video capture of all the colors.

Luma 1 values are illegal. Many devices display them, but we've found some picky ones that won't. Color pixels with a luma value of 7 are also illegal, because the signal levels with Chroma exceed the spec, but we've not found any devices that won't display those. I have some home devices that do the same thing to really *pop* some colors.

You are quite right in that you don't have to use a specific color reference value. When you deviate from that, the "tint" of the display will change, with all the color values rotating through their respective hues according to the reference value you choose. Different references can impact the displayed colors as the hues the Propeller can generate are not inclusive. The value found in the Parallax TV.spin driver is in spec. Other drivers have used other values, depending on a lot of things.

You also don't have to phase shift every other scan line either, though when you don't, pixel color artifacts can be more noticable, however color dot crawl won't be. Every single thing in NTSC is a trade-off.

Effective color resolution is about 160 pixels in the safe area of the screen, with no phase shifting going on. Some drivers push that to 256 with minor artifacts. Pixels are measured in terms of their time in PLLA cycles. Anything under PLLA 8 will show significant artifacts.

Some drivers clock the PLL at the colorburst frequency, others 2X, still others 4X. It depends on how the author of the driver chooses to generate their color. It's not necessary to use the built in chroma capability. Eric Ball has written a few different drivers that have different signal characteristics and PLL clocks. That's a complex topic.

It's possible to generate all the types of NTSC displays. The spec calls for phase shifted scan lines, and an interlaced display. A full spec signal can do 320 pixels x 400 pixels or so very nicely, with moderate artifacts and a frame rate of 30Hz. From there, downgrading it in various ways may or may not have advantages.

Other options are:

No phase shift on any scan line, fixed phase shift alternating on every other scan line, alternating phase shift on every other scan line, and double all of those for vertical interlace or not. We've got a driver written for all those options. There is a subtle addition that took a while, but Eric did it in software, and that is software color not using the generator at all with color timing fixed relative to the pixels. That allows for Apple 2 type color, where only pixels are generated, their position on the screen indicating color, and two or more of them together indicating luma. That's a complex topic too. Suffice it to say, the color palette available with software methods is different from the standard Propeller color set.

All the generator does is maintain a 4 bit counter internally. When color is required, that counter holds the phase difference from the reference. Chroma is output on TV_Start_Pin + 1, or 3, depending on the VCFG mode setting. The start pin +1 is standard, and the +3 puts chroma on it's own pin, making an S-video display possible. Few boards are wired for that however. I have a few, and the right connections on a PPDB that I use for testing, and Bill Henning did one on his Propcade boards.

Hope that helps. It's really just a simple timing exercise to generate chroma.

Ariba

In this thread you find a lot of infos and even a schematic near the end of the thread:
http://forums.parallax.com/showthread.php?124349-Video-generator-docs-someone

Andy

wpd

Hello Duane,
Thanks for tracking down those links for me. I tried, but was unsuccessful/unimaginative enough.

Hello Andy,
That thread is exactly what I was looking for.

Hello potatohead,
Thanks for the info. I was a little punchy last night as wrote that post, and realized later that the whole "why is the phase initialized to 0x8" thing didn't really matter.

The part I was ultimately missing (and had nearly synthesized in my head by this morning, but the threads to which folks directed me put the finishing touches on my understanding) was that there is/must be/ a counter that is clocked by (something -- I'll get to that in a minute). The output (MSB? maybe, I'll get to that in a minute) of that counter adds +/-1 to the 3-bit luminance output (when enabled). If luminance=7, then adding +1 wraps around, which is bad. If lumenance=0, then adding -1 wraps around, which is equally bad. Hence restricting the range to 1..6.

A 4 bit "chroma" phase value is added to that counter. There is no guarantee of the relationship between the phase of that counter and, well anything else. But by fixing a phase offset to a known reference at the beginning of a video output/frame/field/line, and changing the phase offset at specific points in time, one can control the phase of the modulated signal. OK, that makes sense.

Now let's see if I can make sense of the clock source for the counter. The most obvious source is PLLA. Looking at TV.spin, I think I see that (for NTSC) PLLA is set up to run at 114.5454 MHz, which is 32 times the 3.579... MHz colorburst frequency. The MSB of a 4 bit counter clocked at 114.54544 MHz will toggle at 7.15909 MHz. I wonder if, in fact, there is really a 5 bit counter.

At this point, I need to let go of this and get on with my real project. As everybody and his/her brother/sister have pointed out on other threads, the TV output works as designed. There are lots of examples of code making it work. If one starts with those examples and tweaks them as needed things will probably continue to work. If someday I wanted to do something really different, I should just hook a 'scope or logic analyzer (perhaps even a propeller based LA) to the output pins and measure the exact relationship of which pins toggle as a function of the various video circuitry control parameters, and derive a model (involving counters, adders, inverters, AND gates, etc...) that makes sense to me.

On a different topic all together, and since I saw a reference to this question on one of the other threads, it seems to me that modulating the output signal on the 114.5454 carrier frequency should be fairly trivial. Amplitude Modulation consists of multiplying a baseband signal by a carrier. If the carrier happens to be a 114.5454 MHz square wave, taking on the values 0 and +1, then that multiplication could occur by ANDing the PLLA output with the 3 output bits. With a little bit of filtering, the output signal would probably look very much like a broadcast signal. I seem to recall something about broadcast signals being inverted from the baseband signal, but that sort of thing could be accomplished fairly trivially in the propeller hardware as well.

--wpd

ericball

I think you have it, but just are looking for some confirmation. I'll also point you to http://propeller.wikispaces.com/Video+Generator

For TV output PLLA is clocked at 16x the colorburst frequency (57,272,273Hz for NTSC) to provide both the clock used for the two VSCL counters and to clock a free-running 4 bit counter used for color output. This 4 bit counter is added to the 4 high bits of the color value and the MSB is used as the color signal.

For S-Video output the three low pins are driven by the lower 3 bits of the color value and the high pin is driven by the color signal ANDed with the color enable bit of the color value.

For composite output if the color enable bit is cleared then the three low pins are driven by the lower 3 bits of the color value. If the color enable bit is set then 1 is added or subtracted from the luma value (with wrap around). This means if the luma is 0 or 7 then the modulated values are 1 & 7 or 0 & 6 respectively which is effectively a luma of 4 or 3 respectively but with three times the chroma saturation and a 180 degree hue offset.

For broadcast video, there's an additional step to modulate the composite output using PLLB. See wikispaces for the details. You may want to investigate this further if you are trying to use the Propeller for amplitude modulation (although I've heard the frequency stability of the PLLs isn't good enough to use without some heavy filtering).

wpd

Hi Eric,
Thanks for your reply.

ericball wrote: »

For TV output PLLA is clocked at 16x the colorburst frequency (57,272,273Hz for NTSC) to provide both the clock used for the two VSCL counters and to clock a free-running 4 bit counter used for color output. This 4 bit counter is added to the 4 high bits of the color value and the MSB is used as the color signal.

My confusion arises from the fact that the first (and only, so far) two code samples I've looked at have confugured PLLA at 32x the colorburst frequency, rather than 16x.

But it's possible I'm misreading the code. (One of them was TV.spin). Regardless, when I reach the point where I _really_ need to know what's going on under the hood, I'll just hook up a 'scope or LA to the device and derive my own model for how it really works.

--wpd

ericball

wpd wrote: »

My confusion arises from the fact that the first (and only, so far) two code samples I've looked at have confugured PLLA at 32x the colorburst frequency, rather than 16x.

But it's possible I'm misreading the code. (One of them was TV.spin). Regardless, when I reach the point where I _really_ need to know what's going on under the hood, I'll just hook up a 'scope or LA to the device and derive my own model for how it really works.

Looking at my NTSC 8bpp bitmap driver & template FRQA is set to 7159090Hz with VCO / 2 PLLDIV which (combined with the x16 PLL multiplier) yeilds a x8 PLL output frequency of 57.2727272MHz. (FRQA is set is to keep the PLL in it's 4-8MHz lock range.)

JRetSapDoog

WPD, thanks for asking those questions and for asking them is such a clear and detailed manner. I must admit, when I see a long first post (with a clear title), I'll sometimes skim-read it to move on to the answers, which helps me avoid the misinformation and clutter that understandably exists when we ask questions in the forum, thereby allowing me to focus more on the answers than the speculation that often exists along side the questions. But your post was exceeding clear and interesting to read/consider. So thanks again for asking (not that every original post must be that clear). And thanks to those on the forum for the insightful answers. For example, Potatohead is a first-rate Educator here on the forum with the generous amount of detail he provides. Analog video is one of his specialties, which must also be the case for Ericball, too, with that wonderful colorburst/colorbar avatar. Thanks for those replies everyone.