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.
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.
> 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.
> The tty driver will buffer lots of data (or worse, the chain of ssh connections will do it).
That's what Ctrl-O is for, right?
I used to use that all the time on my 1200 bps modem. Usually followed by a Ctrl-L to repaint since discarding some of the buffered data can leave the screen in a weird state.
Indeed. Back when 300 and 1200 bps connections were a thing, Ctrl-O (flush) was a vital special character. You can actually see "flush = ^O" if you run "stty -a" on Linux. However it's not part of Posix, and AFAIK has never been implemented on Linux. This sucks if you've gone through the trouble of hooking up a fun retro terminal or teletype to your machine.
At a minimum it should be possible to up the baud rate to 19,200 via the terminal's setup menu, I seem to recall that's what the "good" labs had going back in college. Beyond that a simple node.js[1] or python[2] script should be able provide a baud rate limited buffer.
The VT102 can be configured up to 19,200, but the documentation says[1]:
> In applications using continuous 19,200 baud communication, occasional data errors may occur.
In my experience, setting the emulated VT102 to use 19,200 makes every keypress generate a data error. Even if it worked, though, the VT102 still runs at 6MHz and it still takes just as long to scroll the screen, and my host PC is still ~infinitely fast, so I think it would just make the problem worse.
Presumably you can paper over this deficiency by running mosh(1) or another such program as the shell, which has its own internal PTY, where the server end computes a stream of visual PTY delta events, and then begins reducing that stream into a series of “frames” (single aggregate visual changes), with the frame rate determined by a negotiated line rate between the client and server.
A mosh(1) client reading at 9600 baud will just receive fewer, likely-full-screen batches, where each batch has likely seen many full overwrites of its buffer before emission. Sort of like a VoIP client over a slow connection will just receive a low-FPS series of keyframes, with I-frames being unlikely.
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.
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.
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.
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".
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.
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.
- 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.
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.
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.