Shop OBEX P1 Docs P2 Docs Learn Events
Ternary Video DAC for More Colors — Parallax Forums

Ternary Video DAC for More Colors

The standard Propeller composite video output circuit consists of 3 resistors of 270, 560, and 1000 Ohms. When connected to 3 output pins this circuit is able to produce 8 distinct output voltages. This is what we expect because 2^3 = 8.

The good: If we add high impedance to the output high and output low states used previously we have 27 unique output states. ( 3^3 = 27 ) There are 8 states that result in 0 volts at the output. In total, we have 20 unique output voltages possible from the circuit.
ternary-dac.png

The bad: The linearity is not so good. It's not obvious how to generate the output state for a given voltage. The easiest way is to compute all 27 states and sort by voltage. A look-up table can solve both of these at the same time. :cool:

The ugly: The video generator doesn't drive DIRA. We would have a bit-banged video driver. It would be best to update DIRA and OUTA simultaneously. One way to do this would be to use one cog for the output high and another for the output low. That way they can have OUTA constant and just update DIRA. They could read the same data and just use a different look-up table. We would have to generate the chroma subcarrier in software. On the bright side, the 80MHz system clock would give more phase resolution than the 16x clock used by the video generator.

Implementing this in the P1v would solve most of the uglies. We could just modify the video generator to let it drive DIRA as well as OUTA. But, without a proper PLL the P1v likely doesn't produce such good quality video.

If I missed a previous discussion about this, please let us know.
1024 x 558 - 61K

Comments

  • Really interesting idea James. I wouldn't have guessed those extra values would fall in such a linear fashion

    Yes you're right P1V would make it easier to implement
  • More colors = more better. :D

    Can you post a state table showing all values, including zero values?
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2018-04-24 19:07
    As long as you're using two cogs, you might as well add a couple more pins with higher-valued resistors, and just drive the OUTs with the video generator.

    -Phil

    Edit: Synchronizing the two PLLs might be a little tricky. :)
  • MIchael_MichalskiMIchael_Michalski Posts: 138
    edited 2018-04-24 20:33
    I'm not sure that the extra colors do you any good compared to the way the video generator already works. Typically you have a pallette of 64 colors in the "typical" implementation.

    Another option could be to trade resolution for colors. Imagine you want a color display in 320x240. So you setup display of resolution 1280x960. Each color is active low and connected to a capacitor through some resistors and a diode. When the pixle switches low, it discharges the cap through the resistor. As the four pixles go by the capacitor dicharges. Every four pixles, there is a clock pulse , active low, from a timer. That rapidly discharges the capacitor, it just connects directly to the pixle through a diode. There might be a rainbow effect across the pixles, but it should either together into a friend of color since the pixles are small. You could also reduce the bandwidth of the monitor with an extra filter across the color pins if needed.

    So now, with the "typical configuration" of 2 lines per color, and two for h and very sync, you can choose (just not all at the same time) between 64 colors. So you blend 4 64 color pixles together. Or perhaps bit bang v sync and use a timer for h sync , allowing all 8 lines to be used for color. You won't get the full range of colors for the bits your sending, but it will be more than you would have without it. If your carefill you might be able to exploit the charging curve of the capacitor.


    It's easy to see though, some color values are degenerate. Consider a simple two color non indexed system. So each pixle is just on or off, and set to black and some arbitrary color via a resistor. Consider averaging only three pixles. We have 4 colors. Off, 1 bit period discharge, 2 bit period discharge and 3 bit period discharge. So 001, 010 and 100 are the same color, as are the 011,110,101. Maybe adding a discharge resistor might help, so that 001, changes say to 1/3, then discharges 1/4 per pixle. The spacial extend of the "rainbow" effect might change theperceived color as well.
  • With NTSC, none of that is actually needed. Just crank the resolution, and output the colors you want to mix. That will happen.

  • "NTSC: Never The Same Color"
  • Yes and no. The same phase relationships to line sync timing do produce the same relative colors. The actual will depend on where one has placed the tint knob.



  • MIchael_MichalskiMIchael_Michalski Posts: 138
    edited 2018-04-25 00:46
    vastly better on modern televisions compared with the old 1970s models. I remember trying to adjust the horizontal hold and getting the color adjusted when I was a kid
  • Tubular wrote: »
    I wouldn't have guessed those extra values would fall in such a linear fashion
    They don't. I've yet to figure out any theoretical way to compute the output states required.

    Changing the load resistance can cause the ordering of the states to change. This could be inconvenient for some applications. But who really wants to complain about extra output voltages? The Propeller color chart looks good already, but it could use more gray levels. It might be reasonable to modify DIRA to get different grays.
    potatohead wrote: »
    Can you post a state table showing all values, including zero values?
    ternary_chart.png


    I've attached the spreadsheet to everyone can play.
    1038 x 953 - 123K
  • It's tough to generate reasonable resolution video without using the video generator as you have only ~1000 instructions to generate the active video. I also wonder what the effective bandwidth is for DIRA.

    In addition to adding the ability for the video generator to update DIRA, you'd need to modify the WAITVID instruction to add a CLUT between the color bytes and the video generator.

    But the 3 bit DAC isn't the limitation for NTSC colors - my 240H sprite driver has a gamut of 172 colors by clocking the video generator at 4x colorburst and generating the color signal directly. The real issue is how the video generator creates color with +1/-1 on the luma value. You'd need to provide additional options for the color intensity to have any real impact. Otherwise you're just increasing the number of grays rather than the number of colors.

    You may also be interested in https://forums.parallax.com/discussion/126099/more-colorful-baseband-tv

  • Good ideas, Eric. While reading your wall post I realized that the 8 bits per color is not a hard limitation for P1V. For 2 color mode, we could use 16 bits to describe a color without changing much. For 4 color mode, we would need to add another long to store the color data. This would require an extra read cycle. It shouldn't affect the programming much. Colors is read from the d-field so it can't be a literal.

    I found a simple rule to generate the ternary dac states: For binary states 1-6, setting DIRA to the same value as OUTA will add a half step. (Instead of outputting low, tri-state the zero bits.) As before, the ordering changes when the load changes.
    ternary-dac-simple1.png

    I think increasing the number of gray levels is useful. Although I probably won't do anything with this work. It's amazing that after over 10 years that there are still tricks to be found.
    1256 x 1039 - 106K
  • I was thinking more about how to add more TV colors to the P1V. I believe it is possible even without changing the existing 3 bit DAC or tristating the output.

    As I mentioned, the main limitation is how the color signal is generated as luma +/-1. My idea is to make more effective use of the color byte and expand the range of color saturations.

    $00 - $07 would still drive the DAC directly to produce sync and 6 shades of grey. However, instead of using $x8 - $xF for color, instead use $1x - $Fx, with the most significant nibble selecting high and low output values which the phase generator would then alternate between.

    One other enhancement I would suggest is to use VCFG[31] to select between adding and subtracting the phase portion of the color byte from the phase counter. This would then be used for PAL to alternate the color phase between lines rather than performing the ones complement on the color byte.
Sign In or Register to comment.