Direct Memory Acces: Forced Downcasting?

RedNifre

I try to implement a little palette swap trick and I have troubles undestanding why the compiler tells me I have to downcast to byte-access.
This is the DAT-Section:

DAT 'Grafik-Kram

palette_map
              long $02_5B_07_5B 'change me!
              long $AD_AC_9B_9A
              long $07_5C_5B_02
              long $7E_8D_6D_7C
              long $07_fC_fB_02
              long $07_FC_5B_02
              long $7E_6D_6C_02

              long $3E_6C_04_02  '7 
              long $3E_CD_04_02  '8 

I want to replace the first entry with entry number 7. Therefore I wrote this code:

palette_map.LONG[noparse][[/noparse]0] := palette_map.LONG[noparse][[/noparse]7]  

The compiler moans that I'm trying to cast to a higher access-type. When I ommit the ".LONG" it gets down to bytes. Why is that the case and what should I do about it?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Hydra in a LEGO NES:
http://forums.parallax.com/showthread.php?p=654788

Baggers

try either putting

palette_map long

or joining the first entry to the palette_map line eg

palette_map long $02_5B_07_5B 'change me!

that should help, as unless a long or byte or word is on the label line, it doesn't know what the data type is, and as your error shows, presumes bytes.

RedNifre

Thanks a lot! It works. [noparse]:)[/noparse]

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Hydra in a LEGO NES:
http://forums.parallax.com/showthread.php?p=654788

Baggers

[noparse]:)[/noparse] no probs, anytime

AndreL

Yes, that's an annoying bug. Or just put the identifier one line down on the same line as the first long.

Andre'

Phil Pilgrim (PhiPi)

Following the principle of least surprise, this is something that ought to be corrected in the compiler. Since data in VARs can get reordered, a naked label should have some meaning, other than getting kicked downstairs with the BYTEs. Associating it with the next declaration seems the most sensible to me, and it's what the casual observer would expect if he were to read RedNifre's original code.

-Phil

RedNifre

Why is casting to a larger type forbidden anyway?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Hydra in a LEGO NES:
http://forums.parallax.com/showthread.php?p=654788

mpark

I suppose because a byte could be at an address that isn't evenly divisible by 4. I believe long accesses zero the two least-significant address bits, so reading a byte as a long might get you something unexpected.

RedNifre

I thought that too, but byte arrays also start at a multiple of 4. Assume you have this code

DAT bytes
BYTE 0,1,2,3,4
BYTE 5,6,7,8,9

Then 3 bytes will be wasted and bytes[noparse][[/noparse]8] would return 5.
So, doing something like bytes.WORD could imho easily return $302.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Hydra in a LEGO NES:
http://forums.parallax.com/showthread.php?p=654788

mpark

Byte arrays don't have to start at a multiple of 4. I tried your example and bytes[noparse][[/noparse]8] gives me 8.

Ym2413a

mpark said...
Byte arrays don't have to start at a multiple of 4. I tried your example and bytes[noparse][[/noparse]8] gives me 8.

True, but LONGs need to be LONG aligned (multiple of 4 bytes).
Words need to be WORD aligned (multiple of 2).

[noparse]:)[/noparse]

Make sure you pad your data if needed for alignment.