Specifying variable addess

PatM

In Bascom AVR I can create a variable and tell it where to reside in memory. For example:

DIM screen_bitmap AS byte * 19200 AT $3000

Is there an equivilent in spin? Been searching the manual and I don't see it (which probably means no).
·

deSilva

IMHO you cannot do this, but I have no idea why you want to to it in the first place? With the exception of the first 511 bytes which can more trickily be addressed from a COG in machine language, any place in HUB is like the other...

Harrison.

You could always do:

CON
     ptrMyVar = $3000     ' memory location you want to access (HUB)

PUB start
     BYTE[noparse][[/noparse]ptrMyVar] := 200     ' write 200 to location at address ptrMyVar

Yes, this is a bit messy, but it works and using BYTE[noparse]/noparse and LONG[noparse]/noparse to access HUB memory is actually very nice and clean looking in my opinion.

Harrison

deSilva

This is just PEEK and POKE

Paul Baker

Harrison provided the answer, however you cannot reserve a particular location in memory. So just like peeking and poking to random locations of memory, doing so·will·yeild unpredictable program behavior. And like deSilva says, other than wanting to do this because some other environment allowed it, why do you really want to do it?

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

Parallax, Inc.

Post Edited (Paul Baker (Parallax)) : 7/8/2007 3:47:58 AM GMT

PatM

Well, in playing with the graphics demos I discovered that the screen buffer doesn't work so well if the starting address LSByte was non-zero. $3000 worked, $3400 worked, but $30FF would garble the top left of the screen. I found this out because instead of using a constant to act as a pointer to the screen buffer I wanted to actually declare an array and have the used memory appear in the memory map of proptool. As long as the starting location actually had room for the entire bitmap, XX00 worked fine while XXXX resulted in the garbling.

When I did use an array, the top left was garbled. I did some experimenting and found it was the LSB problem. So, it seemed to make sense to declare at a specific location.

The 512x384 demo is straightforward and simple to figure out, change a color table entry and that tile changes colours. The way other demos like mars lander handle the colours is a lot harder to understand.


·

Paul Baker

What you are likely observing is the driver expecting things to be aligned to longs (last two bits are 0), there are means for ensuring long alignment without having to specify a specific location. What the driver is expecting depends on which driver you are using.

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

Parallax, Inc.

Post Edited (Paul Baker (Parallax)) : 7/8/2007 6:38:39 AM GMT

deSilva

No it's not LONG, it's VIDEO.SPIN expecting each tile to to start with an address being a multiple of 64 (so it can use 10 bits indexes for addressing them). Those tile addresses are generally computed in a loop setting some vector mostly called SCREEN.... Thus the base address has also be a multiple of 64.

Generally two soulutions are used:

(1)
LONG padding [noparse][[/noparse]16]
LONG buffer[noparse][[/noparse]x_tiles*y_tiles*16]

bitmap := buffer & $ffc0

(2)
LONG buffer[noparse][[/noparse]x_tiles*y_tiles*16+15]
bitmap := (@buffer+15)& $ffc0

Gennady

deSilva said...
No it's not LONG, it's VIDEO.SPIN expecting each tile to to start with an address being a multiple of 64 (so it can use 10 bits indexes for addressing them). Those tile addresses are generally computed in a loop setting some vector mostly called SCREEN.... Thus the base address has also be a multiple of 64.

Generally two soulutions are used:

(1)
LONG padding [noparse][[/noparse]16]
LONG buffer[noparse][[/noparse]x_tiles*y_tiles*16]

bitmap := buffer & $ffc0

(2)
LONG buffer[noparse][[/noparse]x_tiles*y_tiles*16+15]
bitmap := (@buffer+15)& $ffc0

Clarification, please..
In TV_text.spin the screen buffer is defined as
VAR
·· word screen[noparse][[/noparse]cols*rows] 'at 32x13 screen it's 416 words

now, if I need to define a custom font, I do it's this way:

VAR
·· long user_fontbase

