Cogs and VGA

E-Head

Hi

I am just wondering, what is the main reason that some vga-drivers takes more than a
one cog? And how the different cogs take part to drawing a picture on the screen?


Is the picture divided in to smaller "sub pictures" which are drew by different cogs?
That "sub picture" thing doesn't sounds right to me...

Or is it just a speed issue. With more cogs Propeller gets more speed when the work
is divided to parallel for different cogs. That sounds more right to me.


EH

Toby Seckshund

My, simplistic, understanding is that if the data output rate is high then two cogs can be syncronized up to take turns at spitting out data, whilst the other is getting prepared for its turn.

There are far greater minds here that will have the definitive answers.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point

kwinn

The video data rate for VGA is high so there is not enough time for a single cog to output a video scan line and prepare the data for the next scan line. By using more than one cog one or more cogs can be preparing the video data for their scan line while another cog is outputting a scan line.
For example, VGA_HiRes_Text uses 2 cogs. One cog produces the first scan line (and every odd scan line after that) and outputs it to the video display.
While the first cog is outputting it's line the second cog is preparing the video data it will output when the first cog finishes. Once the first cog is finished outputting data the second cog starts outputting it's video line while the first cog prepares its next video line.

potatohead

Another approach is to have a scan line COG. It does the display, and renders from a scanline buffer, while communicating it's state to graphics COGs. The graphics COG or COGs, takes the display data, sorts it, then renders it for the scan line, putting that data into the buffer, so that the display cog can read it to build the display.

This way, multiple COGs can generate graphics, which are all combined in the buffer for display. An example of this might be a display where there are both tiles and sprites. One COG might do tiles, and another one would overlay sprites, all displayed by the display COG.

In general, there is a loop necessary to build the display. The higher the display pixel clock, the tighter this loop must be. Also, generally speaking, TV graphics resolution, say 320 pixels and below, does allow time for some display building at the same time as the display is being drawn. That's a one COG solution. Text, simple tiles, bitmaps and such can be done this way.

As the pixel clock goes up, or sprites are needed, there isn't generally time for that data to be moved in tandem with the core display signal, and that's where multi-cogs come into play.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!

pullmoll

@potatohead Apropos your NTSC TV potatotext object. I would need to understand that one and then write a combined NTSC/PAL driver. It should be capable of 40x25 with 1 of 16 colors text on a whole screen background, and alternatively 160x100 pixel 4 color graphics, also on a selectable screen background color. The background is usually black, but could be made magenta, green or blue (or something like that... have to check old code).
The machine I'm targeting had a 6845 CRTC and you could thus modify the display within some bounds. Up to 48 characters were visible if you tuned your TV display and on PAL you could also have some more character rows.

Do you give me a chance to get that working in two cogs, i.e. a renderer and a video emitter? After looking at your code I think it should be possible, as you also have two color and four color modes in the same cog with different active loops. All I have to understand is how to generate the correct sync pulses for either PAL or NTSC. Cluso99's 1pinTV driver just couldn't teach me that [noparse]:)[/noparse]

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.

Post Edited (pullmoll) : 3/31/2010 6:59:01 PM GMT

potatohead

Well, potatotext is built off of Eric's great templates. I've not yet done the PAL version, but the whole thing should work off of that, just as it did the NTSC. I've got all the timings documented on that one, but one I owe Cluso... Just remembered [noparse]:)[/noparse]

Anyway, 1 of 16 colors text, on a solid background @ 40 chars, should fit into one COG @ 80 Mhz. I've an older driver that does that, and the color mod to it, known as AiGeneric does that too.

160x100 4 color graphics is cake. That's a dead simple, short loop for a bitmap. Should fit into the one COG as well, as a mode.

There are a few things that are expensive on Propeller. They are color indirection, where a number references a table, that contains the color reference. Generally speaking, even with the color table in the COG, it takes lots of instructions to get this done, and there isn't time in the display loop at anything above 128 pixels or so. 160 should fly @ 96 Mhz.

Another one is color cells. That's a set of lookups too, though they can get done at 40 characters easily enough, so long as you don't mind just using bytes for color definitions. That's a bit RAM hungry. Doing a 16 color, with lookups color text definition takes some COG time, and will deffo push a display to 2 COG.

Sprites must be masked in, requiring multi-cogs, or if done as software objects (which works great, BTW), will have to live with whatever color limits are in play. ie: 4 color tiles or bitmaps, means the same colors for sprites.

IMHO, the character / line limits and (bitmap?) resolution you are targeting resolve down to a single COG. If I were you, I think I would take the template Eric built, and modify it to choose both PAL and NTSC from a mode parameter, and strip out the interlace capability, as it's not needed in your case. This would leave you with a base display. Then, do what Cluso did and pull the text code from any of the 8x8 drivers, and build from there. The bitmap is cake. That's just an address, add, feed waitvid, loop, reset during blank. Won't take but a few instructions. Cram that in there last.

The whole thing works well, with your display memory and font memory in the HUB, allowing for a small block of parameters necessary for screen address, mode, etc...

One thing about display drivers is the core timing involved. The timings you build from really impact the display characteristics. For example, the AiGeneric driver is really simple, originally timed by CardboardGuru. The advantage is dead simple display building, the disadvantage being some color artifacts on NTSC above 160 pixels. It's good for 256, but past that, will artifact. And doing that won't ever get you PAL. If you were to build from potatotext, you would get a great NTSC signal, with full interlace if you want it, but then it's got more complexity than you probably need.

That's basically why I think, if it were me, I would combine the templates, get both signal types working with color bars, then build from there. Had I gone with that on potatotext, I think I would have gotten PAL for free...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!

potatohead

Forgot...

Potatotext is kind of odd. It's actually a 4 color driver at the core. For two color text, a lookup table is used to map the one bit per pixel to a two bit per pixel scheme, and reverse the bits at the same time. That allows for the 2 color text, with two unique colors being possible for each character. The two other remaining colors are not defined, reserving them for a mouse pointer that can remain color independent across the display, no matter what the text color definitions are. That mouse pointer isn't coded right now, largely because I just kind of finished that up and had not yet figured out whether or not I could cram the mouse into the two COGs, or whether another COG would be needed. If it's another COG, well... that's three, and probably needs to be reconsidered, or some other features added.

If you want two color text, and have no need for anything else, it can be done with a lot less complexity! And that is what would fit it all into one COG. Essentially, you run with a 2 color waitvid loop, providing your two colors for each waitvid frame. That's your two color text right there, and at the modest 40 chars per line, it should work fine @ 80 Mhz.

When you switch to 4 color bitmap graphics, you use a different waitvid loop. Same timings, just change the bits per pixel, and everything else will go nicely. On the bitmap, if it's 4 colors per screen, you just pick those up, prior to entering your video loop, so all that does is fetch pixels.

The beauty of Propeller video is you really can do lots of stuff on a display, and do most of it on the fly. Some examples would be a display where the top 160 scans are bitmap, and the bottom would be 4 rows of text. This is no problem. You can also mix up the waitvids from two color, 4 color, or full color too, either doing it vertically, or horizontally, given you pre-calculate what the timings are. There are a lot of options.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!

Post Edited (potatohead) : 4/1/2010 5:31:28 AM GMT