PaperTerm Concept

An e-paper remote terminal device

PaperTerm is a laptop computer with an e-paper display. Its sole function is to allow you to connect to--and interact with--a remote terminal and the text-mode programs that terminal can run (both command-line and TUI-based). It is more of an appliance to get at other computers and devices than a traditional computer itself. And like a calculator, it has no conventional operating system that needs booting or waking, so you just open it up and start using it.

Features of the completed project include:

For each of the following sections, we describe the anticipated functionality provided by the first 3 prototypes, named P0, P1, and P2. These three prototypes represent key milestones in the development of this project. Some sections also describe "PF" features. This is just a placeholder for ideas to be incorporated in Future Prototypes--those beyond P2. These ideas should be seen as areas we'd like to explore, not necessarily areas we plan to implement.

When reading this document, keep in mind that this is more of a planning and designing document than a PR document, so unless you're interested in helping out on this project, you'll likely find it a boring read. We've published it publicly because it already exists and it might, just might, inspire others to join and help out. We need all the help you can give in all sorts of areas, both technical (e.g., electrical engineering, programming), non-technical (e.g., documentation, organization). Really, we've got tasks for anyone of any skill, so if you want to help make this a reality, contact for details. (Monetary contributions are welcome too!)

Table of Contents


Implementation Details


Some Guiding Thoughts

We want to make a device that is:

...and we're going to have a blast doing it! It will meet the needs of a specific market. Widespread, general public adoption of PaperTerm is not the goal; we're niche and we're OK with that.

Now let's move on to talking some details, in no particular order (i.e., we need to organize this document better!)


Because the programs you use PaperTerm to interact with run on remote computers, it is important for PaperTerm to have a variety of connectivity options so you can connect to those remote computers. We plan to start modestly and expand from there.


P0 will prioritize implementing the most commonly used connection type these days: wifi. This initial implementation will support 802.11B, G, and N modes using the 2.4ghz spectrum only. WPA/WPA2/WPA2-Enterprise/WPS encryption/authentication is supported.

P1 will concentrate on tightening up the wifi implementation and will also support old skool DB9 serial connections for plugging directly into a device you want to control.

P2 will add wired ethernet (10/100 megabit only).

PF ideas likely to happen include 5ghz wifi, USB serial, bluetooth serial, and an exposed TTL UART interface. More speculative options include cellular, LoRaWAN, "802.11 LR," RS-485, a custom mesh networking scheme, and good 'ole telephone modems.


Connectivity is also about the protocols you can use to speak to other computers when talking to them over a network instead of with a direct connection. PaperTerm will initially use IPv4 for all of its connections. The protocols running over IPv4 will expand over time and we will also eventually support IPv6.

P0 will use SSH only for its connections. This is by far the most prevalent method in common use today. Initially we will only support password-based SSH authentication.

P1 gets direct serial connections, but telnet network connections will also likely be supported.

P2 has some additional telnet extensions and hopefully cert-based SSH authentication.

PF ideas likely to happen include any in the above "hopeful" and "likelies" that didn't get implemented yet. We also will need to investigate the right mix of VPN technologies we should support allow our users in through corporate firewalls. Future investigations include possibly supporting mosh (or a custom mosh-like service), and maybe one day a psexec type solution to connect to Windows hosts.

Terminal Emulation & Features

After PaperTerm connects to the remote computer, the two sides have to speak the same language. There are many schemes available, the most common of which uses control codes that date back at least to the Digital Equipment Corporation terminals from the 1970s. We will use this same scheme, supporting roughly the same set of VTxxx control codes as xterm does. We will also support some ansi and other extensions, eventually. We will support mouse extensions, cut/copy/paste, and beep codes. On the display side-we will support 256 and true color modes, converted to gray scale of course.)

Exactly when (which prototype) each terminal feature will be supported it TBD, as is the exact list of supported control codes and features.

Challenging Environments

The following few ideas should be considered "PF maybe" sorts of ideas.

Some wifi networks have very restrictive firewall rules. We may not be able to get through the firewall to connect to our servers. HTTP is almost never outright blocked in many of these networks. We could host a HTTP (with Websockets) proxy that would let users connect to their servers in such environments. We would need to be mindful of possible abuse of this service (both overutilization and anonymization issues).

