Shop OBEX P1 Docs P2 Docs Learn Events
VGA tiled text console driver — Parallax Forums

VGA tiled text console driver

pedwardpedward Posts: 1,642
edited 2013-04-13 03:52 in Propeller 2
Here is a VGA text console driver. Right now I've got it configured as a retro 40x25 console, but you can very easily modify it to be any resolution. I chose 40x25 because it takes 1000 bytes of memory.

It uses a font I got from the PixelFont ROM Editor. The font is just a bin file containing the bitmaps for chars 1-127, with 0 being blank.

I took the .pf binary file from PixelFont and carved it into the bin file with DD: dd if=font.pf of=font.bin count=1016 skip=8

This is a tile display driver, assembling the scanlines one at a time, with a foreground and background color indicated by the colors variable. Colors are per scanline, with some rewriting, and additional memory usage, you could do an IBM PC type of color mechanism.

I haven't optimized it by any means, but tried to make it readable and efficient where possible. I unrolled the RDXXXX loop to avoid additional shifts, with the cache it should be very efficient.

vga_tty.jpg

Comments

  • SapiehaSapieha Posts: 2,964
    edited 2013-04-11 04:38
    Hi pedward.

    Don't function for me.
    As my little LCD VGA can only display 800x600 resolution
    pedward wrote: »
    Here is a VGA text console driver. Right now I've got it configured as a retro 40x25 console, but you can very easily modify it to be any resolution. I chose 40x25 because it takes 1000 bytes of memory.

    It uses a font I got from the PixelFont ROM Editor. The font is just a bin file containing the bitmaps for chars 1-127, with 0 being blank.

    I took the .pf binary file from PixelFont and carved it into the bin file with DD: dd if=font.pf of=font.bin count=1016 skip=8

    This is a tile display driver, assembling the scanlines one at a time, with a foreground and background color indicated by the colors variable. Colors are per scanline, with some rewriting, and additional memory usage, you could do an IBM PC type of color mechanism.

    I haven't optimized it by any means, but tried to make it readable and efficient where possible. I unrolled the RDXXXX loop to avoid additional shifts, with the cache it should be very efficient.

    vga_tty.jpg
  • pedwardpedward Posts: 1,642
    edited 2013-04-11 11:49
    Your monitor probably doesn't like the extra blanks I put at the top and bottom. You can change the blanks back to 33 and 10, then change the rows to 29 and lines to 240 and it will be full 640x480 doublescan.
  • SapiehaSapieha Posts: 2,964
    edited 2013-04-11 11:53
    Hi pedward.

    But it will still not be 800,600 -- It is only size my LCD recognize

    pedward wrote: »
    Your monitor probably doesn't like the extra blanks I put at the top and bottom. You can change the blanks back to 33 and 10, then change the rows to 29 and lines to 240 and it will be full 640x480 doublescan.
  • pedwardpedward Posts: 1,642
    edited 2013-04-11 13:06
    Here's an 800x600 100x75 TTY driver.
  • David BetzDavid Betz Posts: 14,511
    edited 2013-04-11 18:24
    I'd love to play with this but my workspace doesn't have room for a full-sized VGA monitor. Anyone know of a tiny VGA monitor? The TV I have is only about 7". Are there VGA monitors near tyat size?
  • Roy ElthamRoy Eltham Posts: 2,996
    edited 2013-04-11 18:37
    Adafruit sells a couple small hires (1280x800) VGA displays. They are a bit expensive, but nice:
    http://www.adafruit.com/products/1033
    http://www.adafruit.com/products/1287 This one is without a case, so a bit more work to deal with, but still a nice display.

    Sparkfun also sells a slightly cheaper one, but it's also much lower res (800x480):
    https://www.sparkfun.com/products/11612
  • David BetzDavid Betz Posts: 14,511
    edited 2013-04-11 18:58
    Roy Eltham wrote: »
    Adafruit sells a couple small hires (1280x800) VGA displays. They are a bit expensive, but nice:
    http://www.adafruit.com/products/1033
    http://www.adafruit.com/products/1287 This one is without a case, so a bit more work to deal with, but still a nice display.

    Sparkfun also sells a slightly cheaper one, but it's also much lower res (800x480):
    https://www.sparkfun.com/products/11612
    Thanks! That looks like a perfect solution.
  • Bill HenningBill Henning Posts: 6,445
    edited 2013-04-11 19:17
    I stock some 7" WVGA (800x480) OEM LCD modules with VGA and NTSC/PAL video in for industrial customers - note this is a bare LCD module, and a pcb, with connecting wires (ie no enclosure), normally I sell them for $120+s/h but if you need one, I can sell you one for $100+s/h (insured, tracked shipping would be about $20 to continental USA).
    David Betz wrote: »
    I'd love to play with this but my workspace doesn't have room for a full-sized VGA monitor. Anyone know of a tiny VGA monitor? The TV I have is only about 7". Are there VGA monitors near tyat size?
  • David BetzDavid Betz Posts: 14,511
    edited 2013-04-11 19:20
    I stock some 7" WVGA (800x480) OEM LCD modules with VGA and NTSC/PAL video in for industrial customers - note this is a bare LCD module, and a pcb, with connecting wires (ie no enclosure), normally I sell them for $120+s/h but if you need one, I can sell you one for $100+s/h (insured, tracked shipping would be about $20 to continental USA).
    Thanks Bill but I'm afraid I wasn't able to restrain myself and ordered the one that Roy recommended right after I read his message! :-)
  • Bill HenningBill Henning Posts: 6,445
    edited 2013-04-11 19:22
    No worries - the adafruit ones were really nice and higher resolution... I had to restrain myself from ordering one :)
    David Betz wrote: »
    Thanks Bill but I'm afraid I wasn't able to restrain myself and ordered the one that Roy recommended right after I read his message! :-)
  • pedwardpedward Posts: 1,642
    edited 2013-04-11 20:36
    Here's an 800x480 driver, based of timings from here: http://forums.guru3d.com/showpost.php?p=2754352&postcount=3

    I've included a single scan and double scan.

    I don't have an LCD that will do 800x480, so these are a shot in the dark.
  • SapiehaSapieha Posts: 2,964
    edited 2013-04-11 23:34
    Hi pedward.

    It function now -- Thanks

    But it is possible to made fonts bigger by double showing pixels in both directions?

    Look on attached pic.


    pedward wrote: »
    Here's an 800x600 100x75 TTY driver.
    1024 x 768 - 32K
  • pedwardpedward Posts: 1,642
    edited 2013-04-11 23:48
    800x600 is a tricky one because 50 isn't divisible by 4!

    Let me tinker a bit. You sure that isn't an 800x480 display? The aspect looks like 16:10 or 16:9, not 4:3
  • pedwardpedward Posts: 1,642
    edited 2013-04-12 00:23
    Ok, so this one was fun. I had almost zero confidence in getting a decent looking 800x600 doublescan text driver, and it actually worked despite my efforts!

    So the loop that builds the scanline has to operate in blocks of 4 bytes/32b at a time because that's what WAITVID expects. What is interesting is that you can waste a couple of cycles in the rendering, by doing an odd number of blocks, but then you compensate by adjusting the bytes per row.

    For 50 columns you read 52 bytes per row, so after the 8th scanline it adds 50 to the buffer offset pointer, you effectively throw away 2 bytes, but accommodate odd numbered or non-divisible by 4 widths.

    A note about REPD, it doesn't function like REPS, so it can catch you out, like it did me.

    REPD D,#i - execute 1..64 instructions D+1 times, requires 3 spacer instructions *

    And the dummy Hsync/WAITVID does seem to help the VID pipeline stall that causes truncated scanlines, so if your code structure doesn't readily facilitate a fill following a WAITVID, this is a quick fix.

    Attached is a 50x37 text driver for 800x600 video mode. It works surprisingly well and makes for a very legible display.

    To get 37, I cheated and added 4 scanlines to the top and bottom blanks.
  • SapiehaSapieha Posts: 2,964
    edited 2013-04-12 00:31
    Hi pedward.

    THANKS.

    Now it is readable --- Look on attached pic

    Ps. It is LCD Bill describe in his post
    pedward wrote: »
    Ok, so this one was fun. I had almost zero confidence in getting a decent looking 800x600 doublescan text driver, and it actually worked despite my efforts!

    So the loop that builds the scanline has to operate in blocks of 4 bytes/32b at a time because that's what WAITVID expects. What is interesting is that you can waste a couple of cycles in the rendering, by doing an odd number of blocks, but then you compensate by adjusting the bytes per row.

    For 50 columns you read 52 bytes per row, so after the 8th scanline it adds 50 to the buffer offset pointer, you effectively throw away 2 bytes, but accommodate odd numbered or non-divisible by 4 widths.

    A note about REPD, it doesn't function like REPS, so it can catch you out, like it did me.

    REPD D,#i - execute 1..64 instructions D+1 times, requires 3 spacer instructions *

    And the dummy Hsync/WAITVID does seem to help the VID pipeline stall that causes truncated scanlines, so if your code structure doesn't readily facilitate a fill following a WAITVID, this is a quick fix.

    Attached is a 50x37 text driver for 800x600 video mode. It works surprisingly well and makes for a very legible display.

    To get 37, I cheated and added 4 scanlines to the top and bottom blanks.
    1024 x 768 - 52K
  • pedwardpedward Posts: 1,642
    edited 2013-04-12 01:14
    Sapieha wrote: »
    Hi pedward.

    THANKS.

    Now it is readable --- Look on attached pic

    Ps. It is LCD Bill describe in his post

    Try playing with the 800x480 driver I posted above, that should display dot for dot on your display and get rid of that nasty scaling artifacts.
  • SapiehaSapieha Posts: 2,964
    edited 2013-04-12 01:20
    Hi pedward.

    Last picture are from that last driver.

    But to fill entire LCD area I needed change fill buffer from 1600 to 1800 and still one Char line are free
    pedward wrote: »
    Try playing with the 800x480 driver I posted above, that should display dot for dot on your display and get rid of that nasty scaling artifacts.
  • David BetzDavid Betz Posts: 14,511
    edited 2013-04-12 19:03
    I've tried both the original version of this driver and the 800x600 version and they both leave about the bottom third of my monitor solid blue. Isn't the text supposed to fill the screen? Is this a problem with my monitor. It's a rather ancient 15" LCD computer monitor.
  • SapiehaSapieha Posts: 2,964
    edited 2013-04-12 20:09
    Hi David.

    Change limit in thios position.

    [code]
    begin mov start, #0

    mov buf, #0
    reps #1200, #3 <

    [/coode]
    David Betz wrote: »
    I've tried both the original version of this driver and the 800x600 version and they both leave about the bottom third of my monitor solid blue. Isn't the text supposed to fill the screen? Is this a problem with my monitor. It's a rather ancient 15" LCD computer monitor.
  • pedwardpedward Posts: 1,642
    edited 2013-04-13 00:32
    Yeah, I didn't see this aberration because the FPGA ram isn't cleared after program start. The framebuffer is 1850 bytes for 800x600 doublescan text. The routine that initializes the framebuffer was only initializing 1200 bytes. It doesn't affect your ability to actually use it, it was just a test pattern for the DE0.

    I don't have enough cycles to do anything useful, and I have a DE0, so no other COGs.

    Right now I'm working on color per tile, but the FPGA isn't fast enough.
  • David BetzDavid Betz Posts: 14,511
    edited 2013-04-13 03:52
    pedward wrote: »
    Yeah, I didn't see this aberration because the FPGA ram isn't cleared after program start. The framebuffer is 1850 bytes for 800x600 doublescan text. The routine that initializes the framebuffer was only initializing 1200 bytes. It doesn't affect your ability to actually use it, it was just a test pattern for the DE0.

    I don't have enough cycles to do anything useful, and I have a DE0, so no other COGs.

    Right now I'm working on color per tile, but the FPGA isn't fast enough.
    Thanks! That fixed it. Maybe I'll try hooking this up to display stdout from PropGCC later today.
Sign In or Register to comment.