JWZ has something to show you (confusingly, a portrait screen showing a Matrix effect which makes it look like it’s sideways):
via @cjs in Displays for retro-computing - what do you use?
Here’s the video - one case where portrait-mode video is correct:
I can’t tell how much of that is phosphor persistence and how much is MPEG artifacts, but it seems to have some rather slow phosphors. (jwz mentions this in his writeup.)
OK, as an Emacs user with a number of ancient terminals, there are some real gems in that article:
The way terminals deal with this is flow control: either end can say, “Hold up, I am suffering” and data transmission stops until the other side is ready. The proper way to do this over a serial connection is with DSR/DTR lines, which are extra copper on the RS-232 cable, one for each side, that signal when we’re ready to go. But as noted, the not-quite-a-serial-port that Pis have doesn’t have that. Which leaves you with inline flow control, XON and XOFF, typically the ASCII bytes ^S to stop and ^Q to resume.
[…]
So I eventually figured out which sequences were the troublesome ones: for example, I remember that the command for “clear screen and move to the upper left corner” was a command that took the terminal a relatively long time to execute: after all, it had to zero out every one of those 4,800 bytes in the display RAM! This took it, let’s say, 5× as long as simply sending a character to the screen, which means the serial buffer would accumulate a 5 byte debt and eventually fill up. So the fix was to modify the termcap entry to tell it that the clear-screen command should also send 5 NULs! The terminal ignores NULs, those don’t go in the buffer, but they take up time on the serial line, allowing the dislay processor to keep up!
Well, this must be the ultimate Tetris device…
Yeah. Back in the day in the University of Alberta Computing Science department we had only one Ambassador 60, so it was a good bit of luck, I thought, if it happened to be free when you walked in to the terminal room. Being able to see a full 60 lines of code in vi (or more likely, 60 lines of readnews, was a joy.
(Now that I think about it, it was often enough free even when there were several other people in the terminal room. Perhaps because it made no different for /usr/games/rogue, which apparently destroyed graduate student productivity when the sysadmins installed it along with 4.1BSD.)
Or perhaps it’s just because, weirdly enough, that even to this day many developers don’t seem to care. I still more often than not pair-program with people who seem quite happy with around 24 lines of code displayed on their much larger monitors these days.
Multics provides a -delay control argument for stty, as well as many standard delay settings for various terminal types and baud rates to address this (although it doesn’t have a specific tunable delay to insert after clearing the screen via this interface, but that can, of course, be configured):
-delay STR, -dly STR
sets the delay timings for the terminal according to STR, which is
either the word "default" or a string of six decimal values
separated by commas. If "default" is specified, the default values
for the current terminal type and baud rate are used. The values
specify vert_nl, horz_nl, const_tab, var_tab, backspace, and vt_ff,
in that order. (See "List of delay types" below.)
List of delay types:
vert_nl
is the number of delay characters to be output for all newlines to
allow for the linefeed (-127 <= vert_nl <= 127). If it is negative,
its absolute value is the minimum number of characters that must be
transmitted between two linefeeds (for a device such as a
TermiNet 1200).
horz_nl
is a number to be multiplied by the column position to obtain the
number of delays to be added for the carriage return portion of a
newline (0 <= horz_nl <= 1).
const_tab
is the constant portion of the number of delays associated with any
horizontal tab character (0 <= const_tab <= 127).
var_tab
is the number of additional delays associated with a horizontal tab
for each column traversed (0 <= var_tab <= 1).
backspace
is the number of delays to be output following a backspace character
(-127 <= backspace <= 127). If it is negative, its absolute value
is the number of delays to be output with the first backspace of a
series only (or a single backspace).
vt_ff
is the number of delays to be output following a vertical tab or
formfeed (0 <= vt_ff <= 511).
These days, you’d usually use 0,0,0,0,0,0 for the delays, but if you don’t disable delays when using Multics with the DPS8M Simulator, they are inserted into the serial stream as NULs.
Early Unix also does this! Some of the v6 terminal definitions incorporate this, but you can also set some of them with stty. I remember that the Model 35 terminal definition sets them for carriage return and vertical tab, for sure.
Oh, fun! The default delays on Multics actually tripped me up once recently, when I was working on the automated CI used for the DPS8M Simulator project. I was trying to grep for some strings in the raw output and while I knew they were there and I could clearly see the text with cat, grep was not in agreement. It was because the NULs were inserted into raw log output. The CI scripts now always set all terminal delays to 0, or we otherwise filter the output before examining the logs.
It’s not surprising that old UNIX would do this by default as well, if the choice is having a new terminal that, by default, has some unnecessary delays (and is possibly a little bit slower) vs. having it drop data and maybe not work for the user.