- Ctrl+H for backspace, Ctrl+J for a linefeed, Ctrl+N or Enter for a newline
Also, the "VT100 connected to an IBM PC AT" link above is pretty remarkable, to me - I always used PC-DOS via the default framebuffer, so I didn't know this was possible!
> Ctrl+H for backspace, Ctrl+J for a linefeed, Ctrl+N or Enter for a newline
It is also worth pointing out that having the enter key send a CR+LF pair instead of just a CR is a setup option in the terminal.
> Also, the "VT100 connected to an IBM PC AT" link above is pretty remarkable, to me - I always used PC-DOS via the default framebuffer, so I didn't know this was possible!
I'm not terribly surprised that DOS can interface with a serial console, although I was not specifically aware of the feature.
One thing that is rather interesting about this is that you can easily tell if an application is using the DOS IO routines for IO (because those get sent to the COM port), vs interfacing with the VGA hardware directly since that appears in the VGA framebuffer.
For example, I tried installing windows 1.0 in the emulator, and all the setup screens bypassed the COM port for both input and output until it reached the very end, and then it output a few final messages via DOS IO commands (so they went to the terminal).
Oh yes, DOS could redirect to a serial link using the CTTY command, like CTTY COM1 or CTTY AUX.
Many DOS applications, however, wrote directly to text video memory at b0000h. Those... wouldn't work over serial link. You might be able to get WordStar to work using its ANSI.SYS display installation.
More like a physical and real terminal instead of a terminal emulator, displaying up a shell once the computer sends you the connection bits here and there.
Also you could interface modems by serial and you could send commands over the wire. More like telnet than ssh.
Fun with terminals for those who have never experienced them:
Run Sim390[1] with MUSIC/SP. Then get a TN3270 virtual terminal software to connect to it.
3270 is screen-based--think of it like filling out web forms and submitting, then receiving the results. This is far different than line-based terminals (e.g. your typical *nix TTY).
Compared to IBM's terminals, DEC's terminals seem completely unremarkable.
In the 90s , I wrote Windows C++ software that talked to hundreds of different 3270 applications in a very difficult attempt to screen-scrape them and display the data in a modern windows UI. It was difficult. Then take user input and submit it as a form back to the 3270 application.
It would have much easier if the applications were TTY line-based.
In 2000 and 2001, I used software like that ("TSS") as a customer service rep for MBNA, which has since been bought out by Bank of America.
It was incomplete, as anything offering a WinForms GUI over a 3270 client would necessarily be, but still very useful. A 3270 terminal emulator was also available; most folks quickly learned to use it for tasks the GUI didn't support, and some of us ended up preferring it for some tasks the GUI did support since it tended to be much more accommodating of muscle memory.
In retrospect, it must've been a real engineering challenge to integrate with a 3270 client whether via screen-scraping or the wire protocol. Like HTML, but with structural information only designed to be parsed by the terminal, or in the screen-scraping case with no structural information at all.
On the other hand, it couldn't have been WinForms since that debuted the year after I quit that job, so maybe it's my recollection that's somewhat faulty. It was a long time ago!
I didn't realize that the famous VT100 terminal actually had a full 8080 microcontroller.
Has anyone tried adding extra hardware to a VT100 to enable it to run CP/M using the terminal's own 8080 CPU? ;-)
Then again you could add a Raspberry Pi inside it that would emulate most systems of that era faster than the original hardware - not to mention being able to run BSD or Linux natively and fairly capably.
edit: apparently the VT100 has an internal "Standard Terminal Port" connector which you could plug expansion hardware into, like a PDP-8 or CP/M board... or a modern microcontroller board like a Pi or a BeagleBone:
When I was a high school senior in the 1980s I worked for a company making a VT100 clone (it also emulated several other popular terminals) The processor was a 6502. I can't remember how much RAM it had, but it had an 8k ROM.
When I started on the project we were using 12k of EEPROM. The lead developer and I spent about a week optimizing the firmware to reduce the ROM requirements to 8k. For debugging we used logic analyzer traces. Fun times!
I remember that we called this a "smart terminal" because it had so many functions.
It did, the earlier ones like the VT05 (and perhaps the VT50/52) didn't as far as I recall. They had a ton of boards with a whole lot of discrete logic! A bit like the early computers where the 'processor' was not a chip but also several boards with discrete logic chips.
As a result, those earlier terminals are even harder to emulate as there wasn't really much 'firmware' and definitely no standard CPU architecture. However those were pretty barebones anyway in terms of control codes.
I loved the VT05's design though. It looks really star trek. It won't fit on a modern desk because of the depth (all those custom boards take up a ton of space) but it looks so cool.
This is awesome, I've played Roguelikes but never the original. Cool art and transitions, feels really similar to Brogue(CE), which is still being maintained!
- 4 to switch to Local mode
- Shift+S to save setup
- F9 to exit setup
- Type something. Say hello!
- Ctrl+H for backspace, Ctrl+J for a linefeed, Ctrl+N or Enter for a newline
Also, the "VT100 connected to an IBM PC AT" link above is pretty remarkable, to me - I always used PC-DOS via the default framebuffer, so I didn't know this was possible!