Put Graphics bitmap in VAR section - ran into trouble.

Ken Peterson · 2007-08-22 22:57

Howdy all -

I am using the Graphics object and it seems to work well as long as I set up the bitmap pointer to an unused area of memory.· However, I would like to keep better tabs on how much memory I have, so I decided to define the bitmap in the VAR section like so:

· long· display_base[noparse][[/noparse]x_tiles * y_tiles * 16]
Then, when initalize the screen, I use code similar to the Graphics Demo, except instead of "display_base" I'm using "@display_base".

Also, when I start the graphics object, I do it like this:

· gr.start
· gr.setup(x_tiles, y_tiles, 0, 0, (@display_base))

Now, everything that I draw on the screen seems to be misaligned down in the Y direction, and I get garbage in the upper LH corner.· When I change it back to the way it is in the Graphics Demo, everything works normally.

Am I missing something important?

Ken

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

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

potatohead · 2007-08-22 23:39

I think this might be an alignment issue.

Try the @@ operator thus:

gr.setup(x_tiles, y_tiles, 0, 0, (@@display_base))

I've a color lookup table in one of my programs that does this consistently.

More on run time address -vs- compile time address in Prop Manual p. 279

Edit: What I don't always know is when and why this occurs. In my programs, I don't generally have trouble referencing the display buffer with @. It is the first VAR defined, and run time seems to match compile time addressing. The CLUT is defined in DAT statements and does appear to have different run time -vs- compile time addressing.

Edit: My display buffer does not suffer from this particular alignment issue either. It just starts on a long, and is linear addressed, no tiles.

It's not come up again, so I've not dug any deeper.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!

Post Edited (potatohead) : 8/23/2007 12:36:08 AM GMT

deSilva · 2007-08-23 00:05

Oh, oh! Oh, oh, oh!
No this a complete misunderstand!
Yes, it is an alignment problem, but must be fixed differently.
display_base MUST be aligned to 16 longs (i.e. its address must be a multiple of 64)

There are two or three possibilities for this...
Simplest:

long padding[noparse][[/noparse]15]
long not_display_base[noparse][[/noparse]...]



base_address := @not_display_base>>6<<6

setup(......  base_address)

potatohead · 2007-08-23 00:20

Ok... (big grin over here at deSilvas angst!)

Let's have at it! I need to know why one cannot just use @@ for that condition.

Apologies to Ken, if this is a sidetrack.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!

deSilva · 2007-08-23 00:23

Read my other posting some minutes ago somewhere - I explained what @@ is for..

potatohead · 2007-08-23 00:31

Got it. My use case does not match his. Was for my purpose as it falls under case #1.

My post above then is bad practice. And it's not gonna work.

On that padding then, the order of things must also be considered. Do that first, then define all the other stuff, such that the padding is doing a known thing; otherwise the starting address could be any long and could then run afoul of the boundary / page problem right?

That makes the assumption the variable address allocation starts on a boundary that fits in the first place. Does it always do this?

If not, then wouldn't a more robust solution be to allocate the amount necessary for the display buffer, plus at least 16 extra longs? From there, the address can be obtained, the boundary compatible one computed, then passed to the TV driver.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!

Post Edited (potatohead) : 8/23/2007 12:42:23 AM GMT

Ken Peterson · 2007-08-23 00:36

ya know....deSilva's explanation seems to make more sense intuitively. I'll try that. No offense, potatohead! Too bad it's such a cludge to deal with it. Oh well...let's see what that does and I'll keep y'all posted.

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

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

Ken Peterson · 2007-08-23 00:38

Oh...by the way Potatohead.· I was writing my response when yours went up.· so I skipped ya

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

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

potatohead · 2007-08-23 00:39

No offense taken.

He's spot on right.

Just do it first, unless I'm missing some other key SPIN thing.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!

Ken Peterson · 2007-08-23 00:49

Initial tests show deSilva is right...it does seem to work.· I'll be adding to this if it doesn't fix the problem entirely.· Thanks to both of you!

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

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

deSilva · 2007-08-23 01:42

@potatohad:
Your (second) ideas are generally correct. It is a matter of whether to pad "in front" or "behind". Both works. The trick is, when you need - say - N cells you have to allocate N+15.

It depends now on what you choose as a "starting" point. Using the address of Nplus15 you have to compute

(@Nplus15+15)<<6>>6 which is absolutely fine

My solution it second class, insofar it needs two names and the construction is in danger to be misunderstood. In fact a "good" compiler would even issue a warning ("Array PADDING not used!") I just saved the "+15"

But I think I said :"There are two or three solutions..."

potatohead · 2007-08-23 01:49

You did!

Just wanted to make sure I grokked it.

...and that only applies to the Reference Parallax driver. Others, who may use different addressing schemes, may not have that limitation, or others!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!

deSilva · 2007-08-23 01:57

potatohead said...
...and that only applies to the Reference Parallax driver.

It is an ugly left over from using the ROM font. This is fine aligned to 32 k (so we can consider ourselves happy they took not THAT alignement

)

