Hacker News Reader

Comment by jhallenworld | Hacker News Reader

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.

View on HN

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.

[1] https://www.npmjs.com/package/serial-cat [2] https://github.com/pyserial/pyserial

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.

[1]: https://vt100.net/docs/vt102-ug/chapter6.html#S6.2.7

Pretty sure we ran them at 19.2k using 20mA loop and xon/xoff flow control.

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.

Reply on news.ycombinator.com