Multiple VGA

davidsaunders

I am working on implementing a single Propeller UXGA VGA driver, that supports at least 12BPP, and hopefully 15BPP, using as few cogs as possible.

This thread began as a simple question, about parallel cogs working on the same video output as I have only been using the Propeller for about 5 to 6 weeks.

So far it looks like 12BPP will require 4 COGS in order to not be restricted by the palette. Any suggestions on how to get around this limit are welcome. This could be done in two COGS, but that would leave the pallet limit at 8 colors for each 16 pixals.

The code, and schematic will be released under a MIT license, once it is fully working and the HSync and VSync look clean on my scope (as some monitors have trouble with noise in the Sync). Maybe I should also scope the kitchen Sync to make sure it is clean .

tonyp12

You better get good a syncing the PLL between cogs.
Here is a solution, and it turns out that using 'Gray code'
so only one bit is the differnence from old and new value completes the final stage.

http://www.linusakesson.net/programming/propeller/pllsync.php

davidsaunders

Thank you. I would have not been nearly that thorough with cog syncing.

I do still ask can I output the R,G,B components separately from different cogs on the same 8 pins?

Mike Green

Yes, you can implement multiple VGA controllers on one Propeller. A lot depends on the number of pixels and whether you want text-only or graphics. You're severely limited by the amount of available memory for buffers. Bill Henning has some drivers for his Morpheus board that use external SRAM for VGA video buffers, but the additional I/O pins for the memory are not available then for video output (8 bits per VGA - 2 for sync, 2 for Red, 2 for Blue, and 3 for Green). Other drivers put their buffers in hub memory. For graphics, you're limited in resolution and there's really only room for one buffer. For text-only, you could fit several buffers in memory depending on their size. Remember that the video circuitry only allows 8 bits per pixel. It's possible to handle the sync separate from the video.

It is possible to sync two or more cogs so several video generators work together. You can't do this with TV output because of the way the color subcarrier is produced, but VGA just involves shifting 8 bit values out

tonyp12

davidsaunders wrote: »

Thank you. I would have not been nearly that thorough with cog syncing.

I do still ask can I output the R,G,B components separately from different cogs on the same 8 pins?

If you are a beginner to the prop, start with something simpler .
No one have really made a 9bit vga driver for the prop, though it propbably could be done.

Where are you gone store the larger bitmap?, the prop only have 32k of ram.
Most external ram solution is to slow to help you, or uses so many pins that you have not 11pins left over
for your vga driver as you would need to create your own triple D/A using 3pins for each color.

davidsaunders

While I am new to the Propeller, I have done (a rather simple) 15BPP video device using 2 Mega 164Ps, some logic and a bit of SRAM.

As for where to store the bitmap, What bitmap? This is for graphics created on the fly (using the remaining Cogs) from some simple GEM VDI style vector graphics.

kuroneko

Is there a specific reason to split the colours over countless cogs? I'd have thought that 2 cogs should be enough for the colour part (8bit each). Or at least let them do one component each.

potatohead

Yes, you can do all of that, and you can do it with the waitvid, or just using writes to the pins, however you want to setup the timing.

Props are good at dynamically drawing things. Props are not so good at bit mashing. It's better to operate on data sizes that are easy for the COG, feed to a buffer, then have the signal COG, or COGS display that to the screen.

Using the render to scan line buffer approach, one cog should be able to do your signal, so long as the resolution isn't too high, with the remaining ones building data on the fly.

There are essentially NO restrictions on the video generators. They can output to different pins, the same pins, no pins! Whatever you want them to do. Just set them up, and then feed them pixel and color data. Or.. the same is basically true for the COGS as well, just doing writes to the pins, and using masks, cycle counting for the pixel clocks.

Depending on what you want to do, rendering to scan line buffers avoids the PLL sync issue, because only one COG will output.

Baggers first did something similar a few years ago, outputting 15 bit color, with a low resolution, drawing bitmaps from the HUB. Later on, he managed to get the thing to render WOLF3D, raycast style, with textures (8 bit color) on one prop! Packed all that into 32K as well, minus the baddies. Chip was fast enough, just no RAM left to contain them.

