1mA/MIPS is a pretty generous power budget, with ESP8266 easily fitting the bill (56mA @80MHz + wifi rx; 10 uA in deep sleep [1]). Talking of which - here is Jeroen Domburg's project where he used exactly this chip to make a wireless battery-powered e-ink display:

[0] http://spritesmods.com/?art=einkdisplay

[1] http://bbs.espressif.com/viewtopic.php?t=133

I'd forgotten all about the ESP8266 but this project is about 95% of what I'm aiming for. The rest should be relatively trivial programming work, so thanks!

Can't speak for the other guy (who wants a portable monitor+keyboard system), but what I'm mostly looking for is a terminal that I could carry around/outside the house (i.e. potentially high-glare conditions) and program while connected to wifi, while not recharging for as long as possible, so this is perfect.

Maybe I can embed some stuff like vim or emacs on the device itself to help reduce utilization of the wifi. Is there any sort of "smart" protocol that could handle buffering files while editing on a remote host? I can probably do it, but I'd rather not reinvent the wheel, caching can be non-trivial.

Secondary use-case: RTTY or PSK31 or other amateur-radio textmode terminal, that could idle for as long as possible on a portable (QRP) battery pack. When you're schlepping the gear around, every ounce counts. Something that can talk serial is probably good enough, wifi is redundant there.

Regarding your query about a remote login protocol that's smart about buffering, etc, I think you're looking for mosh: https://mosh.mit.edu/

I have been working on the MagicShifter project (http://magicshifter.net/) and we designed the board so that the UART is available (for MIDI and other things).

If I can find a paper-ink display that I can drive somehow with a UART, I'd be quite happy to wire it up and hack up a MagicShifter app that turns it into a dumb terminal. Know of such a thing?

I regularly use Vim over high latency connections (50ms+) for extended periods, and it's really not that big a deal.

Wait, over 50ms is high latency now? That's less than transatlantic traffic delays, for example. I think you have to be in the actually noticeable (say 250ms plus) range to count as high.

Not to sounds like a Monty Python skit, but 50ms really does seem like luxury to me :-). I guess to back up the OP's point, I regularly use vim over 250ms+ latency lines for hours on end. It's not fantastic, but it's definitely doable. You need to have your vim golf game up to par, though :-)

You know your latency is high when your mental model switches from vi(1) to ed(1).

If you use classic vi modes, I think vi/vim is much more forgiving over high latency than emacs, for some reason.

I'd really love to have one or five of those for maintenance work. There's a lot of devices that I don't really need to have a keyboard and video connected to for 99.99% of their life time, but I still need an LC display and KVM switch connected to for about 10 minutes per decade. It's such a waste.

The Kobo line seem nicely hackable.

They have a horrible bit of forcing the user to connect an account online during first power-up. This can be avoided with a bit of SQL. This site talks about "activating" without the desktop app (and other bits of tinkering):http://uscoffings.net/clc/tech/embedded/kobo-touch/

>Connect the Kobo via USB, and mount its onboard storage on your desktop machine.

> Ensure you have an SQLite3 database browser installed, or some way to execute SQL. For example, sudo apt-get install sqlitebrowser

> Open /mnt/onboard/.kobo/KoboReader.sqlite.

> Execute this SQL: insert into USER values("foo", "foo", "foo", "foo", "foo");

> Save, unmount, and disconnect.

Here's a bit about enabling Telnet (and cross compiling for Arm7): https://github.com/drj11/kobonotes

Here's someone who turned their Kobo into a GPS for their glider. http://hackaday.com/2014/05/28/e-reader-becomes-sailplane-an...

It's still a bit of a mess, and doesn't come with a decent keyboard, and the screens are tiny. I'd rather have something in a notebook formfactor – 12" eInk, full keyboard, and just a serial port on it. (Maybe also USB, for charging and slaved to a serial-to-uart adapter.)

Euhh, I'm not sure I understand your use-case, but e-ink displays aren't especially "cheap", or such. They take a noticeable amount of time to update the display, so doing things like typing, or viewing output from top(1) would be less than ideal. (This seems to get better with firmware, and being "smart" about which places of the screen get updated, generally)

The appeal, at least to me, is that they can display information with little energy cost. For example you could have it monitor the system's health and have it update every half an hour, showing graphs and such, and it would be able to do that for a very long time with a smallish battery.

I feel like I'm missing something - why do you need it to run on battery if it's consistently monitoring a specific machine? Isn't their power pretty much anywhere you'd need something like this?

I edited my use-case after he replied - I think he would be A-OK with something that could be reliably powered from a USB port. I don't speak for him, but I think we've chatted on this topic before.

