Defining new color palettes

MachineMonkey

Is there an option to define your own color palette? I'd like to create SMPTE color bars using the PChip, but the existing HYDRA color palettes are a bit off, especially in the yellow range. I'm still scouring The Book for references to this and I haven't sat down and plodded through it, one chapter at a time--I know, I know...do this first, because I'm hoping to deal with this hurdle first.

Thanks,
Kalo

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Failure is not the only punishment for laziness; there is also the success of others.

- Jules Renard

Ym2413a

Sorry but the Propeller only has a 1-bit saturation control.
So either your saturation is 0 IRE peak-to-peak or 40 IRE peak-to-peak.

The saturation is always 40 IREs while saturation bit is enabled (-20 IRE / +20 IRE from LUMI center).
Though I'm working on ways to get around this and generate more colors from the chip. (While trying to keep the currect 3bit DAC design).

Really my reason for doing so is because from an artistic viewpoint... The fixed color saturation lacks contrast between vivid and muted tones. (which don't exist in the current palette)

--Andrew Arsenault.

MachineMonkey

I'd be willing to sacrifice a few I/O pins for more saturation. Is there a way to increase the saturation via a discrete DAC? I wouldn't mind throwing an external chip at this if it gave me a bit more range.

- K

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Failure is not the only punishment for laziness; there is also the success of others.

- Jules Renard

Ym2413a

Yes, an outside chip could help.

I know that I've mannaged so far to get the Propeller to generate saturations of 40 IRE, 80 IRE and 120 IRE.
(120 isn't the most legal value and shouldn't be used).
Really the Propeller could do much more with a better DAC and two COGs.

Here's a good page on test signals.
www.gekco.com/vidprmr.htm

For the color bars it looks like you'll need saturation values of:...
x0 IRE. White
62 IRE. Yellow
88 IRE. Cyan
82 IRE. Green
82 IRE. Magenta
88 IRE. Red
62 IRE. Blue
x0 IRE. Black

--Andrew Arsenault.

AndreL

You can defintiely do this with a dac lookup outside, or syn 2 cogs together and let their outputs sum. Although, I think that if you start to do these things, probably just better to take a $5 FPGA and make a video controller with 8 bit sat and 8 bit chroma, that feeds from a shared memory or has internal tile memory that you access over a 10-11 bit port from the propeller to the FPGA.

I have made a few hardware mods to the propeller to do this stuff, but the thing I like is if you can live with what it can do stock that's pretty cool, once you start adding more hardware to the video stuff then its like you might as well use another chip.

But, definitely use 2 cogs sync'ed and then summing outputs will work for more chroma as long as the phase relationships are the same.

Andre'

Ym2413a

I say just build a better DAC and use two cogs to control it. If you need the SMPTE color bars.
50 cents in extra resisters doesn't cost a whole lot.

I'm interested in doing the most with the current 3bit DAC since it's stock on two common boards (Hydra and Demoboard) and since a lot of home brewers made the same thing on their hockups.

I agree with Andre though, I feel that if you start adding extra chips and active components like a RAMDAC. It sort of defeats the purpose of the Propeller and most other embedded microcontrollers. The Propeller was designed to do the most with the least around it.

One thing is for sure... The stock propeller doesn't have the saturation control needed for accurate SMPTE without a trick or two.
--Andrew Arsenault.

MachineMonkey

I see the point about switching gears to the FPGA side of things, but the CBG is just the main purpose of my project. I want the user to have the option of several test screens and a couple of games (each with respective balanced audio out). Plus, I don't want to buy or build (or find desk space for!) another programmer. I'd like to keep the solidstate hardware minimal; say, a voltage regulator, the PChip, a video buffer and an audio buffer, a handful of discretes, switches and maybe a DAC. I don't think I'm prepared to wring the versatility I want from anything but an MPU. And becasue these are the chips I've settled on for the foreseeable future, that leaves the SX and the PChip.

So...Andre', what sort of major points would I need to consider to get these cogs synced through the DAC? I assume one cog runs the high bits and the other the low bits. Any major trials in syncing 2 cogs in this way? I haven't done any multiple cog stuff yet, so my ignorance is probably showing.

Andre', I was just looking over the posts before sending this and noticed you actually had 2 suggestions. I'll try them both to see which (or perhaps if a combination) works for this case; to clarify, when you say "...DAC lookup outside...", is this the same as feeding 2 cogs worth of outputs into a DAC?

Thanks guys,

Kalo

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Failure is not the only punishment for laziness; there is also the success of others.

- Jules Renard

Paul Baker

Perhaps Andre is thinking of another setup for the summation, but I would think you would have two seperate DAC ladders (one for each cog) where the output of each is tied together. This is because the output of any pin is OR'ed from all cogs which have the pin set as output (which won't produce the desired effect). The goal is to generate two seperate sinusoids individually and sum the results together, this produces a sinusoid of double the amplitude whose phase has a direct correlation to the difference of the phase of the two individual sinusoids. Since it's the phase of the sinusoid (with respect to the color burst) which determines the chroma component, the sum of two sinusoids produces a greater granularity of the phase (and hence a greater number of colors) of the final sinusoid.

You can look at Chip's newer VGA drivers which use multiple cogs to get ideas for synchronization, I also know that some of the video drivers written for the Hydra use more than one cog, so there is synchronization within those as well.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

Post Edited (Paul Baker (Parallax)) : 2/8/2007 9:32:25 AM GMT