davidsaunders

I had thought that the video shifter used a two bit palette, as such the reason for splitting among multiple cogs is to get around this, allowing any arbitrary RGB value at any pixel location. Am I missing something?

Mike Green

There's not a lot of time from one load of 16 pixels to the next, particularly at higher resolutions. Typically, several cogs are synchronized together and one outputs the video from a line buffer in the cog while others render graphics or text to their buffer. Depending on resolution, a cog may handle several lines in a row.

tonyp12

>allowing any arbitrary RGB value at any pixel location.

You could just simple use %%3210 for pixel data, to just use each the color once.
But at a lower horz res so waitvid can keep up.

kuroneko

davidsaunders wrote: »

I had thought that the video shifter used a two bit palette, as such the reason for splitting among multiple cogs is to get around this, allowing any arbitrary RGB value at any pixel location. Am I missing something?

A 2-bit palette allows you to pick one out of 4 pixels colours. In VGA mode that is usually a byte (4 per long) which is read from hub RAM (this byte will drive all 8 video bits for the duration of a pixel). That said, in the end it's all down to required resolution/timing. If we knew more about those we could provide more specific help.

potatohead

No, I think my comment needed some expansion.

You've got a few choices:

1. Use a 4 pixel frame. This allows all the colors to be output on any pixel. You get hardware support for 8 bits of color that way. "waitvid colors, #%%3210" Colors then becomes pixels, with the actual pixel argument used to just specify the order of output. In this mode, you can reverse the data for screen display in the video generator.

2. Output longer frames, but be limited to four 8 bit colors per frame. This data will need reversing prior to display, unless your dynamic graphics do that as part of their process.

3. Sync more than one COG, and output one of the above in tandem with a primary signal COG.

At higher resolution, it's going to be necessary to use multiple COGs to generate all the color data. 4 pixel frames gets you about 256 horizontal pixels, with the ability to fully use the color bits in the video generator at VGA style sweep frequencies. To do more than that resolution wise, either colors go off the table, or it will cost more COGs, as you've outlined.

You are not fixed in resolution either! It's entirely possible to run one COG at a low resolution, providing more color, and another COG running at a higher one, providing intensity too. They only really need the same sweep frequency to keep it all sane.

I've been wanting to do that with a component video driver, because the sweep frequency is nice and low. Haven't done it, because there just are not that many component displays that are small. Limited to higher end TV's.

davidsaunders

My goal (that I am beginning to see may require 3 Propellers) is to be able to output 1024x768x15BPP@60Hz (65.0MHz pixel clock) with enough cogs left over to generate the video from a simplified GEM VDI style vector graphics image.

davidsaunders

I wish to do this on the propeller for two reasons 1:) The challenge of doing a good video generator beyond what has been done so far, and 2:) it will be used in the video output of another project that I am working on.

potatohead

Well, I look forward to seeing your progress. That's a stiff challenge, IMHO! *Impossible really.

*Heater's law, whereby something declared possible actually ends up done.

davidsaunders

Sorry about the neglect in information. I had a driver working for 1280x1024x12BPP with vector graphics as planned, but the Bread Board burned. That was two days ago. I have not been able to do any testing since, as that ended my supply of resistors. As soon as I can test further I will upload the schematic (if it works with burning up), and the current source (still a little buggy, and not well commented).

This currently uses 6 cogs for video + 1 to manage things. So at present it is not a practical solution for single Propeller designs.

davidsaunders

Just in case it helps any one else.

I burned up the bread board do to a short between the LSB inputs to the Blue resister DAC that was directly connected to a line driver (bypassing the breadboard) that itself was directly connected to the Propeller pins (again bypassing the bread board). I had bypassed the breadboard because I wished to avoid any potential issues with the capacitance of the breadboards conductors (65Mhz is a bit fast for a breadboard). This short some how lit up my "Fire resistant" plastic breadboard.

davidsaunders

It looks as if this may just work (and only take two Propellers [using only 3 cogs each]). Do to the limited number of IO pins on the prop I am having to use two Propellers for this, as I am bit banging the video out (To much trouble with the built in video generator), in an interleaved manner. Though this only allows for up to 800x600 resolutions with the Propeller at 80MHz, at 100MHz should just barely be able to do 1024x768. If I were to to more Propellers (have to be in pairs), the maximum display resolution would increase to 1600x1200.