If we built such a proxy service, we could also host--at the same domain--a web app that you could visit using your phone. The web app would use WebBluetooth to connect to your local PaperTerm and use Websockets to talk to the proxy service. The web app would then allow PaperTerm to talk to any SSH/Telnet/etc. servers via your phone's data connection. This would not be detectable as a tethering situation so should be allowed by any mobile provider. Bandwidth requirements for our text-only connections are low so it shouldn't burn through limited data plans either. 2G service is even enough if you're desperate for a connection. (In theory this web app could be hosted by the PaperTerm itself, but until a web app can talk directly to an SSH server without a proxy, we need the proxy anyway so it makes sense to host it there. That could change in the future though!)


PaperTerm consumes very little power. In standby, it uses single digit microamps of power (at 3.6V). When turned on, it spends much of its time in an invisible-to-the-user light sleep, consuming only single digit milliamps. It immediately goes to a higher power mode as needed, consuming 80-500 milliamps depending on the situation.

But where does PaperTerm's power come from? PaperTerm was originally born out of the desire to create a useful e-paper computer with an "I don't have to think about it" level of battery life. Because of that second part, PaperTerm wants to support an (admittedly) excessive amount of options to power it. But to be able to ship a product, its design has to start more modestly.

With that in mind, the P1 prototype will be powered by rechargeable AA batteries! It can also be plugged into any USB charger for power. USB will be the only source of power for P0. When plugged in, P1 will also recharge the AA batteries. Non-rechargeable AAs are also supported, but not ideal (except in a pinch) for obvious reasons. The USB connection will be micro-usb, but an additional USB-C connector will be added for P2.

P2 will also add another, non-usb power connector: a 5.5x2.1mm coaxial ("barrel") connector. This is the most common size of those small, round, DC power connectors you've already got plugged into various electronics in your house. [image] PaperTerm will accept a wide range of voltages via this connector. Exact minimum and maximum voltages TBD, but it will be at least from 5v to 24V, with auto polarity. Basically, if the plug fits, it should work, no matter what device it originally came from. If you've got a power brick you want to use with a plug that is bigger or smaller, plug adapters would work, but are hard to come by.

PF models will next allow the user to install any single-cell rechargeable LiPo battery they want, provided it physically fits in the available space. Again, no need for a proprietary battery pack. Power-over-ethernet is definitely a power source we'd like to add as well. Finally, as the project matures and we drive the power budget closer and closer to our targets, adding ambient light (solar) to the power source mix could be a legitimately useful option. Imagine having a laptop you almost never have to plug in! Someday, we could also look at possibly adding wireless charging.

(Should we do anything with PaperTerm being able to charge other devices beyond just the USB port we can provide? Probably not, but writing this down should it spur a useful idea. About the best we could do is provide DC plug adapters or a spot to store them internally.)

Physical Design

P0, as mentioned earlier, is a bunch of circuit boards and wires, plugged into the wall. It lives on a bench top and doesn't really have a "physical design."

P1 is the first version that looks like a laptop. To save engineering effort, we decided to house early prototypes in a reused laptop computer chassis. In selecting which old laptop chassis to use, we limited our search to ThinkPad models because

Reusing an old chassis constrains our design, but lets us focus on the parts of the system that make us unique. We can design an optimized chassis with later prototypes, allowing for the design to be thinner and lighter.

P1 is a 13.3-inch model and will be housed in a more than 20 year old ThinkPad 570 chassis. The ThinkPad 570 was chosen because our modest hardware and circuitry does not need much space and the 570 was the smallest-ever ThinkPad with a 13.3 inch 4:3 screen, a perfect fit for the e-paper screen.

