VGA color palettes? (defcon badge)
skintigh
Posts: 2
I just finished soldering on my VGA and other ports to my Defcon badge and I was wondering if there was anything equivalent to the old PC VGA mode 13h or X mode graphics for this chip. In a nutshell: that mode had a palette of 256 colors that could be set with 24 bits, and then each pixel could be set to one of those 256 colors. This let you set pixels on a screen to, say, color 1 which was green, then later change color 1 to blue, and all the pixels set to that color would change from green to blue. Is there any way I can do the equivalent with this chip?
Thanks.
Thanks.
Comments
It is possible to get an 8 bit color definition for the screen, and depending on your VGA output circuit and graphics pixel engine, it might even do 8 bits of color, though the norm is 64 colors.
Video on the Propeller is largely a software affair. The hardware assist is provided by the waitvid instruction, which is basically a shift register that is loaded a few pixels and colors at a time, and that runs in parallel to the CPU, allowing it to fetch more pixels and colors. Multiple CPU's or COGS can all work together to produce one signal, or can be used independently to produce multiple displays, and anything in between.
VGA has two serious constraints:
1. Is the 32KB of RAM. A mode 13h, or something like it rapidly consumes that RAM, unless dynamic drawing methods are used, or the screen is composed of tiles. Full on bitmap displays work well, and Props are fast at manipulating them too, but there isn't enough RAM to really get higher resolutions.
2. VGA horizontal sweep frequencies relative to the overall speed of the Propeller tend to limit the number of operations per scan line, typically mandating two or more COGS be used at resolutions over 640x480 (or so, there are clever drivers out there).
Video pixel generation is done in three basic ways:
1. Bit banging. This generally makes light, or no use of the waitvid instruction.
2. Using the waitvid in the standard way. This means 4 color tiles, and as many of those tiles as desired, each with their own color palette, if desired. (Best case is 64 palettes, but that's by no means absolute) If a 4 color per tile, where a tile is typically 8x8, 8x16, 16x16, etc... is acceptable, then color redirection comes for free! The palette entries may be changed at any time, impacting all pixels that reference that palette in the tiles that also reference that palette. The "Parallax Colors Simplified" linked in my signature shows an example of this for TV. The VGA.spin driver works in the same way, just with a little different color values. In other ways, like tile addressing, color palettes and such, it's basically the same.
3. Using the waitvid backwards. In this method, colors become pixels, with the pixel values fixed for each waitvid frame. A waitvid frame is a combination of pixels and colors to be output to the display. See the Propeller Datasheet for more info on this. Basically, the use of the instruction is inverted, meaning each frame is 4 pixels, and the color definitions are loaded directly, yielding complete color freedom for all pixels, and the costs are both a short waitvid frame which limits resolution, and color redirection as absolute values are used for best speed.
Video "modes" are software things too. Because the system is software driven, one can do a bitmap, tiles, sprites, or any combination of those desired on any number of displays desired, subject to the 32K RAM limit. It's possible to have a monochrome text display running on a TV, graphics tiles on another VGA display, and perhaps another VGA displaying sprites.
The two basic methods to generate complete displays are:
1. Bitmap. This is the simplest of the display drivers to write and use. All one does is dedicate the RAM, and put the pixels there however it makes best sense. Graphics_Demo.spin does this. Bitmaps can be linear or stacked tiles too. Just a matter of a little code difference in the main pixel drawing loops. Multiple COGS can contribute to the display drawing, with only display regions or draw order considerations being necessary as the display buffer and data are shared.
2. Scan line drivers. With this technique, the various COGS all build up a scan line of the desired display, with one primary COG drawing those scan lines out to the screen. Multiple scan line buffers then mean multiple COGS contributing. Advanced tile and sprite displays are possible. One of many of these is in my signature. There are lots of examples of this technique really showing off the chip! Because it's a dynamically drawn scheme, RAM consumption can be very lean, yet resolution and color depth and motion high. It is likely the most complex.
Most drivers out there are some variation of these two ideas, sometimes combining them both, depending on RAM and display requirements.
One thing to consider is the Propeller is very fast. It is entirely possible to update absolute color values used in the HUB with one COG, while another draws them, in effect producing the "red" to "blue" through brute force. The parallel processing capabilities makes this actually viable as draw rates are often plenty fast for that kind of thing to be transparent to the viewer.
Thanks again
But this is the Propeller and nothing is impossible...
- you can use more than 8 pins for vga
- you can use use more than one cog to drive this
- you can add external memory for frame buffer.
- and at last you can add a second Propeller chip; then one of them can do only display task.
http://forums.parallax.com/showthread.php?142227-Does-the-quot-graphics-quot-object-ONLY-work-with-TV
When the Propeller was released Chip Gracey had written a few demonstration programs. This one is a simple graphics demonstration. It's often ignored as it seems dull at first glance, but there are some really great features in this code. Let me list off a few:
1. Separate graphics library COG. All draw commands happen on a secondary COG. Truth is, one can run several of these draw COGS together, each working on a screen region for insane pixel fill rates. Single buffer, animated displays are totally possible, and even with one COG doable.
2. Tile / bitmap display. This is reminiscent of the C64 and other character based computers that did not use a linear bitmap arrangement. The screen is broken into 16x16 or 16x32 tiles, and each tile gets one of 64 possible 4 color palettes. These offer color redirection, meaning you can change the palette entries individually, color cycling pixels in tiles that are assigned that particular palette. Lots of cool palette effects are possible here, and tiles can be reused throughout the screen too.
3. Variable display scaling. One can trade off resolution, screen detail, tiles and such with a lot of flexibility.
The original was for TV, and in my signature you will find the TV one commented to explain the colors and tiles and palettes better. The ideas map right over to VGA, but for the color values which are different.
pik33 is totally right too. Props can do tons of things! If you want to dynamically draw the display, sprites, tiles, color cycling, screen "mode" changes, video overlay (two video generators output to the same pins) and all sorts of other trickery is possible.
http://forums.parallax.com/showthread.php?142227-Does-the-quot-graphics-quot-object-ONLY-work-with-TV