Shop OBEX P1 Docs P2 Docs Learn Events
Highest resolution photo on TV? — Parallax Forums

Highest resolution photo on TV?

RaymanRayman Posts: 14,827
edited 2009-05-19 10:30 in Propeller 1
What's the best resolution anybody has done on TV directly from the Prop?

There's been a lot of talk about adding external ram...· I have a plan (although it may well be flawed) to use the GRAM from LCD display I'm working with as an external frame buffer.

Just want to know if this will be new, or if someone has already done it...

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

Comments

  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2009-05-10 22:14
    Rayman,

    By GRAM, are you referring to VRAM or SG(D)RAM? Are any of these parts in current production?

    -Phil
  • ColeyColey Posts: 1,110
    edited 2009-05-10 22:17
    Ray,
    Baggers has done 640x480 and 720x576 already it was a mixed mode text char map and 4 colour tiled graphics.
    Why don't you PM him...he is extremely busy at the moment though with E3 coming up tongue.gif

    Coley

    EDIT:
    NTSC 704x480 mixed text and graphics
    http://forums.parallax.com/showthread.php?p=717799

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    PropGFX - The home of the Hybrid Development System and PropGFX Lite

    Post Edited (Coley) : 5/10/2009 10:32:51 PM GMT
  • RaymanRayman Posts: 14,827
    edited 2009-05-10 22:38
    Phil: Most LCDs have a controller with GRAM. It's dual ported so that it can write to the LCD screen and be written to by the user interface at the same time...

    Coley: I'm trying to do photos (each pixel an arbitrary color)...

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
  • ColeyColey Posts: 1,110
    edited 2009-05-10 22:55
    Ray,

    I realise that but you asked what resolution, the only reason he used tilemaps was because of the RAM limitations smile.gif
    I used that example to show what resolutions _could_ be acheived.....
    Either way I can't think of anybody better to get in touch with.

    Coley

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    PropGFX - The home of the Hybrid Development System and PropGFX Lite
  • RaymanRayman Posts: 14,827
    edited 2009-05-10 23:02
    Coley: Yes, I remember a post from Baggers a long time ago with a photo of his wife and kids (I think) with the headline "Can the Prop II do this?"...

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
  • ColeyColey Posts: 1,110
    edited 2009-05-10 23:16
    Ray,

    Yeah that was his DXT1 decoder, I think it was 256x192 though

    http://forums.parallax.com/showthread.php?p=742451

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    PropGFX - The home of the Hybrid Development System and PropGFX Lite
  • BaggersBaggers Posts: 3,019
    edited 2009-05-11 07:57
    Hi guys,

    I've done two different larger than prop-ram displays, using only a Prop and HUB-RAM

    1st was 240x160 8bit RLE method, which was for the oxygene streamer demo, which had enough RAM to have two displays in + ( code including the 8K alone for the FSRW [noparse]:D[/noparse] )

    2nd the highest res I've done was 15bit DXT1 picture, was 256x192 ( was 24KB per image ), I also could have increased it to 256x240 removing the ability to add sprites.

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

    ·
  • RaymanRayman Posts: 14,827
    edited 2009-05-11 12:33
    That's pretty impressive!· The downside, of course, is that it uses up almost all of HUB RAM...

    I think my LCD's GRAM actually makes·for nice external memory for the Prop to use to display photos on TV.

    By setting up a window into the GRAM, you get a circular buffer of arbitrary size that autoindexes.· All you have to do is strobe the RD line to have a new byte appear on the 8-bit data bus.· Strobing again gets you the next byte...

    There doesn't appear to be enough time to read in the bytes while doing the WAITVIDs though.· But, there does appear to be enough time to RDLONG a whole horizontal line of colors from HUB RAM during horizontal non-photo time.· So, the current plan is to use another cog to read in a horizontal line from the GRAM to HUB RAM during the visible portion of the scan line.· The TV cog can then read in this line during the horizontal non-photo WAITVID times.

    I'm currently modifying the standard TV.SPIN driver by repurposing the "colortable" array as the horizontal line buffer.· There are three WAITVIDS for the horizontal sync and porches that give enough time to fill this array from HUB RAM.· Then, the other cog has the whole visible photo time to reload the HUB RAM buffer with a new scan line.· I just set the vscl to give 4 pixels only and replace the one tile WAITVID (for 16 pixels) with 4 WAITVIDS of 4 pixels each...

    Of course, there could still be a fatal flaw here that I haven't though of...· I currently am just filling the colortable with a constant set of colors to produce vertical stripes on the TV screen.· But, I'm not sure I have it right yet.· There's some funny business with the TV driver (like why do I need to xor the colors with "phaseflip"?) that I may need to figure out...

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
  • ericballericball Posts: 774
    edited 2009-05-11 13:13
    From a signal perspective your top S-Video resolution is 756x480 (NTSC), composite is more like 252x480. (As per tv.spin, when vcfg[noparse][[/noparse]26] := 0 the msb broadcast pin is the chroma signal.) Of course, some of that gets lost to overscan depending upon the display device.

    Check out my colorbar template & 240H driver (links in my sig). You may find that code easier to modify than tv.spin.

    The phaseflip is for PAL, not required for NTSC.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Composite NTSC sprite driver: http://forums.parallax.com/showthread.php?p=800114
    NTSC color bars (template): http://forums.parallax.com/showthread.php?p=803904
  • RaymanRayman Posts: 14,827
    edited 2009-05-11 14:35
    ericball: Your driver does look a lot simpler! I may ditch TV.spin and use yours instead... It is actually closer to what I want anyway.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
  • RaymanRayman Posts: 14,827
    edited 2009-05-11 14:40
    I guess another question, if all goes as planned, is how well a photo will actually work given the TV palette... It may take some Photoshop prep work to make it look nice...

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
  • BaggersBaggers Posts: 3,019
    edited 2009-05-11 15:20
    Ray, photo's using the TV palette isn't the hottest of things, but it does give it that retro look and feel [noparse]:)[/noparse]

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

    ·
  • RaymanRayman Posts: 14,827
    edited 2009-05-11 16:13
    I have something Phil mentioned in another thread on my mind too... You can use a cog counter to generate a short pulse.... I'm not sure if it would actually work in this situation, but maybe I could generate a strobe on the read line with just one instruction instead of two.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
  • rokickirokicki Posts: 1,000
    edited 2009-05-11 18:27
    > code including the 8K alone for the FSRW

    Hmm, I don't know how you're getting this; no release of fsrw has ever required that much memory.

    The current fsrw is less than 4096 bytes total (this is the sum of buffers required and code space).
  • BaggersBaggers Posts: 3,019
    edited 2009-05-11 19:19
    Oh right sorry rokicki, I stand corrected, I must have added something with it, and miscalculated it.

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

    ·
  • RaymanRayman Posts: 14,827
    edited 2009-05-18 12:18
    My evil plan was foiled by fine print! Turns out my particular LCD controller decided not to implement auto indexing on read, only on write. This despite two seperate diagrams in the datasheet showing sequential reads. Only in the fine print does it say that address does not auto increment on read. But, there are other LCD controllers that look like they do.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
  • hinvhinv Posts: 1,255
    edited 2009-05-19 07:23
    Hi Rayman,

    What LCD were you looking at?
    Wouldn't every lcd have ram for each pixel otherwise they would flicker like an old tv?
    If that is the case, then it seems to me that if you are able to get one with a good interface(for read and write), you solved the framebuffer issue.
    Am I tracking you on this one?

    Thanks,
    Doug
  • RaymanRayman Posts: 14,827
    edited 2009-05-19 10:28
    I think it would work.· But, maybe it would have to be connected to the lower Prop pins, so that one can do a WRWORD or WRBYTE with INA as the source...· I only found one controller QVGA size that allows multiple reads, but I can't find it for sale anywhere...·

    The Oled96Prop allows sequential reads, but it doesn't have that much memory...

    The Sparkfun 128x128 OLED has a decent amount of memory and allows sequential reads.· I may try that one at some point.

    But, right now, I think the best thing would be an 8 or 16 bit sram with a counter for fast sequential access...

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
  • RaymanRayman Posts: 14,827
    edited 2009-05-19 10:30
    Still, my LCD does make for a large, fast input buffer. I can write a lot of bytes to it very fast... Don't have a burning application for that though...

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
Sign In or Register to comment.