There is no change to the physical design of the P2 model other than wiring up additional ports and connectors to the same chassis. That is, P1 will be upgraded to become P2. However, in the P2 timeframe, there is one new thing happening on the physical design front. We plan to create a second physical prototype with the same "guts" and circuitry as the existing prototype. This prototype will be placed in the even-smaller ThinkPad ___ chassis. This P2b prototype will have its e-paper screen swapped to a smaller 10.3 inch model, but other key components remain the same. (This Thinkpad chassis originally housed a 10.4" screen so will have a tiny amount of masking around the screen.) This prototype will let us explore the usability of a slightly smaller form factor. It is not more advanced, more refined, or in any way a successor to the other prototype. It is more of a sibling.

PF models are anticipated to take cues from the standard "thin and light" laptop market. We have no plans to try to advance the industry in any way on this front (although Alex from ei2030 has us wishing for a super thin and light case made of wood with a fine-furniture style finish). We do want our final design to keep in mind reparability and offer user-replaceable components. At some point, adding user-toggleable illumination of the screen and keyboard, perhaps with ThinkLight-style light, would be very useful.


We've got some big hurdles to overcome. Life isn't all sunshine and roses in trying to make this viable. Read on.

The Refresh Problem & Some Solutions

We're using an e-paper display (EPD) which is great because it is 1) easy to look at for long periods of time, and 2) uses no power to display a static image. It is the key technology makes possible the other innovations we hope to do. The problem is that computer displays are interactive and we can't get by with showing just static images. EPD refreshes are slow and expensive (power-wise) compared to industry standard LCD and OLED display technologies. Our solution to this problem is to try and do as few refreshes as possible while still making the device feel responsive to the user's needs.

Part of the problem is solved for us by virtue of the market we hope to serve--the text mode programs we plan to (remotely) run typically don't do many screen updates except when the user is typing; there just aren't a lot of progress bars, counters, animations and special visualizations to be found. And videos are absent. All of that helps tremendously.

However, scrolling is still an issue. It is perhaps the most commonly encountered source of major (nearly full-screen) updates in text mode apps. This sort of scrolling most commonly happens line by line. Recognizing and dealing with that fact will help reduce the number of screen refreshes we need to make. How? Detecting such single line scrolling is usually trivial for software to do. Using that fact, we plan to detect and skip displaying some of the frames that happen during scrolling to save on screen updates, while still making sure we display a minimum threshold of them in such circumstances. Experimentation to get the details right is needed. However, we suspect (but, alas, have not yet demonstrated) that as long as updates in such a scrolling situation are very consistent the perceived performance of the system will not be severely compromised. We plan to experiment to determine if this suspicion is correct and what metrics are most important for to enable this positive perception. (For example, it is important that updates happen exactly every X tenths of a second or perhaps is it more important they happen every Y lines of scrolling?)

On a related matter, periods of so-fast-you-can't-read-anything vertical scrolling are a common occurrence in some command line scenarios. Exploration should be done to see if during this situation we might be able to display a deliberate static blurred suggestion of scrolling (or some sort of similar feedback to the user) and then only update the screen with the final image once the scrolling has either stopped (or slowed to a reasonable, readable pace).

One place we won't try to save on screen refreshes are those refreshes done in response to direct user interaction (keyboard/mouse) except as mentioned in possibly some scrolling scenarios. Many UI studies have shown that user satisfaction goes down as perceived response time to input goes up.

It perhaps goes without saying that we will also employ the same tricks other EPD-based devices use such as partial updates and maybe automatic update "mode" adjustments.

Custom Code

This project will require a significant amount of custom code. Additionally, some areas that require code to be written are areas we have little experience with. Fortunately, we have enough general experience that we know the "shape" that those solutions typically take. In other words, they are "known-unknowns" where we have reasons to think that they won't reveal large unexpected challenges, which is good because the challenges we know about are plenty large.

Existing libraries will be used much as possible, even at the cost of code elegance. We will tolerate some amount of duct taping systems together as long as the result is reliable and meets our objectives. Elegance can come later if this gets somehow funded or otherwise better-resourced. We will, however, always be mindful of not unnecessarily taking on technical debt in the code that will greatly slow our progress in the future.

Custom Hardware

The hardware is a bigger risk than the software. We've not experts in that area and there are unknown-unknowns. The planned strategy is to start with existing working hardware subsystems, and then do the work needed to get them working together into a system that resembles the desired final outcome, even if not meeting all of the desired specs. Then, piece-by-piece, integrate the separate parts into a cohesive larger whole, optimizing along the way. The hardware will see fewer and less frequent iterations compared to the software, but each one is going to be hard and a learning experience.

As mentioned above, the earliest prototypes that start to resemble a laptop will live inside of an old IBM Thinkpad. We will re-using as many of the external Thinkpad components as possible (overall chassis, ports, covers, sliding bays, battery shells, keyboard, etc.), with the exception of the display. The inside of the Thinkpad case will be gutted and fitted with our custom components. Care will not be taken to ensure long-term survivability of the hardware components for the Thinkpad-based prototypes.

Future Directions

This is just a spot to jot down possible future directions and features. Do not take this as any kind of development roadmap.

Beyond Running Apps Remotely

The whole point of this device is for it to connect to other computers and run apps remotely. That said, it is worth considering creating a few apps that run locally. If done judiciously, we may be able to increase the utility of the device without compromising its core design. This may also lead to it being of use to other (still-niche) audiences. One key question we should ask ourselves when considering adding any local app is, "why not run this remotely instead (WNRTRI)?"

Text editor. The possible local app we've identified is a lightweight text editor/word processor. Computer admins could use the text editor when network connectivity is poor (as part of fixing such situations). And adding minimalistic word-processing style features would make this usable by those who desire distraction-free writing devices as a personal productivity hack. (Other such devices already exist, but we haven't seen any as nice as what we're proposing). Those wanting such distraction-free writing devices generally want them to NOT connect to a network since email, social media, web browsers, etc. are a source of distraction. Adding such a local app is probably the most logical "next step" expansion of our core functionality. We already plan to have a SD card interface, so that could be re-used for removable storage. And perhaps USB flash drives some day. (Random thought--PaperTerm is "term paper" turned around. Not sure if that's a good or bad thing with some in the distraction-free writing audience. XD)

