More than 4 colors using 2 video generators?

Jacob D

I just opened my Hydra kit. Perhaps I'm missing something, but at first glance the 4 color 16x16 pixel tile in the VGA driver seems very constrictive. For example, I was hoping to interface with an SD card and display a 32-bit (or at least 16-bit) depth image at 1280x480, but that looks like it's way out of reach. 6 bit color...?

It seems like the hardware is there, since each COG has a video generator - is the lack of real color a software limitation at this point?

Bottom line: If I was to dedicate a COG for the lowbits (__XX, __XX,__XX) and one for the highbits (XX__, XX__,XX__) and link the video pins with the appropriate resistors, could I generate a 4096 color palate?

Rayman

It's possible, but not really worth the effort.

But, I did it anyway:

http://www.rayslogic.com/propeller/Programming/6-Bit%20Bitmap%20App/6BitBitmap.htm

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm

My Prop Products:· http://www.rayslogic.com/Propeller/Products/Products.htm

potatohead

Yes, on VGA, you can use the generators together to get large color sets. You will find HUB memory to be a serious limitation, unless you either fetch data from external storage, or use a dynamic display that's drawn in real time each frame. The Prop is plenty fast enough to do that.

You can also have multiple COGs output to the same pins for overlay effects on VGA too. Doing that does not significantly improve the color space, but it does allow for overlay graphics without all the painful bit masking. Chip did this for a VGA cursor on one of his drivers. Simple things like cursors, or a HUD type display are possible that way.

On TV, doing the same thing in monochrome is pretty easy, but doing it in color isn't. The reason is the PLLA is difficult to get synced up between the COGs, which puts the color signals into conflict.

Finally, using an external chip, or some R2R ladders, you can just drive the outputs directly, skipping the video generators entirely. Baggers did this on PROPGFX, which can deliver a nice, high color display, using most of the Prop pins for output, and the remaining ones for serial or parallel comms, turning the Prop into a dedicated graphics device. The intent there is to just connect it, like one would connect other devices, and use an entire prop for graphics so that all the HUB memory can be used for the screen display buffers.

The lack of real color is largely due to the small amount of HUB memory to work with. Secondary limitations are

the transfer speeds found in external storage

difficulty managing said storage, buffering and such consuming COGs and pins.

If you want to dedicate a Prop to display tasks, then use another one, or some other CPU to handle whatever sits behind the display, lots can be done. If the prop is going to display, and perform tasks, RAM, COGs, and pins will get used up quick!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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) : 5/6/2010 3:12:30 PM GMT

Mike Green

You're not going to be able to display a 1280x480 image at any depth because the Propeller has only 32K bytes of memory to use for a video buffer. It's possible to attach external SRAM to a Propeller to use for a video buffer, but this uses most of the I/O pins of the Propeller for interfacing and the data transfer rate from the SRAM isn't fast enough to handle this sort of image size with the sort of image depth you want.

The Propeller's video generator was designed to support the sort of images that could be buffered in the 32K main memory, hence the color depth limitation.

potatohead

It's also worth noting that the video generator can be ran backwards for a byte per pixel color capability. No colors / tile, just pixels. What you do is execute "waitvid colors, %3210". That draws one pixel of each color, turning the color long, into 4 pixels that are one byte each. This gets you the maximum "stock" Propeller colors, with no placement restrictions.

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

Jacob D

Interesting. The design (a GUI) is not overly complex and mostly sparse, I could write it dynamically rather than map the whole thing in. I still run into a problem at some of the more complicated parts, for example a company logo) where there are 5 colors within a 16x16 pixel region.

I don't necessarily mind dedicating the Propeller to graphics, that was the main reason I picked it up in the first place. There's a Freescale mcf51jm128 and a Microchip PIC 18f4550 going onboard already (HID and CAN, respectively), both which have ample space and capacity to do the rather menial business logic but have no capacity for VGA out.

Jacob D

potatohead said...
It's also worth noting that the video generator can be ran backwards for a byte per pixel color capability. No colors / tile, just pixels. What you do is execute "waitvid colors, %3210". That draws one pixel of each color, turning the color long, into 4 pixels that are one byte each. This gets you the maximum "stock" Propeller colors, with no placement restrictions.

If the Propeller was dedicated to Video in this mode, and I used an external data source to map in a line at a time (8 bit parallel, 32Mhz clock), could the Propeller keep up?

Mike Green

If you're doing a GUI, there's probably a lot of redundancy you can take advantage of. Chip Gracey did a tile-oriented high resolution driver (and demo program) that uses the ROM font table for most of the tiles on the screen as well as several small bit graphics areas. There's no reason why you can't do something similar combining fixed repetitive graphics tiles with text tiles using the ROM font, small bit graphics areas and some dynamicly generated areas. Chip's driver does need to use 4 of the cogs to get the video rates needed, but it's a good example of what can be accomplished with a Propeller.

potatohead

I don't know that it will do a 1280. Fetching the data at that pixel clock rate is going to be brutal. I think the 1280 driver consumed all but one of the COGs @ 80Mhz.

At some lower resolution, it's possible to do. We also had a driver written to use the SRAM card for the HYDRA. Jasper_M and the guitar pedal guy, who I can't recall off hand, did it. Resolution was pretty good, though the graphics were not particularly high color depth.

Props can easily clock at 100Mhz, so that's a nice boost too. 6.25 Mhz xtal, sold on the Parallax site, thanks to Bill Henning, who got people started on that nice, simple 100Mhz timing!

Assuming you settle on a possible resolution, your video code would then need to look like:

1 COG to draw pixels to the screen, from the HUB scan line buffer ram. This COG could either be using the video generators, for all the stock 64 colors, or driving an external video converter, or using some R2R setup, capable of adequate color depth. More resolution = more COGs, with the multi-cog starting at 600 - 800 pixels, from what I've seen.

An equal number of COGs, fetching data from the external storage to fill the scan line buffers.

1 comms COG, so that you can get display data to the thing, or give instructions to it.

1 graphics library COG (maybe), so that draw operations that involve the video Propeller only can just be sent to it, leaving the Prop to draw it, much like a graphics card in a PC does.

You will run into fill rate limitations doing this. Basically, the constant streaming of data to the display won't leave a lot of time to modify the external storage.

All of that is for a bitmap display only, or tiles. If you want things like sprites, you will either have to "draw" them on the bitmap at whatever fill rate you can manage, or dedicate another COG to drawing them based on info received from the comms.

Honestly, at the higher resolutions, I think this is a PITA for what you get. At lower resolutions, say 600 pixels or below, or say TV resolution, doing this kind of thing can be pretty great! The PropGFX project is essentially what you are trying to do, only it doesn't use external storage, keeping it's pixel clock to TV graphics limits. (720x480 tops)

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

Jacob D

Okay guys, thanks for the reality check. Believe it or not my first programing experiences were on embedded systems (BS-II, actually!), so I should know better. I guess after spending 10 years in the "real world", where 256MB is peanuts, one inevitably gets lazy and sloppy - nobody has a problem with image masks and overlays in C# or Java on a PC.

I fought to get this project embedded vs. a SBPC with CE or nix, so I guess it's time face the music and suck it up. Back to the book...

JSD

potatohead

Yeah, these specs are home run in the PC space. Cheers!

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

Rayman

BTW:· Bill Henning at Mikronauts.com has hardware for higher bit depth modes using expanded memory...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm

My Prop Products:· http://www.rayslogic.com/Propeller/Products/Products.htm