have a look on this table. I want to store that in an nice 16bit table when transfering my code from basic to assembler... any ideas? I would prefer 8.8 fixed point format but maybe my math skills are getting old but can someone tell me how to do that?

If it's something like angles, you don't have to stick with Degrees. When I was thinking about 3D calcs, my approach was to use 64 divisions per right angle rather than 90... makes things a lot easier.

But yes, like the idea you just posted - requantify the values such that they're spread over the integer spectrum you're using, and you shouldn't lose too much precision.

You need 13 bits for your max integer value (8800), so if you are forced to 16 bit values, that gets you something like 13.3. In that case I probably would drop the 2 highest values (8800 and 4400.. this sound like Hz values ) and use a 12.4 representation, representing these max values as a "special" case in the code (and assigning them a special bit sequence..).

If size (and speed) is not a problem I would go for a 16.8 or 16.16 representation directly.For the decimal part, 8 bits gives you something like "2.25 digits" of precision, and 16 bits gives you like "4.5 digits" of precision (P-M numbers use 8 bits of decimal precision by the way.. but could also use 16).

This is the code I normally use to transform a float value (below 256) to a 8.16 byte representation:

1) Highest Number is 8800 and should fit in 256 ( 2^8 )2) 2^N as factor for shifting would be nicethis means DIV 32 or DIV 64In DIV32 the 8800 would get 255 instead of correct 275 wich is only 255*32=8160 but you have one mor bit for accuracy

maybe a simple DIV 256 MUL 65536?

simple DIV 64 MUL 256or DIV 32, Max(value,255), MUL 256

You can interpret the resulting numbers as 13.3 or 14.2 fixpoint arithmetic (without using a sign, because all numbers are positive)