Graphics driver problem

mike goettling

is there some docs for the graphics driver. need to display a clock in a location of my display. using VGA 1280x1024 Tile Driver v0.9· need to display the clock in a 12x4 tile area. cant get it to work.

con
· bitmap_base = $5000

· gr.start
· gr.setup(8, 8, 0, 0, bitmap_base)

PRI largetxt | i,j
··· repeat i from 0 to 7
···· repeat j from 0 to 12
····· array.word[noparse][[/noparse]cols * (22 + i) + j + 32] :=· 22 << 10 + bitmap_base >> 6 + i + j << 3
··· gr.clear
···
··· gr.textmode(9,9,5,5)
··· gr.colorwidth(3,5)
··· gr.text (80,65,string("8:44"))
not for sure what i am doing wrong but i only see 8:4

·

rjo_

Haven't even looked at graphics yet, but it looks like you made a typo...

your gr.start needs to be in a method.

so you need something like "Pub driver"

Timothy D. Swieter

Mike -

I am just starting to use the graphics driver myself, so I am not an expert yet. The Hyrda book provides great reference as well as reading through the forums. In the graphics_demo I see that the strings are defined in the DAT section. The strings must be zero terminated, I think I read that in the graphics program. I have implemented the driver with the text in the DAT section and gotten it to work. Be sure that your screen size is setup up right.

Move the x (80) and y (65) coordinates around some to be sure the item is not being clipped. I think the point specified is the center of the string display, not the left hand. I need to experiment more, but I think this is what I was experiencing yesterday.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter
tdswieter.com

---

One little spark of imagination is all it takes for an idea to explode

deSilva

GRAPHICS is quite well documented in its source:

PUB textmode(x_scale, y_scale, spacing, justification)

'' Set text size and justification
''
''   x_scale        - x character scale, should be 1+
''   y_scale        - y character scale, should be 1+
''   spacing        - character spacing, 6 is normal
''   justification  - bits[noparse][[/noparse]1..0]: 0..3 = left, center, right, left
''                    bits[noparse][[/noparse]3..2]: 0..3 = bottom, center, top, bottom

Using (9,9,5,5) means: an extreme enlargement! Justification is Center/Center.

So it seems you have run out of the 128x128 pixel frame you initialized the driver with...

mike goettling

but when i enlarge the pixel frame then the char's are scrambled.

mike goettling

any advice with this is helpfull

deSilva

mike goettling said...
but when i enlarge the pixel frame then the char's are scrambled.

Yes, of course - if you do not change the tile settings if the underlying video driver at the same time. They have to match - obviously!

So eg set all to 12. As you do not use double buffering you should have ample space, even for 12x 16... you should avoid distortion on a 3:4 display...

But what I do not understanding is why you use those settings 9,9,5,5 for textmode in the first place...

deSilva

mike goettling said...
any advice with this is helpfull

My theory is, that you missed to post a COMPLETE program.

It even took me 10 minutes to reconstruct your program from your puzzles to verify my opinion.

mike goettling

here is part of the code to show this issue i am having. this is a motified code that chip wrote. I am trying to understand the graphics driver enough to set a spot on the display to show a large font clock.·I am getting part of the char's but not all of them. tryed to change the settings in gr.setup but anything other that 8 the text is scrambled.




' 1 April 2007
'
' This program demonstrates 1280x1024 VGA, NSTC, and the mouse
' simultaneously on the Propeller Demo Board. This code is a
' mess. It was thrown together to make a visual demonstration
' for the Embedded Sytems Conference in April 2007.
CON
· _clkmode = xtal1 + pll16x
· _xinfreq = 5_000_000
· cols = 80
· rows = 64
· tiles = cols * rows
· spacetile = $220
· display_base = $6000
· w_x = 19
· w_y = 10···············
OBJ
· vga···· : "VGA_1280x1024_Tile_Driver_With_Cursor"
· gr····· : "graphics"
VAR
· long· col, row, color
· long· array[noparse][[/noparse]tiles/2]
· long· cursor_x, cursor_y, cursor_col, cursor_def
PUB start | i, j, k
· 'start vga tile driver
· vga.start(16, @array, @vgacolors, @cursor_x, 0, 0)
· 'start and setup graphics
· gr.start
· gr.setup(8, 8, 64, 64, display_base)
· 'fill screen with text
· print($100)
· 'make some graphics tiles on the screen
··· make_graphics_tiles(w_x, w_y, 21)
··
··· 'do some graphics
··· gr.clear
··· gr.colorwidth(2,0)
··· gr.textmode(9,7,6,5)
··· gr.colorwidth(3,4)
··· gr.text (60,0,string("8:44"))······
···

