Shop OBEX P1 Docs P2 Docs Learn Events
Using the Propeller as a Graphics chip peripheral for other microcontrollers. — Parallax Forums

Using the Propeller as a Graphics chip peripheral for other microcontrollers.

edlikestoboogieedlikestoboogie Posts: 71
edited 2011-01-10 11:01 in Propeller 1
Is a graphics chip a good application for a prop? My idea is to use a single instance of the graphics object to output VGA / TV / LCD simultaneously, selectable by 2 configuration pins. This would be targeted for chips like the LPC1768 ARM Cortex M3, the Cortex chip could emulate an EEprom SPI and send the graphics core IP to the propeller upon startup, that way all you need is a single $6 prop and 32kb of ROM space to gain VGA/TV/LCD. Is this a good idea or are there other cheaper solutions? My only other option is to use a cheap old PCI gfx card, but that would require an FPGA to connect via PCI and wouldn't get TV / LCD cheaply.

Comments

  • Clock LoopClock Loop Posts: 2,069
    edited 2011-01-09 00:24
    The prop can do graphics, but its limited in color space, ram, etc.

    It can do graphics calculated on the fly. NOT pulled from any prebuilt ram.
    http://www.linusakesson.net/scene/turbulence/index.php

  • AleAle Posts: 2,363
    edited 2011-01-09 00:30
    If you can live with the 32 kbytes that the propeller has (enough for text and up to 4 colors 512x256) then it is the way to go. If you need more memory.... then there is some trickery you can use, like the Morpheus board Bill Henning has.
    Generating video on the fly is tricky but it can allow higher pixel counts/colors. Do not forget that you have 8 processors... you can divide the task in 8 portions to simplify calculations...
  • edlikestoboogieedlikestoboogie Posts: 71
    edited 2011-01-09 14:34
    Looks like this Chameleon AVR product made by Lamothe's operation looks like an example of what I am talking about: http://www.xgamestation.com/view_product.php?id=51 .. a good system for getting around the prop's memory limitations would be needed, but if I had the time I'd work on something like this, to allow easy drop-in GFX into our other ARM industrial and commercial applications. In these apps graphics quality is not as important.
  • Bill HenningBill Henning Posts: 6,445
    edited 2011-01-09 19:33
    Hi Ed,

    Using just a prop and EEPROM you can do quite a bit - as long as you don't need high resolution bitmap graphics.

    The prop has 32KB of hub memory - so how much space you have left for graphics depends on how large your code is. You can do a two-stage boot like Catalina with a 64KB eeprom so you don't waste hub memory on holding cog images after loading them.

    The highest bitmap resolution I've effectively used with just a prop is 640x240 (two colors per pixel)... I placed that driver into the Object Exchange. It was based on Chip's 512x384 (two color per pixel) driver.

    640x240/8 = 19,200 bytes, leaving about 13KB for code/data
    512x384/8 = 24,576 bytes, leaving only about 8KB for code/data

    Note that both of the above drivers let you select the two colors for each approx. 16x16 pixel screen block.

    If you need more colors with a bare prop, there are four color modes, where you can have a separate set of colors for each 16x16 (or 32x32) block of pixels.

    320x240x2/8 = 19,200 bytes, leaving about 13KB for code/data
    256x192x2/8 = 12,288 bytes, leaving 20KB for code/data
    160x120 @ 64 colors per pixel = 19,200 bytes, leaving about 13KB for code/data

    Of course you can also write "tile" drivers, but those are not simple bitmapped drivers.

    Since Ale was kind enough to mention Morpheus, if you need more than a prop can natively provide, you could always license part or all of the Morpheus design and drivers for your companies products - PM me for details. I needed high resolution graphics, so I spent a couple of man years designing Morpheus and bringing it to market - the drivers were NOT easy!
  • edlikestoboogieedlikestoboogie Posts: 71
    edited 2011-01-09 21:58
    Hi Bill,

    Thank you for your very informative response.

    Please give me some time to process what you have told me and spec out exactly what I need.

    One question comes to mind: Is it possible to operate the TV and VGA driver simultaneously to display the same buffer?
  • potatoheadpotatohead Posts: 10,253
    edited 2011-01-09 22:31
    Yes.

    The video processors all operate independently, and share the HUB memory space.
  • ericballericball Posts: 774
    edited 2011-01-10 04:17
    One question comes to mind: Is it possible to operate the TV and VGA driver simultaneously to display the same buffer?

    Yes and no. As potatohead says, each cog has a video generator so there's no hardware limitation which would prevent both a TV and VGA display of the same buffer. However, there are other challenges:
    1. Resolution. Due to color aliasing, TV resolution tends to top out at ~240 pixels per line. TV also has a fixed number of lines and is subject to overscan. So my recommendation would be to work out an acceptable TV resolution then tweak the VGA driver to match.
    2. Color & color formats. VGA colors are 6 bit RrGgBb while TV is 6 grey levels + 16 hues of 6 brightness. So a single 8 bit color value is different for TV and VGA (and there's no easy way to translate between the two). Tile drivers normally have a palette so the two displays could have the same tile data but different palettes, but this wouldn't be possible with 8bpp bitmap displays.
  • wjsteelewjsteele Posts: 697
    edited 2011-01-10 11:01
    There is another option for simultanous output to VGA and TV. In the Wingman, we actually re-use the buffer memory for both displays. We draw in the "basic" TV buffer all the information we need, copy that to the TV output then redraw more detailed information on top of the TV buffer and copy it again to the VGA output memory.

    Now, technically, we're not using VGA, but rather Rayman's 4.3" LCD display which is pretty close to VGA in function. It actually works out quite nicely. We do limit the display to 192x160x4 however, but that isn't a problem, as we can shift the palette on any line to give us a lot more color choices. For the TV output, we're actually sending it to our Heads Up Display which only needs one color (green) anyway.

    The trick was getting the timing exactly right, but so far we haven't had a problem with it at all.

    Bill
Sign In or Register to comment.