Device documentation and help. The document management and rendering code used for the text editor/word processor can be reused as part of an on-device help/documentation system. As long as you know how to access the help system, it can assist you with problems you might have with the device, which can include connectivity issues that can't be addressed with an online help system. Quality documentation for consumer electronics is sadly lacking these days. Manufacturers should provide such basic assistance and for physical devices it should be done in a way that the help is still accessible for as long as the user has the physical device, not for as long as the company chooses to maintain an online web presence for the device.

Gemini/gopher browser. A reasonable way to implement this online help system, assuming we want it to be able to have internal links (which is probably a good idea) is as a gemini (or even gopher) site that runs locally on the device and is not accessible from the network. This lets us piggyback off of existing standards. gemini made some questionable design decisions, but in the spirit of avoiding the "not invented here" mentality, it is probably best to just go with something that already works! In doing that, we would have a gemini (or gopher) client the user could use at nearly zero additional resource or engineering cost. This goes a bit against the idea of WNRTRI but does promote the general ethos of the "small web" which feels somehow complementary to our project. Still, it should be noted that should we do this, it would be stretching our focus.

PDA apps. Not that we have any reason to need to add more local apps, but if we want to troll for ideas that might prove useful and can run on a limited power device, we could look to the old catalog of PalmOS PDA apps. When considering a given type of app in this category, in addition to reflecting on WNRTRI, we should also consider whether PaperTerm could do that app notably better than a smartphone. If not, pass.

E-reader. Perhaps not a good fit (has WNRTRI vibes), but to many people e-paper equals e-readers, so adding it to the list for consideration.

Providing Server Infrastructure

One can envision that there might be some people that would be intrigued by PaperTerm, but not have any server to connect to use it. We could provide such a server pre-configured with useful apps for people to use. Or we could provide an OS image with such software already setup that users could run other their existing hardware or on a cheap, press-one-button-to-deploy type cloud services provider.

We're not aware of any nice, cohesive ecosystem of TUI apps. If we can somehow (someday) bring together a collection and put a nice frontend on it with some good polish, the net would be the better for it. This would let people experiment with the concept easily and it could in theory become the regular productivity machine for some people we might not otherwise expect. One big hurdle to note: given how so much of the net is exposed through a web browser, we really would need some sort of modern solution for all of those web-browsing use-cases. came the closest at one point. Hopefully they can get their mojo back and revitalize the project.

Note to self:, despite its shortcomings could be a good entry point for hosting provider for many.

Leaning in to the Admin Usergroup Niche

Anticipating server admins as a group interested in PaperTerm, we could consider making it possible to hook up PaperTerm's keyboard and/or monitor to a local computer and use those to drive that computer directly. Sort of an IT crash cart setup.

Remote Graphical Interfaces

Basic, VNC-protocol-based remote control graphical user interfaces would not be a huge hurdle. It in some ways does feel like another "logical next step" but could lead to problems we've been able to neatly side-step. Graphical interfaces on average take more bandwidth and local resources, and importantly for our power budget, require a lot of screen refreshing for most GUIs. Still, we shouldn't take this completely off the table. Remotely controlling graphical user interfaces enormously enhances the appeal to many people and very much does increase the usefulness of the device. We wouldn't want to do this "not to be niche;" rather, we should only do this because it feels like the right thing to do and we can do it without destroying what makes us-us.

Technical Specifications

Technical specifications are preliminary and subject to revision.

PaperTerm P1

13.3-inch screen prototype housed in a ThinkPad 570 chassis.

