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.
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.
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 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.
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 +".
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.
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.
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).
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.
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 ;-)
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!
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 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.)
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.
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.
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/
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.)
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.
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]
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.
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.
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.
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.
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.
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.
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 have been working on the MagicShifter project (http://magicshifter.net/) and we designed the board so that the UART is available (for MIDI and other things).
If I can find a paper-ink display that I can drive somehow with a UART, I'd be quite happy to wire it up and hack up a MagicShifter app that turns it into a dumb terminal. Know of such a thing?
I'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.
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.
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.
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 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.
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 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!
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 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.
124 comments
[ 5.7 ms ] story [ 343 ms ] threadI do have an old French Minitel terminal, though - anyone know what the protocol for those is like?
http://serverfault.com/questions/176822/how-do-i-use-a-minit...
With a RPi:
https://www.youtube.com/watch?v=M5CltdZktlw
Even now, I still use a variation on that - a tall terminal window, ssh, and screen - for the majority of my work.
Although, I have switched to yellow text / red background for production and blue background for test environments. Keeps one from doing really stupid things.
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?
Although my idea was not necessarily integration in to my work flow, more a dashboard of network/server stats etc.
The VT220 supports Sixels: https://en.wikipedia.org/wiki/Sixel
I wonder if PySixel would work on real hardware: https://github.com/saitoha/PySixel
HN thread about libsixel: https://news.ycombinator.com/item?id=11340367
[0] https://github.com/KnightOS/z80e
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'd merge a pull request adding libsexl support!
Yes, thank you (I'm on Debian). I know a bit more after reading the wiki. I will follow the instructions for the sdk.
> I'd merge a pull request adding libsexl support!
Cool! I'm discovering the new world of custom tools for TI (KnightOS, Axe Parser, OS2...).
I will look at the SDL UI to see what I can do.
BTW z80 is good target for superoptimization and I'm very impressed by your toolchain and its history :)
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.
[1]: https://github.com/Swordfish90/cool-retro-term
Anybody come up with a version for iOS or Android yet? Seeing it on a tablet would be a real juxtaposition.
I recall finding the rendering impressive when playing around with the Mac version.
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!).
Planar ELT320
http://www.sunhelp.org/pipermail/sunhelp/2004-January/019825...
- another large monitor
- my MTG cards collection back
- at least four magic cubes
- a nerf gun
and ... a VT220. At least I got that very same keyboard already.
Seriously, that looks like a really nice working space, completely ignoring the fact that I just learned about sway (I'm on i3 here) in the process.
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.
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.
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!
http://www.computerhistory.org/revolution/mainframe-computer...
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.)
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.
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.
They have a horrible bit of forcing the user to connect an account online during first power-up. This can be avoided with a bit of SQL. This site talks about "activating" without the desktop app (and other bits of tinkering):http://uscoffings.net/clc/tech/embedded/kobo-touch/
>Connect the Kobo via USB, and mount its onboard storage on your desktop machine.
> Ensure you have an SQLite3 database browser installed, or some way to execute SQL. For example, sudo apt-get install sqlitebrowser
> Open /mnt/onboard/.kobo/KoboReader.sqlite.
> Execute this SQL: insert into USER values("foo", "foo", "foo", "foo", "foo");
> Save, unmount, and disconnect.
Here's a bit about enabling Telnet (and cross compiling for Arm7): https://github.com/drj11/kobonotes
Here's someone who turned their Kobo into a GPS for their glider. http://hackaday.com/2014/05/28/e-reader-becomes-sailplane-an...
When Steve Jobs left Apple and started NeXT, he pitched Adobe on the idea of using PS as the display system for his new workstation computers. The result was Display PostScript, or DPS. DPS added basic functionality to improve performance by changing many string lookups into 32 bit integers, adding support for direct output with every command, and adding functions to allow the GUI to inspect the diagram. Additionally, a set of "bindings" was provided to allow PS code to be called directly from the C programming language. NeXT used these bindings in their NeXTStep system to provide an object oriented graphics system. Although DPS was written in conjunction with NeXT, Adobe sold it commercially and it was a common feature of most Unix workstations in the 1990s.
https://en.wikipedia.org/wiki/PostScript#History
https://en.wikipedia.org/wiki/NeWS
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.
[1] https://github.com/IanDarwin/OpenLookCDROM
http://www.codersnotes.com/notes/a-constructive-look-at-temp...
Terry himself is schizophrenic but it's a fascinating piece of outsider art in many respects. He's even posted on HN under several accounts, but he's aggressive and disruptive and inevitably ends up banned.
I 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 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.
https://github.com/blog/1395-relative-links-in-markup-files
https://www.alchemistowl.org/pocorgtfo/pocorgtfo11.pdf
https://www.youtube.com/watch?v=ymei7UwBgX4
Looks like it's running a pretend-terminal website which probably explains the latency (the Kindle does not have a fast processor).
Way on the other end - here's a Dasung 13.3" eInk monitor (i.e. you feed it DVI and it handles all the display driving for you). It can be yours for a cool $1000. I'll pass, but it's looking pretty good even for GUI usage. Probably uses more power than a purely embedded solution could, though.
https://www.youtube.com/watch?v=vny-JTpt-aU
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.)
That'd still be painful for interactive use, though.
An article on here a little while back goes into detail about how even very small latencies affect the typing process: https://news.ycombinator.com/item?id=10787812
[1] Yes, I know it takes longer on an e-ink display to refresh the entire screen than to update a single character. My point is that page turning speed is thought by most to be unimportant, but being used to PC interfaces with fast response times made it unbearable to me, especially when I was skipping through pages trying to find something.
Actually, depending on what you are doing, the nostalgia-induced slowness might even be intended.
[0] http://spritesmods.com/?art=einkdisplay
[1] http://bbs.espressif.com/viewtopic.php?t=133
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.
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?
There are also some e-ink Android tablets, but I forgot if I found any that seemed good.
I also have a strong desire to ssh by e-ink, latency be damned.
+1 for good tmux'ing your output.
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.
[2] https://en.wikipedia.org/wiki/Newline#Representations
I wonder if I could get a keyboard and enclosure someplace and bolt on an LCD panel from a netbook (if only for the sake of power consumption).
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.