As the colourtables were constructed to consist of 16 bit words, they decided to use 64 colors, and leave 10 bits for the address...

Graphics adopted this concept...

But these are just software constraints, the video logic takes any long...

Gennady · 2007-08-23 03:22

just came back to my propeller staff from other projects.
And·- found two great tutorials. So first of all my deepest appreciation and respect·to deSilva for machine language tutorial (just started, and it's a great read) and to Potatohead for the 'beginner's' staff (this one is not that·useful for me personally now, but I wish I had it in my starting·days long time ago). It's unbeleivable amount of work and service to all of us. If I would be in IRS, I·definetely let you write it as a tax deductible donation for the·total taxes amount for the whole year·

Ok, now to the current problems. I·am also confused with all this alignment problem resolutions. I have a text tv program with custom 4-color font·(I did it in order to simplify black border implementation). Screen is 32 (or 30) x 13, font is currently just alphabet, numbers and space.
Anyway, it displays ok when line 1 contains certain amount of characters·(in my case 26). If I add a character to the first line or put any characters to other lines, it·displays characters, which consist of two repeated vertically lower parts of a font characters.
So its like this:

VAR
  long  col, row, color, flag  'standard staff
  long  screen[noparse][[/noparse]32x13]
  ...
 
  long  user_fontbase          'addres of the user defined characters 
 
...
 
PUB start(basepin) : okay
  longmove(@cfont & $FFFF_FF80, @cfont, CONSTANT(63*32))  'Paul Baker's advice
  user_fontbase := (@cfont >> 6)                          'get a pointer to a custom font
  setcolors(@palette)
  out(0)
  
  longmove(@tv_status, @tv_params, tv_count)
  tv_pins := (basepin & $38) << 1 | (basepin & 4 == 4) & %0101
  tv_screen := @screen
  tv_colors := @colors          'pointer to colors table
  
  okay := tv.start(@tv_status)
........
 
DAT
...........
padding long 0[noparse][[/noparse]31]
 'alignment padding for the following user defined characters     

cfont   long %%0000_0000_0000_0000       '0 - 0
        long %%0000_0000_0000_0000
        long %%0000_0000_0000_0000
        long %%0000_0000_0000_0000
        long %%0000_2222_2220_0000
        long %%0022_2111_1122_2000
        long %%0221_1111_1111_2200
        long %%0211_1111_1111_1200
        long %%2211_1112_2211_1220
        long %%2111_2112_2221_1120
        long %%2111_2111_2021_1120
        long %%2111_2111_2021_1120
        long %%2111_2211_2021_1120
        long %%2111_2211_2021_1120
        long %%2111_2211_2221_1120
        long %%2111_2211_1221_1120
        long %%2111_2211_1221_1120
        long %%2111_2221_1221_1120
        long %%2111_2021_1221_1120
        long %%2111_2021_1221_1120
        long %%2111_2021_1121_1120
        long %%2111_2021_1121_1120
        long %%2111_2222_1121_1120
        long %%2211_1222_1111_1220
        long %%0211_1111_1111_1200
        long %%0221_1111_1111_2200
        long %%0022_2111_1122_2000
        long %%0000_2222_2220_0000
        long %%0000_0000_0000_0000
        long %%0000_0000_0000_0000
        long %%0000_0000_0000_0000
        long %%0000_0000_0000_0000

...
'etc for other characters

As far as I understand, the font in this case should be aligned to 128 bytes boundary. Is it right ?

Will highly appreciate all and any advices.

Gennady

deSilva · 2007-08-23 08:03

Gennady,
I do not see how you use user_fontbase, but

longmove(@cfont & $FFFF_FF80, @cfont, CONSTANT(63*32))  'Paul Baker's advice
  user_fontbase := (@cfont >> 6)

is not consistent. After you move your font up the memory you have to use its new address.

It is better style to make this explicit, i.e. define a variable

new_font_start := @original_font >>6<<6  '(or use the & $FFFF ... if you like)

BTW: It's not only Paul's advice but also mine - I remember I posted it an hour earlier, but my reputation was not existent at that time

And I had a typo in it

Paul Baker · 2007-08-23 21:03

The video driver he is using requires the address to be in it's shifted form, so it should stay in the shifted position. There is another driver that expects the address in unshifted form, so your technique would be used for that driver.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

deSilva · 2007-08-23 21:18

No, this is not what I mean!
I am well aware what the driver expects!
But I did not spot that Gennady was alligning to 128 rather than 64. 128 is not strictly necessary, but it will do no harm, IF you compute your user_fontbase correctly.

I flopped with >>6<<6 it has to be >>7<<7 for this case!
So the simplest fix for Gennady would be to set

user_fontbase := (@cfont >> 7<<1)

But I think it would be cleaner to follow aditionally my original proposal.

Gennady · 2007-08-24 00:24

and again, you are absolutely right !
it's fixed.

Thanks a lot (and I do need to go into details of it one time :-( )

Gennady

Put Graphics bitmap in VAR section - ran into trouble.

Comments