Processor 240 MHz dual-core Xtensa LX6 microprocessor. 40nm.
Memory 520KB on-chip SRAM (16KB RTC). 448KB ROM. 16MB of QSPI flash.
Expansion SD card slot, connected but unused until future software upgrade
Connectivity Wifi 4 (802.11 b/g/n), 2.4ghz. Bluetooth BLE 5 (unused for now)
Display 13.3" e-paper. 1600x1200 pixels. 150 dpi. 16-level gray scale. 16:1 contrast ratio.
Keyboard Full-sized 85-key keyboard. Integrated palm rest and Trackpoint pointing device.
Audio Integrated speaker (beeps only).
Dimensions 11.8 x 9.4 x 1.1" (300mm x 239mm x 28mm). 122 cubic inches. Much of it empty.
Weight TBD. Approximately 3 pounds.
Case material Carbon-fiber reinforced plastic.
Battery - type 4 to 12 AA batteries. Must be added in sets of 4. NiMH rechargeable preferred as they will be recharged when the device is plugged in. Non-rechargeable alkaline and lithium ion also supported.
Battery - life TBD. Expected to be days of use per set of 4 AAs.
Ports External ports of the donor Thinkpad chassis are unused except for the power input.
Available upgrades My daughter would recommend you add blue unicorn stickers.
Warranty None.

PaperTerm P2

Same specs as the P1, with an extra co-processor.


Co-Processor 120 MHz ARM Cortex-M4. 40nm. 2MB Flash. 1.4MB SRAM.
Available upgrades My other daughter would recommend pink bunny stickers.

PaperTerm P2b

10.3-inch screen prototype housed in a ThinkPad ___ chassis. Specs remain the same as the P2 except as follows.

Display 10.3" e-paper. 1872x1404 pixels. 226 dpi. 16-level gray scale. 17:1 contrast ratio.
Keyboard 95% sized keyboard. 18mm key pitch. Integrated palm rest and Trackpoint pointing device
Dimensions 10.2 x 8.0 x 1.05" (260mm x 202mm x 27mm). 86 cubic inches.
Weight TBD. Approximately 2.5 lbs.
Available upgrades Smaller stickers.

PaperTerm P2-funmode (ignore this section…)

10.3-inch screen prototype housed in a ThinkPad ___ chassis with a 3D printed base. Specs remain the same as the P2b except as follows.

Keyboard Full-sized keyboard. Integrated palm rest and Trackpoint pointing device
Dimensions 9.7 x 7.9 x ~1" (246mm x 201mm x 25mm). Fewer cubic inches.
Weight TBD. Approximately 3 lbs.
Available upgrades Glitter stickers.

 Misc. Implementation Details

Text Handling Notes

P0 and P1 assume all text is ascii text. P2 decodes utf-8 and uses a lookup table to figure out what glyphs to display. More details later.

Character Generator Notes

Our device uses a 1600x1200 pixel EPD display panel. Each pixel in the panel can display any one of 16 shades of gray. Since we use only a terminal (text-mode) style display, instead of keeping track of the contents of every pixel in a framebuffer it makes more sense to keep just track of 1) each character on the display and 2) how we want each to be displayed (e.g., how black the text should be and how white the background should be). We then let the character generator translate this information into actual pixels on the screen. This is both faster to update and saves a lot of memory.

P0 Design

The ascii characters P0 receives get translated into control codes and glyphs (characters) that should appear on the screen. Making the glyphs appear on the screen is the job of the character generator. The barebones text handling described in this section is going to be broken out into its own section where it will be described more fully.

This first version of the character generator will be done on-board the ESP32 and sent to the display via the Waveshare SPI interface. It will be very simple with the following characteristics:

Display Contents as Stored in RAM

We reserve 64KB (65,536 bytes) of RAM for video purposes (VRAM). The majority of this RAM stores the contents of character cells and this appears at the beginning of our VRAM area. Notes about this area:

Those two arrays take up 64,000 bytes. The next 512 bytes (0.5KB) is reserved for other data that other subsystems may reference. Things such as:

Details to be documented later

The last 1024 bytes (1KB) are used for internal variables and buffers used by the display subsystem. Other subsystems should not touch that memory.

Flash Memory Requirements

The video subsystem also needs some space in the non-volatile flash memory to store the font used:

P1 Design

P1 will use the above "minimal" character generator as a basis for further experimentation, and will again be done on the ESP32. The biggest changes are:

New Glyph Modification Attributes

Every character cell now has a variety of attributes that can be used to modify the glyph displayed in that cell. The details of how the glyph is modified for each of these attributes:

Display Contents As Stored in RAM

The way the screen's contents are stored in VRAM is very similar to P0 with a few small changes needed to accommodate the P1 features.

Flash Memory Requirements

Flash memory requirements remain unchanged from P0.

P2 Design

This version will outsource the character generation to an STM32 L4+ microcontroller which will also directly drive the EPD instead of using the SPI-controller board. The exact model is TBD, but it is expected that the L4+ microcontroller (or a larger H7 cousin) will eventually become the primary microcontroller, replacing the ESP32.