PRI make_graphics_tiles(x, y, c) | i, j
· repeat i from 0 to 7
··· repeat j from 0 to 12
····· array.word[noparse][[/noparse]cols * (y + i) + j + x] :=· c << 10 + display_base >> 6 + i + j << 3


PRI print(c) | i, k
'' Print a character
''
''······ $0D = new line
''· $10..$FF = character
''····· $100 = clear screen
''····· $101 = home
''····· $108 = backspace
''$110..$11F = select color
· case c
··
··· $100:·············· 'clear screen?
····· wordfill(@array, spacetile, tiles)
····· col := row := 0
··· $110..$11F:············ 'select color?
····· color := c & $F

dat

vgacolors long
· long $3C043C04······ 'lt grey on dk grey
· long $3C3C0404
· long $44A844A8······ 'magenta
· long $4444A8A8
· long $88A888A8······ 'magenta light
· long $8888A8A8
· long $E400E400······ 'dk yellow
· long $E4E40000
· long $9C009C00······ 'red
· long $9C9C0000
· long $FF80FF80······ 'red/white
· long $FFFF8080
· long $FF20FF20······ 'green/white
· long $FFFF2020
· long $FF28FF28······ 'cyan/white
· long $FFFF2828
· long $C0408080······ 'redbox
· long $3010F020······ 'greenbox
· long $3C142828······ 'cyanbox
· long $FC54A8A8······ 'greybox
· long $A8540000······ 'dark grey box
· long $C030F050······ 'graphics colors
· long $88143000
· long $8008FC54
·

deSilva

Mike,
sorry for some misunderstandings. But as the comment says: This is a total mess: A tiny graphics plane tuned into a specific place with lots of literal constants all around... Little chance for you. So please change this:

  gr.setup(14, 8, 64, 64, display_base)  ' 14 rather than 8

....
    gr.textmode(9,9,6,5) ' 9 rather than 7
 ...   
   

    repeat j from 0 to 14  ' 14 rather than 12

I could give you further explanation what this all means, if needed
Have fun!

mike goettling

i just figured out what i was doing wrong. as far as the code it is just for testing. the actual code i can't put out to the foum because i am wrighting it for a company that i have sign a privacey and non compete with. so any time i have a problem i have to do it this way. if i make a change to gr.setup. the change also has to be made to make_graphics_tiles. if i change gr.setup to 8,12 then i have to set in make_graphics one less from 12 to 11. that is what i was having problems with is the relationship between gr.setup and make_graphics_tiles. as soon as i apply it to my code i will send a screen shot.


PRI make_graphics_tiles(x, y, c) | i, j
repeat i from 0 to 7
repeat j from 0 to 12

Ken Peterson

Just a friendly word of advice. Understand what all of your function parameters are and set constants for them in your CON section. Avoid putting literal numbers in your code. For example, you might have more than one function that depends on your number of rows and columns. If you don't use constants, you have to change the numbers in more than one spot. Furthermore, using constants makes your code much more readable for when you try to debug it weeks or months later!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


The more I know, the more I know I don't know.· Is this what they call Wisdom?

Rayman

I modified the 1024x768 demo to resize and move the graphics tiles around...· There's a bit of info here:

http://www.rayslogic.com/propeller/Programming/RaysStuff.htm


PS:· I really recommend the 1024x768 driver for practical apps...

deSilva

o.k.
I can as well try some explanations....
(1) What does GRAPHICS.SPIN do? It fills a memory buffer organized as a rectangular view in units of 16 LONGS, imagined to be stacked vertically. Lets call them MEMORY CHUNKS. They contain 16 pixels, and a LONG contains two bits per pixel to allow for 4 different colours.

(2) Mike has used a very small buffer 128 x 128 pixels, 8x8 being the first two parameters of gr.setup(8,8,....)
GRAPHICS can paint on any of those pixels, so for a graphic operation those chunks are of no further relevance. The origin of the drawing co-ordinates will normally be "top left", but you can adjust that. Mike has "centered" his co-ordinate system
gr.setup(8, 8, 64, 64,..)
So drawing something to (0,0) would show it in the center!

