Shop OBEX P1 Docs P2 Docs Learn Events
bit bang VGA — Parallax Forums

bit bang VGA

dr hydradr hydra Posts: 212
edited 2013-02-24 15:10 in Propeller 1
Has anyone created a bit bang video VGA driver using the propeller? I am looking to increase the number of colors from 6 bits to 15 bits. My idea is to use two sync cogs to bit bang the video data to 15 pins (5-5-5 RGB). The idea is to have one cog load the data into the its own cog RAM while the other cogs is driving data (from its RAM) to the pins. Then after one line of video is done the two cogs would switch roles...

Comments

  • RaymanRayman Posts: 14,665
    edited 2013-02-22 11:02
    I think you'd need external memory to do this, right?
    I've thought about directly driving VGA from external memory chips controlled by the Propeller.
    Only problem is that you have to then juggle updating the screen during screen refresh...
  • dr hydradr hydra Posts: 212
    edited 2013-02-22 11:12
    Actually, I am hoping to reduce the resolution down to make it work inside the hub memory...probably around 128x240...that should fit into the hub memory...
  • tonyp12tonyp12 Posts: 1,951
    edited 2013-02-22 11:21
    using:
    movs label,#data
    mov counter,#128
    lable mov outa,data
    add lable,#1
    jnz counter,#lable

    Would get you a pixel rate of 6.6mhz, those will be some wide pixels.
    if you unrooled the loop, you would have no room to store the data for a whole line.
    So your best bet would be to use regular vga driver as is with 6bit and start a second cog (easy to sync) that do 8bit
    So it will get you 14bit Rrrrr_Ggggg_Bbbb.
    But now comes the propblem, where are you gone get store this color and pixel data as your 128x240 would use 54k
  • dr hydradr hydra Posts: 212
    edited 2013-02-22 11:40
    the memory would be a problem...I could reduce the resolution down to 96x160..that should fit...however, how would you sync the two cogs?
  • tonyp12tonyp12 Posts: 1,951
    edited 2013-02-22 12:00
    some info on syncing two cogs pll
    http://www.linusakesson.net/programming/propeller/pllsync.php

    But if your plans is to bit bang really low-res vga, no need for pll.

    Just start both cogs with a cnt number far ahead in future (pass it along to cog with PAR)
    and then you have both cogs use
    mov start,par
    waitcnt start,#0
    But at your low resolution 16bit color (use 6bit for green), I think you could do it in one cog.

    rdword data,hubaddr
    shr data,#10 ' may have to adjust for the pin group (16pins) used for vga colors.
    or data, syncpins ' H and V sync pin are always high during pixel display
    mov outa,data.

    Use my bit banging barebone vga
    http://forums.parallax.com/showthread.php/134552-Barebone-VGA-driver
  • dr hydradr hydra Posts: 212
    edited 2013-02-22 13:22
    tony,

    Thank you for your help...i am still thinking through the options...I like the two cogs waitvid option, but syncing the two cogs has me worried. If it is off a little the screen will get jiggly. Any suggestions?
  • tonyp12tonyp12 Posts: 1,951
    edited 2013-02-22 13:29
    It's is never off, all cogs are run by a single master cnt.

    But due to memory constraints, your pixels will be so wide I think you can do it in one cog
    and no need to interleave two cogs.
  • dr hydradr hydra Posts: 212
    edited 2013-02-22 13:54
    I have been working through the numbers...If I use a tile map (16x16)...I could increase my resolution back to 256x240 and use a 14 bits palette system. Each tile palette could be chosen from 4 different 14 bits colors(like a color look up table). I would use the remaining cogs to create a frame buffer/line buffer. So, I would prefer the two cog waitvid idea (the pixel clock would be to slow to use the it bang method)...I see how the waitcnt will sync the cogs in the beginning, but will the two cogs stay sync'd through the all the waitvid functions?
  • kuronekokuroneko Posts: 3,623
    edited 2013-02-22 16:03
    dr hydra wrote: »
    ... I see how the waitcnt will sync the cogs in the beginning, but will the two cogs stay sync'd through the all the waitvid functions?
    Don't see why not (if done properly). I wrote a 4 cog full colour driver (2 cogs LHS, 2 cogs RHS) and there are no sync issues. Besides, these days a single cog can handle 8bit colour + 2bit sync on its own, IOW 16bit colour with two cogs is possible. What's your intended signalling resolution (e.g. 256x192 can be signalled as 1024x768)?
  • localrogerlocalroger Posts: 3,451
    edited 2013-02-24 14:40
    VGA monitors are much pickier than NTSC about video timing. You might have real trouble bit-banging the horizontal scan at just the right frequency. When using the PLL's the first step is generally to pick a dot clock that is compatible with the signal timing; with bit banging you're stuck with 80 MHz -- worse, really, because while you can use waitcnt to get 1-clock sync, all instructions take 4 clocks or more to execute.
  • tonyp12tonyp12 Posts: 1,951
    edited 2013-02-24 15:10
    >worse, really, because while you can use waitcnt to get 1-clock sync, all instructions take 4 clocks or more to execute.
    That was not the problem, as 200+4, or 211+4 is still 12.5ns granularity
    It was more about hub access being in sync if you get your pixel data from there.
    So that is why all vga drivers that use hub are a little slow and have specs of 59.4 frames a second

    My waitcnt vga routine uses these values: 
    waitcnt  hsync,#152    ' 1.9 micro seconds back porch 
---
hhigh    long   2086   ' 2086*12.5ns = 26.075 micro seconds     [ these values are 2 ticks too high so to align with hub reads ]
hlow     long   306    ' 306 *12.5ns =  3.825 micro seconds     [ if no hub access, you should/could use 2085 and 305 ]
Sign In or Register to comment.