
Real VT102 Emulation with MAME - zdw
https://zork.net/~st/jottings/Real-VT102-emulation-with-MAME.html
======
jhallenworld
MAME should only read from the PTY at 9600 baud to fix the buffer problem.

It will lead to another problem that you have also with real terminals
connected to UNIX. The tty driver will buffer lots of data (or worse, the
chain of ssh connections will do it). This can be annoying: hold PageDown in
an editor, then hold PageUp. Ideally, you should instantly see the top of the
file, but instead you have to put up with potentially minutes of buffered data
going by.

The editor should output only the latest screen contents when there is type-
ahead. But it has to defeat the output buffer to do this properly. The text
editor JOE does it: it does not feed data faster than the baud rate to avoid
buffering. This allows it to detect type-ahead and only output the most recent
screen contents.

~~~
drudru11
This is interesting, thanks for sharing this. I will look at the JOE editor to
see how this is implemented.

I have thought about this problem off and on. Usually the conclusion I come to
is that we need a new tty interface. The old tty interface has too much legacy
baggage. For example l, in addition to the buffering problem, there is also
the key input problem. Ideally, a newer interface would provide scan codes
instead of the escape sequences. Not having to deal with ‘escape’ like we do
today would simplify things.

~~~
skissane
> Ideally, a newer interface would provide scan codes instead of the escape
> sequences. Not having to deal with ‘escape’ like we do today would simplify
> things.

While I agree the Unix tty model is crufty and old, this particular feature
doesn't require any changes to it. The later models of the real DEC terminals
introduced a mode called DECPCTERM to send PC compatible keyboard scan codes,
with escape sequences to enable/disable it. Terminal emulators very rarely
implement it, but there is no reason why they couldn't. And there is no change
the Unix tty subsystem design required to support it.

------
andrewstuart
You can buy a USD$12 computer that does VT100 using FabGL

[https://www.youtube.com/watch?v=n5c27-y5tm4&t=154s](https://www.youtube.com/watch?v=n5c27-y5tm4&t=154s)

[https://www.aliexpress.com/item/33014937190.html](https://www.aliexpress.com/item/33014937190.html)

[https://github.com/fdivitto/FabGL](https://github.com/fdivitto/FabGL)

Which has been further refined into VT132:

[https://thehighnibble.com/vt132/](https://thehighnibble.com/vt132/)

~~~
JdeBP
That is yet another recently written emulator, however. The headlined article
makes the point that it is running the actual original VT102 firmware.
Moreover the fact that _it does colour_ indicates that the "vt132" is _not_
"doing VT100". The VT100 was a monochrome device.

------
gnachman
There is an incomplete test suite for terminal emulators. It was my paternity
leave project many years ago. Contributions are welcome.
[https://gitlab.freedesktop.org/terminal-
wg/esctest](https://gitlab.freedesktop.org/terminal-wg/esctest)

~~~
skissane
How does this compare to [https://invisible-
island.net/vttest/](https://invisible-island.net/vttest/) ?

------
technofiend
I realize it's wishful thinking but it would be cool as hell if HP dusted off
their Digital intellectual property and sold a real VT throwback terminal. The
relay buzz from VT-50s and VT-52s and the keyboard feel and noise from a real
VT-100 are incredibly nostalgic for me. Hell an ADM-3A clone so people could
see where esc-{h,j,k,l} came from would be nice too.

~~~
rbanffy
Add a flexible display that is shaped like a CRT.

Trinitron tubes are easier to mimic that way, but I don't remember any
terminal fancy enough to use one.

------
cosmojg
I hope we can eventually move away from emulating DEC VT-series physical video
terminals and rid ourselves of the associated cruft once and for all. The
command line has the potential be so much more on modern systems. In this
vein, I think notty[0] was the last meaningful attempt at moving things
forward, but it seems to have lost its momentum. I guess we'll be stuck in the
80s forever.

[0]
[https://github.com/withoutboats/notty](https://github.com/withoutboats/notty)

~~~
rbanffy
There are countless millions of work hours invested in software that uses this
perfectly reasonable, time tested character matrix approach.

If that's not enough, there are slightly fewer million work hours invested in
other GUI technologies, from the first ones all the way to Electron

------
adrianmonk
Now that this has come along and shown it has the true claim to the term
"terminal emulator", I guess I'll have to start referring to everything else
as a "terminal simulator".

------
rahimnathwani
Instead of launching a shell, and then invoking getty from within that shell,
can't you just skip the shell and launch getty directly on the pts?

IIRC when I had a real terminal hooked up to my first Linux machine, via a
serial cable, whoever was using that terminal was presented with a login
prompt, and not the shell. I think that used getty.

~~~
thristian
_Something_ has to launch getty. I launched it from the terminal because I had
to run MAME interactively to find out what PTY it created - if I had a
hardware serial port with a fixed name, then yeah, I could tell make init run
a getty on it at system startup without having to disassociate from an
existing controlling terminal.

~~~
rahimnathwani
At the point when you run:

TERM=vt102 LC_ALL=C COLUMNS=80 LINES=24 /bin/sh </dev/pts/10 >/dev/pts/10
2>/dev/pts/10

Can you run this instead?

TERM=vt102 LC_ALL=C COLUMNS=80 LINES=24 /sbin/agetty </dev/pts/10 >/dev/pts/10
2>/dev/pts/10

~~~
thristian
I don't think that exact command-line would work:

\- agetty would inherit the controlling terminal of the shell it launched
from, and it doesn't know how to dissociate itself, so it would still need a
tool like setsid

\- agetty launches login, which needs root permissions, so you'd still need
sudo

\- agetty/login reset the environment for the new session, so setting those
environment variables would have to effect

\- not a semantic problem, just a syntactic one, but agetty manages the TTY
named on its command line, it doesn't pay attention to its stdin/out/err, so
the redirections wouldn't help

Taking all those changes into account, you get the command line from the "no
job control" section at the end of the article.

------
skissane
I'd really like to see VT525 MAME emulation. (I thought about buying a real
VT525 once, almost did it, but then decided there were better things to spend
my money on.)

> Unfortunately, the emulated VT102 is not connected through a real serial
> port, it’s connected through a PTY which (at least compared to what the
> VT102 expects) is basically infinitely fast.

A quick and hacky solution might be two USB to RS-232 converters and a
loopback cable.

I'd previously wished for a virtual serial driver which slowed stuff down
based on baud rate, implemented all the RTS/CTS/DCD/RI etc signals, etc.
Someone with sufficient time, inclination and kernel development skills could
build one. Given it is such an esoteric wish, probably not going to happen.

------
ksherlock
another vt100 emulator -
[https://github.com/phooky/VT100-Hax](https://github.com/phooky/VT100-Hax) \-
actually, 2 - one is ncurses, one is qt.

~~~
fortran77
(and also based on the original ROMs -- and another source for them)

------
Firehawke
I got it to connect to a BBS from Windows using .\mame64.exe vt102 -window
-rs232 null_modem -bitb socket.10.0.0.33:23

You could probably tunnel to get SSH working.

------
ChicagoDave
I wrote video games for the VT100 connected to a PDP-11 in high school.
Memories.

------
kevin_thibedeau
This needs scanline emulation turned on.

------
leoc
The VT100's industrial design shouldn't look too unfamiliar to anyone either.