This is a big change, but worth it. Having the character generator directly drive the EPD has a couple of great advantages.

In addition to switching microcontrollers, P2 brings all these new features:

Glyphs with a value over TBD are double-wide automatically

P2's VRAM encoding scheme

The representation of the character cells is going to be significantly more complicated in P2. If you read what all of the bits and flags do, you'll notice that not all of these features were specified to happen in P2. Just because they appear here doesn't mean they will be put into P2. We're mapping out space for P3 and beyond.

This is a work-in-progress.

Below is a diagram of the 8 bytes of VRAM we use to describe the contents of each character cell. Vertical bars mark the separation between logical groupings of bits. Each letter represents one of the 64 bits and descriptions of what the bits do is below. The order the fields appear in this block of bytes will likely change in the final draft. It will more closely follow the order that we draw the various parts of the cell (e.g., background first, lines last).

|a a|w h t l|b i|l l|u s t b l r|b b b b b b b b|l l l l l l l l|
|f f f f f f f f|g g g g g g g g g g g g g g g g|o o o o o o o o|

Next, we describe what each of these bits mean!

aa = alternate encodings
whtl = flags to control the horizontal and vertical stretching of characters

These flags are how we support double-width and/or double-height characters that are supported in VTxxx terminals. For each character cell, we specify if it is part of a stretched width and/or height character, and if so, what part of that character resides in this cell (e.g., the top right quadrant of a double-width, double-height character).

This encoding lets you specify if the character (or partial character) in this cell is part of horizontally or vertically stretched  

Our encoding isn't optimal. For non-stretched-width characters, the l field is ignored and for non-stretched-height characters the t field is ignored. This means 7 of 16 values don't make any sense. It's a bit faster to parse this way and currently available options can't be packed into fewer bits anyway. However, with better packing in the future, we will be able to support double-width-triple-height, triple-width-double-height, and triple-width-triple-height stretched characters using only a single extra bit. (Or with better packing we could support triple-width-double-height with the existing 4 bits).

bi = bold and italic flags
ll = line style

this line style applies to the borders, underlines, and strike-through

ustblr = lines to draw in character cell
bbbbbbbb = background (cell) color
llllllll = line color
ffffffff = foreground (glyph) color
gggggggggggggggg = glyph
oooooooo = overlay(s) to use

We can add an additional overlay over the top of our glyph. This is drawn using the same (foreground) color as the rest of the glyph. Overlays are primarily used to add diacritical marks (accents, tildes, etc.) to base characters to create our final character.

Consider different overlay tables depending on the range the glyph appears in (e.g., one for Latin alphabets, another for Cyrillic, etc.) Also consider disabling the overlay for certain ranges of glyphs to allow for more bits (and more base glyphs) to be specified.

Unsure if the oooooooo will specify one 256 entry table (for each range it is used) or if it is broken up into (for example) a 5-bit and a 3-bit subfield to allow two overlays to be used. Maybe make this depend on the range of the base glyph?

memory no-object, these 8 overlay bits could just be used to make a giant 24-bit glyph index

Lots to figure out with overlays...

Other notes about VRAM encoding scheme

Before switching from 4-bit to 8-bit color fields, we had the issue that there wasn't any direct way to specify superscript/subscript characters. Since these are not used in the CJK or emoji ranges, and since some other font modifications are also of varying helpfulness to those ranges (underline, bold, italic), the thought was that perhaps we could turn on one or more of these font modifications and turn on some of the high bits of the glyph field to indicate that this is a superscript or subscript character, and the remaining bits of the glyph and/or overlay fields would then become the index into our (smaller) superscript/subscript font. This may still make sense to do, so writing this idea down, especially if we go back to 4 bit color fields to save two bytes of space.

Also, in the future, if we have bigger fonts where italics and such are pre-computed, we could just expand the glyph bits to point into a larger table that includes bolds and italics and such. If we can free up a bit, we can lend it to the bold field and make it possible to have that field represent four different possible font weights: "light, normal, bold, and extra bold"

PF Design

What PF's design will look like is unknown at this point. Here are some ideas for possible changes and features:

Memory Map

(nothing to see here)




User Interface

(nothing here yet)

 Other Stuff

Notes to self

These aren't meant to make sense to anyone but the author of this document. This will get cleaned up eventually.


Old Thinkpad 4:3 Models to 1992 - 2001

Old Models 2000-2005

Old Models 2005-2013

2009 PSRef

X60s PSRef

240X HMM

Many HMMs

Various Old Models


ESP32 Power Consumption

