Multi cog and 1 display?
grasshopper
Posts: 438
Forgive me a bit if this seem as an ignorant question, but could I run 2 or 3 cogs on one display as long as I use an OR gate. I was thinking that I could do some type of video overlaying or at the least improve video performance.
This is just a thought so what do you think?
This is just a thought so what do you think?
Comments
Some of the high resolution VGA displays use more than one cog. They take turns building groups of scan lines. While one is outputting video, the others are copying and formatting data from hub memory into buffers in the cog memory. They have to be tightly synchronized. Have a look at the tiled VGA drivers in the Object Exchange for examples (obex.parallax.com/objects/176/).
One of the objects Mike linked does this for a cursor.
Basically, anything you overlay adds to the primary signal. Cursors, HUDs, and other grey scales than the default are possible. There is a very tiny pixel misalignment that happens, depending. It's minor league.
An external OR gate would probably do the same kinds of things. I don't know that there is an advantage to an external OR gate. A NAND or AND one would be though! Those would permit combinations other than brighter ones to exist.
VGA makes sense. Syncing the COG's can be done, and the object linked on this thread demonstrates how to do it.
If you do it for TV, really it only makes sense for monochrome signals. The phase of the color counter isn't directly addressable. Advanced coding would be required to both sync the COGs, then resync repeatedly until those are in phase.
This task is difficult!
If you do external combining of the signals, it then would save on all the sprite masking operations required to build scan lines. This hasn't been done before, and would probably prove interesting to several people here, me included!
The basic video render approach that makes sense is to have one cog render scan lines, and other cogs develop them. It takes a lot of time to mask in all the sprites, limiting the number of moving objects, when everything is fully masked.
If the display is configured for full color, where each pixel is directly addressable, software sprites do very well, however higher resolutions consume most of the RAM.
Overlay won't get you much resolution wise. The chip is quite capable there. Easy to get a fast pixel clock. With the limited system RAM, it's much harder to keep it well fed, and buffered properly!
If it were me, I would take a shot at combining signals externally, and stay away from the NTSC color graphics, for the best chance at some interesting and fun results.
Also, a play at lower resolutions, say 320 pixels horizontally, is way easier to manage than the higher resolutions are, and they are for the reasons Mike gave. There will be enough RAM to do some graphics, testing and other things, easily enough to gauge the usefulness of the circuit you build.
Be sure and look at the 1024x768 VGA driver with cursor, for an example of how to sync the COGs. That's important, no matter what else you do, internal OR with multiple generators on the same pins, or external, or some combination.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 12/28/2008 4:58:13 AM GMT