You can power a "Full HD" monitor off USB. These have been around for a while, but it's really fun to see someone set up with dual screens at a coffee shop running on batteries: https://www.asus.com/us/Monitors/MB168BPlus/

Kind of random, but you made me think of it. I always wanted to do an entire site in PDF, with all the links opening other pdfs on the same server. That or postscript...

Funny you bring that up, I was just reading about this:

When Steve Jobs left Apple and started NeXT, he pitched Adobe on the idea of using PS as the display system for his new workstation computers. The result was Display PostScript, or DPS. DPS added basic functionality to improve performance by changing many string lookups into 32 bit integers, adding support for direct output with every command, and adding functions to allow the GUI to inspect the diagram. Additionally, a set of "bindings" was provided to allow PS code to be called directly from the C programming language. NeXT used these bindings in their NeXTStep system to provide an object oriented graphics system. Although DPS was written in conjunction with NeXT, Adobe sold it commercially and it was a common feature of most Unix workstations in the 1990s.

https://en.wikipedia.org/wiki/PostScript#History

There is something interesting (if you can say "interesting" to the idea of writing, say, an e-mail client in PostScript):

https://en.wikipedia.org/wiki/NeWS

I remember some fuss being made about this in the early days of OS X, about "looking glass" (the gui system) using display postscript. Anybody know anything about that? If it's still a part of OS X or if it fell by the way side?

OSX was alleged (by Apple, even) to use PDF as the display language, but Quartz just has an object model that maps very nicely to PDF, making PDF transformations and export very easy.

This reminds me of Terry Davis' TempleOS, which features an ubiquitous hyperdocument system.

http://www.codersnotes.com/notes/a-constructive-look-at-temp...

Terry himself is schizophrenic but it's a fascinating piece of outsider art in many respects. He's even posted on HN under several accounts, but he's aggressive and disruptive and inevitably ends up banned.

I get why you'd have that impression (due to his mental illness), but TermpleOS is certainly not outsider art. While unconventional in some ways (and not sharing the aims of commercial projects), it's no more a piece of outsider art than e.g. KnightOS. Its code isn't bad, the design is certainly not idiosyncratic. It has none of the "classic" traits of outsider art that other hobby projects don't. You can read its code much like that of any other kernel. And IIRC, Terry Davis has the kind of academic credentials you'd expect from someone writing an operating system, too.

I am a professional operating system developer. In 1990, I was hired to work on Ticketmaster's VAX operating system.

Hi Terry! Sorry, didn't know you had a new account.

I read some of your post history - can you explain how what you were doing with Ticketmaster was systems programming? It sounds like what would now be considered application programming, but I have no idea how intensive your work was at the time. High-performance code can often cross the line.

TempleOS is simply fascinating. I'm sure you know that I can't agree on the 'divine' part but it's certainly a fascinating OS. Writing an OS is a tough task by any means, let alone a reasonably fast one with a novel presentation. That's a lot of work, even for a productive OS programmer.

Have you taken a look at MenuetOS, Plan9, Oberon, or other non-traditional OSs? I'm curious what you have to think of their own unique features.

I applaud your goal of taking it back to basics. I think you're largely right about the number of abstractions between you and the hardware. Really really fast code needs to be written close to the metal.

I worked on the code that installed language modules into kernel space. I wrote a check-disk utility. I did a file compression archive. There were serial port drivers and I made a command to reset a stuck port.

I worked in VAX assembly language.

I did firmware for a bar code reader networking device with keypad and display. I worked on image processing for an actual bar code reader itself.

I worked there 1990-1996. About half was user space. The other half was kernel or firmware on bare metal.

-----

Pat and I started at the same time. He was in school with me, in fact in my differential equations class. He dropped out of school. I stayed in and got my master's in electrical engineering while working part time at Ticketmaster. I graduated with master's in 1994 and stayed with Ticketmaster for a year.

I returned to Ticketmaster for 3 weeks in 2002. Pat was a boss.

NeWS was an interesting experiment in this direction.

It seems quite odd that old VT terminal hardware is still in use, while it would be almost impossible to resurrect something like NeWS. A case of complexity I guess, but also the worrying volatility of storage media.

I suspect VT-standards-related hardware (and software emulators) survives because the protocol can be implemented without fear of getting dragged into court for licensing fees. Whereas if you wanted to implement NeWS (or Display Postscript) even today, you still have to license it. There is an informal mention that NeWS had too many third-party components to ever open source. [1]

[1] https://github.com/IanDarwin/OpenLookCDROM

What about markdown files and relative links? Works on Github and MacDown.

