PaperTerm Concept, An e-paper remote terminal device(paperterm.org)
paperterm.org
PaperTerm Concept, An e-paper remote terminal device
http://www.paperterm.org/notes.html
93 comments
This seens to be an unpublished, unfinished, unindexed document about a nonexisting product whose project status I am very confused about, yet the concept is absolutely intriguing.
Yes, you hit the nail on the head! This was my (private :-) notes-to-self for the project that will be launching as a public project soon. If you want to help, email me (address is in my profile!)!
I have experience with driver circuitry for waveshare e-ink displays and ARM H7 which has USB2 and Wifi. It shouldn't be too difficult to build a small device which is powered by an USB power bank, receives from a USB keyboard and communicates with a USB LTE stick.
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.
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.
The earliest generation Kindles had keyboards and various ways to run Linux. I think they tick about every box in this concept, except for the "Great keyboard. Terminal mouse support": the keyboards sucked for typing more than a few minutes. I realise that this is a pretty important "except" if you want to use a terminal, but at least they were actual mass market products.
The concept is beautiful. I would use it as a main machine.
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?
ex: https://github.com/olup/kobowriter
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?
ex: https://github.com/olup/kobowriter
I'm the author. I didn't find that this hit HN until I woke up this morning and saw it here so missed out on replying to comments until now.
Concept is very cool. The PineNote seems to nail some of it, though I'm not sure about the battery life (definitely not the battery type). If the PineNote could output its desktop when docked it would be a very interesting product I'd happily purchase.
I’ve chasing this dragon for years for the purpose of working outside; first trying to hack a kindle paper white, then using a Dasung monitor, then hacking a reMarkable 2. All were disappointing for a reason or another but I’m ready to try again with the PineNote. 4th time’s the charm, right?
I was thinking of the same, however when I look at large eink displays most of the time the vendor specifically cautions against using them in bright sunlight. Check waveshare etc.
Outdoor doesn't imply in direct sunlight. I've used my eInk devices outside for years, but I would burn up if I stayed in sunlight.
I use my kindles in direct sunlight for sure, they work fine, strange enough. This is why I don't understand they caution so much against some of these models.
What were some of the reasons for disappointment?
What was wrong with Remarkable2?
reMarkable 2 is awesome for it’s purpose, but trying to hack it into a terminal was too finicky and I bailed (same but worse dor the paperwhite). It still works great as a notepad and pdf reader, but 10.3” is the bare minimal practical size IMO.
The Dasung proved to be super finicky for it’s _intended_ purpose and generally awkward as a monitor. I can’t recommend it.
The Dasung proved to be super finicky for it’s _intended_ purpose and generally awkward as a monitor. I can’t recommend it.
I have a Remarkable 2 -- it doesn't have a good SSH client nor supports an external keyboard, as far as I know.
Sounds like an easy 'dev mode' to add, and capture a large market of developers. For years I've been looking into eink for development etc.
Remarkable is actually very open. Getting root access is as easy as going to the bottom of the About page to get the device's ip and its root password for SSH access.
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.
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 would be great, if there were more documentation to get started with developing for the remarkable and perhaps a few shared libraries with commonly used functions, e.g. just to be able to display a given png. Even if it were just a command line program, it would enable many usages.
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.
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.
> But still, the hacking scene is far from big. There is no SDK.
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
[1] https://github.com/NixOS/nixpkgs/pull/102503
[2] https://github.com/NixOS/nixpkgs/pull/105432
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
[1] https://github.com/NixOS/nixpkgs/pull/102503
[2] https://github.com/NixOS/nixpkgs/pull/105432
I have a remarkable 2 as well, and although I love it for reading/drawing, the biggest downside for me is the total lack of developer support. There are some cool 3rd party tools for interacting with the file system, but absolutely no support from the manufacturers for running your own code on the thing. I know its possible, but seems like a huge hassle.
> I’ve chasing this dragon for years for the purpose of working outside; first trying to hack a kindle paper white
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.
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.
Yeah the white ones also make the "paper" look darker:)
Related: Discussion yesterday on "E-Ink Typewriter":
https://news.ycombinator.com/item?id=28426741
https://news.ycombinator.com/item?id=28426741
Is the refresh time of e-ink display suitable for convenient terminal use? (I just skimmed the article.)
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.
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.
Yes, if you're only making small updates and not dumping tons of lines all the time the even an old e-ink display is plenty fast. It works the same way when you're menuing on an e-reader.
The modern ones are quite impressive: https://www.youtube.com/watch?v=xTok6imfgoM
Still very expensive, but with tech it's just a matter of years
Still very expensive, but with tech it's just a matter of years
From the demos I've seen of other e-ink tablet devices like the Max Lumi, it seems like it can handle handwriting pretty smoothly [0].
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.
[0]: https://youtu.be/B8X7JPdgsh0?t=788
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.
[0]: https://youtu.be/B8X7JPdgsh0?t=788
I have been craving an e-ink laptop with a low voltage RISC processor for twenty years. It is impossible to open a normal laptop at night, after the kids have gone to bed, without becoming more awake than after a double espresso. I can't stare into a bright back lit screen at night. It often ends up with me sitting way to late up at night. At daytime, the often ridiculously bright back lit screen makes me unfocused and almost hypnotized.
If I could afford it I would buy an Onyx BOOX Max Lumi https://onyxboox.com/boox_maxlumi
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 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."
have you seen the pinenote annoucement? https://www.pine64.org/2021/08/15/introducing-the-pinenote/
Does it support HDMI in? Couldn’t find a mention about it immediately.
Not that I can see, here's the wiki: https://wiki.pine64.org/wiki/PineNote, the discord has a lot of info as well (that's where I saw it)
I own one, it's a true three star experience. It's completely unique in its class as it's a true e-ink display at A4/Letter scale and even has two monochromatic backlight sources, one without any blue light. That rocks.
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.
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.
[deleted]
It's android. Are you disabling the "Whiten Apps Background" optimization? It's on by default and it makes it harder to use apps I find because controls and buttons end up hidden. Turn it off and it's fine.
Thank you for this suggestion! I have a Nova 3 myself and I didn't realize that this "optimization" was on by default. Any clue if there's a way to change this to off-by-default?
No I don't sorry. Other than to root and then uninstall the related code. I haven't personally done it though, just read some posts on mobileread.com about it.
> it's a true three star experience
Out of how many stars total?
Out of how many stars total?
Doesn't everyone use five stars these days? :)
I suppose yeah, just wasn’t sure :p
I leave a picture of my setup that I previously posted in Reddit: https://www.reddit.com/r/emacs/comments/o16nfa/pretty_please...
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.
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.
Hi, if I can ask, what is that keyboard? My local electronics chain had it listed as "Raspberry keyboard" but it's no longer available and I've been looking for it for months.
Dell logo in the top left corner, bluetooth indicator in the top right; nothing on the Dell website that matches it, but on Amazon and Newegg "Dell KW14M01" looks very similar (though neither have the logo top left, so could be different minor version or not actually Dell...).
The keyboard is a Dell K07M, but beside the cute form factor I will NOT recommend buying it. Maybe mine is damage, but I got a lot of ghosting in my key pressing. I’m looking to replace it, maybe with a K3.
I also have a BOOX note Air, and I am very happy with it. I even installed python and Jupyter LOCALLY. I had no problems processing a few millions of primes in milliseconds. However, the display is not good enough to program as growing code often requieres to fast refresh the screen while browsing code or following stacktraces, which is quite uncomfortable. Also the lack of syntax highlight but I guess some people could get used to those.
I tried to throw together something similar for my Kindle browser just now. I connected my bluetooth keyboard to my phone and ran the following in termux:
pkg install shellinabox
shellinaboxd -d -t -p 8080 -s "/:$(whoami):$(whoami):/:tmux attach"
Years ago, I've made a program turning Pocketbook e-ink readers into computer monitors with some extra features: https://github.com/borzunov/remoteink
The update speed is quite good (comfortable for writing texts and browsing most websites) even when connecting via Wi-Fi.
The update speed is quite good (comfortable for writing texts and browsing most websites) even when connecting via Wi-Fi.
Oh, hi all! I didn't my project to show up here today! This was just my private notes-to-self I'm using to organize a group to create this thing.
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!
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 built something similar: https://bbenchoff.github.io/pages/dumb.html
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?
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?
That is very cool! Have you built a physical copy of it?
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.
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.
The other reason not to run Linux is because the ESP32's a bit underpowered to run Linux (lacks an MMU). Slightly more powerful hardware (eg Raspberry Pi Zero) would do better, and get you a working device far sooner, which would be great for testing out some of the other components while waiting for getting the software written.
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.)
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.)
The ESP32 is getting replaced with a better microcontroller (it's down to either an upcoming STM32 ultra-low power or the upcoming Ambiq Apollo4 depending on how well they perform in real life), but ESP32 was what we started with given familiarity and availability.
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.
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.
Honestly, 13" is more than you need for a 4:3 terminal. A lot of classic character terminals had 9 or 10 inch screens...it's not until you get to like the VT320 that you have a 14" screen. I'd consider a 10 inch screen about ideal, and the keyboard doesn't have to be 13", either.
We are making prototypes in 3 different 4:3 sizes--10.3, 12.1, and 13.3. 13.3 is furthest along. The end of your comment talks about the real size restriction for us--keyboard. We do not want to compromise the typing experience.
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).
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).
Have you considered using a DES display or Sharp Memory LCD? I know the first is definitely cheaper than a branded E-Ink display, and the latter has much faster refresh rate and may be more suited to being a terminal (and may also be cheaper than E-Ink, I just haven't looked into it).
Yes we have considered it. Do you know of any such large (over 12 inches) panels with decent resolution and pretty fast updates that are available? Such a thing would probably help with power consumption. (e-inks consume a lot of power during screen updates).
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.
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.
I know that the DES displays go up to 10.1", but I haven't seen displays beyond that size (though I'm unsure if they intend to make larger displays in the future). For the Sharp Memory Displays, I think I may have spoken too soon - looks like they top out at 4.4" currently, which of course wouldn't work for your application.
RLCD is an interesting option, I guess the sacrifice there is readability angles and paper-like-ness?
RLCD is an interesting option, I guess the sacrifice there is readability angles and paper-like-ness?
Ones with good viewing angles exist, but for sure there isn't paper-like-ness and you loose the no zero-power persistence of e-ink. But you get fast, artifact-free refreshes, perfect sunlight readability, at very low power consumption. (No backlight which can be a pro and a con...if only a more modern Pixel Qi type panel existed.)
Do you estimate thay this concept will ever come to life? (say, P1)
If so, when?
(I'm OP, sorry for unsolicitedly posting your notes to HN. I guess I am just a bit too excited for this)
(I'm OP, sorry for unsolicitedly posting your notes to HN. I guess I am just a bit too excited for this)
We have a prototype-y thing part way between P0 and P1 already.
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.
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.
I realize this might simply put me into the "not target demographic" group, but what makes this so useful as a terminal, that a laptop won't do?
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.
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.
Use as a distraction-free word processor is listed as a use-case if you read far enough. (As mentioned, the notes are a bit of a mess and weren't cleaned up for public consumption.)
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.
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.
I would be pretty close to the exact target for this product. The killer feature that would put it over the edge for me would be the possible "crashcart" KVM feature mentioned later in the notes.
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.
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.
A distraction free word processor that could display PDFs along with the text (for writing LaTeX) would be a real godsend for me. In fact I am writing this very comment while distracting myself from some LaTex I am supposed to be writing...
You could probably do that with a cheap laptop by cutting down a Linux distro then removing/breaking all network hardware antennas/ports
I think this would be great for the same reason that using a Remarkable tablet is great.
Exactly because it is limited in it’s application.
Exactly because it is limited in it’s application.
There is also this project, might be interesting to get in touch: https://hackaday.io/project/179890-india-navi
For sure! Thank you for the pointer to it.
Sounds like a very interesting project, I certainly would be tempted to have an eInk terminal. Can you post images on how the terminal looks on the eInk screens?
I can give you images of how a terminal looks on e-ink screens but not with the final panel we're likely to use nor with final software, so probably best no to since it wouldn't be representative.
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.
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.
Does the e-paper display you use have to "flash to black" on just about every change like so many of the Kindle whites do?
Our panel supports partial refresh (no black flash) which makes it much more performant. The software does have to do occasional flashes to keep the screen tidy (otherwise you get a lot of ghosting over time). You can control how often this happens.
In similar vein there's also Clockwork Pi DevTerm, I wish it would use e-ink display instead https://www.clockworkpi.com/devterm
Neat! I've been thinking of building something similar to this — a portable Linux machine that has an eInk display and little QWERTY keyboard, in a size that's a just a bit bigger than a smartphone.
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!
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!
Sounds like a neat project. Yes, partial refreshes help a lot, lot, lot!
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!
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!
Thanks! As you say, the Pi does chew up quite a bit of the battery life, but I hope that usage should last for at least a day or two. I plan to use a 3,000 mAh battery with the thing, which seems to be quite a lot — my Pixel 4 has 2,800 mAh _and_ that doesn't even have an eInk display! For the purposes of my project, I'm not really focused on trying to make the device extremely thin either. Something relatively chunky (like 1-1.5 cm) is sometimes quite nice and welcoming imo.
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!
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!
Did you notice you are replying to the PaperTerm author himself/herself?
Ha, this looks great, the list of goals seems really similar to a list I came up with a couple years ago for what I’d consider optimal for a writing device, too:
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?
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?
Sure, email me and I will send you updates. My email is in my profile.
I made something similar to this several years ago, and it was pretty usable considering that the software was thrown together in Python and the display I had did not support partial refresh. I got it so I could run terminal applications nicely, and even run X applications poorly. Then my little girl cut the pretty colored wires with scissors, and I didn't have the heart to do the hardware work over again.
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
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
> Also for simplicity of P0, the exact font used is the 14-line EGA font with the last line duplicated to the 15th-line.
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.
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.
Yeah, I hear ya! It's just temporary. :-)
EDIT: I see you added more detail. Yes, I will definitely ping you. Thanks!
EDIT: I see you added more detail. Yes, I will definitely ping you. Thanks!
I will happily crowdfund this, and I don't crowdfund anything...
For PF, I recommend "disconnected by default" I've been using my laptop like this for a while now and the peace of mind is easily worth the one command I need to run to connect each time. Especially on a distraction free device where I wouldn't expect a lot of notifications and synchronizations.
This could only happen if we've got some local apps beyond the main (terminal) app. PF-timeframe, as you say. I will write the idea down so it doesn't get lost.
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.
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.
I'm sorry if I'm misunderstanding you but, why are local apps a prerequisite for controlled networking? Or is that just how you want to build it out?
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.
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.
Ah, I misunderstood you. Without the local apps, unless you are connected to a network, there is literally nothing to do with this device. That's because it is more-or-less a terminal only (excluding the few PF local apps). There are no notifications to speak of.
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.
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 promise you can make Linux wake from a low power state much faster than you can wake up the radios and negotiate a stable network connection with "the cloud!?". Not to mention battery life... Even if my host was connected over ethernet I wonder how realtime benchmarks would compare with whatever network hardware you have in mind.
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?
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?
I think the disconnect between us is that this is running on a microcontroller. Think "a beefier version of what runs your smart thermostat." Linux isn't unheard of for such a device, but is a pretty heavy lift because of limited resources. Using a microcontroller has its advantages. One advantage goes exactly to the point--with smart design it can maintain a wifi connection, waking for milliseconds at the required interval, so when you want to use it there is no wifi negotiation time. Keeping things open all the way to the remote host is whole other matter, but I believe that's touched on in the document.
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/
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/
> 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?
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.
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.
Gotcha. I don't think we could make this the right fit for you then, sorry.
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.)
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.)
Maybe you make a little RPi-like device that is designed to connect and host this thing as a module that attaches nicely to the enclosure. You could build out the whole idea as you have it and come back to this for people like me. Meanwhile, I might just carry around a RPi for this purpose, as long as they can share power easily.
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.
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.
Might be a possibility to incorporate with this project?
Pumpkin OS https://news.ycombinator.com/item?id=28466858
Pumpkin OS https://news.ycombinator.com/item?id=28466858