VGA tiled text console driver

pedward

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.

Sapieha

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.

pedward

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.

Sapieha

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.

pedward

Here's an 800x600 100x75 TTY driver.

David Betz

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 Eltham

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 Betz

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 Henning

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 Betz

Bill Henning wrote: »

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 Henning

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! :-)

pedward

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.

Sapieha

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.

pedward

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

pedward

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.

Sapieha

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.

pedward

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.

Sapieha

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 Betz

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.

Sapieha

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.

pedward

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 Betz

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.