more colorful baseband TV
ericball
Posts: 774
As I suggested in http://forums.parallax.com/showthread.php?t=123324, the auralsub pin on the Demoboard (and others) can be used to increase the number of colors which the Propeller can display in baseband composite mode. Attached is a modified version of TV.spin which uses this idea and a demonstration program which displays a color grid using both TV.spin and my TVplus4.spin.
Comments
What resistor value should one use on the aural pin?
Is it the standard 560 Ohms?
Wouldn't it be better to use something like 100 Ohms for a better DAC ?
The standard auralsub resistor is 560ohms, and that's what's on the Demoboard. Yes, a lower resistance (400ohms) would allow Y=0 to be pushed up to blank, rather than blacker-than-black.
A bigger improvement would be to have the 4th pin be a higher resistance (i.e. 750ohm) then use S-Video mode for burst only. (And add a 5th pin at 400ohms for sync/blank.) That would mean the saturation of the colors would be 50% more.
I'll do a capture or two later today. Can't wait.
@Eric: Can you refresh me on S-video mode settings and output? I was looking for this the other day, and can't find it.
It worked for me mostly even with the 4th resistor value too high; it did lose sync periodically though (impedance mismatch artifact?). It seems very nice for a tile driver display ... maybe someday a 256 color small pixel raster driver with fast external memory would also work.
Cheers.
@rokicki - I haven't replaced my PCI capture card after upgrading.
@potatohead - 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.
@jazzed - The Video Generator is only capable of 136 colors. My changes are exclusively to the output, not the tile descriptions. It is certainly possible to use external memory for video, the limitation is bandwidth and concurrent access.
I can confirm that many TV's won't tolerate the sync level in the display. The worst place for it is early or late in the scan line. Many TV's will latch onto that in a irregular way. If those levels are to be used, put them in the middle, and don't make 'em too big.
(found that out with the potatotext color table)
Re: Colors... Many more colors are possible, even without the changes here. Artifacting can deliver 1K colors easily, at a resolution of 160 pixels in the safe area. See the Wiki. There is a screenie with 400+ there, and I didn't use the high sat colors, which would have more or less doubled that performance.
Ram is at issue, as always. On PAL, and to a lesser extent NTSC, there are some other schemes that can produce more than 160 colors, at a higher resolution. They use vertical banding, and can look very good, depending on what is done.
Getting setup for some captures now... (grin)
I'm liking this mod actually. Been struggling with project throughput time right now, and honestly, I think it makes great sense to optimize this TV.spin Lots of stuff works with it, and a few "modes", in particular a "scan buffer" mode, would make porting lots of stuff easier, and it has the PAL support, which has been sort of kicking my ***. (potatotext timings are very NTSC dependent, and I've been just stalled on a rewrite of that whole thing)
The first two are PAL. New color generation code first, from the left.
Thanks Doug. The ones with the + in the corner are using TVplus4.spin while the others are using TV.spin. The TV.spin picture might have sync issues due to the 1 line (note: just the colors are 1, Y=0 and Y=1 display Y=2), the TVplus4.spin picture might have sync issues (or other corruption) due to the PWM.
Need to run on a few TV's to see where it's really at.
Oh, and it was a $%(#$&%($% cable! Not software, not the capture device. Easy fix.