I've always wanted an ultra-low-power dumb terminal using eInk paper displays - something you could hit days of runtime with using a small battery pack. eInk uses no power when they're not updating - so idling or long-running operations would hardly use any power.
So far the easiest approach I've found is using a hacked Kindle with an attached keyboard. You can run a terminal client on it and ssh into another system, which I think is a sensible access mode.
Ideally, something like the AVR PicoPower microcontrollers would be fantastic - they run on ultra-low-voltage, eat 1 mA/MIPS, and idle down to basically nothing (<1ma active and a few dozen microamps during sleep). ssh is probably out of the question but I could toss a VT100 stack on it. Unfortunately the eInk display is the hard part there - most eInk parts have very poor documentation.
1mA/MIPS is a pretty generous power budget, with ESP8266 easily fitting the bill (56mA @80MHz + wifi rx; 10 uA in deep sleep [1]). Talking of which - here is Jeroen Domburg's project where he used exactly this chip to make a wireless battery-powered e-ink display:
I'd forgotten all about the ESP8266 but this project is about 95% of what I'm aiming for. The rest should be relatively trivial programming work, so thanks!
Can't speak for the other guy (who wants a portable monitor+keyboard system), but what I'm mostly looking for is a terminal that I could carry around/outside the house (i.e. potentially high-glare conditions) and program while connected to wifi, while not recharging for as long as possible, so this is perfect.
Maybe I can embed some stuff like vim or emacs on the device itself to help reduce utilization of the wifi. Is there any sort of "smart" protocol that could handle buffering files while editing on a remote host? I can probably do it, but I'd rather not reinvent the wheel, caching can be non-trivial.
Secondary use-case: RTTY or PSK31 or other amateur-radio textmode terminal, that could idle for as long as possible on a portable (QRP) battery pack. When you're schlepping the gear around, every ounce counts. Something that can talk serial is probably good enough, wifi is redundant there.
I have been working on the MagicShifter project (http://magicshifter.net/) and we designed the board so that the UART is available (for MIDI and other things).
If I can find a paper-ink display that I can drive somehow with a UART, I'd be quite happy to wire it up and hack up a MagicShifter app that turns it into a dumb terminal. Know of such a thing?
Wait, over 50ms is high latency now? That's less than transatlantic traffic delays, for example. I think you have to be in the actually noticeable (say 250ms plus) range to count as high.
Not to sounds like a Monty Python skit, but 50ms really does seem like luxury to me :-). I guess to back up the OP's point, I regularly use vim over 250ms+ latency lines for hours on end. It's not fantastic, but it's definitely doable. You need to have your vim golf game up to par, though :-)
I'd really love to have one or five of those for maintenance work. There's a lot of devices that I don't really need to have a keyboard and video connected to for 99.99% of their life time, but I still need an LC display and KVM switch connected to for about 10 minutes per decade. It's such a waste.
They have a horrible bit of forcing the user to connect an account online during first power-up. This can be avoided with a bit of SQL.
This site talks about "activating" without the desktop app (and other bits of tinkering):http://uscoffings.net/clc/tech/embedded/kobo-touch/
>Connect the Kobo via USB, and mount its onboard storage on your desktop machine.
> Ensure you have an SQLite3 database browser installed, or some way to execute SQL. For example, sudo apt-get install sqlitebrowser
> Open /mnt/onboard/.kobo/KoboReader.sqlite.
> Execute this SQL: insert into USER values("foo", "foo", "foo", "foo", "foo");
It's still a bit of a mess, and doesn't come with a decent keyboard, and the screens are tiny. I'd rather have something in a notebook formfactor – 12" eInk, full keyboard, and just a serial port on it. (Maybe also USB, for charging and slaved to a serial-to-uart adapter.)
Euhh, I'm not sure I understand your use-case, but e-ink displays aren't especially "cheap", or such. They take a noticeable amount of time to update the display, so doing things like typing, or viewing output from top(1) would be less than ideal. (This seems to get better with firmware, and being "smart" about which places of the screen get updated, generally)
The appeal, at least to me, is that they can display information with little energy cost. For example you could have it monitor the system's health and have it update every half an hour, showing graphs and such, and it would be able to do that for a very long time with a smallish battery.
I feel like I'm missing something - why do you need it to run on battery if it's consistently monitoring a specific machine? Isn't their power pretty much anywhere you'd need something like this?
I edited my use-case after he replied - I think he would be A-OK with something that could be reliably powered from a USB port. I don't speak for him, but I think we've chatted on this topic before.
You can power a "Full HD" monitor off USB. These have been around for a while, but it's really fun to see someone set up with dual screens at a coffee shop running on batteries: https://www.asus.com/us/Monitors/MB168BPlus/
Kind of random, but you made me think of it. I always wanted to do an entire site in PDF, with all the links opening other pdfs on the same server. That or postscript...
Funny you bring that up, I was just reading about this:
When Steve Jobs left Apple and started NeXT, he pitched Adobe on the idea of using PS as the display system for his new workstation computers. The result was Display PostScript, or DPS. DPS added basic functionality to improve performance by changing many string lookups into 32 bit integers, adding support for direct output with every command, and adding functions to allow the GUI to inspect the diagram. Additionally, a set of "bindings" was provided to allow PS code to be called directly from the C programming language. NeXT used these bindings in their NeXTStep system to provide an object oriented graphics system. Although DPS was written in conjunction with NeXT, Adobe sold it commercially and it was a common feature of most Unix workstations in the 1990s.
I remember some fuss being made about this in the early days of OS X, about "looking glass" (the gui system) using display postscript. Anybody know anything about that? If it's still a part of OS X or if it fell by the way side?
OSX was alleged (by Apple, even) to use PDF as the display language, but Quartz just has an object model that maps very nicely to PDF, making PDF transformations and export very easy.
Terry himself is schizophrenic but it's a fascinating piece of outsider art in many respects. He's even posted on HN under several accounts, but he's aggressive and disruptive and inevitably ends up banned.
I get why you'd have that impression (due to his mental illness), but TermpleOS is certainly not outsider art. While unconventional in some ways (and not sharing the aims of commercial projects), it's no more a piece of outsider art than e.g. KnightOS. Its code isn't bad, the design is certainly not idiosyncratic. It has none of the "classic" traits of outsider art that other hobby projects don't. You can read its code much like that of any other kernel. And IIRC, Terry Davis has the kind of academic credentials you'd expect from someone writing an operating system, too.
Hi Terry! Sorry, didn't know you had a new account.
I read some of your post history - can you explain how what you were doing with Ticketmaster was systems programming? It sounds like what would now be considered application programming, but I have no idea how intensive your work was at the time. High-performance code can often cross the line.
TempleOS is simply fascinating. I'm sure you know that I can't agree on the 'divine' part but it's certainly a fascinating OS. Writing an OS is a tough task by any means, let alone a reasonably fast one with a novel presentation. That's a lot of work, even for a productive OS programmer.
Have you taken a look at MenuetOS, Plan9, Oberon, or other non-traditional OSs? I'm curious what you have to think of their own unique features.
I applaud your goal of taking it back to basics. I think you're largely right about the number of abstractions between you and the hardware. Really really fast code needs to be written close to the metal.
I worked on the code that installed language modules into kernel space. I wrote a check-disk utility. I did a file compression archive. There were serial port drivers and I made a command to reset a stuck port.
I worked in VAX assembly language.
I did firmware for a bar code reader networking device with keypad and display. I worked on image processing for an actual bar code reader itself.
I worked there 1990-1996. About half was user space. The other half was kernel or firmware on bare metal.
-----
Pat and I started at the same time. He was in school with me, in fact in my differential equations class. He dropped out of school. I stayed in and got my master's in electrical engineering while working part time at Ticketmaster. I graduated with master's in 1994 and stayed with Ticketmaster for a year.
I returned to Ticketmaster for 3 weeks in 2002. Pat was a boss.
NeWS was an interesting experiment in this direction.
It seems quite odd that old VT terminal hardware is still in use, while it would be almost impossible to resurrect something like NeWS. A case of complexity I guess, but also the worrying volatility of storage media.
I suspect VT-standards-related hardware (and software emulators) survives because the protocol can be implemented without fear of getting dragged into court for licensing fees. Whereas if you wanted to implement NeWS (or Display Postscript) even today, you still have to license it. There is an informal mention that NeWS had too many third-party components to ever open source. [1]
As an aside, do you have an idea where to buy e-ink displays? I'd love to experiment with some. If fact if I could I'd love to get one of the poster sized ones!
Visionect (https://www.visionect.com/) sells e-ink dev kits up to 32 inches, but they aren't exactly priced for experimentation (nor do they include any sort of case/bezel). On the other hand, their displays do come with Ethernet, Wi-Fi and cellular connectivity built in.
Looks like it's running a pretend-terminal website which probably explains the latency (the Kindle does not have a fast processor).
Way on the other end - here's a Dasung 13.3" eInk monitor (i.e. you feed it DVI and it handles all the display driving for you). It can be yours for a cool $1000. I'll pass, but it's looking pretty good even for GUI usage. Probably uses more power than a purely embedded solution could, though.
FYI, I've seen virtually zero latency running livereload experiments with the embedded browser in my Kindle, the basic 3rd-gen 2014 model.
My method was extremely rudimentary - inotify -> long-polling JS (being fed entire new file) -> innerHTML rewriting, with the Kindle connected over 802.11g - but hitting Save in my editor produced updates on the Kindle's display in around around 20-40ms.
I would put a moderate amount of money on the possibility that the latency is coming from the fact that the terminal app in the video is being run on a non-local server, and that keystrokes have to go up to the cloud-hosted app and then come back down to get onto the Kindle's display.
If the whole thing were local (with the terminal app hosted on target system, ideally) I expect updates could happen in <100ms.
Also, the CPU is a 1GHz i.MX6 (@ 996MHz), next to 400MHz LPDDR2 (@ 396MHz). It performs quite well in my experience; it's the OS that's terrible. :P
(The best OS I've yet seen was the one on my Ericsson MC218, which let me drag windows around the display faster than the LCD crystals could physically keep up. Solid windows, not outlines. On an ARM7TDMI running at 36MHz.)
No idea about the refresh rate of eInk displays, but terminals were always designed to work over slow connections. So long as your configuration is pretty traditional (e.g. your text editor scrolling half a page at a time instead of line by line), it should be quite usable by 1970s standards.
Many bi-stable displays can be quickly set in one direction, and only have a slow refresh cycle for clearing or "cleaning" the display. Given that, a terminal based on e-ink could potentially display characters quickly and only be slow when clearing or scrolling.
That'd still be painful for interactive use, though.
I suspect it would. I ended up giving away my Kindle partly because the delay in page turning[1] was long enough to bother me. I can't imagine typing with such a display.
[1] Yes, I know it takes longer on an e-ink display to refresh the entire screen than to update a single character. My point is that page turning speed is thought by most to be unimportant, but being used to PC interfaces with fast response times made it unbearable to me, especially when I was skipping through pages trying to find something.
I've always thought that eInk+terminal would be the perfect use case for vt100 mode. This is built into xterm etc. and emulates phosphorus displays, where adding new elements to the display is fast but calling a full redraw is slow. Just like eInk.
You can change stuff without flushing the current contents, but previous contents may leave a weak trace when you do so. It's why Kindles have a setting to flush the screen every three pages or something; a decent compromise between ghosting and refresh rate.
The VT220 is fascinating as an example of "old" computer technology that still influences the devices we use on a daily basis.
I've recently had to understand exactly which control characters are sent between the app and the terminal (emulator) for delete and backspace.
Guess which ASCII control characters is sent by the Backspace key on your PC keyboard? ASCII DEL (0x7F/^?)! All modern terminal emulators on Linux and OS X (including the Linux console, xterm and libvte-based terminals, OS X Terminal.app and iTerm2) now default to sending DEL [1] when you press the Backspace key... now it makes much more sense that on a Mac keyboard, that key is labeled "Delete" and used to have the same symbol as on the VT220!
Oh, and what character is sent when you press the (forward) Delete key? Why, the escape sequence 1B 5B 33 7E (ESC [ 3 ~), of course :) Because the terminals we emulate didn't have a key for forward delete ;)
For bonus credit, lookup the historical usage of the Linefeed (LF/0xA/^J) and CarriageReturn (CR/0xD/^M) characters [2]. There was much more than just the Unix/Mac/Windows divide in text files...
[1] yes, you can swap for ASCII BS (8/^H), but if your app needs that, consider updating it.
I had a Wyse dumb terminal attached to my main Linux workstation for a few years in the late 90s, back when such things were fairly easy to pick up for free.
Its not to be sneezed at for doing serious programming work. The green on black, text only CRT was super high contrast (especially compared to any modern LCD), and the complete lack of distractions that come with a multitasking desktop environment (email notifications, chat, web browsers, Facebook, etc) mean that it's productive for serious work, and pretty much only serious work. I'd happily do this again if I could get them for free, but paying shipping seems a bit much.
Wyse attached to my Linux workstation in the late 90s too.
My Linux workstation's monitor was mainly in text-mode too. I used the Wyse to tail some logs and used vim and a shell for 'real' work on 2 VTs, with IRC and mutt on a couple more.
All this talk about how expensive serial terminals are now makes me think I should have kept some of the hundreds I threw away over the years, but then I think about the storage required!
Is the contrast on an old CRT really better than on a modern LCD screen ? I find that a bit hard to believe but I certainly don't have any way to check. You could run a plain vanilla window manager with a single xterm if you want to avoid distractions.
It depends. You can crank up the brightness much higher on a CRT, and so you can get better contrast in a sunny room. In a dark room, any decent LCD and any half-decent CRT can get the characters uncomfortably bright.
But it's only 80x25! I may have read megabytes of email and Usenet on such things, but I always lusted over the big displays of the Suns that could fit 40 rows down, and change character size to match my desires.
So I'm all for adding more screen real estate, but a VT220 isn't my pick for best way to do that. I prefer a second large monitor in portrait mode.
Sure, CRTs have better contrast than LCDs in general, but monochrome CRTs have incredible contrast. I guess it's because they don't have separate red / green / blue subpixels (2/3rds of which would be off for green on a color CRT). Also, the particular shade of green phosphor they use is really intense, I guess they just use the wavelength the eye is most sensitive too, because they don't care about how it mixes with other colors.
Ha ha! I suffer ocular migraines and found that a super huge font helps me avoid migraines. With the font I use, I get 111x26 :-) One of the things that prompted me to try such a ridiculous font is remembering using 80x25 terminals for the first few years of my career. I have absolutely no trouble programming this way. Trying to pair program like that, though, is problematic ;-)
I used to use a VT52 and TECO, later replaced by a VT100. The smooth scrolling seemed impressive at the time. Not long after that I moved into embedded software and wrote firmware to emulate these terminals, mostly in Z80 assembler.
I've long since given away or sold most of my old DEC terminals, I've still got a couple (VT340, VT340+, VT220 x 2) but the keyboards don't hold up. I'm down to two working keyboards (an LK201 and an LK401). I've been tempted to wire up a HID -> VTxx adapter using a simple embedded controller. I'll have to add that to my list of fun projects for a long weekend.
Generally though when using them on older machines I am amazed at how frustrating 80 columns of 24 (or 25) lines can be! Sure you can do "wide" mode and get 132 columns but still, the desire to see more screen real estate is a constant issue.
I was discussing an identical project with a coworker a while back, and have been stalking ebay for VT2X0s occasionally since. However they seem to be incredibly rare in the UK, and all the listings shown require shipping from the US with monstrous fees.
Although my idea was not necessarily integration in to my work flow, more a dashboard of network/server stats etc.
Hang out with the retrocomputing people. Also to some extent the ham radio people, at least some of them.
The business model for the $200 Wyse-60 is OMG our CNC milling machine's terminal is down and every day of production we miss on the missile contract costs us $50K, so I don't care how much it costs, ship one here by tomorrow morning, etc etc. Or you can haul away a Wyse-60 for free because the previous owner won't have to pay electronic recycling fee. That's the model I have. Its pretty nice for a dumb terminal.
Aside from plugging into a linux box and having another cheap screen for scrolling logs or whatever, I mostly use it for exotic hardware. Software terminals are generally not as compatible as hardware terminals (despite hardware terminals mostly being SBCs with exotic firmware) and if a hardware fault puts 220V on a connector and vaporizes my "free" terminal I'll be much less unhappy than if it vaporized my expensive main computer or even a rasp-pi. Also they boot very quickly, 3 seconds from flip the power to work, whereas a "modern advanced" computer takes maybe 5-10 minutes. So from a stopped condition, "I just wanna know if this PLC is alive or dead" can be answered in 6 seconds instead of 6 minutes.
Given that you can haul them away for free, depending how many dumb mistakes I make, I have roughly a lifetime supply.
Restoration of old hardware can be entertaining as a hobby in itself, I have to rip out the (inevitably leaking) dead nicads and replace them with a diode and dual AA battery holder, at least on my Wyse-60's.
That's pretty cool! It reminds me of a similar project I did called z80e, which is an emulator for TI calculators [0]. It uses unicode braille to "render" the screen onto a terminal. Doesn't work on the VT220, though, for obvious reasons.
I'm reading the source code of z80e (tui.c). Your idea of using unicode to display pixels is very interesting. I imagine a fallback mode for libsixel for terminals not sixel-compatible (or the opposite).
I try ton compile but it fails (first because scas was missing and now I have an "a2x: not found" in scas).
I appreciate a lot the "multitarget rendering" (emscripten, tui, sdl...).
I remember someone at school wrote a program to inspect a remote Decstation 3100 (1024x864x1) screen on a vt320. Frequently people were running X with "xhost +".
I feel old; I used a Wyse 320 and later a VT220 as my sole / main IO device in 1995-96 - connected to a SPARCstation 10 via a multi-port serial box at 9600 baud, with heavy use of GNU Screen.
Even now, I still use a variation on that - a tall terminal window, ssh, and screen - for the majority of my work.
LOL. What's old is new again, mate. When I worked at Shell in 1989 and 1990 we were going to throw out Sun 3 desktops as underpowered and useless. Instead I convinced them to recycle the 3/50s and 3/60s as X terminals by replacing init and booting straight into X. You could use local X terms and telnet (ssh? what's that?) to systems, but we found it was faster to use XDM and supply the desktop from a server like a Sun 4/280.
I would kill to have a modern-day equivalent of the native UNIX desktop I had on a 4/110 after we ditched the 3/50's: the system had two frame buffers and you could switch between desktops by crossing the desktop boundary in any direction. Probably easier to just use two screens these days but at the time that meant putting two extremely large and deep CRTs on your desk.
Here we are 25 years later and xterm+ssh is still the easiest way to get my UNIX work done even if everything else (e-mail, productivity apps) is in Windows. Where's my modern-day NCD X terminal equivalent and unix desktop?
I really liked the Wyse 320? and used it for years until CRT died. It seemed to have the most diverse emulation support. Same deal with vt320 and HP 700/96 I just got tried of working on the CRTs all the time. Now I just use ZOC.
Well, I've used the Z19, IBM 5150, and VT 220 & 240 in my early years, so your among other late 80s / early 90s terminal room dwellers. I still have a green screen terminal configure on my Mac.
Although, I have switched to yellow text / red background for production and blue background for test environments. Keeps one from doing really stupid things.
Honestly, were it not for a web browser I really wouldn't need a GUI at all: everything else I do is a terminal and emacs (sure, both are running in X, but I don't really use their GUI features for much).
I remember when I was a kid with access to a local university's systems, and the only way to do anything was with dumb terminals. I telnetted to MUDs, FTPed software, read Usenet — in a lot of ways those dumb terminals were smarter than my current computer. Sure, I can still do all that, but the magic is gone.
At work, I have a Wyse 50 tailing my console log. It's actually really useful to be able to debug stuff when something goes awry on my development machine.
For fun at home I have an ADDS Regent 25 with a raspberry pi inside. Turn it on, it boots to Debian and binds to the network. I force the kids to play 'snake' on it when I'm sick of them using iPads.
In my home "office" I've got my VT102 tied to a PDP/8 simulator on a pi, with one of these kit front panels:
I don't really use it for editing code, I just needed to put something on the screen that wasn't email or irc (which would reveal semi-sensitive information.)
Those examples all seem to have excessive bleed from the bright areas. If those were physical devices, I'd be turning down the brightness control immediately.
Anybody come up with a version for iOS or Android yet? Seeing it on a tablet would be a real juxtaposition.
These things continue to show up in the weirdest places as never-intended consoles.
Phone switches, network devices, control panels, etc.
There were so many of them leftover from the switch to PC's and they always seemed to work (once you got the parity right). Usually in some closet somewhere, balanced on top of a box with the keyboard leaning against the wall. Need a power cable? Grab one from a PC, use it to power up, change some settings, turn it off and put the cable back.
I can't remember the exact model number, but a company sold gas-plasma-discharge orange-on-black compact "flat panel" VT220 clones years ago.
I owned one for a while before selling it off (along with a 19" gas plasma flat panel for a MicroVAX that I got at Goodwill for $25 - now THAT was a steal that I turned into a nice profit!).
Hmm, seem to recall Wyse had a gas-plasma display. The Googles do nothing to turn up a model #, though. Several vendors made them, with Wyse being the more popular brand IIRC, and early Toshiba laptops used them (had a 386 with a gas-plasma display).
For our next LAN party this week, we did a small player interface to welcome users using VT220. Here is it working with an acoustic coupler throught a field phone: https://vimeo.com/159678785 :)
I recycled a couple of nice Hazeltine terminals about eight years ago ... About three years ago I was wishing that I had them back. Projects like this as well as their use (with a serial multiplexer) as the console for a rack of servers remind me of the good old days.
I picked up a VT220 a year ago at an estate sale, the previous owner was using it with amateur radio gear. Prices (especially including shipping) seem prohibitively expensive otherwise!
Lucky you. I also had a working VT100 some years ago. It's a nice device but rather huge. Still I hope to have it back. It was nice to see those monsters in The Big Short.
I bought an apple IIe for nostalgia and one of the first things I did was hook up a null modem cable to the serial card and make it a linux terminal. I was able to use google via elinks. My kids love the various games like ultima because it's like minecraft (blocky) but you can't build in it.
I used VT320 (amber) "back in the day" a lot. I wish I could find one to hook up to my workstation or an SGI Octane2 (for full retro feeling to it). I would only write text/screenplays on it anyways. Something about CRTs that modern monitors haven't captured.
I've had a handful of these over the years, initially in my home racks and workstation, later migrating to my datacenter so I had an always on stats screen showing traffic, alerts, etc.
I used mostly VT420s in my old VAX sysadmin days - I always preferred the white text on black ones. Nice thing about VT420s was the split screen dual serial port mode.
The Ann Arbor Ambassador was the ne plus ultra at the end of that age, it did up to 60 lines of 80 characters, had the fancy features to minimize data transfer, and could do it all at 9600 baud. The VT220 was a nice evolution of the clunky VT100, but there wasn't a vast difference from, say, the VT52 to it, besides the extra commands that allowed minimizing data transfer (at the cost of rather hairy redisplay code).
I've always wanted an ultra-low-power dumb terminal using eInk paper displays - something you could hit days of runtime with using a small battery pack. eInk uses no power when they're not updating - so idling or long-running operations would hardly use any power.
So far the easiest approach I've found is using a hacked Kindle with an attached keyboard. You can run a terminal client on it and ssh into another system, which I think is a sensible access mode.
Ideally, something like the AVR PicoPower microcontrollers would be fantastic - they run on ultra-low-voltage, eat 1 mA/MIPS, and idle down to basically nothing (<1ma active and a few dozen microamps during sleep). ssh is probably out of the question but I could toss a VT100 stack on it. Unfortunately the eInk display is the hard part there - most eInk parts have very poor documentation.