Shop OBEX P1 Docs P2 Docs Learn Events
AD725 save video resources/memory? — Parallax Forums

AD725 save video resources/memory?

Oldbitcollector (Jeff)Oldbitcollector (Jeff) Posts: 8,091
edited 2008-10-26 13:36 in Propeller 1
I've been looking at that Uzebox again and thinking that perhaps that AD725 NTSC/PAL RGB Encoder
might be a way to free up resources used by video on the Propeller. Is it possible that this chip might
be an answer to saving memory used currently, or is it simply an output device?

It certainly looks impressive as far as resolution and colors are concerned, but what is doing the work?

AD725
www.analog.com/en/digital-to-analog-converters/video-encoders/ad725/products/product.html#quicklinks

OBC

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?

Getting started with a Propeller Protoboard?
Check out: Introduction to the Proboard & Propeller Cookbook 1.4
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card connected? - PropDOS

Comments

  • tpw_mantpw_man Posts: 276
    edited 2008-09-27 17:05
    Looks like all it does is basically convert VGA to NTSC, so it makes it easier for the processor to generate the video signal because RGB certainly seems much easier to generate than NTSC. In other words, it doesn't help the propeller because you still need to generate RGB.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    I am 1011, so be surprised!


    Advertisement sponsored by dfletch:
    Come and join us on the Propeller IRC channel for fast and easy help!
    Channel: #propeller
    Server: irc.freenode.net or freenode.net
    If you don't want to bother installing an IRC client, use Mibbit. www.mibbit.com
    tongue.gif
  • Oldbitcollector (Jeff)Oldbitcollector (Jeff) Posts: 8,091
    edited 2008-09-27 17:15
    Ah, finally located the schematic for the thing.. Massive resistor DACS used to generate the signals. 8 datalines. Wow.

    OBC

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    New to the Propeller?

    Getting started with a Propeller Protoboard?
    Check out: Introduction to the Proboard & Propeller Cookbook 1.4
    Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
    Got an SD card connected? - PropDOS
  • JoJo Posts: 55
    edited 2008-09-27 17:17
    Don't think so, it seems to mostly just do the same thing that the propeller counters do in video mode (well,
    a fair bit more sophisticated and tuned to this specific task, but nonetheless similar function)
    The propeller resource that we're short of for any better graphics is primarily memory to store the bitmap
    into.

    A widely used technique in demos is not to have any bitmap for graphics: instead, generate the video signal
    algorithmically. Not as widely useable, but certainly can produce impressive visual demos beyond what would
    appear to be the normal limits of the hardware.

    Mind you, this leads me to wonder if a vector based display on the propeller would avoid some of the
    current memory imposed resolution limits; instead we'd have limits based on drawing complexity, eg
    max number of lines. Have a few cogs scan through the vector space computing intersection with
    scan-line-about-to-be-draw. This approach would only need memory for 2 scan lines (well, plus a lot
    of code smile.gif ) [noparse][[/noparse]1 line to draw into, 1 line to draw from]

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    ---
    Jo
  • BaggersBaggers Posts: 3,019
    edited 2008-09-27 18:07
    Jeff,
    The AD725, just handles converting a PAL or NTSC, RGB input signal to a composite and/or s-video output signal, so basically you feed it ( the sync values and ) the RGB values that you want on screen, and it handles the rest, so sorry to disappoint you on the fact of it being able to save memory on the Prop, it won't do that for you, it will just give you an RGB pixel colour, instead of the 86 colours we have now, ( obviously depepnding on how many io-pins you give it, for each R,G and B.

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

    ·
  • pemspems Posts: 70
    edited 2008-10-25 23:15
    Jo
  • BaggersBaggers Posts: 3,019
    edited 2008-10-26 09:05
    pems, do you mean something like PropGFXLite ?

    http://www.propgfx.co.uk/forum/Blah.pl?m-1207995807/s-all/

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

    ·
  • pemspems Posts: 70
    edited 2008-10-26 12:51
    Hey Baggers

    I remember reading briefly about your 3d rendering work. In fact, that's the reason i thought about having prop as a vector graphics accelerator.

    I don't know much yet about prop application for video (i read a bit about it), so maybe you can answer a few of my questions:
    - from what i understand, the resolution and color depth that one can get out of prop depends on how you balance the available resources (i.e cogs and memory). What's the max resolution one can achieve with say 3 bits color depth (i.e 1 bit per component). Does it depends on teh output format? (i.e VGA, NTSC, PAL)
    - let's say i want 320x240 or higher, and accelerate drawing of such primitives like lines, circles, arches and fonts for drawing a GUI - is this idea even feasible for a prop?
    - i see your model renders with quite a low res (looks blocky) - is this because of a hard prop limitation, or are you just experimenting with least resources?

    Cheers
  • BaggersBaggers Posts: 3,019
    edited 2008-10-26 13:36
    pems,
    The max resolution depends on if you want bitmap or charactermap,
    Charactermap, in VGA has been driven to an amazing 1600x1200 resolution by none other than Chip himself.
    Bitmap, you could have 512x511 1bit but that would be all you could have, because you'd have 48 bytes of ram left.

    as for 3bits color depth, you might as well make it 4 unless you don't mind the fact that the data will overlap bytes. RGBRGBRG BRGBRGBR GBRGBRGB etc.
    so if you go 4bits, you could paletise it, and have 16 colours, not just 1bit rgb. especially since NTSC and PAL aren't direct RGB values.
    so 4bits, you could have 320x200 ( = 32,000 bytes ) you're drivers would have to be in cogram, for the display, and for the communications with the host, and drawing primitives.
    or 256x248 ( = 31744 bytes ) again you would have to have drivers in cogs and no spin help, as too much of ram is used for these resolutions [noparse]:)[/noparse]

    as for the my model renders looking blocky, that was the 8bit mode, where you can have any pixel on screen any of the props colours, and the res was 128x96 ( 128*96 * 2 = 24K, leaving room for other stuff, like palette, poly data, etc ) as it was double buffered to avoid any flickering that may appear, although it does clear the screen and draw the character rather quickly, as it could handle 3 of them at that size at 60fps, also, I have it running in 4colour mode at 256x192 and 2colour speccy mode too, since it's the same code on the host side, just a change of display drivers and poly drivers [noparse]:)[/noparse]

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

    ·
Sign In or Register to comment.