|
> Counting mW and decades implies text > GUI. so, i don't want to be unkind, but i think this is a misconception, or a pair of misconceptions, and i think i know where one of them comes from. i'll try to steelman it before explaining why it's wrong the first assertion is that counting milliwatts (or actually microwatts in this case) implies that text beats guis. the second assertion is that counting decades implies that text beats guis. i have no idea where the second assertion comes from, so i'll focus on the first a first plausible justification for the first assertion is that power usage (over leakage) is proportional to the number of toggling bits (or perhaps cubic or quadratic in the number of toggling bits if voltage scaling is an option) and a character generator toggles many fewer bits than all the computation needed to draw a gui, so applications written for a character-cell text terminal can use much less power than gui applications. a second plausible justification is that we have many examples of applications written for character-cell text terminals which use much less computation (and therefore power) than any existing gui alternative the first justification has two problems: first, it's comparing solutions to the wrong problem, and second, character-cell text terminals aren't even the best solution to that problem; they're the best solution to a significantly different problem which we don't have the problem that the first justification is trying to solve is the problem of generating a video signal that is useful according to the goals of the application. in that context, the character generator is running all the time as the beam refreshes the phosphors on the crt over and over again. it is true that the character generator can compute the pixels to send to the crt much faster and with less transistors than a cpu can. but in the zorzpad, the display itself is bistable, like the plato gas plasma terminals from the 01960s. there's a flip-flop printed on the glass in amorphous silicon next to each pixel. so we don't have to consume any computational power refreshing a static display (though we do have to reverse the polarity to it a few times a second to prevent gradual damage to the lcd). we only have to send it updated lines of 400 bits. we don't have to generate a continuous video signal moreover, the fact that a character generator would toggle less bits than the cpu to generate a line of pixels is somewhat irrelevant, because ambiq doesn't sell a character generator chip, and a character generator implemented in conventional cmos from another vendor (or on an fpga) would use orders of magnitude more power than the subthreshold-logic ambiq microcontroller, so we'd have to do the character generation process on the cpu anyway. at that point, and especially considering that the memory-in-pixel lcd display hardware doesn't impose any timing constraints on us the way an ntsc or vga signal does, there's no extra cost to generating those lines in a more flexible way. even without a framebuffer, generating lines of pixels on demand, we could support glyphs positioned with pixel precision rather than character-cell precision, proportional fonts, multiple sizes, polygons, rectangles, stipple patterns, overlaid sprites, and so on also, though, generating a line of pixels or a vga video signal from a framebuffer requires less bit toggling than generating it from a character generator. with the framebuffer you literally just read sequential words from ram and send them to the display with no processing. what character generators save isn't power; it's memory. with a character generator you can drive a 1280×1024 display with an 8×16 font (256 characters, say, so 4096 bytes of font memory) displaying 64 lines of 160 columns, requiring 10240 bytes of glyph indices, for a total of 14336 bytes of memory. for the traditional 80×25 you only need 2k of modifiable memory and a font rom. and you can do it with strictly sequential memory access (many early character-cell text terminals used delay-line memory or shift-register memory) and meeting the strict hard-real-time guarantees required by the crt hardware being driven in this case, 400×240 1-bit pixels would require 12000 bytes of framebuffer per screen, and 24k is about 6% of the apollo3's total 384k of sram. in theory the apollo3 needs about 2.1 cycles per 32-bit word to copy data into the framebuffer without rotating it, a number i haven't tested, so 12600 cycles to redraw both screens from scratch; at 48 megahertz that's about 260 microseconds, so it doesn't use much of the chip's available horsepower even at submilliwatt power levels. the display datasheet only guarantees being able to draw two megapixels per second, so redrawing the screen should take 48000 microseconds, although others have reported that it works reliably at three times that speed. hopefully i can use the cpu's built-in spi peripheral to spew out buffered spi data to the screen while the cpu goes back into deep-sleep mode. if i use a character generator implemented in software to avoid having a framebuffer, i have to wake up the cpu periodically to generate new lines of data, using more power, not less. (which might be worth it for the memory savings, we'll see.) even without enough memory for a framebuffer, though, character generators weren't the only way to generate hard-real-time video signals. the nintendo (nes) only had 2k+256 bytes of vram, for example, and you could do pretty elaborate graphics with that. it used tiles (which are sort of similar to font glyphs and can in fact be used for font glyphs) and sprites (which aren't), plus scrolling registers. some other hardware supported display lists of straight lines instead of or in addition to glyph indices the second justification is basically a cohort confounder. yes, vs code uses a lot more cpu than vim. but vim was originally written for the amiga, and vs code is written in electron. applications that run in character-cell text terminals do empirically tend to be a lot faster than gui applications, but that's largely because they're older, and so they had to be written with more attention to efficiency. remember that geos provided a standard wimp interface on the commodore 64, with mouse pointers, sliders, pulldown menus, proportional fonts, overlapping windows, and so on, and all that in color without a color framebuffer, adding extra work. it was slow, especially when it had to load data from the floppy drive, but it was usable. the commodore 64 is about 0.02 dhrystone mips (https://netlib.org/performance/html/dhrystone.data.col0.html) and the apollo3 is about 60, so running something like geos on it at 10× the commodore speed ought to use about .3% of its full-speed cpu. or 3% if it's running in a simple bytecode interpreter so that's why i think submilliwatt computing doesn't require abjuring the gui does that make sense? have i just totally misunderstood you? |