Ale

Are you sure that a Propeller is the way to go ? You could get a small FPGA to produce video output at the required frequency for less money: http://forums.parallax.com/showthread.php?119689-A-new-dimension-in-Propeller-marriages-pPropFPGA just sain'

davidsaunders

The prop will leave some power left over for some basic video processing. And I do not think it would be cost effective to implement that powerful of a video processor in FPGA. Besides the circuit is so simple that most Propeller users would be able to implement it. Yes it does cost ~$20.00.

davidsaunders

There are some applications were people sometimes ask 'why send a FPGA to do the job of a MCU', to me this is backward i say 'why send a FPGA to do a MCUs job. It is a lot easier to debug code running on a MCU, and a simple HW design than to debug a complex design in a FPGA, and it shortens development time. And the product tends to be of a better quality as a result. Are you not comfortable with the KISS concept?

jmg

Kiss ? With three chips ?

Might be smarter to focus on packing what you can into one chip, with a CPLD, and then wait for Prop 2 ?

davidsaunders

jmg wrote:

Kiss ? With three chips ?

KISS = Keep It Simple Silly.
The chips are Propellers.

jmg wrote:

Might be smarter to focus on packing what you can into one chip, with a CPLD, and then wait for Prop 2 ?

As I said KISS. As such I am doing this with Propellers.

Ale

I understand your point but I just do not see that it is that KISS, but the DEBUG is definitely easier.

kuroneko

davidsaunders wrote: »

Do to the limited number of IO pins on the prop I am having to use two Propellers for this, as I am bit banging the video out (To much trouble with the built in video generator), in an interleaved manner.

What exactly is the problem?

davidsaunders

In order to get the desired results with the video generator, I would need a separate cog for each 2 bits of the signal plus 1 cog for the sync, making 9 cogs. This is due to the limit of a 4 color palette for each 16 pixels. With Bitbanging I can use 4 cogs for the pixel data and sync, but to reliably interleave the output requires (16 * 3) + 2 pins, so 2 props are needed.

davidsaunders

Now that I have a few more Propellers, I will to make some more progress on this.
Also It can be done using 1 prop using the built in video generator (8 cogs), Though I will focus on a 12 bit version, that uses 6 cogs, and see if I can not reduce that, If so then I will see if I can not do this on one Prop.

davidsaunders

I should have something to show by the end of the month, the MultiDB68k relies on it. Though I do still need a better name for the Amiga clone, MultiDB68K just does not roll off the tongue very smoothely.

davidsaunders

Updated the top post to reflect the current aim of this thread. It now reads:

I am working on implementing a single Propeller UXGA VGA driver, that supports at least 12BPP, and hopefully 15BPP, using as few cogs as possible.

This thread began as a simple question, about parallel cogs working on the same video output as I have only been using the Propeller for about 5 to 6 weeks.

So far it looks like 12BPP will require 4 COGS in order to not be restricted by the palette. Any suggestions on how to get around this limit are welcome. This could be done in two COGS, but that would leave the pallet limit at 8 colors for each 16 pixals.

The code, and schematic will be released under a MIT license, once it is fully working and the HSync and VSync look clean on my scope (as some monitors have trouble with noise in the Sync). Maybe I should also scope the kitchen Sync to make sure it is clean .

davidsaunders

Found a limit that I can not get around. Reading from hub mem limits one cog to reading 20MB/s, with only enough room for two 4 cycle instructions between, to get the needed four 4 cycle instructions in the limit goes down to 10MB/s, thus with 4 cogs at 8BPP the limit would be 800x600, assuming that one can get all cogs off by 2 clocks. If there were enough space in COG mem to fit 256 longs + the 16 longs config + the code, then could get this down to 2 cogs at a time, though still limited to 800x600x8BPP. I guess that the solution is to impose the limit of no more than 4 colors for each 16 pixels, with a total of 4096 or 32678 colors on screen available. Maybe I could use alternating pallets across 4 frames to simulate the needed depth.