Extended Video Hardware

Mike Popoloski

Well, I just about finished designing my own game console system (seems like everyone is doing it nowadays) and I have a few extra I/O pins on the Propeller left open, as well as the EEPROM and Programming pins in case I need more. I was wondering if there was a way to add extra hardware to these pins to help increase the amount of colors that can be output to the TV screen (NTSC). I saw a project on these boards that had a dedicated Propeller as a graphics chip, and there was extra hardware attached to help generate colors. I was wondering if anyone could provide some more information on this topic, and maybe give some advice on how to spend my extra ports.

deSilva

Increasing the number of colors for TV is extremely tricky. The projects I know of use VGA. There are a lot of posibilities here. Using two synchronized cogs will give you 4 lines per RGB = 4096 colours. Three R/2R ladders or just extending the three current DACs with 1k and 2k2 k resistors will be a simple possibility.

---
Edit: PropGFX that's a completely independent hardware approach. You can "duplicate" some oft hat, but need a separate "color generation chip" anyway. Baggers/Coley use much (most?) of the processor power of their separate Propeller to drive their video.

Post Edited (deSilva) : 1/9/2008 12:28:19 AM GMT

Mike_GTN

Hi Mike,

I wonder deSilva if he is thinking about the PropGXF project being worked on by Baggers and Coley at present. Gosh feel like a person on a desert Island as can not provide any Parallax links to this from here. There is an external site www.propgfx.co.uk/forum/Blah.pl with some details of the work being done by them.

I hope this is of some help.

With regards

Mike.

Paul Baker

Most of the higher colors NTSC drivers achieve the higher color by overdriving a pixel, so instead of using a single color for a pixel, half of the pixel is illuminated by one color and half of it is illuminated by another color. Since it's a signle pixel the two colors are averaged together. But you dont get a 64*64= 4096 colors because very dissimilar colors do not mix very well.

Extra I/O will not help the situation because NTSC encodes the color information via the phase of the signal.

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

Parallax, Inc.

Tnt9

Well, couldn't you run the Propeller at a frequency that is a multiple of the NTSC color carrier, like the processors in the home computers of yore? Then, you keep a small sine table in the cog memory, and read it out to a slightly better DAC (I 've seen that you can get 8-bit machine-trimmed resistor ladders) with a counter. So you could vary the hue (phase) just by modifying the index, with better precision.

An interesting link: http://www.rickard.gunee.com/projects/video/sx/howto.php

Phil Pilgrim (PhiPi)

Another option for NTSC would be to jiggle the PHSx register of the clock used with WAITVID, thus shifting the colors for one line or section of a line. The pixels will shift left or right, too, but probably not perceptibly. You just have to make sure to restore the timing again before the next color burst, as those have to be in phase with each other.

-Phil

Baggers

Mike,
If you're thinking of something like the PropGFX, but doing you're own RGB with extra hardware, and you're doing it yourself,

You'll need a good few IO pins free depending on how many bits you want for rgb, + sync + probably 2 for clock and pal/ntsc switch

If you're using a device like AD724, unless you're using a real clock, not generating one. propgfx is 15bits for RGB 1 for sync and two for clock + pal/ntsc so 18 pins was used for PropGFX,

How many io's do you have spare?

Jim.

VIRAND

What if you put a DAC (1K and 2K resistor ladder) on the VGA port with an RCA video out,
and clock out luma bytes at 14_318181 Mhz? (3.57954545 Mhz x 4)
Seems to me you'd have an RGBYRGBYRGBY like sequence with almost a longful of possible colors
diverse enough to apparently not be missing any, based on 256 luminances (incl sync levels) per primary color phase.
Can the Prop Video generators send 14 MBps out the VGA port?

Lets ignore the memory limit and assume the cogs are busy at full speed with a clever video synth demo,
like a colorful tunnel zoom.

deSilva

This is a nice idea..You will get four hues only, but with a lot of intensity levels...

The limit of the video logic is the time it needs to deliver data (see the last chapter of my Machine Language Tutorial for examples).

In 4-color mode you can output 4 different bytes per LONG, using the sequence $11_10_01_00
which means you have to deliver a WAITVID each 260 ns, which are 5 instructions, one of them being the WAITVID itself.

I see not much chance for one COG alone... it will need a god sync of at least 2 COGs to display something useful...

VIRAND

I forgot to explain that this is in NTSC, and the four hues will certainly mix, since they correspond to the
four quadrants of the color subcarrier, and produce predictable mixing, such as red and green make yellow,
green and blue make cyan...

(I'm talking about generating full color NTSC in VGA mode of the cog video generator)

this is how NTSC works except for a minor difference in phase which could be corrected,
which is that the phases are called +I,+Q,-I,and -Q, which are close to RGBY but not quite,
I think "+I" maybe the colorburst which looks green if its in phase on the screen, and "-I" is very orange.
This won't be a problem though since you can still get all the same colors even without changing from
colorburst sync (and I and Q) to RGBY phases.

Whether you call this artifacting or not it doesn't matter the results are the same.
I and Q mix together to make a correct color wheel because sin(x)+cos(x)=1... a circle of radius=one.
Same as X squared plus Y squared = circle of R squared for all X,Y, and R.
In other words, Full Color NTSC, not limited to four hues but all points in between.
R represents Saturation, ATN(X/Y) or ATN(I/Q) represents Hue,
and the numbers actually transmitted are the Luminances of the 4 certainly-combined hues.