Excellent overview of ESP32 sleep modes

Consumption of various development boards


E-paper Displays

Small power meter

13.3" Waveshare docs

10.3 Waveshare docs and (D)


E-paper Driver Board Info

Waveshare IT8951E driver

MPicoSys driver board datasheet

MPicoSys driver board purchase

Beck Driver Board

Good-Display Driver Board

Cypress Driver Board


E-paper Hobbyist Projects

Paper Terminal: an e-paper terminal experiment with 2.9" display (python)

The Paper Top: an attempt to make an e-ink laptop

Project driving EPD directly with an STM32 and Project Github




F-RAM 1MB chip

F-RAM 512KB chip


ESP32 Development Boards

TTGO Mini32: Small WROVER-B breakout







stuff below this is for other pages


Home Page

| ,----------------------------------, |
| |::::::::::::::::::::::::::::::::::| |
| |:::: ___ :::::::::::::::::::::::| |
| |:::: | _ \__ _ _ __ ___ _ _ ::::| |
| |:::: | _/ _` | '_ \/ -_) '_| ::::| |
| |:::: |_| \__,_| .__/\___|_| :::::| |
| |:::: _____ |_| .........:::::::| |
| |:::::: |_ _|__ _ _ _ __ :::::::| |
| |::::::: | |/ -_) '_| ' \ ::::::| |
| |:::::::: |_|\___|_| |_|_|_| ::::::| |
| |::::::::....................::::::| |
| |::::::::::::::::::::::::::::::::::| |
| '----------------------------------' |
/ ,----------------------------------, /|
/ /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/__/ //
/ /__/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ //
/ /___/_/_/_/_/_/_/./_/_/_/_/_/_/____/ //
/ /______/_/_/_/_/_/_/_/_/_/_/_/_____/ //
/ /__/__/__/________________/__/__/__/ //
/ '----------------------------------' //
/ _____ _____ //
/ / / / / //


PaperTerm is a thin and light laptop with an easy-on-the-eyes ["no eye fatigue?"] e-paper display and week-long battery life. Interested? You (yes, YOU [link]) can help us make it a reality!

Key features:

How is this possible and is PaperTerm right for me? Find out. [link]



| ,----------------------------------, |
| |::::::::::::::::::::::::::::::::::| |
| |:::: ___ :::::::::::::::::::::::| |
| |:::: | _ \__ _ _ __ ___ _ _ ::::| |
| |:::: | _/ _` | '_ \/ -_) '_| ::::| |
| |:::: |_| \__,_| .__/\___|_| :::::| |
| |:::: _____ |_| .........:::::::| |
| |:::::: |_ _|__ _ _ _ __ :::::::| |
| |::::::: | |/ -_) '_| ' \ ::::::| |
| |:::::::: |_|\___|_| |_|_|_| ::::::| |
| |::::::::....................::::::| |
| |::::::::::::::::::::::::::::::::::| |
| '----------------------------------' |
/ ,----------------------------------, /|
/ /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/__/ //
/ /__/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ //
/ /___/_/_/_/_/_/_/./_/_/_/_/_/_/____/ //
/ /______/_/_/_/_/_/_/_/_/_/_/_/_____/ //
/ /__/__/__/________________/__/__/__/ //
/ '----------------------------------' //
/ _____ _____ //
/ / / / / //
          | ,----------------------------------, |
          | |::::::::::::::::::::::::::::::::::| |
          | |::::  ___  :::::::::::::::::::::::| |
          | |:::: | _ \__ _ _ __  ___ _ _  ::::| |
          | |:::: |  _/ _` | '_ \/ -_) '_| ::::| |
          | |:::: |_| \__,_| .__/\___|_|  :::::| |
          | |::::    _____ |_| .........:::::::| |
          | |:::::: |_   _|__ _ _ _ __  :::::::| |
          | |:::::::  | |/ -_) '_| '  \  ::::::| |
          | |:::::::: |_|\___|_| |_|_|_| ::::::| |
          | |::::::::....................::::::| |
          | |::::::::::::::::::::::::::::::::::| |
          | '----------------------------------' |
         / ,----------------------------------, /|
        / /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/__/ //
       / /__/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ //
      / /___/_/_/_/_/_/_/./_/_/_/_/_/_/____/ //
     / /______/_/_/_/_/_/_/_/_/_/_/_/_____/ //
    / /__/__/__/________________/__/__/__/ //
   / '----------------------------------' //
  /             _____  _____             //
 /             /    / /    /            //

|        (o)   ::                     PT2b   * * * * * o    |
|                                                           |
| ,---, ,--,--,--,--, ,--,--,--,--, ,--,--,--,--, ,---,---, |
| |esc| |f1|f2|f3|f4| |f5|f6|f7|f8| |f9|f0|f1|f2| |ins|del| |
| |---'-,--',-'-,'--,-'-,'--,--',-'-,--',-'-,'--,-'-,-'---| |
| |  1  | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 0 | - | = |  <- | |
| |-----'-,-'-,-'-,-'-,-'-,-'-,-'-,-'-,-'-,-'-,-'-,-'-,---| |
| | ` | Q | W | E | R | T | Y | U | I | O | P | [ | ] | \ | |
| |---'-,-'-,-'-,-'-,-'-,-'-,-'-,-'-,-'-,-'-,-'-,-'-,-'---| |
| | tab | A | S | D | F | G | H | J | K | L | ; | ' | ret | |
| |-----'-,-'-,-'-,-'-,-'-,-O-,-'-,-'-,-'-,-'-,-'-,-'-----| |
| | shift | Z | X | C | V | B | N | M | , | . | / | shift | |
| |-----,-'-,-'-,-'---'---'---'---'---'---',--',--'-------' |
| | fn  |ctl|alt|                     |alt |ctl|    ,--,    |
| '-----'---'---'---------------------'----'---' ,--+--+--, |
|                    ,------,------,             '--'--'--' |
|  :::::             '------'------'                        |
|  :::::                                                    |
|  :::::                                                    |
|                                                           |




