Shop OBEX P1 Docs P2 Docs Learn Events
VGA - Where to start? — Parallax Forums

VGA - Where to start?

John BoardJohn Board Posts: 371
edited 2012-04-12 20:50 in Propeller 1
G'day,

I am wanting to play around with prop's VGA capabilities... but I have no idea where to start. I am currently using a demo board, and a 18" VGA monitor. Does anyone have any suggestions where to start? I.E. A good Object or something of the sort.

Thanks,

John

Comments

  • TubularTubular Posts: 4,706
    edited 2012-04-10 01:52
    G'day John

    Installed with your Propeller Tool software is a directory (Program Files/Parallax/Propeller Tool/Examples/Library)

    In there you'll find about 6 VGA demos that should run straight up with the Demo board. Start with VGA_demo.spin
  • John BoardJohn Board Posts: 371
    edited 2012-04-10 04:00
    Thanks, already tried it though, I got something good to work with - not as easy to use as the Hydra graphics libraries though :/

    -John
  • localrogerlocalroger Posts: 3,452
    edited 2012-04-10 15:43
    Most of the stock VGA drivers are either not very dense because of the dot rate, or are very very dense and somewhat memory intensive. You might want to check out my 40 x 18 ROM font driver which I created to plug this gap:

    http://obex.parallax.com/objects/796/

    It supports multiple colors per line, reverse text, user defined characters, and uses the ROM font to save Hub RAM.
  • TubularTubular Posts: 4,706
    edited 2012-04-10 16:20
    Ok looks like you're up and running. What do you want to do with VGA ?

    Kye has a 160x120x64 colour driver in the obex. By changing the resistors it can be used as 64 greyscale mode which is useful for photographic work. Its easy to use because each pixel is just a single byte.

    Kuroneko has recently posted high character count text modes - 100x50, 100x75, 128 x 64 characters, with selectable foreground and background colours. These may not be in the obex yet.

    Bill Henning has posted several VGA drivers and I think these are also in the obex.

    Rayman spent some time documenting the VGA driver, in case you want to really dive in and modify

    The main limitation is hub memory. 160x120x1byte per pixel is 19200 bytes, or just under 60% of hub ram. 128x64 chars is 50% of hub ram using indexed foreground/background colours.

    There are other VGA variants, this is just a random selection.
  • RaymanRayman Posts: 14,840
    edited 2012-04-10 16:21
    Personally, I've found the 1024x768 (XGA) driver the best comprimise between space required, cogs, and resolution.
    It also supports a mouse.
    I've done a lot with that one, including an IDE (VisualSpin).

    There's also "HiResVGA" with a text demo and new GUI appnote from Parallax that takes less space, but it's monochrome (too boring for me...)

    Kuroneko just posted some interesting new drivers that are like hiresvga, but with multi-color.
    If I were to start over, I'd carefully consider using this one...
  • kuronekokuroneko Posts: 3,623
    edited 2012-04-10 17:26
    localroger wrote: »
    You might want to check out my 40 x 18 ROM font driver ...
    ... or its [post=1063168]slightly fatter sibling (50 x 18)[/post] ...
  • Oldbitcollector (Jeff)Oldbitcollector (Jeff) Posts: 8,091
    edited 2012-04-10 18:09
    If it's graphics you are looking for, you might take a look at Jim Bagger's Doug's Tile Driver.

    A couple of us did some moderately interesting gaming demos with it on Savage Circuits.
    http://www.savagecircuits.com/forums/showthread.php?529-VGA-Spyhunter-test-using-Tile-Driver

    I can't lay my fingers on the original thread here in the Parallax forums. Perhaps someone will have the link.

    OBC
  • kuronekokuroneko Posts: 3,623
    edited 2012-04-10 18:17
    Oldbitcollector (Jeff) wrote: »
    I can't lay my fingers on the original thread here in the Parallax forums. Perhaps someone will have the link.
    Maybe it's this one [thread=127123]Full Color Tile Driver Thread[/thread]?
  • Oldbitcollector (Jeff)Oldbitcollector (Jeff) Posts: 8,091
    edited 2012-04-10 18:27
    Yeah! that one!.. Perhaps I was mistaken, looks like Doug's doing, but good stuff abounds here..

    OBC
  • potatoheadpotatohead Posts: 10,261
    edited 2012-04-10 19:41
    Yep, you can also find some documentation on it, example code and such in my blog. "pixel art" I'll look it up later, if desired.
  • localrogerlocalroger Posts: 3,452
    edited 2012-04-11 17:49
    kuroneko wrote: »
    ... or its [post=1063168]slightly fatter sibling (50 x 18)[/post] ...

    Yean, kuroneko tightened up the timing a bit and got some more columns in there. But he never put it in the obex. (I wouldn't mind if it ended up there.)
  • John BoardJohn Board Posts: 371
    edited 2012-04-11 19:06
    Thanks guys, will try these ones out later.

    As for my purpose, I am just wanting a good comprehensive way of displaying data on a screen. One more thing, although it is probbably a proccess which requires great time and patience... how do I make a VGA driver? I.E. How does it work?

    Thanks,

    John
  • RaymanRayman Posts: 14,840
    edited 2012-04-11 20:15
    Writing a VGA driver is pretty difficult. Maybe only writing TV driver is worse...
    I think Kye posted a bare-bones, from scratch VGA driver, so I'd look for that...

    I posted a more documented version of Parallax's VGA driver somewhere...
  • ericballericball Posts: 774
    edited 2012-04-12 05:47
    I'd recommend reading section 4.10 of the Propeller Datasheet which describes the video generator. Video (VGA or TV) on the Propeller is software defined with some hardware assistance, so there's a lot of flexibility. The purpose of the video driver is to translate data structures into video generator inputs. The three main restrictions are:
    1. limitations of the hardware, i.e. in VGA mode the video generator outputs to 8 pins which then typically translates to 64 colors.
    2. timing - each PASM instruction takes time to execute and during that time the video generator is consuming pixels
    3. HUB RAM - 32K isn't enough for more than a tiny bitmap. Therefore video drivers will use different techniques to reduce how much RAM is required while still generating a high resolution display.

    And I'd argue that VGA is harder than TV for reason #2. VGA frequencies are at least double TV frequencies.
  • potatoheadpotatohead Posts: 10,261
    edited 2012-04-12 05:52
    That was going to be my basic comment. Low raster frequencies allow for more operations to happen / scan line. On VGA, Jim Bagley (baggers) found 640x200i will display on modern screens. Comparable to TV, though still faster.
  • tonyp12tonyp12 Posts: 1,951
    edited 2012-04-12 17:38
    If you want to know how it works, my simple barebone driver does give some clues.
    http://forums.parallax.com/showthread.php?134552-Barebone-VGA-driver
  • John BoardJohn Board Posts: 371
    edited 2012-04-12 19:31
    I reckon I'd better learn ASM to get into this deep stuff ;)

    By the way, are there any good ASM tutorials out there?

    -JOhn
  • potatoheadpotatohead Posts: 10,261
    edited 2012-04-12 20:50
    My first work is here. http://forums.parallax.com/attachment.php?attachmentid=58857&d=1235275582

    Got a second in progress. (day job, plus startup is keeping me slow, right now...)

    It's light, but the deSilva tutorial it's attached to is pretty great. Graham knocked out some of the first great stuff many of us learned from, right here in the forum.

    You might find C works for you too. A pong game with driver has been written. Nice work actually. So that's another route you've got.

    Go digging in here, find something you can relate to, and start asking some questions!

    http://forums.parallax.com/showthread.php?111166-Propeller-Resource-Index

    If you are thinking about TV drivers, I can't recommend Eric Ball's work more highly. There are a few of us who enjoy this kind of thing. Eric has pushed the TV in several directions, leaving templates behind. :)

    I personally got started slogging through Chip's TV and VGA drivers. Honestly, I still really like them. They go underused a lot of the time. More capability there than many people think. Anyway, my start involved commenting some existing drivers, making small changes, slowly building up to my own. It's a lot of fun! (graphics_demo.spin, and friends)

    When you do that, get the driver up with a known display, then you can make small changes to verify each thing does what you think it does, then strip it down to a signal with test / static data, like color bars, or a checkerboard, then add in your desired pixel / tile / sprite loops and COGS.

    Looked for the thread, but I can't find it. I know at least one of Eric's drivers had "the rules"

    Those are (roughly)

    Start with a static image, establish your timings, do the math, then write up the bare minimum to get a signal. (this is why working from existing is so valuable early on) Make ONE change at a time, testing, building, keeping your old code revisions religiously.

    A scope helps, but many drivers, arguably the majority of them, have been done without one.

    From there, you get to where most of the signal elements are stable. Then you can work on the pixel / sprite / tile / bitmap loops. I find a bitmap easiest to start with, just because it's a simple linear memory read. Only takes a few instructions. There are places you can play rather freely, once you've got a signal framework up and running.

    So far, we've seen a two kinds of drivers written. Lots of variations on these.

    1. Single COG signal + Pixels. One can do bitmaps & tiles with this fairly easily. There isn't enough time to really do sprites, though little things like a mouse or cursor are possible.

    2. Multi-COG drivers. The most common is the "scan line" type driver. You build up one COG to take data a scan line at a time. Buffer that, so the COG can be reading a full one, while another COG or COGS are filling future ones. Use these buffers round robin style, if there is more than two.

    In this way, the signal COG spends most of it's time just doing a bitmap! It's just a single line bitmap. Some optional tasks, like color assignments, and polling for signal type changes can be done too. Any other COGS sync to the signal COG, which writes a state bit to indicate what it's doing, spending all their time building up scan lines from tables of sprites, tiles, bitmaps, whatever. More COGS = more objects = more colors on the display, in general.

    3. "graphics server" type drivers, where the entire Prop is turned into a graphics engine. One communicates with it, either serially, or on an 8 bit bus for better throughput. The Prop runs it's drivers, and the comms. It's then driven by basically anything that can send it graphics data. Google PropGFX for one fairly well known example. Microcontrolled and OBC have done similar efforts.

    Props work well on displays because displays can be parallelized in various ways, allowing the whole chip to contribute meaningfully to one, if desired. This has been done with multiple props doing even and odd scan lines, for a higher resolution display, but that's not been seen outside the "can I do it?" realm of things.

    Cluso likes one pin, minimal TV drivers. These are nice for simple graphics displays and text, debugging, etc...

    My personal interest is the TV. I just like TV graphics, and the hacks to get colors and push the display are many and varied. A Propeller can output monochrome, standard color composite and an S-video display rather easily. Technically, a component driver can be done too, I just don't think anyone has done one for lack of cheap, small displays. Many TV's have these inputs, and one of these days... :)

    TV does a great monochrome signal all around. In color, NTSC is solid, PAL is kind of crappy with varied results among the drivers that exist.

    On VGA, Props perform well, and there are a lot of options!

    Have a lot of fun. :)
Sign In or Register to comment.