Actually I was thinking of an alternative method, where we are still going to loose some space but much less than storing 8 bits on 14 bits, and also relatively easy to calculate addresses: We store the first 7 bits of each bytes in a way of: 0 0 0 0 0 0 0 1 1 1 1 1 1 1 (word 0) 2 2 2 2 2 2 2 3 3 3 3 3 3 3 (word 1) 4 4 4 4 4 4 4 5 5 5 5 5 5 5 (word 2) 6 6 6 6 6 6 6 7 7 7 7 7 7 7 (word 3) If we are going to store 7 bit data stream like pure ascii, then we are already fine, but if we need the 8th bit, then we store it in a separated area: xx xx xx xx xx xx 00 01 02 03 04 05 06 07 (word 0) xx xx xx xx xx xx 08 09 10 11 12 13 14 15 (word 1) xx xx xx xx xx xx 16 17 18 19 20 21 22 23 (word 2) Se here we are loosing 6 bit/8bytes, but its much easier to divide by 8 here, and by 2 when calculating for the address of the first 7 bits. Also the remainder is fairly easy with a single ANDLW instruction... With these 8th bits we can use RETLW as well as it could be faster to do so than eeprom reading. Alternatively it could be shared with a table of 6 bits of data array. What do you recon? Tamas On Mon, May 12, 2008 at 1:25 AM, Timothy J. Weber wrote: > Forrest Christian wrote: > > My initial glance at your code looks like it still requires the divide > > by 14, and the multiply by 8, just in opposite directions. (Divide by > > 14 to get which "block", then multiply by 8 to get the starting address > > of the block). The retrieval seems worse, though since it requries 8 > > bitwise shifts, 8 ands, and 8 ors. > > Yup, I think you're right. > -- > Timothy J. Weber > http://timothyweber.org > -- > http://www.piclist.com PIC/SX FAQ & list archive > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist > -- Rudonix DoubleSaver http://www.rudonix.com -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist