Byte Access into Array of Longs

mynet43

I'm trying to figure out the syntax needed to extract byte data from an array of longs.

Here's what I'm using:

VAR
  long  cam_data[noparse][[/noparse]6400]          ' storage for 20 lines of camera data 20 * 1280 bytes / line

' * * * other code

PRI cam_data_out | r, g, b, fst, snd, x, y, line
' some code...

    repeat y from 0 to 45         ' 46 lines
      repeat x from 0 to 6        ' 14 fields per line
        ix := (x + y*7) + (line-start_line)*1280 ' two bytes per pixel
        snd := cam_data[noparse][[/noparse]ix].byte[noparse][[/noparse]0]      

When it encounters the statement "snd := cam_data[noparse][[/noparse]ix].byte[noparse][[/noparse]0]", I get an error message that says:
"Expected end of line." And it highlights the decimal point.

As near as I can tell, this follows the syntax shown on p. 169 of the Prop Manual.

I know I can do it with a mask and shift operation, but this looks like it should work.

Thanks for the help.

Jim

James Long

Jim,

Your syntax should be:

snd := cam_data.byte[noparse][[/noparse]ix]


James L

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
James L
Partner/Designer

Lil Brother SMT Assembly Services

mynet43

James,

Thanks for the help. I'll try it.

I assume if you want the second byte in the long, you'd use:

snd := cam_data.byte[noparse][[/noparse]ix+1] Right?

Also, if you compile a null routine, you'll see that there are more than 8,100 longs available.

In my case, I have 746 free.

Thanks again,

Jim

mynet43

James,

I just tried what you suggested.

Basically it worked, but I discovered two things.

1. ix is an index into the long array, therefore, I have to multiply ix by 4 to get to the right long.
So if I want the second byte, I would use: snd := cam_data[noparse][[/noparse]ix*4 + 1]. This works perfectly.

2. I discovered to my surprise that the 'first' byte in a long (byte index zero) is physically the last byte in the long.
In other words, the low order byte, NOT the first byte from the left, like I was assuming. I'm sure this is just my ignorance, but maybe it will help someone else get it right the first time. To me this is counter intuitive, based on the way the data is stored in a byte array. Think what would happen if you did a BYTEFILL into a long array and then tried to access the data this way.

Mike Green

Don't forget that your program will use some stack space and that will use part of the "free" space.

The byte order is what is called "little endian" where the least significant byte comes first in memory.· Some computers use "big endian" where the most significant byte comes first.

mynet43

Good point Mike.

I know it's really tricky to estimate the stack space, so I'm assuming that 700+ longs should be plenty.

I realize now what's happening with the byte order. I was packing the byte data into the long array in an assembly language routine. Then using this spin routine to display the data. I chose the long array to avoid the re-ordering of a byte array by the compiler. Looks like I fooled myself.

The good news is that this explains why I couldn't make sense of the data I was getting...

Thanks for the help.

Jim