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…