(3) Drawing text is very flexible; text can be horizontally or vertically aligned. Text can also be enlarged!
gr.text(9, 9, 5...
would enlarge the normally 8x4 font to a 72x36 size. Now Mike was painting 4 characters, with intercharacter spacing of 5, which would take 4*36 + 3*9 = 171 pixel, somewhat more than the 128 available. This does no harm, as GRAPHICS is a very cleanly written program...

But what is this 3*9 stuff?? Well the "spacing" is not counted between the characters, but absolutely, including their nominal width (which is 4). And it is measured in "un-enlarged" units...

I here again add the description oftextmode, as very often the alignments parameters are forgotten

PUB textmode(x_scale, y_scale, spacing, justification)
'' Set text size and justification
''
''   x_scale        - x character scale, should be 1+
''   y_scale        - y character scale, should be 1+
''   spacing        - character spacing, 6 is normal
''   justification  - bits[noparse][[/noparse]1..0]: 0..3 = left, center, right, left
''                    bits[noparse][[/noparse]3..2]: 0..3 = bottom, center, top, bottom

(4) Now how does this 128x128 "graphics window" correspond to the things the real video driver (TV or VGA) outputs? Well, using tiles of course. We just put the addresses of our MEMORY CHUNKS into the tile_matrix (generally called "screen") of the driver.

The conventions are as hunderedfold explained here in threads: 6 bits color, 10 bits TILENUMBER; TILE NUMBER is something when multiplied with 64 gives the byteaddress.

So this is where we need a pair of nested loops

repeat i from 0 to 7
     repeat j from 0 to 12
      array.word[noparse][[/noparse]cols * (22 + i) + j + 32] :=  22 << 10 + bitmap_base >> 6 + i + j << 3

so the tiles of eight columns times thirteen lines were directed to the MEMORY CHUNKS of the GRAPHICS driver.

Well, didn't we only have a 8 x 8 tiles memory for the graphics.
(a) That's true - but what is memory? You see that "bibmap_base" has dangoriously been set to $6000. So there is memory 8k bytes at least. And the structure of the memory, is determined by this harmlessly looking << 3.
Exactly! <<3 absolutely determines that you have got 8 rows (of 16 pixels) the length of those rows being arbitrary, but clipped by the settings in the setup parameter..


A lot to change when you change.....
Keep a stiff upper lip for it

Post Edited (deSilva) : 10/10/2007 3:30:10 AM GMT

mike goettling

got it as soon as i get permision i will send up a screen shot

deSilva

Mike, now that we understand your problem, let me explain what my problem is:

(1) First you posted some code out of context. However the most likely problem was obvious and explained to you.
(2) You did not react to those explanations other than saying that it does not work.
(3) Then - 24 hours later - you posted a different piece of code - which differed not only considerably but in relevant aspects from your first posting. No wonder you couldn't be helped...
(4) I undertook the trouble to fix your bugs.. there was a specific reason for it, though it is considerably after midnight local time now.
(5) Then you posted something of your own findings; which generally is fine, as you have of course to work on it!

So this all does not look like team work to me....

Post Edited (deSilva) : 10/10/2007 5:00:00 AM GMT

mike goettling

my apologies i am not very good with postings. normaly i don't post unless i am totaly loss. As I said in a earlier post that i am bound by a contract with the customer that i am working for and cannot post the program in forum. Also this is a part time job and i am married and have kids so i can't always get to the computer to check, that is why there was a 24 hour delay. I have been working with the propeller since first of the year. the last time i did programing was in 1995 so i am rusty when it comes to the asm of the chip.

Right now the program that i am using is run 7 out of 8 proc's
3 for the vga driver
1 for the main program
1 for the full dupex serial
1 for the graphics driver
1 for a procss that changes the color table to cause flashing text.

mike goettling

deSilva

So you have still ample space
Some remarks, some allredy made.
- If you not absolutely have to do something else, use the "simpler" driver Rayman keeps advertising.
- Updating the color tables is a simple job that can be included into the VGA driver during vertical sync, if need be
- As you have experienced, a most annoying fact is missing documentation. So why not write a "How to use GRAPHICs with different video drivers!" for us? I already mae a start with my posting four above

Post Edited (deSilva) : 10/10/2007 1:51:57 PM GMT