PaperTerm Concept, An e-paper remote terminal device
paperterm.org
paperterm.org
These notes haven't been cleaned up to be public yet (near the end it gets particularly messy and the memory map has changed from the state shown on this page), but oh well, it's been found!
I will answer any questions you may have.
And if you want to help make this, my email address is in my profile. Programmers, electrical engineers, testers, documentation... whatever skills you have, I'm sure you can help!
I could understand the no-distraction writing i.e. word processor use-case that some people think E-Ink would be good for, but that doesn't appear in your list of possible applications either.
But, yes, a laptop can do pretty much everything Paperterm can do. A laptop can do everything a Kindle can do. A laptop can do a huge percent of what your phone can do. If the advantages of this niche device (e.g., sunlight-readable display with no backlight/blue-light, it's insane battery life, a no-compromise keyboard, and it's always-ready-"never-off" state) doesn't appeal to you, then you're right, you're probably just not in the target demographic. Those in the target market find a lot to love in such specs. This is explicitly a niche product, not trying to be everything for everyone (which is closer to what a laptop does).
EDIT: if you have a look at the (also not ready for announcement) root of the domain, you'll see a brief pitch: http://www.paperterm.org/ This page also has notes-to-self in brackets, and I'm not in a spot where I can fix it right now, so ignore that.
Lugging around a full KVM console is overkill (unless it is literally on a cart and you only need it at one location). And USB crash cart adapters are buggy, overpriced, and unmaintained.
With serial, SSH, and KVM this will fill the perfect "there is a piece of hardware on the rack I need to interface with" role.
Exactly because it is limited in it’s application.
Google can give you an idea of how it looks, but with a much smaller screen than we're using (ours is 13.3") so these images feel more cramped and look more "plain jane": https://www.google.com/search?q=e-ink+terminal&um=1&ie=UTF-8... With the larger screen and more refined setup than these Google Images pictures show, it is very pleasant to use. I hands-down prefer it to a laptop running a terminal, except when color is important.
What are you going to do about the actual cost of the device? You've already got an e-paper display, but you're also adding a 'laptop' style enclosure, real keyboard, and if you're storing SSH keys, you're really close to running a cut-down Linux system. That's basically a laptop, and you could get the same thing with, you know, a laptop. Have you thought about scaling down the display, keyboard, and enclosure to something palm-top sized?
No, I think the smaller size is probably a non-starter for the intended audience. This is meant to be a tool that a lot of these folks are using for hours and hours a day so overall typing and reading experience is paramount, and meant to be a "selling" point.
Cost-wise, yes--we're still grappling with costs of the e-ink screen. It's the by far the largest expense in the unit. We've got a good lead that I unfortunately can't talk about at the moment (under NDA).
A cut-down Linux really is overkill for this, and isn't capable of making some of the other specs happen (battery life, availability), at least as far as we've been able to determine. Custom code is unfortunately where we've been forced to go.
Looking at all of the options a simple full RLCD would probably be best for us--not eink--but we can't find appropriate parts for the size and resolution.
RLCD is an interesting option, I guess the sacrifice there is readability angles and paper-like-ness?
Embedded Linux (eg any distro using busybox for glibc) is (imo) the appropriate stack to use for this given how cheap a microcontroller with an MMU is these days, and once you get rid of all the bloat, is capable of very quick boot times (availability), and if the device is off (and not just sleeping), then its battery life is similarly extended. (Don't let the poor battery life of Android phones let you believe Linux isn't capable of long battery life. Smartphones don't actually get to sleep while the screen is off.)
Remember, the device can sometimes have enough time to sleep BETWEEN keystrokes while typing. (The microcontroller can sleep then wake and power up peripherals with only a tiny, imperceptible delay.) This isn't your typical Linux setup. FreeRTOS is plenty. For the limited things it does, it wants to be a no-compromise device. There is no on button. There is no off button. You grab the device, it has an image on the display because it's e-ink and you start typing. Assuming you've previously connected to a remote device the system will have done what's necessary to keep that connection alive (invisibly waking as needed). Your keystrokes can go through right away to the remote connection. Your results will hit the screen right away too. The device is always on and it is always off, if that makes sense. There's more to it--bits of stuff and bother and implementation details--but I hope this gives you the idea.
Around 12" (in a 4:3 body) is about as low as you can go without messing with the typing experience much. The problem at that size is the available e-ink panels are S-L-O-W; no fast refresh models are out there.
(You might ask why we would even do the 10.3" prototype if we know that's too small for keyboard reasons? It's mostly for marketing reasons when we actually try to try to get attention for this project. The 10.3 is going to use a Thinkpad 701c butterfly keyboard in a custom body just for the "wow!" factor in showing the sorts of things that are possible. The 10.3 would actually be a killer end-product, but no similar keyboard is in current production so we couldn't actually make it).
(I'm OP, sorry for unsolicitedly posting your notes to HN. I guess I am just a bit too excited for this)
A "you can build it yourself" P1 version of that will probably be well-documented by early next year, but it won't be something you can just go out and buy yet. You'll have to gather together the parts needed, get the PCB produced, etc.
The plan was for us to get something to that P1-stage and then go more public about the project. No worries on jumping the gun with posting it. It's not exactly a secret, just not *intended* for public consumption yet.
I think when we have a couple of copies of P1s ready to show off (and videos of the product, and an actual product website! :-) having something put together we can show off would help open up some doors from people with more experience with getting hardware produced so people can get this more readily (even if just in kit form to start). Right now we're just doing one-off prototyping.
This is a BOOX Note Air, with Termux + Mosh + TMUX and my editor of choice Emacs DOOM.
I'm pretty happy of this setup. I went in holiday and I manage to use my editor to do some coding.
The only side effect is that it requires internet for extra processing power, although you could still run all locally depending on your requirements.
pkg install shellinabox
shellinaboxd -d -t -p 8080 -s "/:$(whoami):$(whoami):/:tmux attach"
The idea has already been approached, but the realization of a specific machine for that has never been tried.
Do you know the project author?
So I'm pretty sure that someone has already designed something similar as open hardware that you could fork and customize. I'd start with Googling "kicad eink arm". From memory, the Watchy eink watch with esp32 comes to mind. And I think there are arduino epaper driver boards on Amazon, too.
Nooooooooo! It's so horrible. There are a multitude of similarly sized bitmap fonts that bring back much nicer memories.
IBM DOS ISO8 and ISO9, for instance: https://int10h.org/oldschool-pc-fonts/fontlist/font?ibm_dos_... https://int10h.org/oldschool-pc-fonts/fontlist/font?ibm_dos_...
The Siemens PC-D https://int10h.org/oldschool-pc-fonts/fontlist/font?siemens_...
NEC APC3 8x16 https://int10h.org/oldschool-pc-fonts/fontlist/font?nec_apc3...
Cordata PPC-400 (one of my all-time favorites) https://int10h.org/oldschool-pc-fonts/fontlist/font?cordata_...
Missing from this website is the Epson QX-10 and QX-16: https://i.imgur.com/WDrTBpC.png
Ping me if you want help with these.
EDIT: I see you added more detail. Yes, I will definitely ping you. Thanks!
The update speed is quite good (comfortable for writing texts and browsing most websites) even when connecting via Wi-Fi.
It can be used as an external monitor for your laptop or desktop via HDMI port according to https://onyxboox.com/files/manuals/BOOX_MaxLumi_User_Manual....
Screen Size 13.3 inch
Resolution 2200*1650
Is it actually good enough to do real work on? I don't know, but I would be willing to try.
Certainly looks interesting. https://www.youtube.com/watch?v=8_WjTgmwMRk
Also worth noting though, from the manual linked above: "In the state of secondary monitor, the device is only user for monitor reading. Touch for operation do not work in this state."
It's a near-perfect reader and digital notepad and that's what I use it for.
The software however is bad. Did I say bad? It's laggy, it's supposedly Android but not really. Lots of apps only work semi-well if they use colors or greyscale. It feels like using a tablet device from a decade ago.
In the end, I'm still rather happy, but it's hard to justify the price point.
Out of how many stars total?
The Dasung proved to be super finicky for it’s _intended_ purpose and generally awkward as a monitor. I can’t recommend it.
But still, the hacking scene is far from big. There is no SDK. You can do things with QT but for a lot of use cases, you have to work directly with the screen capacities. e-ink screens are not good old framebuffer screens. If you want to have nice performance (like, instant note taking), you have to actually "draw" things on it.
You can draw things relatively fast on an e-ink device. But you can not draw a lot of things at the same time. That's why you have to wait maybe a full second between two pages of your book, but you can also have a blazing fast writing experience.
So the display paradigm is totally different compared to a classic screen and you can't just port existing apps. Well, you can, but it'll be without the "smart refresh" part. So it will be slow. If you want something usable, you have to think what and when to draw things on the screen.
Hence, few usefull apps exists on remarkable, because you have to build them from zero, with no real documentation, and to target a niche.
It is trivial to compile Go programs for the reMarkable - just compile with ARM as a the target architecture. One can do that on any machine with Go installed. But for the lack of APIs, I have had no idea yet where to reasonably start with programming the reMarkable.
There is an open source SDK[0] for compiling things to the reMarkable (1 and 2), and it's also a cross-compile target (1 and 2) in Nixpkgs[1][2].
[0] https://github.com/toltec-dev/toolchain
Really? I've never understood why Amazon wanted white kindles, but this is the worst possible use case for one. Actual paper books aren't usable outside, because they give off too much glare in sunlight. Kindle solves that problem! Use one of the gray ones; they're better anyway.
I've had a spare eInk display laying around for some time now, and it's about ~~5"~~ 3.7" in size, I think. I managed to get it working with a Pi Zero, and wrote a small Python script which captures the desktop, and then compares it to the previous capture, and then updates the bounds of where the capture is different. Somewhat slow with a Pi Zero, but still somewhat usable. I really need to look into the possibility of performing partial refreshes on the display to save it from having to invert the screen every time there is a change.
I might try and use a Pi 4/ Pi CM4 to drive the whole thing — I believe the bottleneck mainly lies in sending the data over to the display, which the Pi Zero is unfortunately quite slow at doing. Plus, it would potentially be a bit more powerful/useful with the newer processor found on the Pi 4!
Battery life might end up becoming a problem if you intend for it to run on batteries. Compared to PaperTerm or smartphones, a Pi uses a lot of juice, but it is great for proof-of-concept!
I wrote up my own notes-to-self much like the author of the PaperTerm did, which provides a brief overview of my general ideas: https://github.com/inkySystems/resources
It's a tiny bit outdated since it has no mention of my idea of using a Pi CM4. I haven't got many publicly-available info about what I've done so far with my board (seeing that it's a side-side-project of mine or something to that effect...) but it's something I'm experimenting with whenever I've got time on my hands!
When reading an e-book, the page is typically refreshed 1-2 times per minute, while the typical CLI use is more fast-paced, not to mention TUI programs.
Still very expensive, but with tech it's just a matter of years
So it could probably handle typical CLI use too, but higher refresh rates would of course mean higher battery usage. I think e-ink displays can handle local refresh zones, so it doesn't necessarily mean that it would have to refresh the whole screen.
However, without pagination, a lot of our computer usage includes scrolling, and I would imagine that's more power intensive, and can maybe hit the refresh rate limits of e-ink displays. I guess that would be akin to a lot of phones now letting you pick a fixed or variable refresh rate depending on the experience and battery life you want to get out of the device.
It wa a nice toy that might have become a good tool over time. Good luck! Here's my lousy code: https://github.com/ThePaperTop
http://www.willett.io/posts/device/
So, I’m of course in total agreement, and interested! Is there any place we can sign up for some kind of mailing list?
It probably makes sense as a toggle, perhaps selected when initially setting up/getting a software tour of the device, depending on who is using the system. Writers for example, would want it, sysadmins, not so much.
To be clear, all I'm suggesting is executing a command like `network connect <SSID>` instead of automatically connecting to saved networks.
Maybe I'm just not sold on the concept of a truly remote terminal (like the real old terminals). Why should I have to carry around two devices when Linux could run on this device itself? Perhaps it's a lot more work? but there have been some efforts made on this already. I would like to casually launch vim and start writing, without worrying about connectivity.
As an aside, also consider looking at how the reMarkable tablet implements ether/IP over USB, that has been working pretty well for me too, though I really wish it would broadcast an mDNS entry over WiFi as well.
A Linux OS based device can't meet the goals of the device from a couple of standpoints (power, availability, and the limited RAM/resources on the microcontroller pop to mind right away). Think of this as an instant on appliance. You turn on your old Commodore 64 and you are instantly able to type.
I hear ya, when it comes to "just wanting to be able to open the thing and start typing into vim (or whatever)". We're working on sanding down those edges in a couple of ways--1) eventually, we'd like to point people to a very cheap, simple cloud linux deployment if they don't want to setup their own, with lots of conveniences. 2) regarding actually getting a network connection since we're talking terminal-only the bandwidth requirements are tiny; because of that, it looks like we're going to want to add cell network connectivity. This is early-stages in thinking this through, but there are plans in the $40 - $60 range for an ENTIRE YEAR that would give you unlimited bandwidth that is plenty fast for terminal purposes (128kbps after using a limited amount of faster 4G bandwidth).
I will take a look at the reMarkable ether over USB. Thanks for pointing it out. It'll be a while before we've got a full USB stack working though. Remember, the software footprint for this device is tiny by design.
I love the idea of having cell and wifi modems, but these seem like high priority secondary concerns to me personally.
I understand that I may not have the same vision as you exactly, but I really am pretty much your target consumer. I totally get the elegance of reimplementing the "dumb terminal", but I really challenge you to justify it.
On that note, do you plan to support PDFs?
What is your use case for this sort of device? We'd certainly like to support as many as possible without compromising the overall vision. You mention PDFs--is your use case for reading or creating documents?
There was no plan to support local viewing of PDFs--again, parsing them is a pretty heavy lift for a low-power microcontroller to do with acceptable performance. We've got a related (very alpha) project that uses Chromium to render websites in a fancy text-only fashion. This is because for most devices, having a modern web browser is table stakes so we want to support that for this device. However, this browser would would be installed on the host you connect to with this device, not on the device itself. The browser can view PDFs (it uses Mozilla's pdf.js). I can show you screenshots of output of this browser, but not much else at this point. Those closest relative of this browser that is public is Browsh. It would give you an idea for what can be done: https://www.brow.sh/
Creating documents implies reading them in their final form, unless you have a publisher on staff. Even then I'd argue the medium matters. Most of the time I stick to plaintext, but there's a lot of value in PDF layout as well.
So yes, I plan to use this device for both reading and creating.
And I DO NOT trust my network connections. Just saying.
Well, the more I think about it, it's conceivable it could handle it with some small amount of extra hardware, but would take a LOT of software work and as hobbyists with no funding...
> And I DO NOT trust my network connections. Just saying. Yes, this should be a hard pass for you then! (Unless built-in, dirt-cheap cell connectivity would assuage those concerns.)
I hope I'm not being too discouraging. I really like this idea, which is why I'm pushing you on it a bit. I would love to help, but yea, fund-less hobbies are tough to get large scale support for. I wish I had more to offer.