Forcing a DAT block to be 32 long aligned for TV_TEXT custom characters
m.r.b.
Posts: 36
Ok, firstly, the background...· (I know what I want to try to explain/ask, but might not be getting there the best way!!!)
I would like to have a DAT block with several user defined characters (for TV_text object)... IE cursor symbol/hourglass symbol, fancy borders etc....
... Easy so far!!
However,·going from my recollection of how the TV object works... the 'tile' data needs to be 32 long aligned,·with the·tile address·being shifted to lose the lower order bits when its placed into the 'screen' data, for the corresponding character cell.
I will display my user defined characters by placing the address·(after left shifting)·into the tile·'address' field of the appropriate 'screen' data WORD for the XY character to be displayed, just as TV_text does with the rom font, only with reference to my (32 long aligned) memory·block start·instead!
I have three possibilities;
··· 1) I can use longmove to copy the (most likely NOT·32 long aligned) user defined character data to a 32 long aligned 'free' block somewhere near the top of memory;
or· 2) I can use '32 long aligned' forced DAT data.
or· 3) Add an extra parameter to a modified TV object, to account for the offset W.R.T. the 32 long alignment, when the tile data is in ram rather than rom memory space.
I would prefer to use the 2nd option, because it uses half as much memory space (IE only has DAT space data; rather than DAT space + an aligned copy of the DAT space data), although (provided it doesn't cause timing issues) I am happy implementing·option #3.
How do I 'force' a block of DAT data to start at a known location??
I know that with something this fundamental, I should know better, but I can't find the answer in the prop' manual.
Cheers, mathew
I would like to have a DAT block with several user defined characters (for TV_text object)... IE cursor symbol/hourglass symbol, fancy borders etc....
... Easy so far!!
However,·going from my recollection of how the TV object works... the 'tile' data needs to be 32 long aligned,·with the·tile address·being shifted to lose the lower order bits when its placed into the 'screen' data, for the corresponding character cell.
I will display my user defined characters by placing the address·(after left shifting)·into the tile·'address' field of the appropriate 'screen' data WORD for the XY character to be displayed, just as TV_text does with the rom font, only with reference to my (32 long aligned) memory·block start·instead!
I have three possibilities;
··· 1) I can use longmove to copy the (most likely NOT·32 long aligned) user defined character data to a 32 long aligned 'free' block somewhere near the top of memory;
or· 2) I can use '32 long aligned' forced DAT data.
or· 3) Add an extra parameter to a modified TV object, to account for the offset W.R.T. the 32 long alignment, when the tile data is in ram rather than rom memory space.
I would prefer to use the 2nd option, because it uses half as much memory space (IE only has DAT space data; rather than DAT space + an aligned copy of the DAT space data), although (provided it doesn't cause timing issues) I am happy implementing·option #3.
How do I 'force' a block of DAT data to start at a known location??
I know that with something this fundamental, I should know better, but I can't find the answer in the prop' manual.
Cheers, mathew
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
What I shall do, is more-or-less what your doing in your 1 bit bitmap demo.... Good solution
(But.. excepting your 16 Versus my 32 high tiles, means I have to copy 32 longs per pair of UDG chars)
In the grand scheme of things, losing·16 longs (considering 8K longs within the prop') isn't that bad!!
Regards... Mathew.
Post Edited (m.r.b.) : 8/24/2009 7:53:39 PM GMT
Thanks as well... I may need to wander this way to solve my PSM graphics issue as well.
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
If I might pose a question here, I am just briefly looking at the 1b and 2bit code samples and note that they calculate a 64 byte aligned address then use longmove to move the user data...· is memory wasted by both having to store the data and then also reserve a new location for it?
Do you do a test compile first to locate the address of the font data in order to determine the required padding?
Along the lines of the original question, is there any way to specify the address where data will be placed, similar to how you can specify eeprom data in a pic or avr?· It seems like it would be handy to have these kind of things positioned from the compiler if possible.
edit - would a potential workaround / hack be to manually edit an eeprom or binary file with your data at your selected address?
Thanks for the sample code - I'll have to review it tonight.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Post Edited (Agent420) : 8/25/2009 5:58:44 PM GMT
long 0[noparse][[/noparse]((($+15)>>4)<<4)-$]
For 32 bytes, I'd use this:
long 0[noparse][[/noparse]((($+31)>>5)<<5)-$]
It works in BST, I do not know in the others.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit some of my articles at Propeller Wiki:
MATH on the propeller propeller.wikispaces.com/MATH
pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL020
OMU for the pPropQL/020 propeller.wikispaces.com/OMU
Post Edited (Ale) : 8/25/2009 7:42:47 PM GMT
Could you expand on that a little?· I'm not sure I understand it...· does the $ represent the address of the data block to be aligned?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
long value[noparse][[/noparse]number_of_times]
$ is the current address so the number of longs till next boundary is the next boundary minus the current address:
next boundary is: (($ + 31) >> 5) << 5
Whem the current address is 7 we have:
next boundary = (( 7 + 31) >> 5) << 5 = ( (38) >> 5) << 5 = (1) <<5 = 32
number of times = 32 - 7
then:
long 0[noparse][[/noparse]25]
Edit: you can also do an AND, shifting left and then right is the same as ANDing :
long 0[noparse][[/noparse] (($ + 31) & 0xffe0) - $]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit some of my articles at Propeller Wiki:
MATH on the propeller propeller.wikispaces.com/MATH
pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL020
OMU for the pPropQL/020 propeller.wikispaces.com/OMU
Post Edited (Ale) : 8/25/2009 7:51:13 PM GMT
Thanks for taking the time to clarify that :-)
edit -
I guess worst case is that you burn up 63 longs to get in synch.· Still I wonder if the binary files could be hacked and then the app uploaded via Propellent or something.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Post Edited (Agent420) : 8/25/2009 8:00:21 PM GMT
Your method aligns the data in the cog, but not in hub memory, since $ is relative to your org 0.
-Phil
Yes Phil, you are right. The same method using either @ or @@@ with a label does not work. It seems the compiler does not like the @ operator used more than once. I'll report the bug to Brad. <- It seems I wrote the wrong equation then it did not work but it really does when correctly written.
For HUB RAM it should be (memory is in bytes and not in LONGs:
label byte 0[noparse][[/noparse] (( @@@label + 31) & $ffe0) - @@@label]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit some of my articles at Propeller Wiki:
MATH on the propeller propeller.wikispaces.com/MATH
pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL020
OMU for the pPropQL/020 propeller.wikispaces.com/OMU
Post Edited (Ale) : 8/26/2009 10:13:15 AM GMT