S-Video Display Test
potatohead
Posts: 10,261
I'm circling around to do the next round of fixes and features for the Potatotext 2 driver, written for Bean's Embedded BASIC.
1. Changed the 2-color mask generate to happen AFTER fetching the HUB parameters. Thanks kuroneko!
This means you can edit the video configuration settings in the hwdetect method for your board, bypassing it entirely, if desired, and those changes will be reflected properly in the TV driver. They weren't before.
2. S-video and monochrome display options.
This is where I am right now, and I've a coupla observations to share. It's pretty easy to make a circuit where either the fourth resistor is connected to start_pin+3 as part of the DAC, or just connected directly to the chroma input of a S-video capable display.
Did that today with the PPDB, just moving a lead from one row to the other, where I had a 570 ohm resistor connected to the chroma line on a S-video cable, so I could just connect the reference DAC, or break off start_pin+3 to the separate chroma line for testing.
Normally, the chroma signal is mixed into the 3 pin DAC. It can be output on start_pin + 3 with the following info Eric posted some time back, that I find difficult to remember and not obvious from the datasheet:
if Chroma0 (VCFG[26]) = 0 and the VPins[7 or 3] = 1 then the color PSK is output to pin 3 or 7 rather than being mixed into pins 0-2.
So there it is for archive purposes.
When I did this last time, looking to advance the driver, I had sync in display trouble, thinking I had made some coding error. Today, I found the source of the trouble. When running in composite mode, the Prop will output high saturation colors for some values. When running as S-video, those same values result in sync levels in the DAC!
Normally, the color signal, when added to the luma one, results in a level that is not sync, but when the chroma and luma are output on their own channels, this does not occur, meaning you've got to watch your color values. Not all of the composite values will result in a viable display.
The attached code is modified for demoboard @ 80, and is just here for anyone who wants to tinker a little. I'll finish the features and fixes and post that a bit later.
If you run this, use a demoboard video circuit, with start_pin+3 not part of the DAC. On my PPDB, I simply used the reference video DAC on the board, and added the 570 ohm resistor, so I could move a jumper from the prop back and forth between the two.
When configured for S-video mode, the luma channel will display sync in the display with the test data given, when the S-video circuit is used. If you go ahead and connect start_pin+3 to the dac in the usual way, this code will display fine, with some slightly different colors than would otherwise be seen.
On a S-video display, it won't work, without first changing the color values. Comment out "testdata2" in the start SPIN method program to accomplish that.
The upside out of this test is that 64x50 color on a good capture card or TV will be usable. 80x50 monochrome will be usable.
That's the last major change to this code, once I get the S-video color differences accounted for.
1. Changed the 2-color mask generate to happen AFTER fetching the HUB parameters. Thanks kuroneko!
This means you can edit the video configuration settings in the hwdetect method for your board, bypassing it entirely, if desired, and those changes will be reflected properly in the TV driver. They weren't before.
2. S-video and monochrome display options.
This is where I am right now, and I've a coupla observations to share. It's pretty easy to make a circuit where either the fourth resistor is connected to start_pin+3 as part of the DAC, or just connected directly to the chroma input of a S-video capable display.
Did that today with the PPDB, just moving a lead from one row to the other, where I had a 570 ohm resistor connected to the chroma line on a S-video cable, so I could just connect the reference DAC, or break off start_pin+3 to the separate chroma line for testing.
Normally, the chroma signal is mixed into the 3 pin DAC. It can be output on start_pin + 3 with the following info Eric posted some time back, that I find difficult to remember and not obvious from the datasheet:
if Chroma0 (VCFG[26]) = 0 and the VPins[7 or 3] = 1 then the color PSK is output to pin 3 or 7 rather than being mixed into pins 0-2.
So there it is for archive purposes.
When I did this last time, looking to advance the driver, I had sync in display trouble, thinking I had made some coding error. Today, I found the source of the trouble. When running in composite mode, the Prop will output high saturation colors for some values. When running as S-video, those same values result in sync levels in the DAC!
Normally, the color signal, when added to the luma one, results in a level that is not sync, but when the chroma and luma are output on their own channels, this does not occur, meaning you've got to watch your color values. Not all of the composite values will result in a viable display.
The attached code is modified for demoboard @ 80, and is just here for anyone who wants to tinker a little. I'll finish the features and fixes and post that a bit later.
If you run this, use a demoboard video circuit, with start_pin+3 not part of the DAC. On my PPDB, I simply used the reference video DAC on the board, and added the 570 ohm resistor, so I could move a jumper from the prop back and forth between the two.
When configured for S-video mode, the luma channel will display sync in the display with the test data given, when the S-video circuit is used. If you go ahead and connect start_pin+3 to the dac in the usual way, this code will display fine, with some slightly different colors than would otherwise be seen.
On a S-video display, it won't work, without first changing the color values. Comment out "testdata2" in the start SPIN method program to accomplish that.
The upside out of this test is that 64x50 color on a good capture card or TV will be usable. 80x50 monochrome will be usable.
That's the last major change to this code, once I get the S-video color differences accounted for.
zip
25K
Comments
Yep, as I've noted in the past: with S-Video you lose the high saturation colors. The high saturation colors occur because the +/-1 causes the output value to wrap around: Because the saturation is negative, the colors are 180 degrees out of phase from the normal saturation colors.
This is S-video mode, by the book. Make the following changes to graphics_demo.spin
'normal composite mode, demo board @ 80 Mhz long %001_0101 'pins long %0000 'mode 's-video long %001_1101 'pins 'enable output on start_pin+3 long %0100 'mode 'do not output chroma signal mixed into baseband lumaIf you want "monochrome mode" without having to redefine colors, or kill the color burst in the signal, just make the second change shown above, and be sure you don't select the high saturation colors in the display.-001 and -002 are S-video captures on a rather average capture card, and represent what most TV display devices will do with this signal, assuming they are not a half-resolution device, like some lower pixel count LCD's are.
-003 and -004 are composite captures, where smudging and display artifacts can easily be seen. Again, the monochrome composite capture was done by shifting the chroma to start_pin+3, and not enabling it as a output pin. On most boards built with the reference video circuit, there isn't any real change in the display, because the resistor is wired to the DAC.
The last screen shot shows a reference video circuit running with the S-video configuration turned on.
Display artifacting limits are clearly seen on the stars.
I didn't see a significant difference in display quality between both the usual composite setup and the composite circuit, with S-video configuration, suggesting that a simple jumper or switch on a board could easily toggle between the two, depending on the code somebody wanted to run, and the color data in use.
-005 was captured on the reference circuit, composite input attached, S-video code configuration.
64 and 80 columns shown, monochrome and color.
IMHO, it's time to get text drivers S-video capable!
In the screen shots above, I did not chroma challenge the TV much at all. The text is monochrome. A red on blue or green character wouldn't render well at 80 characters. Colorburst is too low of a frequency to encode that.
The capture card used here is a normal definition one, and reflects most average TV performance. My good one is not usable at the moment, due to a system disk crash. Gotta build up another machine.
When I get that done, I'll probably do a few more demonstrating what HD capable devices do with this signal. There is a lot of processing! My CRT TV will render about what you see above. The Plasma can do most color combinations correctly, even though the signal limits are clearly below that. So will the HD capable card.
Wonder how they do that?