https://github.com/blog/1395-relative-links-in-markup-files

See Chapter Nine:

https://www.alchemistowl.org/pocorgtfo/pocorgtfo11.pdf

I've played video games that were distributed as PDFs. You can actually do a lot inside a PDF.

Could you not do a similar thing with html and css sans js?

As an aside, do you have an idea where to buy e-ink displays? I'd love to experiment with some. If fact if I could I'd love to get one of the poster sized ones!

Visionect (https://www.visionect.com/) sells e-ink dev kits up to 32 inches, but they aren't exactly priced for experimentation (nor do they include any sort of case/bezel). On the other hand, their displays do come with Ethernet, Wi-Fi and cellular connectivity built in.

Sparkfun sell small ones in kits.

Do you mean Adafruit?

Yeah, maybe. Probably both :)

Do you know if it's possible to do this to a Kindle without hardware hacks? Thinking specifically on connecting a keyboard.

There are also some e-ink Android tablets, but I forgot if I found any that seemed good.

I also have a strong desire to ssh by e-ink, latency be damned.

Wouldn't the very slow refresh rate of eInk be an issue here?

I actually found a video of a Kindle being used as a terminal:

https://www.youtube.com/watch?v=ymei7UwBgX4

Looks like it's running a pretend-terminal website which probably explains the latency (the Kindle does not have a fast processor).

Way on the other end - here's a Dasung 13.3" eInk monitor (i.e. you feed it DVI and it handles all the display driving for you). It can be yours for a cool $1000. I'll pass, but it's looking pretty good even for GUI usage. Probably uses more power than a purely embedded solution could, though.

https://www.youtube.com/watch?v=vny-JTpt-aU

FYI, I've seen virtually zero latency running livereload experiments with the embedded browser in my Kindle, the basic 3rd-gen 2014 model.

My method was extremely rudimentary - inotify -> long-polling JS (being fed entire new file) -> innerHTML rewriting, with the Kindle connected over 802.11g - but hitting Save in my editor produced updates on the Kindle's display in around around 20-40ms.

I would put a moderate amount of money on the possibility that the latency is coming from the fact that the terminal app in the video is being run on a non-local server, and that keystrokes have to go up to the cloud-hosted app and then come back down to get onto the Kindle's display.

If the whole thing were local (with the terminal app hosted on target system, ideally) I expect updates could happen in <100ms.

Also, the CPU is a 1GHz i.MX6 (@ 996MHz), next to 400MHz LPDDR2 (@ 396MHz). It performs quite well in my experience; it's the OS that's terrible. :P

(The best OS I've yet seen was the one on my Ericsson MC218, which let me drag windows around the display faster than the LCD crystals could physically keep up. Solid windows, not outlines. On an ARM7TDMI running at 36MHz.)

I want one of those monitors so bad. Why does it have to be $1000?! Anyone willing to contribute to my Indiegogo campaign? ;)

I want one too. Suddenly, I know what I'd do if I won the lottery.

No idea about the refresh rate of eInk displays, but terminals were always designed to work over slow connections. So long as your configuration is pretty traditional (e.g. your text editor scrolling half a page at a time instead of line by line), it should be quite usable by 1970s standards.

Would that be significantly slower that phosphor persistence of old displays?

Actually, depending on what you are doing, the nostalgia-induced slowness might even be intended.

Many bi-stable displays can be quickly set in one direction, and only have a slow refresh cycle for clearing or "cleaning" the display. Given that, a terminal based on e-ink could potentially display characters quickly and only be slow when clearing or scrolling.

That'd still be painful for interactive use, though.

I suspect it would. I ended up giving away my Kindle partly because the delay in page turning[1] was long enough to bother me. I can't imagine typing with such a display.

An article on here a little while back goes into detail about how even very small latencies affect the typing process: https://news.ycombinator.com/item?id=10787812

[1] Yes, I know it takes longer on an e-ink display to refresh the entire screen than to update a single character. My point is that page turning speed is thought by most to be unimportant, but being used to PC interfaces with fast response times made it unbearable to me, especially when I was skipping through pages trying to find something.

but every change on screen require redraw the whole thing right? stuff on terminal change a lot more often than reading a book.

I've always thought that eInk+terminal would be the perfect use case for vt100 mode. This is built into xterm etc. and emulates phosphorus displays, where adding new elements to the display is fast but calling a full redraw is slow. Just like eInk.

You can change stuff without flushing the current contents, but previous contents may leave a weak trace when you do so. It's why Kindles have a setting to flush the screen every three pages or something; a decent compromise between ghosting and refresh rate.