Shop OBEX P1 Docs P2 Docs Learn Events
Better composite graphics available than the Prop? — Parallax Forums

Better composite graphics available than the Prop?

sccoupesccoupe Posts: 118
edited 2010-07-20 21:30 in Propeller 1
I have a few projects that use the propeller to generate graphics via composite video. I have need to do more hires stuff than the prop allows. Are there any other options. Microchip has a Pictail, but it uses the prop as well. Any ideas?

Thanks

·
«1

Comments

  • whickerwhicker Posts: 749
    edited 2010-07-10 21:51
    NTSC Television has such a low resolution that the Propeller can definitely exceed it, causing chroma crawl, shimmering, and horizontal line bounce.

    Do you really mean more colors? Or what do you mean?
  • potatoheadpotatohead Posts: 10,261
    edited 2010-07-10 22:06
    Is your problem memory buffer, or the signal?

    If it's RAM, I get it. The Prop can't really display a full screen, high resolution composite signal, unless it's text, tiles, etc...

    If it's signal, that can be addressed.

    Coupla things:

    Use the S-video option. Most of the drivers out there right now, including the Parallax one, can operate with a different VCFG value which takes the chroma off of start_pin +1 and puts it on start_pin +3

    It's the same resistor too, which makes things easy. Once you've got that change done, either wire up another video circuit, or cut the trace that links start_pin +3 to the DAC, separating it. That's your chroma for S-video. Prop output that way looks really great. I would capture and toss up a screenie, but my capture device won't do that.

    The other thing that can be done is to run a full interlaced signal. Potatotext does this, and the results are great! To avoid flicker, just double up the scanlines, keeping vertical resolution at 200 lines or so, and run horizontal at 320+ up to 640. The interlaced signal significantly improves the overall reproduction.

    Finally, how the signal itself is generated has a big impact on the overall artifacts and color. Eric Ball's video templates run at 7Mhz, and they are pretty sharp. He's got a 14Mhz one that has far better than stock color, though it's horizontal resolution is 224 pixels...

    The Parallax drivers are 3Mhz drivers and have a subdued signal. Other drivers, like AiGeneric also are 3Mhz, but don't do color phase shifting, significantly limiting their horizontal resolution to 256 pixels or below.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Propeller Wiki: Share the coolness!
    8x8 color 80 Column NTSC Text Object
    Wondering how to set tile colors in the graphics_demo.spin?
    Safety Tip: Life is as good as YOU think it is!
  • LeonLeon Posts: 7,620
    edited 2010-07-10 22:17
    People often use FPGAs for generating composite video. Such a system could be interfaced to a Propeller quite easily.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Leon Heller
    Amateur radio callsign: G1HSM
  • sccoupesccoupe Posts: 118
    edited 2010-07-10 22:31
    I guess maybe I could just be looking for more colors, but speed has become a problem when re-writing the whole screen at say 15 fps. I guess more of what im looking for is a nice digital display where the digits have shadowing and all of that like you can get from VB.NET. Even when sent out of a composite video card to a TV, it still looks good. Now, I realize that thats talking about a lot more horsepower, but shouldnt something more economical be able to be completed for an embedded type application? The Nissan GTR has some nice smooth graphics for its status monitor. Thats more like what im looking for and Ive never seen a prop demo that looked near this good even using VGA. I'm suprised that there isnt a chip out there that just handles graphics like this.



    Thanks again for the input.
    798 x 1200 - 82K
  • potatoheadpotatohead Posts: 10,261
    edited 2010-07-11 01:03
    That's gonna be Prop II.

    For now, I would think one of the single board embedded computers would pull that off nicely.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Propeller Wiki: Share the coolness!
    8x8 color 80 Column NTSC Text Object
    Wondering how to set tile colors in the graphics_demo.spin?
    Safety Tip: Life is as good as YOU think it is!
  • BaggersBaggers Posts: 3,019
    edited 2010-07-11 09:07
    May be able to get something close adding an AD723/4/5 to a prop, then using a character/tile mapped screen.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    http://www.propgfx.co.uk/forum/·home of the PropGFX Lite

    ·
  • potatoheadpotatohead Posts: 10,261
    edited 2010-07-11 15:01
    Seems to me, an awful lot of that display could be spooled from serial storage too, leaving the changeable graphics to be mere sprites over the top. A large serial device could contain the various "modes" the display would be in.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Propeller Wiki: Share the coolness!
    8x8 color 80 Column NTSC Text Object
    Wondering how to set tile colors in the graphics_demo.spin?
    Safety Tip: Life is as good as YOU think it is!
  • ericballericball Posts: 774
    edited 2010-07-13 18:23
    Generating video using the Propeller has several limitations:

    1. Composite video is inherently bandwidth limited due to signal multiplexing to about 240 active pixels per line (and 480 active lines). S-Video can increase that to ~320 active pixels per line as the two chroma signals are still bandwidth limited. Anything higher than that and you will get color artifacts instead of increased resolution.

    2. The Propeller video circuit uses a 3 bit DAC with 1 level 4 bit PSK color on a separate pin (S-Video mode) or as +/-1 luma. For composite video luma = 2 is black and luma = 7 is white for six levels of grey. Depending on the TV (and whether you use S-Video or composite output) you could get up to 128 different colors. However, you only get 2 color intensities with composite (dull and bright) and only 1 (dull) with S-Video. It may be possible to use PWM to gain an additional level of grey.

    3. For all-points-addressable bitmap displays, the higher the resolution, the more RAM required to store the display. 32K of HUB RAM simply isn't enough to store a full bitmap (which is why graphics.spin is tile based). External RAM could be used, but then you run into speed of access and concurrent access limitations.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Composite NTSC sprite driver: Forum
    NTSC & PAL driver templates: ObEx Forum
    OnePinTVText driver: ObEx Forum
  • markaericmarkaeric Posts: 282
    edited 2010-07-14 01:40
    I've been thinking about something similar. I've purchased Andre LaMothe's book to try to get a better understanding of the Prop's composite video capabilities. In it, Andre states that when color is used the number of horizontal pixels is only 188! The thing that gets me is that most of the smaller 16:9 LCDs claim to have a 480X234 resolution, while only having composite inputs for interfacing. So I can't help but wonder if the specified resolution is only a marketing gimmick, or if there's actually a way of achieving such high resolution. If double buffering is not necessary, then said resolution @ 2bpp can fit in hub ram.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2010-07-14 03:06
    markaeric said...
    The thing that gets me is that most of the smaller 16:9 LCDs claim to have a 480X234 resolution, while only having composite inputs for interfacing.
    Each horizontal pixel may have an R, G, or B color filter in front of it, making the true, full-color horizontal resolution 160. That's pretty close to Andre's figure. (Truth in marketing can be a pretty slippery concept!)

    -Phil
  • markaericmarkaeric Posts: 282
    edited 2010-07-14 03:41
    Phil,

    Many of these displays actually quote the resolution as being 480xRGBx234. But I have seen plenty of retailers counting individual RGB components as pixels. I'm pretty sure the 480x234 on many of these displays is legitimate.
  • ericballericball Posts: 774
    edited 2010-07-14 13:54
    An NTSC line is 227.5 cycles of colorburst, or 63.555uS. According to the spec, horizontal blank is 10.9uS or 39 cycles leaving a maximum of 188.5 cycles, although some of those will be lost to overscan. I suspect that's where Andre gets his 188 value. 160 cycles is what the Atari 2600 used as a safe value.

    However, a pixel can be less than a full cycle of colorburst. Using the Propeller video driver each cycle of colorburst is 16 PLLA cycles. So 160-188.5 colorburst cycles is 2560-3016 PLLA cycles which can be divided by any integer value. 15 PLLA cycles per pixel gives a resolution of 170-201 active pixels. However, the closer you get to 8 PLLA per pixel, the higher your risk of color artifacts. 12 PLLA per cycle should be a fairly safe value.

    Note: S-video luma and composite greyscale are not bandwidth limited. S-video chroma (color) still has the same limitations.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Composite NTSC sprite driver: Forum
    NTSC & PAL driver templates: ObEx Forum
    OnePinTVText driver: ObEx Forum
  • markaericmarkaeric Posts: 282
    edited 2010-07-14 23:23
    Shouldn't it be possible to achieve higher horizontal resolution if the only color that is preceding or following an rgb color is black/grayscale/white? So you can only add a chroma signal to a pixel if the surrounding pixels are not colored, and therefore not be constrained to the limited color resolution if a sequence of multiple colors is not required. Or am I missing something?
  • Ken GraceyKen Gracey Posts: 7,401
    edited 2010-07-14 23:29
    sccoupe said...
    Microchip has a Pictail, but it uses the prop as well.

    I can't find the video PICtail that uses a Propeller chip. Are you certain that a Microchip design uses a Propeller?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Ken Gracey
    Parallax Inc.

    Follow me at http://twitter.com/ParallaxKen for some insider news.
  • Bill HenningBill Henning Posts: 6,445
    edited 2010-07-15 01:11
    As far as I know, it does not - the only pictail I am familiar with that has decent graphics are their LCD driver boards.
    Ken Gracey (Parallax) said...
    sccoupe said...
    Microchip has a Pictail, but it uses the prop as well.

    I can't find the video PICtail that uses a Propeller chip. Are you certain that a Microchip design uses a Propeller?
    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
    My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
    and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
    Las - Large model assembler Largos - upcoming nano operating system
  • potatoheadpotatohead Posts: 10,261
    edited 2010-07-15 03:50
    @markaeric, it's like that. Generally, I see it being all about how aggressive the transitions are, from color to color and luma to luma.

    Somebody is going to chime in here with a more precise reply. Until then, yes. One nice advantage the Propeller has is it being possible to deal with the whole signal. Tweaks can be made, and one can check out the different signal types all on the same chip!

    I've done a lot of pushing on the TV / composite boundaries. When the colors are far apart on the color wheel, the transition takes more time, and introduces artifacts.

    If colors of a similar hue are desired, it's possible to get the perception of higher resolution, like you say. There are artifacts, but similar color / luma combinations have artifacts that are generally subdued.

    A great example is white on blue text, compared to white on black. When the pixel clock approaches that 8 PLLA number, various color artifacts can be seen. The high contrast display displays them easily, and that's the red / blue fringing on text displays that are over about 32 columns, in the safe area of the display.

    The same text, in the white / blue display shows lesser artifacts and the blue tends to wash them out, leaving text that is far easier to read, in a sense increasing the signal to noise ratio for the viewer. In both cases, the resolution limits are the same, but the perception is different.

    In general, I've found how the signal is produced matters a lot.

    A simple NTSC signal, where there is no color phase shift on the scan lines is like the old computer displays. Artifacts show up huge on those, limiting color to somewhere between 128 and 256 pixels. At the 128, the pixels are large enough that any pixel can be any color, and clearly differentiated from all the other pixels. The "noise" where artifacts are a part of the display is very small in relation to the "signal", the pixel.

    At 160 pixels, some color contrasts show heavy artifacts. Red on bright green, for example, would artifact considerably, making the pixels difficult to see as pixels. It's more like a smudge.

    At the 256 pixels, it's the same, but for less aggressive color combinations.

    On that kind of signal, one needs to choose color transitions that don't have a huge angle on the color wheel, and limit luma changes in the same way. Moderate contrast displays, with larger pixels work very well.

    When the signal is upgraded one notch, so that there is color phase changes on every other scan line, things improve considerably. There are two ways to do this. One is static, where all even lines have one phase, and all odd scans have the other phase. The other way to do it, is to have those phases alternate every other frame.

    The numbers go up some, maybe to 320 pixels being acceptable, but with some limits. There is also dot crawl with the alternating phase, and there is some distortion of the shape in the static mode.

    My potatotext driver allows one to choose the static mode for a good balance between reading higher resolution text (40 to 64 colums in color), and dot crawl, shimmer kinds of effects that people find difficult to look at for things like text, but that work well for movies and such.

    64 columns in color is about 512 pixels of luma, with the usual lower color resolution in play. If a character is the same hue as it's background and a different luma, it will generally render well with this kind of signal, either phase change mode. Static, or dynamic. If those are very different, it generally renders as a "smudge".

    Finally, there is the full on interlaced display. Most of the time, the interlace is used to get more vertical resolution. That means 400 or so lines, instead of 200 or so lines vertically. The horizontal limits really don't change much, unless...

    The vertical resolution is kept the same. Potatotext does this too, rendering higher resolution text on an interlaced display, with only the 200 lines of vertical resolution. That's like the PC "scan doubling" that was popular during the transition from CGA / EGA to VGA. Both scan lines render the same graphics.

    What I found is the artifacts were lowest of all the display methods. It seems most displays can process that data giving one a pretty good display. Newer televisions can render 80 column text pretty darn well, in color on a composite signal. It's actually well beyond what I expected. I've some captures posted here that show a little of that off. In fact, all of my captures here are off of a simple composite connection, and most of them are a lot sharper than the signal limits would lead one to expect.

    I have found ordinary standard definition displays, like all CRT televisions and cheaper SD only LCD TV's, more or less break down over 320 pixels, no matter what the signal looks like. Some are better than others, and there are a few exceptions, like my SONY WEGA television which can render the 80 columns almost as good as the newer HDTV can.

    On the newer HDTVs, they appear to get quite a bit more out of that signal, doing a lot of processing between it, and the display you see. When I get done posting this, I'll try and find the photos I took of the screen rendering the 640 pixel, 80 column text. With most reasonable color combinations, it's clear enough to work with, and I did not expect that.

    I also think that has to do with the special color case of text and simple computer graphics. There are not lots of aggressive color transitions like there would be for most scenes, and the processing seems to work that out.

    Even though the S-video color limits are the same, because the color signal is the same, just carried on it's own wire, pushing them farther than normal is very consistent and a lot lower noise. An aggressive color transition will generate a color artifact, but not a luma one, and it won't stand out anywhere near what it does when the signals are combined. That means the higher luma resolution looks spot on, with the color smudged over the top of it. The perception of higher resolution is really significant in this case, which is why most people "see" higher resolution on a S-video display. Truth is, they are really just seeing a lot less "noise" in the form of artifacts, and they get the full benefit of a sharper luma.

    Most S-video displays will easily render 640 pixels in monochrome. Most composite displays won't, as the luma ends up being rolled off because of how the circuits are designed. Some will eliminate that roll off, if there is no color signal present, but not all do.

    Older TV's and small displays appear to limit resolution to something below or at 320 pixels. Newer TV's will go above that, with the quality depending on the signal, and graphical image presented to them. HDTVs will render even better, even though the signal supposedly doesn't carry enough information. Interesting stuff.

    I find for text, and simple 4 color graphics, the useful resolution of the Propeller on composite is 320 pixels on a phase change, composite display. It's about 160 pixels on a non-phase change. It goes up to 640 pixels on a monochrome display, and something between 320 and 640 pixels on a S-video connection. Most images and most displays will render those correctly these days.

    All of those figures are in the "safe area", not overscan. If overscan is acceptable, like with a small LCD, or with a PC capture card, those numbers go from 640 to a little under 720 in the monochrome, and you can scale that down for the others.

    That translates to 80 column text monochrome, or S-video, 40 - 64 colums composite. Maybe 32 columns, depending on the display size and overall quality.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Propeller Wiki: Share the coolness!
    8x8 color 80 Column NTSC Text Object
    Wondering how to set tile colors in the graphics_demo.spin?
    Safety Tip: Life is as good as YOU think it is!
  • markaericmarkaeric Posts: 282
    edited 2010-07-15 06:10
    Very interesting stuff, potatohead! I've just recently started to get my feet wet in the world of composite/s-video interfaces, so there's a lot of stuff I have yet to wrap my head around. Can't wait to try out your potatotext driver when I get back home (I brought my demo board with me on a business trip, but forgot a composite cable). In the mean time, I would love to see those screen caps tonight if you find 'em..


    "On that kind of signal, one needs to choose color transitions that don't have a huge angle on the color wheel, and limit luma changes in the same way."

    How does this affect white/colors on black? As wouldn't that pose a significant luma change?
  • ericballericball Posts: 774
    edited 2010-07-15 12:44
    For color artifacts you have to think about how the signal is decoded. First a composite signal is run through some kind of filter to separate out the B&W (luma) and color (chroma) signals. Depending on the display this might be a simple low pass filter, a notch filter, a comb filter, or something even more exotic. For S-Video this step isn't required because the signals are on separate wires. And hopefully it's disabled if the signal doesn't have colorburst (so a black & white signal has full bandwidth).

    The next step is to demodulate the color signals into I & Q, U & V or R-Y & B-Y color difference signals. Finally those color difference signals are recombined with the luma signal through a 3x3 matrix to produce the R G & B values.

    The reason color artifacts occur is we are generating a time domain signal which is decoded in the frequency domain. So a change from white to black is a square edge which rings into the higher frequencies. Same thing happens with an abrupt phase shift when changing colors.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Composite NTSC sprite driver: Forum
    NTSC & PAL driver templates: ObEx Forum
    OnePinTVText driver: ObEx Forum
  • potatoheadpotatohead Posts: 10,261
    edited 2010-07-15 15:01
    I would like to point out two things:

    1. No captures until a bit later this morning. They exist on a machine at work...

    2. The composite NTSC sprite driver in Eric's signature above does this process in software, producing really great color.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Propeller Wiki: Share the coolness!
    8x8 color 80 Column NTSC Text Object
    Wondering how to set tile colors in the graphics_demo.spin?
    Safety Tip: Life is as good as YOU think it is!
  • ericballericball Posts: 774
    edited 2010-07-15 16:06
    potatohead said...
    2. The composite NTSC sprite driver in Eric's signature above does this process in software, producing really great color.

    My sprite driver is a special case - you could say it uses color artifacts to create a larger color gamut than the Propeller video generator can do on its own. The secret is changing the luma output at four times the colorburst frequency. This gives the driver full control over the in-phase and in-quadrature color difference signals. The cost is a lot of complexity as it's not possible to retrieve data from HUB RAM while feeding the video generator. Multiple synchronized COGs alternate between outputting a line of video and generating pixel data for the next line in COG RAM.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Composite NTSC sprite driver: Forum
    NTSC & PAL driver templates: ObEx Forum
    OnePinTVText driver: ObEx Forum


    Post Edited (ericball) : 7/15/2010 5:25:12 PM GMT
  • markaericmarkaeric Posts: 282
    edited 2010-07-16 00:15
    ericball said...


    My sprite driver is a special case - you could say it uses color artifacts to create a larger color gamut than the Propeller video generator can do on its own. The secret is changing the luma output at four times the colorburst frequency. This gives the driver full control over the in-phase and in-quadrature color difference signals. The cost is a lot of complexity as it's not possible to retrieve data from HUB RAM while feeding the video generator. Multiple synchronized COGs alternate between outputting a line of video and generating pixel data for the next line in COG RAM.


    Wow! That's a clever trick!

    ericball said...

    The reason color artifacts occur is we are generating a time domain signal which is decoded in the frequency domain. So a change from white to black is a square edge which rings into the higher frequencies. Same thing happens with an abrupt phase shift when changing colors.

    So if colorburst is used during sync, a change in the croma signal beyond the rate that color ntsc/pal allows (over composite) will most likely result in color artifacts/smudging even if it was from black to white/gray?
  • markaericmarkaeric Posts: 282
    edited 2010-07-17 11:18
    Might it be possible to "overdrive" the colorburst signal, and scale it with an increase of resolution? It may be possible that some displays have a decoder PLL flexible enough to lock on to non-standard frequencies.
  • potatoheadpotatohead Posts: 10,261
    edited 2010-07-17 17:35
    Nope. It's got a very narrow tolerance to prevent color variations. It's tight enough that using a resonator instead of a crystal is enough to lose the color.

    The next step up from s-video is component, or vga, or digital.

    If it didn't take so damn many pins, I would have already done a Y, Cb, Cr component driver for Prop I. What I wanted to do was run the Luma nice and high, and the color at a reduced resolution for a balance on images overall. It also would work great for higher color images, but it's gonna cost about 9 pins, and three cogs. For a text / tile / sprite graphics display, the color could be sharp too, but costly in terms of RAM.

    BTW, if you don't want color, sending a monochrome signal into the Y input of a component device yields excellent resolution. It's often better than the luma portion of an S-video input, and often can be done progressive scan (480p +) for non-interlaced, over 400 line resolution. Maybe that should be done one of these days. A monochrome progressive scan signal could do 80x50 text, in grey scales, and look tack sharp too.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Propeller Wiki: Share the coolness!
    8x8 color 80 Column NTSC Text Object
    Wondering how to set tile colors in the graphics_demo.spin?
    Safety Tip: Life is as good as YOU think it is!
  • markaericmarkaeric Posts: 282
    edited 2010-07-17 17:57
    Bummer, because there are so many smallish (3 to 9") LCDs that have decent resolution, but only have composite video inputs. Such a waste.
  • ericballericball Posts: 774
    edited 2010-07-18 01:59
    markaeric said...
    ericball said...

    The reason color artifacts occur is we are generating a time domain signal which is decoded in the frequency domain. So a change from white to black is a square edge which rings into the higher frequencies. Same thing happens with an abrupt phase shift when changing colors.
    So if colorburst is used during sync, a change in the croma signal beyond the rate that color ntsc/pal allows (over composite) will most likely result in color artifacts/smudging even if it was from black to white/gray?
    Kinda. First, colorburst is 9 cycles of 3.5795 MHz (NTSC) during the horizontal blank period which the TV uses to sync a PLL which is then used (free running) during active video to demodulate the color difference signals.

    But your question is why an abrupt black to white change causes a color artifact. It's because although the change is nice and clean in the time domain, it has a significant frequency component near or at the colorburst frequency. This component gets picked up by the filters as a color signal and then demodulated into a color artifact. (Actually, that time domain edge probably isn't as clean as we think since all signals are analog and are thus imperfect.)

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Composite NTSC sprite driver: Forum
    NTSC & PAL driver templates: ObEx Forum
    OnePinTVText driver: ObEx Forum
  • Oldbitcollector (Jeff)Oldbitcollector (Jeff) Posts: 8,091
    edited 2010-07-18 19:56
    This is heresy, but perhaps would something like this be the answer.. It's getting some very impressive results with another unnamed micro.

    Instead of using the Propeller to generate video onboard, maybe I could generate what this circuit needs?

    Heck, it looks like you could simply feed this the prop VGA signals and get composite/svideo.

    OBC

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Propeller Feature Projects: PropellerPowered.com
    Visit the: PROPELLERPOWERED SIG forum kindly hosted by Savage Circuits.

    Post Edited (Oldbitcollector) : 7/18/2010 8:02:53 PM GMT


    873 x 557 - 59K
  • Bill HenningBill Henning Posts: 6,445
    edited 2010-07-18 20:31
    Yes, at an increased cost.

    I am thinking about it for Morpheus, due to having 256 colors for TV then [noparse]:)[/noparse]

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
    My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
    and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
    Las - Large model assembler Largos - upcoming nano operating system
  • Karl SmithKarl Smith Posts: 50
    edited 2010-07-18 20:51
    OBC, that looks like part of the uzebox, it uses an AVR 644

    Here is the link http://belogic.com/uzebox/
  • Oldbitcollector (Jeff)Oldbitcollector (Jeff) Posts: 8,091
    edited 2010-07-18 21:11
    Yes, it was clipped from uzebox... Uzebox is doing some incredible video right now..
    I don't see why the Propeller couldn't come up to speed.

    I'm looking at this from the viewpoint of seeing some standardization of video drivers.
    As well as a possible method for seeing a boost in both resolution and number of color displayed.

    There are some impressive VGA drivers for the Propeller right now..
    Something like this might bring everyone under one roof.

    OBC

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Propeller Feature Projects: PropellerPowered.com
    Visit the: PROPELLERPOWERED SIG forum kindly hosted by Savage Circuits.
  • Karl SmithKarl Smith Posts: 50
    edited 2010-07-18 21:27
    I know the original PropGFX prototype used the·AD723/4/5 but that was so long ago I don't know where the link is
Sign In or Register to comment.