You know why I thought it's better not to do so? Because I thought we can have our messaing software arrange the bit patterns the way it's easier for the uC to manipulate. You know writing C code on a PC is very much easier than assembly on an embeded system regardless of the level of complexity on the PC programmer's shoulder. I intended to do this to make the job of uC easier, but it seemed that I can't solve the problem of how to arrange the bit patterns in the SRAM. Yet, it seems to me that despite what I thought it may surprisingly be easier to simply put the data in consecutive locations in SRAM as you (Eric) suggest.


I don't quite follow. I'm multiplexing, each module has four HC595s. P1 provides serial data: each pin of P1 is connected to a module and feeds four HC595s, the HC595s in turn provide row data. I did this to benefit from having to issue just one clock for every 8 bits sent to the modules, but I wonderred how to "make" the byte for P1.
I may have to think of something like this:

get char"s" from different locations of RAM addresses: 0, 8, 16, ...
loop for 8
some bitwise torture to make the byte using the chars and some rotations
put byte on P1
clock high
clock low
if not 8 back to loop for 8
strobe