Why: to experience what it's like to do computing under such constraints, and to learn more about Unix programming.
I find it interesting to see how programs like pagers, web browsers and such deal with screen updates. I'm aware of the role of curses in general terms but it's fascinating to see it in action. For example, running from a PuTTY session scrolling up in less(1) is very efficient as it reuses the scrollback buffer, but not on macOS' Terminal.app (as in the video).
Any remarks or questions re. the concept or implementation are welcome. C programming is a hobby and a lot of this lower level Unix stuff was new territory for me.
Warning: Since the tritty program does not set the TTY baud rate (as shown by the “stty” command), programs cannot properly detect the slowness of the terminal, and will not compensate and/or optimize for it. Therefore this should not be seen as an accurate portrayal of life in 600bps.
I settled on that as the default because it's slow enough to clearly show it working from simple use (e.g. you don't need to open elinks to see it's slow) but fast enough to not discourage playing around with it.
Of course, there's a -b option that takes any rate between 50 and 57600 baud (the upper limit there because I'm not sure if it would keep up).
The “tritty” program does not set the baud rate on the TTY (with for instance cfsetspeed()), so programs running still think the terminal is fast. This means that programs (like Emacs) that have many optimizations for slow terminals, won’t use them, even though they would have been appropriate.
Thanks! I had seen the attribute but wasn't aware of its use. I'll read up on it and try to implement it appropriately.
Interestingly vim does seem to disable syntax highlighting after a while, as can be seen in the video. Since the rest of the colours etc continue working I don't think it's a rendering artefact.
I don't know if I can deal with such a high speed terminal. It really is too fast for comfortable reading.
When I first saw a 300 baud Texas Instruments Silent 700 terminal, it was an eye-opener. Sure, the thermal paper printouts faded pretty quickly, but at 30 characters a second it was three times as fast as the Teletype machines I used before.
Even with all that speed, it wasn't too fast for the human mind to comprehend. Not like this 600 baud monstrosity.
I played on Silent 700s when I was kid. My father would bring one from work every now and again and I would be allowed to play on it... a bit anyway (I was ~10 at the time). I remember being in awe at how sophisticated some things could be... that you could actually put the telephone receiver in a couple of rubber cups and the machine could "talk" to a remote machine far away. Wonder of science that. And no, I'm not saying that sarcastically either! The phone we'd put in the acoustic couple modem was itself still a pulse-dialer with a cord (cordless phones still weren't generally on the scene just yet, though DTMF dialing was a thing, a newer thing, but a thing).
Between that and the copy of 101 BASIC Computer Games book I had (and still have) from that era, my career was really started unbeknownst to me.
Beautiful. I looked at obtaining a teletype or similar device but these things take quite and investment of not only money but also time and effort now.
Maybe it would be fun to try and write a small program at 300 baud or so with a line editor like ed or ex. Not sure though if terminal scrollback is a good substitute for having printouts to refer back to.
Dialing in to the 1200 baud MODEM pool was both uneconomical and didn't even confer any great benefits. The 900 baud pool was only like a buck a minute and the 1200 baud pool was $4 per minute!
That said, I might actually have to get off your lawn. My first was a 900 baud cradle. Hayes, I think? Maybe Digital? That was a whole lot of years ago.
Pedantic note: in this case baud and bits per second may be the same rate, but they technically denote different things. Baud denotes the symbol rate. If you’re able to transmit more than one bit per symbol, then the baud and bps are different amounts. For example, 1200 bps modems transmitted 2 bits per symbol and thus were 600 baud. That said, the term “baud” was almost always misused as a synonym for bps.
Speaking of modems, the coolest one ever made was the Novation Apple-CAT II:
My first modem was 600 baud. I used to like waiting a long time before source code would be in and I could check & run it. I would read the description of the game/program and in my mind I used to make up what it would be like. The reality was always nothing like it, but that was ok.
There was something fun about reading/typing in/very slowly downloading game/program listings. Later I had the same feeling with going to meetups and standing in line for ages to copy sources onto floppies.
It doesn't address the TTY part, but for limiting a pipe's throughput there's also pv[0]. It's main purpose is visualising pipe transfers, but the throttling support is solid.
Curiously I've experience using 63 baud PSK on amateur radio, setting this to that same speed feels slower than when receiving text over the air. I guess this must be some extra overheads somewhere
PSK31 and it's derivatives use a variable length encoding of the characters (for example, space is 1 bit and e is 2 bits). For English-like text that'll cause it to be faster than tritty.
Well, not a serial terminal, judging by that ^c in the video! Worst thing about a slow baud rate is if you cat a big file you're gonna sit there and wait until it finishes flushing down the pipe before your ^c makes it up.
It seems to depend on the program. cat is very quick to respond to ^C whereas in vim, less and elinks often a large amount of text is printed before ^C is echoed and takes effect, like you describe. I suppose that has to do with the size of chunks written.
In reality though it's more about the trickling than actually mimicking a proper serial connection.
I'd expect the ^C to immediately kill the connection. It sends a SIGHUP, which indicates the serial line has been disconnected. (Based on the DCD line, per Wikipedia.)
I'd think the ^C would be transmitted by a physical disconnect, i.e. changing the state of the DCD line. The DCD disconnect should immediately trigger an interrupt, which should trigger a SIGHUP.
To be fair, though, I can't say I've used a proper serial terminal.
Perhaps you are too young to have experienced only having access to the internet via a shared UNIX system which in turn was only accessible by serial terminal?
Why: to experience what it's like to do computing under such constraints, and to learn more about Unix programming.
I find it interesting to see how programs like pagers, web browsers and such deal with screen updates. I'm aware of the role of curses in general terms but it's fascinating to see it in action. For example, running from a PuTTY session scrolling up in less(1) is very efficient as it reuses the scrollback buffer, but not on macOS' Terminal.app (as in the video).
Any remarks or questions re. the concept or implementation are welcome. C programming is a hobby and a lot of this lower level Unix stuff was new territory for me.
Source: https://github.com/sjmulder/trickle