How is this possible?

While PaperTerm isn't a reality yet (we're still working on it), our eye-poppint feature list is doable. It comes from using the right set of technologies and making the right set of trade-offs.

Yes, we said trade-offs. Every device has them. We are just choosing a different set of them than any other device on the market. Our most important trade-off is that while PaperTerm may look like a regular laptop, it operates as a terminal.

(Don't know what that is? Click here...

Because PaperTerm is a terminal, all of the hard work gets offloaded to the remote computer, allowing PaperTerm to use a processor that doesn't use much power and still remaining lightning fast.

The second key design choice is that PaperTerm uses an e-paper display. If you've used a Kindle or similar e-reading device, you've used an e-paper display and already know how much easier and more pleasant it is to look at such a display compared to a traditional computer, laptop, or cell phone display even though it isnt color, only grayscale.

One nice thing about e-paper is it uses no electricity to maintain an image on its display. However, it takes quite a bit of energy to change the image on the screen and these screen updates aren't as fast as a regular display. If we are careful about understanding the details of those facts, beyond just being pleasant to look at and read, we can use the e-paper display to help extend our battery life while still maintaining reasonably rapid screen updates.

Is PaperTerm right for me?

If that concept is new to you, let me try to explain. A terminal (like PaperTerm)

lets you connect to and run programs on a remote computer as if you were

The simplified explanation is that a terminal (like PaperTerm) is a device that lets you use its screen and keyboard/mouse to remotely control and run programs installed on another. It is as if you were sitting at that remote computer and you can use that computer's programs anywhere you are as long as you have an internet connection.

What's the catch? Typically terminals only allow you to run text mode programs. You won't be running the latest version of Microsoft Word or Chrome with a terminal, but you can still run word processors and web browsers that were made to run in text mode. (Fun fact--Microsoft Word was originally a text mode program and you can still use that version with a terminal!)

Why are terminals typically text only? That results in a low bandwidth, lightning fast experience. While PaperTerm will eventually support graphic mode display, that isn't a priority for the project.

can be thought of as a device that connects to other computers and lets you control them. Your keystrokes and mouse movements get sent to the remote computer and its screen contents get sent back and displayed on PaperTerm's screen, so it is kind of like sitting right at the remote computer. All of the programs still run on that remote computer--PaperTerm makes it possible to use them from anywhere you've got a wifi/internet connection.

Text only

Power savings
Lightening fast

Two key points:
-we use an e-paper display to save power, just like a Kindle or other e-reader. Our 13.3" screen is much bigger though. Power savings aside, many people actually prefer e-paper displays because traditional displays give them eyestrain, headaches, or upset their sleep cycles.
-PaperTerm is all about connecting you to other computers to run your programs. It operates as a terminal. Your keystrokes and mouse movements get sent to the remote computer and that computer's display gets sent back to PaperTerns screen, so it's just as good as sitting next to the computer, but PaperTerm doesn't have to do the heavy calculations. (Never setup a computer to allow remote connections? Don't worry, we'll getting you up and running quickly).

As long as you've got wifi, you'll be fine.