Products > Programming

altermatives to vt100? neater protocols?

(1/11) > >>

so, I put my money into the purchase of several vt-terms, a VT220 and a Digital DEC VT525.

They are nice machines based on 8080 CPUs, they are nice when you just use them with Linux, and they are very useful when you program on the text-console, especially the VT525 with a faster serial.

With VT100, ANSI escape codes for cursor control and other tasks became the de facto standard for hardware video terminals and later terminal emulators, and when you look at the protocol ... well, it's rather patchy, especially if you consider all the DEC addictions.

I'd like to re-design the terminal in modern terms, supporting blocks like IBM 3.27K (but not too IBM-ish) to minimize the number of I/O interrupts required by transferring large blocks of data known as data streams with high an a 48Mbps optical fiber interface, udp/ip over Ethernet connection optionally available.

So, a bit smarter than a dumb-terminal, not so much, but, absolutely of primary importance, the protocol must be designed in a super polished and neat way.

I don't want to see complex ESC sequences with the quality of being so illogical, inconsistent, and unclear, that trying to implement it's fsm in HDL is practically more annoying than heaping and stacking stones in the mine,

Suggestion, advice, all welcome  :D

It seems to me that you are conflating two entirely different issues:

1) the commands recognised / sequences sent by special keys, and

2) the communications channel, whether 20 mA current loop, RS-232, SDLC, X.25 etc, synchronous or async, "line mode" or not.

Waaay back 40 years ago when I was using such things, I seem to recall that the VT100 by default interpreted both ANSI ("VT100") commands and VT52 commands in the same mode. You could switch to ANSI-only using I think ESC < and to the mode that did both using ... uhhhh ..  ESC [?2l ??????  I don't think VT100 had a pure VT52 emulation mode, that I can recall.

When we wrote games on the PDP-11 or VAX, we used the VT52 codes to the maximum extent possible, because they are shorter and that made a huge difference at 9600 BPS. Especially the random cursor positioning using ESC Y row col (encoded in binary) was much shorter than the ANSI  ESC [23;75H or whatever.

Regarding communication channel: I remember at some point fairly early on a PDP-11/34 was re-purposed as a "LAT" to manage the async terminals and service their interrupts, and provide the VAX with nice packetised input and output. And to let you connect your terminal to any one of several VAXen too. That protocol is probably documented somewhere.


That's dated 1989 but I was definitely accessing VAXen via this protocol by ... 1983 maybe.

Why would you want to torture yourself implementing that in HDL (so I suppose using an FPGA, unless you actually plan on making silicon out of that), when even a small modern MCU would allow you to implement this with ease? Just wondering. (And yes, even with a VGA output without any additional ICs if you're using something as cheap as a RP2040!)

As to the protocol, I've never looked at it closely enough to figure if it was really that bad. But sure if you don't need to be compatible with anything, you can devise a clean protocol, not based on clunky ESC sequences. And if you're targetting much faster interfaces than what was standard at the time, you can encapsulate everything in neat packets with nice headers and CRCs and whatnot.

At one point “X terminals” (tektronix and NCD were two vendors) were a wonderful thing.
They even supported a compressed Async protocol (XRemote) that made them useful over 9600bps dialup (and Cisco supported it in their terminal servers!)
X runs over tcp/ip, of course.

I think Stanford’s “V kernel” did similar things, but didn’t catch on anywhere.  I suspect SUN siphoned away all of the developers.


--- Quote from: westfw on August 23, 2022, 07:15:47 am ---x11?

--- End quote ---

I own an original Tektronix xp-2xx-line with its netboot OS and license  :D

It's MIPS-R3000 based @ 50Mhz with 16Mbyte of fastpage 72pin ram (must be <=50nsec), fully net-booting, VxWorks v5-based, built-in mwm Windows manager, telnet, a built-in superfast Nescape browser and a font client.

First problem: it's pseudo color ---> forget everything GTK-based, only OpenMotif apps will work.
Second problem: only HTML-v1 (1991) and HTML-v2 (1995) are supported ---> forget 90% modern web sites

However, it also adds two serial lines in case you need vt100 an vt200 emulation.

And you don't need any "multi window" extension to operate with two sessions (you need >= vt420 for this), just open two of them, and connect each on a dedicated serial line, you have two physical serial lines, you can have up two sessions.

Do you want more? Use telenet, connect to a trusted telent-to-ssh bridge (WR703? a router?) and you will have many many more.


I like it, I like the "thin terminal" concept, and I recently replicated with a modern PPC GNU/Linux + uclibc + nanoX + DWM + (Invisible Island version) xterm solution ...

... just X11 and nanoX are toooooooooo big and complex to be implemented from scratch, and I won't for sure try to build my own.

The funny here is: the PPC@200Mhz with GNU/Linux and X11 is 1.2x slower than X11 on VxWorks on a MIPS-R3000@50Mhz

Kind of LOL


[0] Message Index

[#] Next page

There was an error while thanking
Go to full version