One of my regular commenters on A&D, Random832, wrote the following in response to my inclusion criteria for Things Every Hacker Once Knew.
On “common knowledge at the time”, I think the problem with dismissing things as “fascinating but obscure trivia” means too much exclusion of the real facts behind things that were already forgotten or inaccurately known, and reduces its value as a historical document. There’s also the fact that the intersection between, say, the Lisp and Unix hacker spaces seems to have been tenuous enough to cause some things to have been lost in translation […] – maybe there was never really anything every hacker once knew, just some things some hackers once knew, and other things other hackers once knew, all worth preserving. I think arbitrarily drawing lines around “provides too much historical context” runs the risk of the document being better described as “Things Eric Once Knew”.
I think this comment raises real issues that deserve to be squarely engaged. I’ve omitted one sentence that I think is based on a a factual misunderstanding in order to focus on the large questions.
The first and most obvious point is that this is not a new set of issues. I already had to engage them in connection with the Jargon File a quarter century ago. My answer now, as it was then, is that of course every historian has unconscious biases and selectivities. But if we let that paralyze us we could never write any history at all. This would be a cure worse than the disease that Random832 is pointing out.
There are equally obvious ways to address this problem. One is doing now as I did in 1990: exposing my process to peer review and willingly engaging in a public conversation about both fact and interpretation – not just accepting correction from other witnesses but inviting it. This is more than most historians are willing or even practically able to do.
In this particular situation, I think I am a reliable negative filter (if I didn’t know it, it wasn’t common knowledge) but a less reliable positive one (if I knew it, and thought everyone else did, it was common knowledge).
The reason for this is precisely the position that Random832 sees as a possible weakness: in the crucial period 1976-1985 I lived at the intersection of three subcultures. They were: the Lispers, the Unix minicomputer guys, and the micro hobbyists. It wasn’t a perfectly symmetrical situation; I was deeper in the Unix culture than in in the Lispers and micro guys. But it gave me a breadth of perspective that nobody confined to those individual subcultures could quite match.
But putting it that way also risks overstating the divergence. Because, for example, essentially everybody who learned his chops before the early 1990s either had to deal with serial terminals day to day, or (if they were on a workstation or micro) had recent memory of doing so. There simply was no way for this not to be true, given the technological surround. Similarly for modems in the pre-DSL era.
I am, therefore, actually pretty confident about the ubiquity of most of what’s in there – that it isn’t just things Eric once knew. I get some confirmation of this from the rather high volume of traffic related to the document in my mailbox. The overwhelmingly dominant tone is “Thanks for the trip down memory lane”; I don’t think anybody has yet said “I didn’t know that”, or suggested that I’m too focused on one of the subcultures. I have been alert for such criticism because I understood the issue going in.
Looking over the whole document with this in mind, these are actually just two pieces that worry me that way. One is the ‘graph about the Space Cadet keyboard; the other is the discussion of standard vs. TTL serial. They present opposite problems.
On the one hand, I’m not certain the Space Cadet keyboard was common knowledge at the time. It became so later, but that might have been a retrospective effect of the Jargon File.
On the other hand, I now think the details of the level distinction in RS-232 were common knowledge then – even though I, less hardware-savvy then than now, only vaguely knew of it – but I could still be wrong; that might have been been micro-culture only, which is why I was only vaguely aware.
Whereof one cannot speak, one must remain silent; but if one chooses to bear witness, the hazards of imperfect memory and limited perspective are ever present. The best we can hope for is to mitigate them by cultivating humility and openness.
I started in PDP8/tty’s, came up through TRS-80 with a side trip in AT&T 3b2 and SWTPC 68000 multiuser, and then moved into PCs, Xenix, Linux, etc.
I didn’t find anything in 1.0 that really struck me as all that out-of-the-mainstream.
FWIW.
>I didn’t find anything in 1.0 that really struck me as all that out-of-the-mainstream.
As I’d expect, with the possible exception of the Space Cadet keyboard. By confirming this, you partly answer Random832’s question about whether what’s in there was everyone’s common knowlege rather than just mine.
Doesn’t address the other side, though: what should be in there that isn’t?
Curiously, I think the only common trivium mentioned by multiple witnesses and not subsequently incorporated is the use of FS/US/GS/RS in various financial and point-of-sale protocols.
Or maybe it’s XMODEM and descendents. I might yet add something about those; I would have already if I didn’t judge they were micro culture only.
Just last week, I ran across a discussion of “dll hell” where one of the preconditions to the problem being as hard as it is *had been fixed in Multics*. It had almost completely been forgotten, even though the avoidance mechanism was heavily used as recently as in Solaris (by my team) and is present in Linux inside glibc.
I had the odd perspective of being on the Internet from 1987-1990 while running a mixed PC/Macintosh lab at a university. I had to deal with regular terminals, PCs, and Macs, while trying to get the Macs to work well with TTY emulators that talked to the Vax that connected us to the Internet (one megabit/second connection to the backbone in 1990!). It was interesting trying to translate terminology between the Mac users and the PC/minicomputer/mainframe guys.
I dropped a couple of entries on the Jargon File back then – trivial stuff, mostly. I still have a late-90s printout of it.
XMODEM got used in network stuff and other places where firmware uploads were done over RS-232. It was a simple enough protocol to implement that it worked well for that.
The space cadet keyboard was completely foreign to my experience. I still have never seen one in person. (Yu Hsiang Whole Fish? Really?!) That’s probably the only part of this that’s exclusively the domain of the Lispers.
TTL-level “RS-232” was common in the micro world, but was it common outside it?
>TTL-level “RS-232” was common in the micro world, but was it common outside it?
You know, I’m not even certain it was common in the micro world then. My observations are consistent with a history in which nobody shipped a device with a TTL serial interface until well after the heroic age of micros (1975-1981) was already past.
The first I personally heard of such devices was after 2000 – GPS engines using TTL serial for output. But I was less aware of hardware then, so it might have happened a lot sooner.
at http://www.pcables.com/
you will find text beginning
The Samsung Note 3 has an available RS232 Serial Port via USB! And we carry cables for it!
and
* Suitable for use on any Android platform with Android v3.2 and later versions.
* Provide general terminal UART utility; easily adaptable to a console function.
* Support CTS/RTS, DTR/DSR and XOFF/XON Flow controls.
* Support Baud from 300 to 921600.
* Save file and Send file functions support XModem, YModem and ZModem file transfer protocols.
AFAIK, non-Unix (e.g. DOS) people certainly did a lot of file transfer with x/y/z-modem.
Or let me put it to you this way: it was something I helped my mother with.
RS-232 vs. TTL levels? Still important, and for the same reason. You may not need to know, but if you do need to know, there is one thing you really need to know. RS-232 levels will easily fry almost any silicon which exposes a TTL-level interface, so don’t hook them together.
If you’re debugging by looking at things with a volt-meter, it’s helpful to know the idle state of a standard TTL-level UART signal is around 3.3V, while the idle state of the RS-232 level signal is negative — anywhere from -3 to -15V (not to exceed -25V in an open circuit).
So RS-232 transmitters, in addition to changing the voltage of the signal, also invert the signal — commonly, 3.3V becomes -12V and 0V becomes +12V. Naturally the receivers reverse the process.
FWIW, I had no fucking clue what a Space Cadet keyboard is.
> FWIW, I had no fucking clue what a Space Cadet keyboard is.
OTOH, in 1983 I wrote Z80 firmware for a protocol converter that allowed connection of an ASCII APL terminal to an IBM mainframe via 3270 SNA/SDLC or Bisync.
On the one hand, that’s so obscure it probably doesn’t belong in your doc. On the other hand, if the TIOBE index existed back then, I wouldn’t be surprised if APL outranked lisp, so the Space Cadet probably doesn’t belong there either.
>On the other hand, if the TIOBE index existed back then, I wouldn’t be surprised if APL outranked lisp,
My experience was that I started programming on APL and moved to Lisp. But even then I knew that was unusual and APL was an odd corner to be in. As in, odder than Lisp.
>so the Space Cadet probably doesn’t belong there either.
I am growing more doubtful about this, it is true.
@ Chuck
Yeah, USB Micro to 9-pin serial. I deal with those once a week or so when I’m called in to help with restaurant menus that live on flat-screen monitors. They take the place of a remote control, running from the controlling computer to a serial port on the monitor. I hate the damn things!
@David:
> …and is present in Linux inside glibc.
Unfortunately, as I have recently found to my great annoyance, it is still possible to find yourself in dependency hell on Linux.
Ubuntu’s release updater hung on an update from Trusty to Xenial before it got to the point of actually downloading packages, so I *thought* that nothing had been fine and I’d just have to do the update by a fresh install whenever I next had time/energy.
Turns out, it had updated sources.list with the Xenial repos before it hung. When I next tried pulling in updates, I ran into some issues that should have clued me off to something being badly wrong, but went ahead and updated, not knowing that the repos had been switched.
So now I have a Trusty/Xenial frankensystem, and pretty much can’t do any (un)installs without dpkg –force-foo
“My experience was that I started programming on APL and moved to Lisp”
This explains much.
>This explains much.
Oh? Do tell.
(Yes, C was actually my third major language.)
Oh, come on, Eric. Anyone who started out with APL and then went to Lisp next was bound to turn out to be seriously warped…although, granted, in a different way than the one Dijkstra attributed to learning BASIC.
— Stan Kelly-Bootle, The Devil’s DP Dictionary
APL is weird. Lisp is weird. The combination is weird squared.
>APL is weird. Lisp is weird. The combination is weird squared.
I wear my freak flag proudly.
Seriously, you know what starting out in those languages does? It makes you aware of the mathematical foundations of programming; it teaches you a regard for elegance. I believe I became a better C programmer than I would have otherwise because I was fluent in Lisp first.
I once tried to learn LISP, but lost patience and gave up on it.
You guys can have the leftover code I never used:
(((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((
(((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((
)))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))
))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))
Hope that helps.
Much of this is important.
Consider why we call a personal pocket computer a “phone”.
Or references to “tape”. Re-WIND and Fast Forward?
TV is another – Oh, how to do it. AM for the luminance, FM for audio 4.5MHz above. We need to add color – oh, 3.575545 crystals are now everywhere!
Two books that affected me. The second was a book on telephony in the Montrose Michigan museum that began with basic Math and continued with all known (Faraday) as of 1920. It contains a lot of electrical engineering and physics that have been forgotten, but you could recreate telephony from that one book. The Second is Audel’s Mathematics and Calculations for Mechanics which also goes encyclopedic with every measurment, mathematics, somewhat less electrical. An honorable mention is the CRC huge tome which has everything in chemistry and physics you would ever want to know.
There are those who want to know the minimum, and those who want to thoroughly understand. The latter need to know the historical problems needed to be solved.
@esr:
> You know, I’m not even certain [TTL-level asynchronous serial communication] was common in the micro world then.
Agreed. In the past, you had to buy a serial comm port card to do serial communications, and that card had the level translators on it. Later, when the motherboards absorbed the serial comm ports, they couldn’t very well introduce the incompatible change of signalling levels.
It’s very common now, but that’s because of five related things: (1) Moore’s Law has made the transistors that implement the UART free, so there’s a gratuitous UART on practically every embedded micro; (2) this UART is often brought out to a header for debugging purposes; (3) one of the things that has enabled Moore’s Law is the downward scaling of voltages, and that SOC with the UART cannot tolerate RS-232 level voltages, so the level translation to RS-232 levels is most assuredly not free in most systems. It’s done (if and when it’s done) in an external chip that requires board space and extra capacitors for the charge pump required to generate the negative voltage; (4) PCs don’t have serial ports on them any more anyway — you’re going to need a USB dongle to do serial; and (5) you’re not running the debug cable between the embedded micro and your PC hundreds of feet, so you don’t need the extra noise immunity that a large voltage swing gives you.
The cost of the level translator chip is not a problem when you’re building a system that touts a real serial port. It’s a huge problem when you’re building a $5.00 Raspberry Pi Zero, so you leave it off. That sort of thing becomes popular enough that you can now easily get a USB serial debug cable that leaves it off (and saves cost on that end as well).
>(3) one of the things that has enabled Moore’s Law is the downward scaling of voltages
Ahhh. Then it is very likely that TTL serial postdates the general shift from 5v to 3.3v logic. Do you remember when that happened?
Then it is very likely that TTL serial postdates the general shift from 5v to 3.3v logic
No. As someone who designed and wrote code for lots of embedded micros, TTL serial levels were everywhere there was serial. And then we endured the agony of adding the level converter chip and the extra voltage levels. At that time I’d never heard of any logic that ran at 3.3v. (Well, except for the exotic ECL stuff that ran at 2.3V but that doesn’t count and has been thankfully outmoded for decades.)
I was familiar with everything in the doc, but I’d never heard of the Space Cadet keyboard.
If you’re going to include Xmodem, shouldn’t Kermit also be in there?
Dunno about Unix, but it was widely used in VAX/VMS.
>If you’re going to include Xmodem, shouldn’t Kermit also be in there?
XMODEM isn’t in yet.
Kermit had some uptake in the Unix world (I remember it), but that was only very shortly before TCP/IP smashed everything else flat.
At least in my experience, Kermit was contemporaneous with XMODEM, but in the micro world, had almost zero uptake, because it was crankier and harder to deal with. It was mainly used to communicate with platforms that didn’t or couldn’t do XMODEM for some reason.
>At least in my experience, Kermit was contemporaneous with XMODEM, but in the micro world, had almost zero uptake
Kermit first shipped in ’81, XMODEM in ’77 (nothing political about this so I’m willing to trust Wikipedia). Yes, I do remember them serving rather different constitituencies.
Kermit seemed to be pretty popular with the DECUS folk.
I used Kermit as a VT100 emulator on an Apple IIe (1988 or so) to talk to our campus VAX – it was the most reliable emulator I could get at the time for that computer and the modem I was using. There were also some odd BBS packages that didn’t like the other emulators for the Apple.
@esr:
> Then it is very likely that TTL serial postdates the general shift from 5v to 3.3v logic.
I didn’t explain clearly. I don’t think that it was ever common practice to integrate the UART with the level shifter. But when more and more integration got stuffed into a single SOC, the UART level translator transistors were left out of that integration. Probably for two reasons: the one I mentioned (smaller geometries, thinner insulators; lower voltage tolerances), but also because it would have taken a couple of extra pins for a capacitor for the charge pump to produce the negative voltage. (There are a few SOCs with charge pumps to develop negative voltages these days, usually in order to be able to connect headphones without huge blocking capacitors.)
> Do you remember when that happened?
That’s more of a slow process than a shift at a particular time, and it’s ongoing. In fact, a lot of smartphone logic is now down at 1.8 or 1.2V, and you can still buy relatively new chips that work at 5V. FWIW, you could get CMOS logic that would operate at 3.3V in 1982 (and RTL logic that would operate at that voltage in the 1960s).
Interestingly, the way that bipolar TTL worked, you never really got 5V at the outputs, and the voltage would be reduced even more depending on the loading (number of inputs connected to the output). The minimum high input voltage was specified at 2.4V, so a 5V-tolerant 3.3V CMOS part will interoperate just fine with 5V TTL parts, and might have better noise immunity to boot.
I’ve thought some more about what bothered me about this. First is what seem to me to be factual inaccuracies, at least apparently inconsistent with the other information I found on the Space Cadet Keyboard and its predecessors and successors. These are things that maybe weren’t accurately known or remembered at the time, that didn’t disseminate well from their origins to the wider hacker community, but they’re still historical facts worth recording.
The other is not mentioning things like, for example, the VT220 ctrl-2345678 thing, because those are things that are still in effect today. I doubt I’m the only one to have accidentally killed a program with ctrl-4. I think things like that would do a lot to help the document connect for people who may be using Unix/Linux today but weren’t around for the earlier eras under discussion. That is, the target audience.
But I do understand the need to keep this document focused. Maybe what’s needed is a “behind/beyond what every hacker once knew” companion piece.
—-
The third thing that bothers me is that both your original blog post that led to this and the document asserts stuff about obscure ASCII control characters that you have not really substantiated the claim were common knowledge. I’m not sure I buy the premise that everyone knew, without having to look it up, that “ETB” was 0x17 or Ctrl-W. I’m not even sure if you’re trying to sell it, but that’s what it seems like the common knowledge filter means.
>The other is not mentioning things like, for example, the VT220 ctrl-2345678 thing, because those are things that are still in effect today.
But, I think, fail the common-knowledge-at-the-time filter. Possibly this was just me (and looking up the sales figures now I find it surprising) but to this day I think I’ve never seen a VT220 in the wild. Lots of VT52s and VT100s, though.
>I’m not sure I buy the premise that everyone knew, without having to look it up, that “ETB” was 0x17 or Ctrl-W.
That’s not one of the character names I could instantly map to binary, for sure. Maybe I need a way to mark the names I think were that well-known.
So… I recall working on a few lab devices that used TTL serial in about 1993-94 (specifically, a spectrograph motion control system and a seriously frightening programmable power supply… up to 7kV and 1A, would do both at once, would hold the current limit through an arc at whatever voltage it took). And, while I had heard of the Space Cadet keyboard (as an explanation of some of Emacs) back in, IIRC, the Southern Hemisphere summer of 1990-91, I have yet to see one in person (unless there’s one in the Computer History Museum in Mountain View I’ve forgotten about).
but to this day I think I’ve never seen a VT220 in the wild.
Really? When I was working at a large multinational in the mid 80s we had thousands of these. So did every other DEC shop I was acquainted with. They were a commodity item but very rugged and fairly affordable.
@esr:
I had a VT220 on my desk by 1985 IIRC.
@Andrew McGregor:
Ah, yes, the 7KV supply and spectrograph motion control system — indispensable tools in any hacker’s arsenal! :)
More seriously, though, I remember seeing, probably starting in the late 80s, a lot of equipment that had an optional serial port. Except that, even by then, the UART was cheaper than a parallel bus connector, so the UART was moved to the main board, and the $200 extra they charged you was for a tiny board with level shifters and perhaps a negative voltage power supply on it, and a much smaller and cheaper connector. “Value marketing” at its finest, same as that $2.00 coke to go with your $3.00 hamburger.
This, naturally, spawned a cottage industry of small RS-232 to TTL adapter boards, for much less money than the original manufacturer’s board. The appearance of those boards spawned the practice of bringing signals from “free” comm ports (often for debug) to cheap and ubiquitous 0.1″ headers for debugging — often not even populated, so they only cost a bit of PCB space.
This virtuous cycle accelerated considerably when USB became the dominant interface bus for PCs. For a start, the PC manufacturers got rid of the huge and expensive printer DB-25 connector, and most of the devices that used to use the (TTL-level) printer port for input wouldn’t work very well, or at all, anymore, because parallel printer USB device silicon was really sucky for upstream data.
Once every PC had USB ports, and fewer and fewer of them had UART ports, the market for USB-to-serial dongles took off, and (since the level shifters were never integrated into the USB-to-serial silicon) it was cheaper to make one of these that used TTL levels than RS232 levels, even when the TTL ones were shipping in smaller volumes than the kind of dongle that would attach to a real modem. The appearance of relatively cheap and functional USB-to-serial converters from Cypress, Prolific, TI, FTDI, and others meant that the old $20 RS232-to-TTL level shifter board became a $30 USB-to-TTL converter. Now that there is a significant hobbyist market that doesn’t even care about having the converter in a case, they’re yet another order of magnitude cheaper.
> But, I think, fail the common-knowledge-at-the-time filter
The post you replied to was an attempt to suggest, say, a companion document to relax that filter. And it’s not the VT220 that makes it interesting (it just seems to be the origin – the VT100 documentation does not mention this behavior), it’s the fact that modern terminal emulators do it.
Kermit had some uptake in the Unix world
I actually ran a DOS version of it to talk to the VAX at the MIT Plasma Fusion Center in 1987-88 (over a 2400 baud modem link).
I would argue that space-cadet keyboard is still an important example to have in the document, even if it shouldn’t be under “These were things every hacker knew.” It shows vividly how easily the computer interface could have been different. The keyboard is how we know a thing is a computer, and one of the most standardized (for a given region) bits. Now I miss the counter-factual history where 36-bit machines won (followed not too long ago by 72-bits), and I only found out that that was a thing when you posted 1.0!
Heh…I always wanted a Space Cadet Keyboard equivalent for my PC, just to intimidate the hell out of anyone else who might sit down in front of it. The best I could find was a Logitech G19, that has a dozen “macro” function keys on the left, three macro shift modes with programmable backlight colors, and a built-in mini LCD display.
(I also had a 15-button mouse, the Warmouse Meta, attached to that system at one point, for precisely the same reasons. However, the Warmouse turned out to be too fragile for heavy daily use, so I reverted to a more-usual mouse type.)
>Heh…I always wanted a Space Cadet Keyboard equivalent for my PC, just to intimidate the hell out of anyone else who might sit down in front of it.
What the world needs: space-cadet layout, USB interface, buckling-spring switches.
Hey, I can dream, can’t I?
When i was working a summer job in the IT Dept of my ~2K student college (Midwest USA) in the summer of 1990 we had ~100 VT220’s in the dead storage area, and hundreds of VT320 and VT420’s in active use across campus. I only saw one VT100 and it was hooked up to a odd piece of Physics Dept gear and not the network
I spent the summer servicing the serial lines for the VT’s and installing the first 10baseT lines on campus. A couple buildings were 10base2 and one had a Thicknet backbone to do vampire taps on. :)
I used a VT-220 for several years, first with an NCR Tower XP (that I got to replace the PC/AT. I wanted real Unix, and I got it.) and then some other stuff I was poking at. It didn’t get retired in favor of a VT-420 until the turn of the millennium. I still have the latter running.
> What the world needs: space-cadet layout, USB interface, buckling-spring switches.
Apparently there’s been some development work in the DIY keyboard building community (because of course that’s a thing that exists) to something called the “Hyper 7”, which takes the space cadet as an inspiration / starting point, adds a numeric keypad and a bunch of function keys. They tend to go for discrete keyswitches like Cherry MX though, since that’s much easier to DIY.
>the DIY keyboard building community (because of course that’s a thing that exists)
Yes. Yes, it is. I have an account at geekhack.org and check in there occasionally.
When I first introduced myself there, someone replied “Nice to see that ESR attends to details like keyboards.” Which led me to write Keyboards are not a detail!
I would certainly think a section on the file transfer protocols would be relevant. While they were part and parcel to Micros, especially in the BBS age, they were still the only game in town if you wanted to talk to two different machines, of any kind, over a serial device — and those two machines weren’t using UUCP to do it. Unix machines were not the only systems regularly sharing information.
X/Y/ZMODEM were very dominant in the Micro realm, but Kermit was everywhere, and it was very capable, and scriptable. Kermit is a story of its own — from the format (capable of sending binaries over 7 bit connections, among other things) to the software distribution model.
But the underlying point is that, outside of simply working for terminals, if you were moving any volume of data over a serial connection, these protocols were ubiquitous. UUCP had it’s own version, and mostly hid this process from the users (properly configured, UUCP was quite easy to use — with an emphasis on “properly configured”). Everywhere else, the protocols were more upfront and visible.
I’ve enjoyed reading this doc as it has developed, but I wonder if there’s a little “no true Scotsman” going on here. I learned to program on an IBM 360 in the 70’s, in Fortran, Algol, Lisp, and PL/1, and I’ve been a software engineer on Unix systems since the 80’s, in C, C++, Modula-2, and Python. Like most people I learned with, I called myself a hacker before the term shifted to criminality, and insisted on its correct meaning afterward. But most of the stuff you describe touched me only peripherally if at all.
I take no offense :-) because I know that lots of my compatriots did deal with that stuff, and wouldn’t have quibbled about it except that the definition of boundaries seems to be of interest to you.
>I’ve enjoyed reading this doc as it has developed, but I wonder if there’s a little “no true Scotsman” going on here.
It’s a fair question, and I have only real answer: I can only write about the hacker culture I know and lived through. The ex post fact justification for doing so is that the hacker-culture traditions I came out of, while they may have touched you only peripherally, are the root of today’s Linux and open source culture. That makes them of continuing interest.
The hardest thing about editing this document is that I have to be ruthless about what I leave out – which doesn’t just mean suppressing other people’ nostalgia for half a dozen technological dead ends and false starts in the heroic age of microcomputers, it means stuffing my own nostalgic impulses back in the box.
The upcoming 1.8 version includes a short section on heritage games – ADVENT, Zork, Rogue, Nethack, etc.. I dithered for a while before including it – wasn’t sure my fond memories weren’t causing me to overestimate the relevance of that lore today. Finally decided ‘for’ because they’re a significant story about the affordances of VDTs and pre-graphical UIs. But it wasn’t an easy call.
All this is by way of asking forgiveness if my filters seem a little too strict; the alternative is to be overwhelmed.