I've not used it in that that mode, though I've certainly used it with Termux as a terminal driver. There are also freestanding displays sold. At larger sizes there is a considerable price premium.
The Max Lumi runs $800--$900 itself.
I'd be satisfied with 80×24 characters (400 × 192 pixels without grayscale). It's not optimal, but it's adequate for reading, including hypertext browsing of Kiwix, and writing, including text and code. The Nokia 84×48 pixel screen is inadequate.
It's battery powered. Consumption depends on usage patterns.
The battery on the Max Lumi 2 is 4300 mAh. Under my typical usage which includes much Web browsing, use of frontlights, and WiFi, 1--2 day battery life is typical. Optimized for e-book reading only (no radios or lights, periodic page turns), up to a week. If you're just looking at a static image ... forever.
Running as an active display, I'd expect battery usage to the lower end of the range and for the display interface itself (HDMI) to account for a good chunk of that, though this is pretty uninformed speculation.
Specs: https://onyxboox.com/boox_maxlumi2
Cutting out the middleman, if you're looking at e-ink monitors, there are the Mira and Mira Pro:
https://onyxboox.com/boox_mira
https://onyxboox.com/boox_mirapro
Again, neither offer a specific power consumption rating.
The Mira is effectively the Max Lumi display in a monitor package. No power draw spec that I see though it's drawn over USB-C.
The Mira Pro is a 25.3" E Ink Carta display with a lower dot pitch (145 dpi) at 3200x1800.16 bit greyscale.
I'd suspect that the major draw would be in the HDMI interface itself, as well as whatever the update frequency was.
With e-ink itself, persistence is free, colours are few, paints are expensive. Pagination or cell updates (e.g., text terminals) probably fare better than raster graphics. Running additional processing (e.g., Web rendering, audiobook processing, frontlights, WiFi, Bluetooth) cut into battery life, though it remains excellent.
For my purposes neither 100 mW or 10000 mW counts as "excellent battery life". Like I said, what I'm interested in is submilliwatt computing.
Enough processing for an interactive computing environment is a lot lower power than running an e-ink display, comparable to the SHARP Memory LCD. Even conventional CMOS microcontrollers like the STM32L are down around 200 pJ per 32-bit instruction, at which rate running a conventional CLI environment (150 kips, like a C64 or CP/M box) costs about 0.03 mW, though you start to run into leakage and wakeup limits, and a 3M workstation like the Sun or PERQ (1 megapixel, 1 megabyte, 1 MIPS) should cost 0.2 mW. The Ambiq subthreshold line claims closer to 30 pJ per instruction, putting the 3M performance level back down to 0.03 mW, plus 68 μA overhead, which at 3.3V is 0.22 mW. You can totally do web browsing at that speed but we're talking Elinks or Dillo, not Servo or Blink (and so not Slack or Fecebutt).
Otherwise, I've given you the information I have, and have pointed you in the directions I'm aware to point you in. My interest and awareness here is modest at best.
With one further exception.
GSeph Electronics is a YouTube channel which has given some technical e-ink demonstrations and might offer further information along the lines of your questions:
See this video demonstration of response times (not what you're looking for, what I have on hand): https://youtube.com/watch?v=KdrMjnYAap4
Video playlist: https://m.youtube.com/c/GSephElec/videos
Twitter (via Nitter): https://nitter.kavin.rocks/gsephelec
I'm curious just what you're thinking of that requires / demands a maximum of 100--1000 mW power draw.
What I'm interested in is lightness, autonomy, resilience, and durability. Batteries are terrible for these because they are heavy, they are difficult to make and repair, they spontaneously catch fire, and they wear out very quickly, typically in about two years in the case of lithium-ion batteries. Moreover, if you need multiple watts of power, it's a real hassle to recharge the battery without plugging in.
Reducing the size of batteries reduces these problems somewhat, but you need to eliminate the batteries entirely if you want a computer that can last 50 years.
As I said in my comment above:
> Pulling once on a pullstring to wind up your computer yields potentially about 25 J. At 300 mW that yields a minute and a half of usage. At 3 mW, two and a half hours of usage. At 0.2 mW, 34 hours of usage. So below 1 mW you're into solar-calculator territory; I disassembled one of those solar garden lights with an LED and a rechargeable battery in it and measured its 38 mm square panel at 8 mW.
A few years ago this sort of thing was infeasible: memory LCDs didn't exist, subthreshold processors were confined to laboratories, and SSDs were both power-hungry and slow. Now all the pieces have come together to make it possible to build a 10-MIPS workstation (burstable to 1000 MIPS), easily capable of rebuilding all of its own system software, with a screen comparable to the original Macintosh (but smaller, and readable in sunlight), with hundreds of gigabytes of storage, that runs on under a milliwatt. But it can only have a few megabytes of RAM, so it needs differently designed software.
What would such a thing be useful for when our cell phones have become pocket supercomputers with multi-megapixel displays, always-on multi-megabit internet connections, gigabytes of RAM, and teraflops vector GPUs? Well, they don't actually work very well for writing a novel, reading a book in the park, designing a circuit board, writing a video game, ssh, or even plain text email, they run out of battery after only a few hours of continuous use, they're fragile in part because they're heavy, and you have to replace them every few years, generally without the option to transfer your existing customized environment to the new hardware. They're difficult to back up (except to sharecropping PRISM landlords like Google and Apple), they stop being able to so much as set an alarm when their filesystem gets full, and they're designed to disrupt your mental focus rather than sharpening it.
I think you should be able to render epub files, PDFs, Kiwix dumps, and OpenStreetMap maps in a few megabytes of RAM, especially with modern microsecond-latency NAND flash instead of floppy disks as secondary storage, and obviously that's plenty of RAM for an editor, a GUI, a high-level programming language, or a cryptocurrency wallet. And you should be able to design it lightweight and waterproof enough to take to the park or on a camping trip; the display I linked above has 0.1 megapixels in 60×35 mm, so original-Macintosh resolution is 60×70 mm.
I have a few general concerns:
For any human-oriented computing based on accessing remote or general-distribution content, I think you'll find that as compute power gets cheaper, the response will be for payloads and tasks to become ever more complex. What used to be communicated in plain-text email, talk(1), or write(1) payloads is now wrapped in apps or JSON or HTML+CSS+JS, where the package-to-payload ratios often run 100:1 or worse. PDF documents become ever more complex and heavy. Your ultra-low-power system simply won't keep up.
I'd resurrected a 2005-era system for general use over the past few years. It was great for pretty much anything except surfing the Web. Firefox + 2-3 tabs would routinely lock the system. Terminal-mode browsers were far more viable, though much of the Web is now inaccessible to those.
So that's the first problem.
The second was a realisation I'd had a few years back that with the falling cost of SoCs and the like, a period where a full computing system would be available at less than a $1/unit price point (and falling from there at the rate of an order of magnitude every 3 Moore's cycles or so, that is, about every 6--8 years), was close.
The major problems at that point are power and comms.
Current-generation logistics tracking, particularly for orientation, shock, and temperature excursions, are based on physical detectors. These tend to change state if tolerances are exceeded and require direct observation to detect that shipping violated spec, but now when.
With a $0.10 adhesive-affixed data logger having an integrated WiFi or SIM capability, days, weeks, or months of data logging at 1s -- 1m resolution are possible. A one second resolution costs you ~2 MB storage per data channel byte month, uncompressed. And it should compress fearsome well.
Surveillance devices don't need e-ink displays ... but might be all the more interesting if they offered these.
As for solar power: the Max Lumi has a surface area of roughly 1/16 m^2 (the size of a sheet of A4 paper). With a case that has an integrated solar cell, that ought to be good for 6 W power, or 48 WH given 8 hours of irradiance per day.
(Mind: you can't use the device whilst it's charging, but ... let's roll with that.)
At a power draw of 2000-9000 mW, or 2-9W, the cell by itself could ... mostly keep up with the draw of the device itself. And if you had a battery to store that energy ... The Max Lumi with battery masses at about 500g.
My thinking is that you're far better off having your power source off-device. An external solar panel can be much larger than the device, and pull in far more energy. Again, that can be stored in various systems, and yes, batteries are a mess, but they're a pretty decent mess. For the forseable future you're sacrificing a lot of capability by excluding them.
PV charging cover does seem like an option.
A deployable array, of whatever size is suitable, would be a more flexible and IMO better option.
The notion of a computing device which could function on ambient energy is an interesting / terrifying one, so I follow you there. Low-end chips (apparently Zilog -- the Z-80 from Sinclair fame -- is one of these and popular in low-energy applications) might offer this.
With sufficiently rudimentary text formatting at least a general information device might be possible.
The original Unix ... seems like a reasonably decent candidate for this.
I really liked the Z80 idea myself, because CP/M is close to the minimum system where self-hosted development is a reasonable thing to do, and there are full free-software toolchains for it. But as it turns out, according to the datasheet, the Z80 is super power hungry, like 500 mW when it's running. Two orders of magnitude worse than the STM32L, and three orders of magnitude worse than the Ambiq chips! And there doesn't seem to be a low-power clone. Also, the Z80 isn't very good at running C, even if it's not quite as bad as the 8080 or the 6502.
Unix doesn't demand much more than CP/M, but fork() does require some sort of MMU, and writing a large system in an unsafe language probably requires some kind of memory protection for fault isolation in practice (at least an MPU). There's lots of available chips that can do milliwatt computing with the oomph of a SPARC-20 or PowerMac, but none of them have MMUs, not even PDP-11-style segmentation registers, and they also have less RAM. You'd have to compensate for the lower RAM by using secondary storage more aggressively; fortunately, secondary storage is four orders of magnitude lower latency now than it was in SPARC-20 or PowerMac days, but in the submilliwatt regime you're probably limited to I/O rates that are slower than those machines could typically manage.
If you're interested, more detailed notes can be found in Dernocua in notes/energy-autonomous-computing.html. Along with, of course, lots of marginally relevant crap.
You may be interested in the discussion about Oberon that started the other day if you missed it: https://news.ycombinator.com/item?id=30467122
On CPU architectures and such --- I'm pretty much out of my depth. I'd been in a discussion of the Z-80 a month or few back on Mastodon and asked whether or not there was still any extant usage, I was told there was. My understanding (very shallow, likely wrong) is that present gen versions of the chip are low-power, though there may well be far-better-suited options.
On low-end CPU Unices, there's Alan Cox's Fuzix. I followed some of his disucssion of that. There's been less discussion of late, and I'm not sure of specifics. IIRC that was based on 286-ish CPUs, with no MMU. Among the ports I'm aware of is the RaPi Pico. No idea where that falls in your power budget.
https://www.cnx-software.com/2021/02/23/fuzix-unix-like-oper...