"Normal" shell arrays did not work for me, but substrings work.
You can put thousands of chars into a var like I do with the K3 black pixels (or K4/touch white pixels) in $B in the "tangle" script. Then access them with
${B:$((y*width+x)):1} and just use different chars for your data. Or you can make the width :2 instead :1 and double the width for larger array values.
EDIT: I only tested the substring access on a touch, and we leaned later that it is not supported on the K3, so the older "echo and cut" method would be needed on a K3. This is not as bad as it would seem because echo and cut are busybox built-ins, and we are already running the busybox shell, so echo and cut would already be memory-resident.
At least that way there is no external RAMdisk access using hexdump and/or dd...
Of course, no '\x00' inside the string, but it seems to hold other binary data okay. You can use just characters to represent cell states, and use them in a case...esac after extracting them from the storage string. To replace a character at position 100 in the string with a new value in $N, I would do something like:
a=${B:1:99}; c=${B:101}; B=$a$N$e
... and you can get the length of $B with
${#B}
I just tested this by storing about
2 million chars in my $B, and extracting selected characters. It worked. So just store your "database" in a string var instead of a file on /tmp. At least I would try that and see if it is faster.
I find it fascinating that you can store megabytes in a string var, as long as it contains no NULL chars (\x00). I am going to try storing a whole framebuffer in a string (with \x00 changed to \x01, which is fine for a K4 or touch, but would reduce blacks to dark gray on on K3).
And when using a K3, you do not need to call the eips program (but you do for the K4 and touch). Instead, on the K3 and older, you can update the display the "old fashioned" way:
echo 1 > /proc/eink_fb/update_display
That would save having to call the external eips program as an external process.
EDIT: I was just about to examine your "script", but it starts with "ELF" -- so you decided to do C, eh? I just ran it. Considering that you are updating the entire display, 4 to 5 fullscreen updates is all the faster the eink can do. If you change a smaller window on the display, you can get about 12 frames per second updates, on the eink Pearl display (the older DX eink is a lot slower).
You are at the limits of the display technology here. If you want more speed you need to reduce the size of your active pixel grid on the display. The size I used on my "vidtest" demo was about the largest I could use on a K3 without slowing down the eink display refresh rate.
What I would do is use a smaller update area, but surround that with a nice ornate "picture frame" that does not change and therefore does not slow down the display... 
*** Good job! ***
I would like to use your source code if you don't mind... Is it available for download somewhere?
