VGA 1600 x 1200 Tile Driver
cgracey
Posts: 14,206
Well, it takes SIX cogs!! It pumps out pixels at 160MHz. Want a cursor? That'll take another cog. You'll have one left to do something with. I'll try to reduce the cog count later, but I wanted to get it running.
It looks great on a CRT, but some LCD's have trouble syncing perfectly. CRT's are much more forgiving since they are analog and let the pixels land where they may. You may notice a slight sawtooth pattern on the edges of characters. It is only a fractional pixel in width and is caused by the 0 to ~2ns delay from the chained pin-output OR gates going through zero to five consecutive cogs, in sequence for consecutive scan lines.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
It looks great on a CRT, but some LCD's have trouble syncing perfectly. CRT's are much more forgiving since they are analog and let the pixels land where they may. You may notice a slight sawtooth pattern on the edges of characters. It is only a fractional pixel in width and is caused by the 0 to ~2ns delay from the chained pin-output OR gates going through zero to five consecutive cogs, in sequence for consecutive scan lines.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Comments
You just had to push it to the limit, 1600x1200, unreal[noparse]:)[/noparse]
But how do you get 160MHz from a 80Mhz micro?
At the moment the number of colours is limited because you are only using 2 pins each for RGB.
What resolution can you get if you use 3 pins or 4 pins for each RGB and how many colours, 512, 4096?
At 3 x 5 bits·-·32768 colours this would be good for displaying pictures, lose 11, 14, 17 I/O pins?
Gavin
Its' still bloody impressive though.
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Sid Weaver
Don't have VGA?
Newzed@aol.com
·
From an external hardware point of view increasing the number of colours is simply a case of adding a few resistors and changing the values of the existing ones, but the standard cog hardware will only output 2 bits per colour component, so you'd need to have several cogs running in sync outputting to different sets of pins. You could then get 4 bits per component with two cogs (4096 colours), 6 with three cogs (262144 colours), and the maximum would be 8 bits per component from four cogs giving 16777216, but there'd be no pins left for anything else, as you'd also have four sets of horizontal and vertical sync lines coming out of each cog as well.
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Sid Weaver
Don't have VGA?
Newzed@aol.com
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 11/23/2006 5:53:57 PM GMT
waitvid colors0,pixels0
waitvid colors1,pixels1
waitvid colors2,pixels2
...
waitvid colors99,pixels99
Whew!
POST-EDITED FOR TIMING CORRECTNESS
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 11/25/2006 12:54:20 AM GMT
The other highres demo's lately have been great though!
Brian
I firugured I wouldn't be using the box colors so I modified and substituted some of the first few longs.· I now have white on maroon, white on orange and red on yellow.· Still trying for the yellow on blue.
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Sid Weaver
Don't have VGA?
Newzed@aol.com
·
dinky-dy.
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Sid Weaver
Don't have VGA?
Newzed@aol.com
·
Thanks
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Sid Weaver
Don't have VGA?
Newzed@aol.com
·
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Sid Weaver
Don't have VGA?
Newzed@aol.com
·
Thanks
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Sid Weaver
Don't have VGA?
Newzed@aol.com
·
As far as colours are concerned, the cog video hardware is very simple - all it does is set the eight output pins to one of the four bytes provided by the second argument in the WAITVID assembly instruction depending on the colour of the pixel being output at that time. As on the demoboard two of those eight pins are used for the horizontal and vertical sync lines which at a simplistic level essentially provide the structure of the picture itself, if your colour bytes have either of these bits set, and those colours are displayed anywhere on the screen, then your display will be garbled. In theory by feeding it screwy timing, you could damage your monitor, but most will handle dodgy signals in a sensible manner, blank the display, and maybe show a suitable message.
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Sid Weaver
Don't have VGA?
Newzed@aol.com
·
Sorry for the delay, but I was out of town and just got home. Everything you are talking about doing can be done in the top-level Spin file. You will see towards the end of the file that there is a color table. I believe that the first two·longs·are used for the main background/foreground color combination. There are two longs, not just one, because those ROM font characters are interleaved and to pick one out, you will either have to use the even or odd bits within their pixel definitions. The first long always selects the even-bit colors and the second long always selects the odd-bit colors. To get a maroon background and a yellow foreground, you should set the first two longs to these values:
$F044F044·· 'even-bits character's color: yellow on maroon
$F0F04444·· 'odd-bits character's color: yellow on maroon
If you read the documentation for the PUB 'start', you will get an explanation of this. To make a full-blown text printing, color selecting, print positioning object to set up the data for the tile driver, you only need to write spin code. That color_mask $FCFCFCFC you saw is used to clear the H and V bits for each of the four colors, so that in case some lousy data was passed with any non-color bits set, they won't cause any errant sync timing.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
$F044_F044·· 'even-bits character's color: yellow on maroon(purple)
$F0F0_4444·· 'odd-bits character's color: yellow on maroon(purple)
which turned out to be yellow on purple.· I changed it to:
· long $A040_A040······ 'yellow on maroon············
· long $A0A0_4040
With this knowledge, I was able to come up with five different "default" screen combinations.· I haven't been able yet to figure out how to pre-determine what color combination to call.··In the two groups above, they both call out a yellow font, but none of the four bytes are the same.· So I just punch in different values and if I like what I get, I save it.
Thanks again, Chip.· Now the agony of deciding which combination I want to use.
Sid···
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Sid Weaver
Don't have VGA?
Newzed@aol.com
·
"setxy(n,m)" instruction in Mike Green's OS program.
Thanks
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Sid Weaver
Don't have VGA?
Newzed@aol.com
·
Chip, I really hate to bother you again, but…………………..
In your program, the object
" vga_1280x1024_tile_driver_with_cursor", says:
PUB start(base_pin, array_ptr, color_ptr, cursor_ptr, sync_ptr, mode)
In the top file I have:
vga.start(8, @array, @vgacolors, @cursor_x, 0, 0)
With this my program works perfectly. I decided to put in a cursor to see what it looked like, but after several hours I hadn’t succeeded. Apparently "@cursor_x" is the "cursor_ptr", which is supposed to point to four longs – xpos, ypos, cursor color and cursor form. Cursor_x is a variable, so how and where do I write the four longs that cursor_x is supposed to point to. I can’t make a DAT list "cursor_x" because that expression is a variable.
Have I expressed things clearly?
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Sid Weaver
Don't have VGA?
Newzed@aol.com
·
cursor_x doesn't point to the four longs. It is the first of the four longs. Somewhere in your top file you should have "VAR long cursor_x, cursor_y, cursor_color, cursor_form". When you write "@cursor_x", you are computing the address of "cursor_x" and, in this case, passing the address to the vga.start routine as the value of "cursor_ptr". Does this help?
Mike
cursor_x := 100
cursor_y :=100
cursor_col := %%3330
cursor_def := 1
just ahead of the statement:
vga.start(8, @array, @vgacolors, @cursor_x,0,0)
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Sid Weaver
Don't have VGA?
Newzed@aol.com
·
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Sid Weaver
Don't have VGA?
Newzed@aol.com
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Chip and Mike, I got the cursor displaying with no problem. Figuring out how to precisely locate it using 0 to 1279 and 0 to 1023 was a different story. I determined that 80 columns takes 16 per column, and that 64 rows takes 16 per row. However, each line of text takes two rows to display so each line actually takes 32. With this in hand I came up with the following instructions that let me precisely locate the cursor:
cursor_x := (column*16)-1
cursor_y := ((32-row)*32)-1
This allows me to position the cursor exactly where I want it. If I want to temporarily eliminate it, I just comment out the cursor_col line. By inserting the cursor_x and cursor_y in the different methods in my program and changing the parameters, I can have the cursor always appear at the right spot.
Thank you both for the help in improving my display.
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Sid Weaver
Don't have VGA?
Newzed@aol.com
·
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Sid Weaver
Don't have VGA?
Newzed@aol.com
·