After looking over the source for custom pics (from the other thread), I figured out how the pics are stored. Basically, he cheated. He's not storing the data as a list variable, but in one. Try and edit the list and you'll see some ugly stuff.
To explain why it's "cheating" you'll need to know (1) how floating-point numbers are stored, and (2) how list data is stored.
(1) Floating-point (FP) numbers are 9 bytes in length (well, 11, but the last two aren't saved). The first byte determines whether it's real/complex, positive/negative. The second is the exponent, offset from $80 (i.e. if you have the number 28 =2.8×10^1, the exponent byte would be $80+1=$81). The next 7 contain the actual number. Each has two decimal digits, for a total of 14 digits. For example, π=3.1415926535897 so in FP it's $00 (sign), $80 (exp=0), $31, $41, $59, $26, $53, $58, $97.
(2) The first two bytes of a list contain the length. After that are FP numbers placed one after the other (that's why a list entry is 9 bytes).
Now, if you have an n-element list, then after the length bytes are nx9 bytes for the data. As I said in my earlier post, the screen is 96x64 pixels wide, but (to correct my earlier statement) the bottom row of pixels isn't usable so it's really 96x63 pixels to be saved, which means it takes 12x63 bytes to save it. What luck! 63 is a multiple of 9, so you can use 12×63/9=84 FP-numbers-worth of data to store the whole picture. This data has absolutely no meaning* if you try and recall it as a list, but is fits nicely inside the memory allocated for the list.
- e.g. The number $FF, $FF, $11, $11, $22, $22, $33, $33, $AA can't be a FP# since $FF has no meaning as a sign flag, the other $FF would mean the exponent is 127, and $AA is not made of decimal digits.
