I second this. To read an individual bit (where bit 0 is the lowest one) you can do:
I know we have posted many, many codes to store an image as a list and I know I have done binary packing. It isn't as efficient as you might think. First, a number on the 83+ is always a float and it always takes 9 bytes. A complex number is comprised of two floats, so it takes 18 bytes. Theoretically, you could fit 47 bits of data in a TI float (14 decimal digits nibble-packed into 7 bytes, a mantissa, and an additional byte that includes a sign bit giving the 47th bit). However, rounding problems limit this to a few bits less, so around 44 bits is what you can reliably get. If, for example, you were trying to store an 8x8 sprite, you could do it pretty easily by storing it as a complex number where the real part contains 32 bits and the imaginary part contains the other 32 bits.
As well, you would not want to extract each bit individually— that would be less efficient than other techniques. For example, if you divide a number by 2, if its low bit was 1, then a 1 would be on the other side of the decimal in binary form. So using your example of 51, 110011/2 = 11001.1. So translating to base 10, this is 25+1/2=25.5. So in BASIC, fPart(.5Ans)≥.5 would mean the bit was set. But now your number is set up so that you can get the next bit just by dividing by 2 again. In this case, you get 1100.11 which translates to 12+3/22=12.75. So in code, to draw 40 pixels from Ans:
For(A,0,39
Pxl-Off(0,A
.5Ans
If int(2fPart(Ans
Pxl-On(0,A
End
As well, to store the pixels, reverse the process:
0
For(A,39,0,-1
2Ans+pxl-Test(0,A
End
I'm surprised I haven't added my routine for creating a self-extracting image routine to the hexcodes page, though. I will have to dig it up, but you basically supply the program a name and it generates an assembly program that contains a short code followed by image data. Running the program extracts the data and draws it to the screen.