...
user_fontbase := (@cfont >> 2)
...
DAT
padding long 0[noparse][[/noparse]x]
cfont
······ 32 longs of 32bit (4 color) custom character 1 bitmap
······ 32 longs of 32bit (4 color) custom character·2 bitmap
······ ................32longs of 32bit (4 color) custom character·n bitmap
=================
screen[noparse][[/noparse]416] array contains color pointers and character map pointers (as·user_fontbase + offset in a font)
If I understand it right, it's the cfont·(bitmap) that should be aligned at·64 boundary - am I wrong?
I am trying to do alignment by changing x in the above padding long 0[noparse][[/noparse]x].
The problem is that x should be changed any time the preceeding code changes..
That's where assignment of the cfont block to a particular address could help tremendously (AFAIU)

And the whole thing·doesn't work, but it's probably a different story..
Gennady

deSilva

I think I see your point.... AFAIK there is no directive to allign something to 64 byte in SPIN or Assembler...

I would use a "brute force" approach just to make it go:

DAT
  padding            long 0[noparse][[/noparse]15]
  oldCharGen  long 0,0,....
  endOfCharGen


....

charGenAddr := constant(@oldCharGen & $3f)
movelong(charGenAddr,  oldCharGen,  constant(@endOfCharGen -@oldCharGen)/4))

...
Characters can be set to "SCREEN" using the value 
(charGenAddr>>6)+characterNumber

Looks a little bit clumpsy though...

Paul Baker

Yeah thats the technique I used for the kiosk program, originally I was attempting to create a 64 byte buffer then do a longmove all of the character data to align it, but was having trouble doing it at the time and gave up because of time constraints. I will re-investigate the method to see if I can get it working properly.

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

Parallax, Inc.

Post Edited (Paul Baker (Parallax)) : 7/11/2007 12:02:00 AM GMT

Paul Baker

OK figured out the code to align to a 64 byte boundry. First there must be a 64 byte padding before the data which needs alignment (64 bytes = 16 longs):

 CON
  numchars = 63
 
PUB start
...
  longmove(@cfont & $FFFF_FFC0, @cfont, CONSTANT(numchars * 32))
...
 
DAT
padding LONG 0[noparse][[/noparse]16]
cfont   LONG ....      'data which needs alignment to 64 bytes 

Since each character comprises 32 LONGs that is multipled with·the number of user defined characters. The first argument strips out the portion of the address which is less than 64 thereby finding the 64 byte boundry preceeding the address @cfont, and since that lies somewhere in the padding no data is trampled on and all user characters are aligned to a 64 byte boundry at run time alieviating the need to·hand align.

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

Parallax, Inc.

rokicki

If you're using longs already you only need 60 bytes of padding, so O[noparse][[/noparse]15] would be sufficient. Very minor point, but
perhaps useful in some cases.

deSilva

This is why I used 15 LONGs in my suggestion. When you correct the two typos in it (missing NOT, and LONGMOVE not MOVELONG ) it is exactly the code Paul re-invented

Paul Baker

Just discovered TV_Text.spin expects characters to be aligned to the 128 byte (32 long) boundry (the size of a character in ROM), so the mask is $FFFF_FF80 and the padding is 31. The code above is for VGA tile drivers.

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

Parallax, Inc.

deSilva

I do not see anything like that; and there would be no reason for in the first place... As far as I understand TV_TEXT v1.0 it only uses ROM-characters.

Line 170:   screen[noparse][[/noparse]row * cols + col] := (color << 1 + c & 1) << 10 + $200 + c & $FE

Paul Baker

It is a modified TV_Text which contains user defined characters, and specifically related to what Gennady is working on. And the mode TV_Text places the TV.spin driver, characters aligned to 128 bytes is required for anything which is not in the ROM (actually the ROM is inherently aligned to 128 byte boundries).

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

Parallax, Inc.

PatM

Of course, this is only necessary if you want the memory used to display in the Proptool memory usage graph since you can do as the examples do and just use a constant value that is alligned to the boundry. The driver just wants a pointer so it doesn't matter if you send the address of a defined array or just a constant that is set to the appropriate value.

Just in case other new folks see this thread and think you have to jump through hoops to get the video. Works fine without it, I just like seeing the memory use reflected in the graph.


·