Tricks to improve TV output quality ?
aderfy
Posts: 6
Hello.
I have built my own demo board, based on the propeller demo board schematics, and I'm experimenting with the TV output. I must say that I'm a bit disappointed about the output quality, I understand that I can't get the quality of a broadcast transmission, but I was expecting a bit more. Maybe the schematic is not correct or there is some trick to improve the output quality ?
For example, I'm trying to understand the color scheme and build a simple 8 or 16 colors palette. I have readed the documentation, I know that it is a combination of hue and luminance. I have found some indications on the internet, however none of the color schemes I found seems to work as indicated, for example this one http://www.rayslogic.com/propeller/programming/TV_Palette_indexed.png doesn't results in the same colors: 08 seems equal but 18 to 38 are just shades of green, it isn't even near the colors in that image. I also tried to use the values from the Hydra game development manual but they do not correspond. Also the TV_Terminal_Demo.spin should display a green text, but it is not, it some undefined color. My feeling is that something is missing.
Is there some trick to improve the quality ? Maybe the resistors are wrong (I'm using 1% resistors, same values used on the schematic, 1.1k, 560 and 270, no aural subcarrier pin) ? The output should be in PAL, I found very few examples in PAL.
Any help will be greatly appreciated.
Regards.
I have built my own demo board, based on the propeller demo board schematics, and I'm experimenting with the TV output. I must say that I'm a bit disappointed about the output quality, I understand that I can't get the quality of a broadcast transmission, but I was expecting a bit more. Maybe the schematic is not correct or there is some trick to improve the output quality ?
For example, I'm trying to understand the color scheme and build a simple 8 or 16 colors palette. I have readed the documentation, I know that it is a combination of hue and luminance. I have found some indications on the internet, however none of the color schemes I found seems to work as indicated, for example this one http://www.rayslogic.com/propeller/programming/TV_Palette_indexed.png doesn't results in the same colors: 08 seems equal but 18 to 38 are just shades of green, it isn't even near the colors in that image. I also tried to use the values from the Hydra game development manual but they do not correspond. Also the TV_Terminal_Demo.spin should display a green text, but it is not, it some undefined color. My feeling is that something is missing.
Is there some trick to improve the quality ? Maybe the resistors are wrong (I'm using 1% resistors, same values used on the schematic, 1.1k, 560 and 270, no aural subcarrier pin) ? The output should be in PAL, I found very few examples in PAL.
Any help will be greatly appreciated.
Regards.
Comments
Also for PAL I think that there might be a more optimal crystal value that can be used. I think 6.25MHz rather than 5MHz but I need someone else to confirm that.
-Phil
I beleive that the NTSC is better, but then PAL was a complication of it.
I have found that if you try to fool the system by telling it that the Xtal is plus or minus a bit,- 500Hz in my case, then the beating of the blue background could be minimized if not cured. you will never get the subcarrier to horizontal relationship (1135 ....) right.
Hey at least the chip gives video, in lots of different flavours too :-)
The thing with NTSC is it's easy, and far more flexible in the signal options than PAL is. For the Prop, this works out to a wide variety of methods to generate TV. NTSC is more exploitable than PAL is, generally speaking.
Have you tried putting a 191R to ground (across the TV connector on your prop board)? Anything above 191R will do. This terminates the output impedance. There area few threads discussing this, including a recent one that discusses VGA values (last week or so). This has a table of correct values for VGA and TV. I have reposted here for your convenience. Please let us know what you find.
A picture says more than a thousand words!
Here is the thing: I started with the PAL_colorbars.spin source because it outputs the full colors (not a palette for 16 or 32 pixels), with this source I can't get a reliable color mapping with the tables I found (the bitmap link I posted early or the tables in the Hydra programming manual). After reading your answers, I tried the Graphics_Palette.spin from the properller tools, and it worked, the colors are what I was expecting. Looking at the source, I see several differences, first, if I'm not wrong, the TV.spin doesn't do phase flipping for PAL while PAL_colorbars does phase flipping, more TV.spin does phase flipping for NTSC, as far as I know phase flipping is for PAL only (Phase Alternate Lines). I think these are the difference I see in the colors output.
So my question is: who is correct here ? TV.spin or PAL_colorbars.spin ?
Regarding the crystal: I'm using a 5MHz crystal, this one to be precise: http://www.digikey.it/product-search/it?x=0&y=0&lang=it&site=it&KeyWords=300-8475-nd
looks like the correct type to me, anyway, the trick to change the _xinfreq a bit worked, things are a bit better now, still some squiggles but looks better.
Using a 6.25MHz crystal isn't out of spec ? What if I use a 4.433618 crystal ? It should be perfect for PAL outputs, maybe a bit slow overall (70MHz with pllx16 instead of 80MHz) but should not be a problem.
@Cluso99
I saw the thread about the resistors but I didn't noticed the values for composite, I'll try that.
Thanks you all for your suggestions.
A picture says more than a thousand words!
On NTSC it's actually in the spec, but optional to implement. Maybe Eric Ball will chime in here at some point. On PAL, the phase flip is mandatory as the color displayed is an average of two frames. The advantage PAL has over NTSC in this is very little color "dot crawl" where fringes can be seen on color boundaries that have a significant angular difference on the color wheel. That and the higher color burst frequency means much improved color resolution over NTSC.
NTSC phase flip impacts the pixel position on screen, allowing for interlacing horizontally as well as vertically. Doing that generates dot crawl and flicker, but the perceived resolution is much higher. Great for pictures, not always so great for text. We've done lots of different NTSC drivers, with Eric contributing significantly to this. Many variations on the signal output are possible, and it would take a lot of text to describe them. As I wrote earlier, NTSC is highly exploitable, resulting in considerable variation in driver signal output quality and pixel characteristics.
As far as the color value differences go, a lot depends on the color burst reference color used. Because Propellers do software video, with some light hardware assist from the video generator and waitvid instruction, the actual signal details are up to the programmer. If you look at the part of the driver that outputs the color burst, you can see what value is used for that reference. Different values will "tint" the display differently, shifting the palette much like just turning the "tint" knob on a TV would do. I don't think I've seen an NTSC set that doesn't have a tint control. It's my understanding many PAL sets actually don't!
In any case, that's the primary reason for color value differences.
A secondary reason is how the programmer chooses to implement color. When raw values are used, as in values fed directly to the Propeller from RAM, black is actually the value $02, not $00. The entire signal is encoded as colors as far as the Propeller is concerned. Using the wrong values could result in a sync pulse being visible on screen. This happens with some color values, unless corrected for by the programmer. If the driver employes some correction, the values may or may not equate to the same color seen on the screen.
Short answer? Both drivers are correct! It's just a matter of implementation and understanding how a given driver does it's color. There are a LOT of ways to get that done on NTSC, and fewer ways on PAL, but still enough to produce variances.
Re: Pictures.
They do help considerably when discussing this stuff. Many small details take a considerable amount of time to discuss, and often that discussion isn't indicative of what really is going on.
http://forums.parallax.com/showthread.php?99657-Spintris-NTSC-PAL-video-game-for-Propeller
I can explain why that looks so excellent...
You are not changing the color phase (chroma), only the luminance level, within your individual graphics. Plus, you go to black before changing the chroma (any grey level would have the same effect). This looks good on the Propeller because it can only output square waves, and does not gracefully make chroma changes like a real analog video source would, where a sinus shifts in phase. You can imagine how coarsely square waves transition in phase - you get extended pulses going one way and glitches going the other way. The TV hates it. There is another limitation of the Propeller where you get 16 chroma phase possibilities, and 5 luminance possibilities, but no control over the chroma saturation - it's fixed at a certain level. That's why you can't get a good yellow.
The Prop II will overcome these limitations by allowing you to set 9 matrix coefficients to define any color space, providing all the luminance, chroma, and saturation information for any 8:8:8 RGB color. Plus, it has a CORDIC rotator to compute a precise sinus, instead of muscling everything with square waves. It's way easier to use, due to the RGB color control, and assembly language video drivers will be much smaller, due to a way better shifter.
That the original Propeller does video was a stretch and something to reach for, at even a low level of performance. In the Prop II, video gets much better treatment.
In summary, to get good TV graphics on the Propeller, follow these rules:
1) Only change chroma phase after some grey-scale (black..white) pixel(s).
2) Once you begin displaying a certain chroma phase, you can modulate the luminance all you want.
3) Following rules 1 and 2 will allow you to nicely display white or black text pixels within a colored line.
4) Small chroma changes CAN be made in adjacent pixels without much degradation.
Yeah, we are sure pushing the P1 way beyond your wildest expectations... and we are still discovering ways to push it even further
Now.. Get back to that P2 ! Ken, put him back in his cage
First, you should to double check your circuit. You need three resistors 1.1kOhm (P12, DIP #17, QF #13), 560Ohm (P13, DIP #18, QF #14) and 280Ohm (P14, DIP #19, QF #15) tied to the RCA center pin. There have been a few forum posts with change recommendations and using resistor networks (e.g. as shown in cluso's post). It is also possible to use different pins but it must start on a multiple of 4 and will require changes to the video driver (typically to the input parameters).
So my question is: who is correct here ? TV.spin or PAL_colorbars.spin ?
TV.spin. Although I've tried to make PAL templates, I've never been 100% successful. TV.spin produces a better, more stable, image than I ever managed.
I have attached a modified version of colorgrid.spin from http://forums.parallax.com/showthread.php?126099-more-colorful-baseband-TV&p=943709 which uses TV.spin. I haven't tested it out and I'm hoping I've modified everything correctly. The image might not be 100% stable due to the Y=1 line of colors.
You might be able to get better results using a colorburst crystal, although you will probably need to modify TV.spin to hardwire the FRQA value.
Regarding phase flip; for NTSC the colorburst phase flips between frames which is used to identify four fields for VBI data like closed captions. It probably also has a minor impact on the signal characteristics & interference rejection. But NTSC color is easy because it's always WRT the colorburst for the line.
PAL is much (much) more sensitive as color is a combination of the current and the previous line.