| HN Mirror

with respect to moving very little data around, the bulk of the data that needs to be moved is pixels to display; a character is 1–3 bytes in the editor buffer, but in a 16-pixel-tall font, it averages about 128 pixels. that's 512 bytes in 32-bit rgba or 16 bytes in 1 bit per pixel. on the zorzpad, without interpretation overhead, i think i can roughly guesstimate about 100 instructions, and at a nominal 25 picojoules per instruction, that's about 2.5 nanojoules

i still haven't measured, but if i recall correctly, the ls027b7dh01 memory lcd datasheet says that maintaining the display statically costs about 50 microwatts, while inverting all the pixels once a second raises that to 175 microwatts, which is to say 125 microjoules to invert all 96000 pixels, which works out to 1.3 nanojoules per pixel. so updating those 128 or so pixels will cost about 170 nanojoules, which is a lot more than 2.5 nanojoules

i'm unclear on how much of this 125 microjoules is due to simply shifting in new lines of 400 pixels, regardless of their contents, and how much is due to the actual inversion of color of the pixels; after all, they invert polarity several times a second just to maintain the display without damaging it. if the expensive part is shifting in the pixels, then to display a single new 16-pixel-high letterform, we're updating 16 × 400 = 6400 pixels rather than 128, costing 8300 nanojoules. typing at 60 words per minute (5 letters plus a space) would then dissipate another 50 microwatts if you fully updated the display after every letter. when you're typing into previously empty space, you could maybe update only a third of the pixel rows after each letter to cut down on this, completing the delayed updates after a few hundred milliseconds if you stop typing

it might turn out that the most important thing to do to minimize power usage is to minimize the amount of the screen that gets regularly updated, and last night i was thinking about how in bsd talk and on mit its, text would wrap around from the bottom of the window back to the top rather than scrolling. emacs does a less aggressive version of this where it does scroll, but it scrolls by half a screenful at once when the cursor goes off the screen, so that updates to the whole screen only happen every ten or twenty lines of movement or typing, rather than after every line. this was important on terminals like the adm3a that didn't have escape sequences to insert and delete lines

narrowing the view to a single symbol might avoid the need to spend energy drawing lines of text from other symbols, perhaps repeatedly as line insertion or deletion moves them around on the screen

the adm3a also didn't have escape sequences to insert or delete characters, and vi (strongly influenced by the adm3a) does a peculiar thing with its 'c' change command; if you say, for example, ct. to change all the text before the following period, it doesn't erase that text immediately, but puts a $ at the end of it so that you know what you're changing. this avoids the need to shift the rest of the line right after each character. (vim does not do this.) if the big energy suck is actually changing pixels, as i think it is on e-ink, rather than shifting them through a shift register, that might be a useful strategy to adopt: open up space to type into, with some kind of indicator that it doesn't contain spaces or any other characters. like a visible manifestation of a buffer gap, but measured in pixels rather than bytes

i don't think there's a reasonable way to hack a hardware blitter into the zorzpad, but doing it in software is very reasonable