When you deal with firmware / hardware, you still have to know all that and far more. Like how to use a timer input capture to create a UART.
Hardware was simpler back then too – but there are very simple micros that in cost sensitive (or power usage) also need to be understood.
> VT – In the days of printing terminals this often caused them to scroll down half a page
To my understanding, this actually worked in much the same way as a horizontal tab (the ECMA-48 standard makes it clear this is the intent of the standardized character), in that it would move to the next increment of a specific number of lines. At one point I saw a statement that it was specifically to the next multiple of six lines, which was supposedly the size of a pair of bars on green-bar paper.
Some printing terminals and some CRT terminals use it as the command to move up one line.
> SO (Shift Out), SI (Shift In) Rarely used (and never natively on Unix) as escapes to and from an alternate character set.
I’m not quite sure what you mean by “natively on Unix”, since they are supported by the VT100 and many terminals to this day that emulate it (though there’s something of a movement to “these or UTF8, pick one”), and used by curses for box drawing and other miscellaneous special symbols.
> Sometimes used as a packet-framing character in binary protocols. That is, a packet starts with a DLE, ends with a DLE, and if one of the interior data bytes matches DLE it is doubled.
I once saw a proposed extension to the IRC CTCP protocol that used it in the same manner as backslash – i.e. following it by 0, n, r, or itself to embed null, carriage return, line feed within a message.
Wikipedia claims it was used as “DLE STX” and “DLE ETX” as the packet start/end in some unspecified serial protocols.
Field notes from someone who works with crazy point-of-sale hardware and legacy (or modern wrappers, because nobody dares touch the base systems) payment processors:
FS and sometimes GS/RS and the like are pretty common in binary blocks built for payment processing backends (probably because in their core there’s stuff going back to punchcards on mainframes).
(My response to this is usuall “oh, for God’s sake, would it kill them to at least pretend it’s 2017 and they have an API?”)
You still see RS232 in some uses in restaurants (e.g.) because they’re electrically noisy places and RS232 supports long cable runs and noise tolerance better than USB or Ethernet.
(Obviously even more so in industrial embedded stuff, but I’m limiting the content to “stuff people do today you might actually see and that uses commodity retail hardware”.)
When you talk about ASCII, for ACK and NAK, I’d have noted that they were used as single-byte affirmative or negative responses in a few different protocols, most notably XMODEM and its variants. If you weren’t in the unix circles in the late 80s/early 90s, but were hacking DOS boxes, you used these extensively. In my circles, it was very common to respond to queries with just ACK/NAK, and everyone understood you. I remember sometime in the late 90s being disturbed that the younger guys had no idea what I meant, and associated ACK with Bill the Cat, not protocol answers.
> I remember sometime in the late 90s being disturbed that the younger guys had no idea what I meant, and associated ACK with Bill the Cat, not protocol answers.
Heck, I got upset the same way. So it wasn’t just DOS people…
This & the previous discussion had me thinking about how much closer everything used to be tied to physical reality – the physical keyboard, the physical pin-out of the serial port connection. It amazes me to think how many layers of indirection & very abstracted we are now, even just w/ this type of (still physical) peripheral equipment; let alone virtual machines that are now old hat. It also reminded me of the TED talk “No one in the world knows how to build a computer mouse.” Even in the hardcore hacker community where we do share a lot of common knowledge & culture, we’re becoming more & more specialized, and there’s less & less that you can count on “every” hacker knowing.
On CR-LF combo: I remember reading about how the CR tended to take longer than the LF to actually run on printers, so it was sent first to give it that fraction of a second more time, while the LF was still being sent over the wire. Some older printer drivers would send LF-CR, until someone noticed it slowed down the overall print time a measurable amount.
Also, in today’s *nix terminals, CR can be used w/out LF to overwrite the same line. e.g. echo -n “Hello World!” ; sleep 1 ; echo -e “\rGood bye World!”
Specific thoughts to your doc:
“CR (Carriage Return) Still does what it says on the tin.” For the target audience (younger hackers), it may not be clear what it says on the tin. What is this carriage that’s being returned?
Off-by-1: under the ASCII table “code points 0-32” and again later “mapping it to the 0..32 rqange” should be 0-31 (and range is misspelled).
Sigivald: “(Obviously even more so in industrial embedded stuff, but I’m limiting the content to “stuff people do today you might actually see and that uses commodity retail hardware”.)”
Some, but RS-485, either point to point or multidrop (which it supports well), is far more common as a serial protocol – though Ethernet is finally supplanting it in complex control systems. Still, speaking MODBUS over RS-485 will get you talking with an amazing array of industrial sensors and control systems.
> before that displays were monochromatic, typically with white characters on a green screen.
Not sure what you are referring to here. I’ve seen green on black and it’s inverse with the slow phosphors, and later there was amber.
Might be worth noting that there were multiple ACSII versions, both standardized and unstandardized and every so often you’d find old terminal equipment that uses some bastard mixture.
> BEL (Bell) … but is generally not supported on software terminal emulators.
Most of the emulators I see in the wild respond to BEL visually (e.g. flash the window or title bar) rather than audibly by default. The traditional “make a bellish noise” behavior is often still available, but needs to be manually enabled–and then promptly disabled, because everyone who has done a nontrivial amount of work on a terminal with audible bell enabled has endured the experience of somehow accidentally triggering an embarrassingly long sequence of BEL characters at some point in their lives.
A less common behavior upon receipt of BEL is raising the window, possibly in addition to flashing or noise, or performing some more modern notification process (like the combination of overlay text, sound, and vibration found on smartphones).
Completely mute terminal emulators are somewhere in the top four most common cases, but I’m not sure where.
IDEs for embedded devices with “serial output” windows are often far from complete terminal emulators (they wouldn’t be able to sustain a usable vi session, for example), and will more likely print the BEL as some indecipherable glyph instead of treating it as a control character.
I don’t know if you want to mention the nightmare of parallel vs. crossover cables? One of the reasons we had so many adapters laying around…
In addition to SO and SI isn’t ^H still used by curses libraries? Like scp and curl progress bars?
Also, remember when any time you spewed binary data to your terminal and the bell would ring once out of every 256 chars? Good times, good times…
Finally, as I alluded in the prior thread, you might want to mention how “\r\n” confusion still crops up to this day. Some bits of software try to hide it from you while others don’t. So it can still bite you in strange ways. Windows notepad still formats unix files to one big long line. And I seem to remember an obscure VxWorks bug that stemmed from someone checking in a DOS ending file. Can’t recall the details anymore though.
You’re telling me that I don’t actually need that bin of cables, connectors, and adapters that’s sitting in my garage?
Delightful document. Thanks for creating it. I’m not even a hacker, just a hobbyist, but still knew most of that stuff because of my age. The things we used to have to go through just to play computer games… (I first learned Unix just so I could play moria on a SPARCstation)
Regarding BEL, gnome-terminal supports it, but it depends on the configuration of your DE and audio stack (if playing the bell through your sound chipset), and ISTR it also depends on Compiz configuration as well if you’re running that (though I’ve forgotten what needs to be configured, if anything in Compiz actually needs to be configured, and where that option is). If you aren’t getting anywhere with playing it through your main sound chipset, you can get a gratifying squarewave beep from the PC speaker, depending on the presence of the PC speaker kernel module, module blacklists, presence of PC speaker hardware, presence of firmware emulating the PC speaker with the main audio chipset, etc.
Both paths depend on the phase of the moon, the primality of the Saros number for the last lunar eclipse, the remainder from dividing the Saros number of the next solar eclipse by 17, and the sum of the mean anomaly of Phobos and the true anomaly of Callisto.
>The Control modifier on your keyboard basically clears the top five bits of whatever character you type, mapping it to the 0..32 range. So, for example, Ctrl-SPACE, Ctrl-@, and Ctrl-` all mean the same thing: NUL.
Oh, man — talk about a trip down my memory lane. I cut my first serious teeth on DEC-20s & Primes followed by CMS and older IBM mainframe operating systems (after grade school teletype machines) until the world changed. Stayed in the IT business until recent retirement.
A lot of the ASCII control characters were used by the ASCII dialect of IBM’s bisync protocol. A typical 3270 text message was SYN SYN SOH header_byte+ STX payload_byte+ ETX parity pad. There are other protocol messages that use other control characters. It’s been a *long* time since I had to code a device driver for this (~1975). Bisync was obsoleted by SDLC. Wikipedia has a good article on bisync called Binary_Synchronous_Communications.
RS-232, sentence beginning “This, in particular” has unmatched close parens.
“It does, however, retain one advantage over USB and Ethernet”–and also the advantage of raw simplicity. The flip side of “can’t tell quiet from missing” is that an output device (e.g., a multimeter) can just spit data out a serial port with no configuration or cooperation from the nonexistent receiver. You can hook up a computer or even an old TTY midstream and read the output without the device’s ever needing to know about it.
UUCP section ends in comma.
“white characters on a green screen”–do you have a picture of this? I’ve only ever seen green, amber, or white on black.
period after “vector graphics”
“general-purpse”
“could assume the character to have”–terminal?
BEL has been supported on every terminal emulator I’ve encountered. Modern ones usually have configurable behavior, but Konsole (as of the ancient version I stubbornly use) still has audio playback as default.
In VT, the word “up” is in blue but isn’t a link–weird stylesheet?
FF still works as advertised on line printers, which hang around for carbon forms and some industrial environments.
TCP handshake should probably be “SYN SYN-ACK”
Note that Escape is “^[“? It still prints occasionally, and it can be useful to know they’re equivalent.
>“white characters on a green screen”–do you have a picture of this? I’ve only ever seen green, amber, or white on black.
I’m going to take this out. I was thinking of the Wyse 50 and 75, which I believe were probably the most widely distributed type (I’ve seen more of them than I’ve seen VT-100s, and I think I still have some 75s in my basement) but there’s a perception problem here – I think what reads to a lot of you as black looks to me like very dark green.
I’ve always seen certain kinds of CRTs as just faintly green too, so you’re not alone.
I’ve never seen one that produced white lettering though, they all did just green. The ones that did white lettering were always solidly black when not active.
>>“CR (Carriage Return) Still does what it says on the tin.” For the target audience (younger hackers), it may not be clear what it says on the tin. What is this carriage that’s being returned?
[In the current parlance]
^
|
THIS!!!
I’m no spring chicken, but even this one caught me a little off guard. (Obviously, “on the tin” means what it says on the can of dog food you are about to eat.)
Like a floppy-disk icon equating to “Save” or a Ma Bell handset icon equating to making a phone call, cultural commonality didn’t quietly evaporate–it fell off a fucking cliff!
Not to be an old fuddy-duddy, but if there is ANY chance that this epistle can strike bone with the current generation of “hackers”, one might really need to distill the abbreviated, semantic, and metaphorical logic structures down to easily-digestible Millennial bytecode, if there is such a thing.
>> I remember sometime in the late 90s being disturbed that the younger guys had no idea what I meant, and associated ACK with Bill the Cat, not protocol answers.
> Heck, I got upset the same way. So it wasn’t just DOS people…
Well, if it’ll make you feel better, I can tell you that ACK and NAK as affirmative/negative responses are still quite common at Google. I do it.
> Modem speeds increased from 110 bits per second back at the beginning of interactive computing to 56 kilobits per second just before the technology was effectively wiped out by wide-area Internet around the end of the 1990s, [Emphasis added]
Hm? That’s not quite how I remember it. ISTR using a 56k modem to get onto the Internet–well into the 2000s. I didn’t get a DSL until ~2004. Then again, 1999-2000 is about when I first started seeing phone companies advertising DSLs… (Prior to that, if you wanted megabit Internet in the 90s, you needed an expensive T1 line.)
> The PDP-7’s successor as a workhorse Unix machine, the PDP-11, had 16-bit words – but the damage had been done. C wasn’t adjusted to prefer hex, and the surprising interpretation of leading 0 wasn’t removed.
I thought C didn’t appear until after the transition to the PDP-11. (Around 4th/5th edition PDP-11 Unix, I believe. I’m not entirely sure; this was all before my time, so I only know what I know thirdhand.) I suspect that the convention predates even that–probably going back to the earliest Unix assemblers for the PDP-7. Old habits die hard, I suppose… (As an aside, there is still one good use for octal, though: Unix file modes. The bits are grouped in threes, which is nicely represented in octal. Imagine how they’d look in hex!)
>Hm? That’s not quite how I remember it. ISTR using a 56k modem to get onto the Internet–well into the 2000s. I didn’t get a DSL until ~2004. Then again, 1999-2000 is about when I first started seeing phone companies advertising DSLs…
Yeah, we could argue the fine points of the transition timing all day. And it wouldn’t matter a bit. There was enough variability in DSL deployment that you have to give “just before” a couple years of slack. Also, we could wrangle over whether “wiped out” means “vanished” or “development money ran the hell away because everybody could see what was coming”.
>I thought C didn’t appear until after the transition to the PDP-11.
I’ve actually forgotten the details here. I think the way it went is that octal syntax got embedded in the B interpreter and then rapidly inherited by C.
> confusingly, DB-25 came to be used for printer parallel ports
You know how to tell ’em apart, right? Serial ports are male: the socket on the hardware has the pins. Parallel ports are female: the socket has the holes. For the cables, of course, you reverse that.
> After 1978 there was an ANSI standard for terminal control codes, based on the DEC VT-100. By the early 1990s ANSI conformance was close to universal in VDTs, which is why that’s what your software terminal emulator does.
Ah, good old ANSI.SYS… (Eh, you wouldn’t know, Eric. You never ran MS-DOS–or if you did, it was for very short periods of time while cursing its very existence and plotting to replace it with something actually serious. :)
> Windows, other non-Unix operating systems, and some Internet protocols (such as SMTP) tend to use CR-LF as a line terminator, rather than bare LF.
Apple stuff, on the other hand, tended to use a bare CR as a line terminator. It’s not just pre-OS X Macs, either; all Apple OSes did this (prior to Mac OS X, of course). I suspect this goes back to the Apple II–the [Return] key generated a CR there. (And now you know why Apple’s keyboards all have a [Return] key instead of an [Enter] key.)
> and XON (DC1) was used as a requast
Typo “request”. (You weren’t kidding when you said you were a poor typist! :)
> As Ctrl-S and Ctrl-Q these were implemented in the Unix terminal driver and long outlived their origin in the Model 33 Teletype.
It wasn’t just Unix. The Apple II firmware supported this, too. (Why is this relevant? Well, there was once a time when Apple was a hacker’s company, but that’s another story.) I wonder how many other systems supported this…
> However DOS and Windows use Ctrl-Z (SUB) as an end-of-file character; this is unrelated to its ASCII meaning.
This actually goes back, like a lot of things in MS-DOS (and therefore, Windows), to CP/M. Since CP/M could only allocate whole disk blocks, there needed to be some way to mark the end of the file’s content, and ^Z was it. (Why ‘Z’? Probably because it’s the last letter of the alphabet.) Naturally, MS-DOS, which was originally built to be ~95% backwards compatible with CP/M, inherited this convention.
> If you have a Meta or Alt key, and it’s not being diverted to do something else, it adds 128 to the ASCII keycode for whatever it’s modifying. How that will be interpreted depends on whether you’re set up to use an extended character set, and which one it is.
Well, that explains why Mac/IIGS [Option] gets mapped to [Alt]. :)
I assume that you mean 7-bit ASCII here, as 8-bit ASCII includes bit sequences that are invalid UTF-8.
8-bit character sets aren’t ASCII. They’re often supersets of ASCII, but they’re not the same. :)
Unicode goes one step beyond: the first 256 codepoints are Latin-1, which itself is of course a superset of ASCII. However, Latin-1 documents (ones that aren’t simultaneously just ASCII) cannot be UTF-8. All codepoints beyond 007F must be encoded specially in UTF-8; two bytes are required for 0080 through 07FF.
and i still have the cables and at lease one computer with a working db-9 serial port, just in case.
uucp. the last few i setup was almost 20 years ago for a store and forward mail system. i think i could still do it, except i think all my modems have gone to hardware heaven.
One area where RS-232 (and RS-422) communications is still widely used in machine control. I work for a company developing CAD/CAM software for plasma/waterjet metal cutting machine. I still have a bag with serial cable test, gender benders, db-25 to db 9 adapters, etc, etc.
However since 2000, the machine controllers are mostly industrial PCs running various flavors of embedded windows. Their software open CNC files over a Ethernet network. Right now most can also download CNC files over a RS-232 link but since 2010 the number of Ethernet only models is rising.
My company is the odd duck where we always controlled the machine directly with a workstation or PC. In the mid 80s it was a HP 300 series workstation with a GPIO board running stepper motors. Now it is a Dell PC with a specialized PCI motion control board or talking to a specialized motion control box via ethernet. Functionally it doesn’t make a different as the drives present both setup in the same way.
Any in the embedded world of machine control, you have to know pretty much everything in ESR’s list. We are dealing with resource constrained device, along with hardware designed to last for decades designed decades ago.
One factor is that while the Ardinuo and Raspberry devices are great for hobbyist right now change is too rapid to use for a production machine. It hard to get the same model from the same vendor for more than a year. Hence the prevalence of decades old design in the control industry.
Looking through the terminfo database, it looks like VT/^K for line-up is mainly a “non-ANSI VDT” thing rather than printing terminals – the ADM-3a and Wyse 60 being notable examples.
On the subject of things that do what they say on the tin:
Backspace: Some mention of overstriking for accents and underline on printing terminals might be useful (and nroff still outputs this for bold and underline, with less taking care of translating it to terminal-specific bold and underline codes)
Tab: Of course, everyone knows what a “tab” does, there’s a key on the keyboard that does more or less the same thing in text editors and word processors. Might be worthwhile to mention that this comes from “tabulation” and was originally intended for making tables – which also explains why terminals [and modern word processors] have arbitrarily configurable tab stops, and every eighth character or half inch is just the default.
Bell: I don’t think I’ve ever actually used a terminal emulator that doesn’t use an audible sound by default, so much so that I suspect that the people who say it is uncommon are being more influenced by sound configuration problems (or they have their system on mute and it perhaps additionally uses a visual display) than actual design choices of the terminal apps.
Carriage return: “so this needs explanation: “carriage return” is the operation of moving your print head or cursor to the left margin” Or, when there was an actual carriage, moving the paper to the right so as to place the left margin under the fixed “print head”. Did any printing terminals do this, or is this mainly a feature of conventional typewriters?
Random832, you are succumbing to a temptation I too am having to fight – throwing in stuff that, while interesting, was not common knowledge.
>Did any printing terminals do this, or is this mainly a feature of conventional typewriters?
The latter. I never saw a printing terminal on which the carriage moved rather than the print head. It is worth remembering that the Selectric worked like this too – the typeball moved, not the carriage. I am almost sure that the moving carriage was peculiar not just to typewriters but to non-electric ones (which could be what you meant by “conventional”).
Update: I now think this not only didn’t but could not have happened. If you tried to build a moving-carriage device with the duty cycle of the printers from which these printing terminals were derived, it would shake itself apart.
The typewriter I used for school reports as a kid was electric and had a moving carriage. There was a whole period where they basically just put solenoids and switches on the manual designs. To get the print head small enough that it makes sense to move the head and not the carriage needs a daisy wheel or type ball, or some other striking method that’s more compact than the old “two characters per striker” used for manual typewriters.
Some of the early teletypes did move the paper, but I rather suspect they were probably never attached to a computer.
As a young’un(I’m 31), and someone whose coding skill consists of farting around in C# to make baby applications once every couple years, I found this a rather interesting historical document, though after years of reading ESR, I’ve learned to gloss over Unix-speak any time it gets beyond my ability to parse. I’m sure glad I don’t need to know it all, though.
Might be worthwhile to mention that [“tab”] comes from “tabulation” and was originally intended for making tables – which also explains why terminals [and modern word processors] have arbitrarily configurable tab stops, and every eighth character or half inch is just the default.
Tab’s role in making tables also explains why “tab” has informally become shorthand for “move to the next field in a web form”.
Other errata:
“UUCP stands for Unix to Unix Copy program.” Should probably capitalize “program”.
“tham” -> “them”
I wish I knew enough to do semantic checking on any of this. Downside of being a child of the 1970s.
I will at least say that this article sounds like the title doesn’t quite fit. This is “Things Every Hacker Once Knew WRT ASCII and A Few Related Artifacts”; TEHOK sounds like it could be a series of articles you could write, applying not just to ASCII, RS-232, Unix, DEC, etc., but also early Internet customs, certain hardware commonalia (5.25″ vs. 3.5″ vs. 8″, tape drives, etc.), programming practice (including old VCSes like SCCS), and so on.
A lot of this starts to overlap with The Jargon File, in fact.
Nearly all typewriters except the Selectric, manual and electric both, used moving carriages. Even IBM’s pre-Selectric electrics did that. That was what made the Selectric so special.
Printing terminals/output printers couldn’t use moving carriages for another reason: either you have to lug that heavy roll or stack of formfeed paper back and forth with the carriage, or else put up with the feeding issues not doing so would cause.
I had a post on the history I’ve read on octal in C and Unix that doesn’t seem to have taken. Did it get caught in the spam filter, or did it disappear in transit?
>I had a post on the history I’ve read on octal in C and Unix that doesn’t seem to have taken. Did it get caught in the spam filter, or did it disappear in transit?
I’m sad that I’m adding to this… but “A Random Googler on 2017-01-27 at 03:54:08 said”
>> However DOS and Windows use Ctrl-Z (SUB) as an end-of-file character; this is unrelated to its ASCII meaning.
>This actually goes back, like a lot of things in MS-DOS (and therefore, Windows), to CP/M. >Since CP/M could only allocate whole disk blocks, there needed to be some way to mark the >end of the file’s content, and ^Z was it. (Why ‘Z’? Probably because it’s the last letter of the >alphabet.) Naturally, MS-DOS, which was originally built to be ~95% backwards compatible >with CP/M, inherited this convention.
CP/M took a bunch of stuff from DEC’s operating systems (especially RT-11). ^Z meaning end of file was one of those. Really, I found CP/M pretty comfortable after using the PDP-11. The fact that MS-Dos has ‘\’ for directory separators because ‘/’ was the introducer to command switches stems from that tangled history also.
Sigh, I still have *two* 300 baud “data couplers” (modems) – one is a box with two circular cutouts embedded in rubber padding in which you put your telephone handset. One cutout has a microphone/pickup and the other cutout has a speaker.
The other data coupler is two rubber cups on wires that connect to the (surprisingly small) modem box. I used the latter when away on trips. Not every client had a modem, though everyone had phones :-). Plug the other end into the VT-52 or -102 or whatever they offered me, then away I went.
> The PDP-7’s successor as a workhorse Unix machine, the PDP-11, had 16-bit words – but the damage had been done. C wasn’t adjusted to prefer hex, and the surprising interpretation of leading 0 wasn’t removed.
In my original post that got eaten, I said “I wasn’t born yet at the time, but from what I’ve read…”, but now that I’ve got more time to work with, I’m tracking down “what I’ve read” to have a more solid source, which turns out to be, for my first comment, Dennis Ritchie’s “Early Unix History and Evolution” at https://www.bell-labs.com/usr/dmr/www/hist.html .
As I read it, I don’t think the PDP-7 was never really a “Unix workhorse”. It was the environment that they conceived and first developed Unix on, but I don’t get the impression from EUHaE that more than one PDP-7 ever ran Unix, or that any production or externally distributed version of Unix ever ran on the PDP-7, or that the PDP-7 was any more than a stopgap until they could get somebody to flip them a couple quarters (+/- a few orders of magnitude) to buy a real computer. I don’t even really get the impression that PDP-7 Unix, or early PDP-11 Unix was a very recognizable Unix by modern standards (no HLL kernel, no pipes, etc.) and dmr even says of the kernel rewrite in C “It was at this point that the system assumed its modern form”.
My second comment is sourced from DEC manuals and front panels:
I believe that the usage of octal in C and Unix on the PDP-11 was more a matter of DEC carrying it over from their other lines with mulitiple-of-three word sizes when they designed and documented the PDP-11 than it was of Thompson and Ritchie carrying over the use of octal in PDP-7 Unix onto an architecture that would have been better suited by hexadecimal.
With the exception of branches, which are unusual, and condition code operators, which have six one-bit fields, PDP-11 instruction words consist of fields that are a multiple of three bits long (with the leftover bit added to the opcode field, making it a multiple of three, plus one), octal notation is used throughout the DEC documentation for the PDP-11, and the front panel switches are colored in groups of three.
Thompson and Ritchie might be said to have carried over the use of octal from PDP-7 Unix to PDP-11 Unix, but only in the trivial sense that they continued using it. The actual carry-over (in terms of using octal because of tradition rather than because it was the most logical choice) happened at a lower level (the ISA design of the PDP-11), although I’ll give DEC the out that, from toy instruction sets I’ve drawn up on scratch paper in my free time, it’s really *hard* to design a really satisfying 16-bit instruction set that works well with hexadecimal. The PDP-11 *is* really satisfying except for being a @#$%!!! octal architecture on a non-octal word width.
Early electric type writers and the Flexowriter that was the original console for computers that had consoles moved the carriage and had standard typewriter type typing rather than a print head.
> from toy instruction sets I’ve drawn up on scratch paper in my free time, it’s really *hard* to design a really satisfying 16-bit instruction set that works well with hexadecimal.
The MSP430 ISA is somewhat similar to the PDP-11, but contains almost no three-bit fields (see chapter 3 of http://www.ti.com/lit/pdf/slau049 ). Of course, that’s easier with 16 registers …
One thing I’ll say about “carriage return” is that its may not actually be entirely unknown to younger hacker(oid)s: My first typing classes in kindergarten (early 90s) were on typewriters, and one of the DOS games I played as a child had things like “Press CR to continue” all over the place. Asking my dad what that meant was where I learned the term “carriage return”. So I’d say that anybody born in the late 80’s or earlier has at least a fighting chance of having learned the term before they were exposed to ASCII.
> The following table describes ASCII-1965, the version in use today. It used to be common knowledge that the original 1963 ASCII had been sightly different (lacking tilde and vertical bar) but that version went completely extinct after ASCII-1965 was promulgated.
Largely true of course, but a few quirks in the PETSCII character set used in some early micros, namely the ? (up arrow) and ? (left arrow) characters, can in fact be traced to ASCII 1963. The ZX Spectrum set shared the ? character, but not the ?. (Of course, these early character sets had plenty of _other_ quirks besides!)
That “very different” parallel printer connector was known as a Centronics connector (after its maker), specifically the 36-pin version. The 50-pin version would become familiar to a later generation as the SCSI-1 connector (inherited from SASI, Shugart Associates System Interface; Shugart himself later founded Seagate).
The serial interfaces were even more complex than you mention. RS-232 used odd, by today’s standards, signal levels. Mark (1) was -3 to -15V, space (0) was +3 to +15V. I usually saw +/- 12V used before the differential standards became popular. The Mac introduced to the microcomputer world the differential RS-422 standard; this used a 5V difference between +/- lines to signal. USUALLY… USUALLY… you could make this work with an RS-232 device by tying Tx- to Rx, Rx- to TX, letting Tx+ float, and grounding Rx+. Sometimes this wouldn’t work or would work only in one direction. And if you worked with components rather than machines, there were a lot of things claiming “RS-232” which actually used “logic level” RS-232, where 0V was 0 and +5V (later +3V or thereabouts) was 1.
And that’s without getting into DCE (Data Communications Equipment) vs DTE (Data Terminal Equipment), where the signals were called the same things but Tx on a DCE was an INPUT whereas Tx on a DTE was an output (as one would expect), and so on for all the pins. This is reminding me how much I don’t miss that mess. The advantage to this was that to connect a DCE to a DTE just required a straight-through ribbon cable. Anyway, this ended up leaving 4 different configurations (not counting odd ones or the Mac), all of which were used — DB9 female DCE, DB9 male DCE, DB25 female DCE, and DB9 male DCE. Which meant an essential thing for hackers to have were sufficient gender changers, 259 adapters, and null modem cables to make anything talk to anything else.
Oops, make that 8 configurations — all the ones I mentioned plus the same ones in DTE. Modems being DCE and computers being DTE was the rule but sadly not without exceptions.
That was a nice trip down memory lane. It reminds me of a midnight lecture Steve Russell gave to a few of us around 1973. That got all the way down into how stop bits tied into the whirring machinery in old TTY’s.
Today, in the embedded world, RS-232 is still around. I have long done firmware for audio equipment. These use 8 bit MCU’s, and RS-232 comms, maybe front-ended by a telnet to RS-232 bridge, or a USB bridge. But, down in the guts, the same old stuff, right down to character-at-a-time interrupt handlers.
Right on time for this article, I found a GitHub repo for ITS. Yes, PDP-10 ITS, the OS of MIT hackerdom before Unix came along and ate everything. Now young hackers (even I count as “young” for this purpose) can boot — and play with and hack — the OS where Stallman got his start. (Do I see TECO Emacs in this bundle? Why yes, I believe I do!)
C got it’s octal number syntax from B which in turn got it from BCPL. The question is did BCPL get it from CPL? I don’t know anything about CPL except that BCPL is its parent. ALGOL 60, CPL’s predecessor, doesn’t have octal numbers.
Bliss, another system programming language developed around the same time, also has octal numbers, but uses ‘#’ as a prefix.
Having a way to write constants in some power-of-two form is pretty useful for a systems programming language, so it’s not surprising that BCPL and Bliss have it.
@Jeff:
Back when I was first coming into contact with hacker culture in late 2009/early 2010, I thought “gee, it would be fun to port ITS to a HLL and more modern hardware platform, just for laughs”.
@Sam P: are you sure about BCPL’s octal number syntax being leading zero? According to Martin Richards’ book (which should be the definitive reference), the prefix for an octal constant was # and for a hex constant was #X. I can’t remember seeing the leading zero used anywhere other than in C.
I would like to point out that SOH charactors are still in use as a field delimiters for the FIX (Financial Information eXchange) protocol.
This 90s vintage protocol was designed with modems in mind, for sending securities prices and orders. It is still used for derivatives trading, although these days it mostly gets sent over tcp/ip.
It’s a godawful mess of a protocol due to the fact that no one is in charge and it has metastasized new features semi-randomly.
James M: Never used BCPL, was relying on an old online BCPL Reference Manual, but I misread it. Though what is in the manual doesn’t make much sense, since it uses a prefix of ‘8’.
Ah, now I’ve found Martin Richard’s site with a much newer language guide, and as you say, it is ‘#’ or ‘#o’ for octal and ‘#x’ for hexadecimal.
> It had three symbols per keycap, no fewer than seven shift keys, and could generate over 8000 distinct 9-bit characters
I don’t grok this at all. With a 9-bit symbol table, you get 2^9=512 possible 9-bit characters. In order to be able to represent over 8000 distinct characters, you either need 13 bits or something involving “Code Page Shift” symbols to redefine the meaning of some or all of the others.
Maybe a UTF-9 thing where 0xxxxxxxx defines 256 codes, 101xxxxxx,11xxxxxxx gives you 8192 more, (and room to grow 1001xxxxx,11xxxxxxx,11xxxxxxx, etc.) but those are arguably 18-bit characters.
>I don’t grok this at all. With a 9-bit symbol table, you get 2^9=512 possible 9-bit characters. In order to be able to represent over 8000 distinct characters, you either need 13 bits or something involving “Code Page Shift” symbols to redefine the meaning of some or all of the others.
You’re right. Because I don’t know the details, I’ve weaseled out by saying “8000 glyphs”. I conjecture that some kind of code paging was involved.
I actually had my hands on one of these at MIT in…I think…1984, but didn’t know what questions to ask then.
With 7 shift keys, you could in theory bust the nine-bit limit with just two non-modifier keys. Dang. I wonder if how it actually worked is documented anywhere?
I’m not sure if the 8000 glyphs is supportable. The Wikipedia page says “over 8,000 different characters”, but doesn’t say these were graphical characters, or that they were representable in any 8- or 9-bit character set with or without “code page shift”.
The 8000 claim dates back (via an early Wikipedia import of FOLDOC) to the Jargon File version 1.5.0, but the reasoning it provides (five glyphs per key with shift/front/top, four other modifier keys) only supports ~4000. Doing the math myself I got anywhere from that at the low end to 10,624, depending on what keys were allowed, what modifiers were allowed [were top and front allowed in combination with each other, and top in combination with shift? They have to be to break 8000, but the entry makes no suggesting this combination was meaningful]
Also, since “control” just seems to have been a modifier bit, I doubt that keyboard provided any way to generate arbitrary ASCII control characters, which is otherwise a running theme in this document.
This may be useful https://deskthority.net/wiki/Symbolics (page 279 mentioned here is physical page 294 of the linked PDF, and defines an 8-bit character set (or possibly the bottom half of a nine-bit one), with extra graphical symbols at (octal) 000-037, and special characters (some of which seem to be in the same relative position as the ASCII control characters with the same meaning) at 200 onward. No thousands of glyphs here.
> With 7 shift keys, you could in theory bust the nine-bit limit with just two non-modifier keys. Dang. I wonder if how it actually worked is documented anywhere?
Like I said, I’m almost certain I’ve read somewhere that the modifier keys set bits *outside* the character representation, in a *word* that was sent to the system.
>The 8000 claim dates back (via an early Wikipedia import of FOLDOC) to the Jargon File version 1.5.0
That’s pretty solid, then. That version was reviewed by Guy Steele, who’d used one.
>Also, since “control” just seems to have been a modifier bit, I doubt that keyboard provided any way to generate arbitrary ASCII control characters
I would be astonished if this were true. We can tell some things about this keyboard from its influence on the design of Emacs. I think it’s safe to assume that the Control key was the same modifier it us today.
> For the longest stable period of modem technology after 1970, about 1984 to 1991, typical speed was 9600bps.
Even after that, 9600 bps, being the top speed the fax manufacturers standardized upon in the late 80s, was the practical standard for long-distance data transmission. If your phone lines couldn’t handle 9600 bps, you’d complain to the local telco, and they’d fix the line. Anything above that (14.4, 28,8, … 56K) was gravy.
Re. Bill the Cat, it may be sobering to realize the latest generation barely knows what Bloom County was, and probably associates ACK with Mars Attacks instead.
> Very old keyboards used to do Shift just by toggling the 32 bit; this is why the relationship between small and capital letters in ASCII is so regular. The ASR-33 even let you generate some punctuation characters it didn’t have keycaps for by shifting capital letters; thus, for example, Shift-K (0x4B) became a [ (0x5B).
Toggling the “32” bit (0x20) would turn k=0x4B to K=0x6B, so you must mean something else here.
@The Monster – The ASR-33 was an uppercase-only terminal. The other thing missing from the explanation is that the shift function in bit-paired keyboards could be a different bit on each key, so on a normal upper/lower keyboard it would be 0x20 on letter keys and some symbols like [{ ^~ @`, and 0x10 on numbers and other symbols (1!, 2″, 3#, ;+, :*, /?).
http://www.quadibloc.com/comp/kybint.htm has a good discussion of bit-paired keyboards (and the relationship of some parts of the layout with manual typewriters, which influenced the character assignments in ASCII)
One more bit of trivia is that modems worked by encoding information into audio — early modems actually had cups into which you placed a regular telephone handset — and so a working modem emitted a series of whistles and beeps. Anyone who spent some time around modems soon learned what the happy song (the modem negotiated the connection and connected successfully) sounded like which meant you knew whether you got through before your terminal told you.
If you had connectivity problems, you also learned several sad modem songs and could start diagnosing the problems based on which particular set of beeps and whistles you heard.
@ESR, but toggling “32” is indeed what’s done for the alpha keys to toggle upper/lower case. Based on Random’s description, the specific example is for a different sort of “shift”.
>@ESR, but toggling “32” is indeed what’s done for the alpha keys to toggle upper/lower case. Based on Random’s description, the specific example is for a different sort of “shift”.
> I would be astonished if this were true. We can tell some things about this keyboard from its influence on the design of Emacs. I think it’s safe to assume that the Control key was the same modifier it us today.
Well, Emacs would have to have adapted itself to ctrl as it is today through decades of Unix ASCII terminals, regardless of its origins, wouldn’t it? And its insistence on its own meanings of C-h, C-s, and C-q would seem to show it only adapted as much as it was absolutely forced to.
Did you look at the deskthority wiki page that I linked, and the lisp machine documentation it links to?
http://infolab.stanford.edu/pub/cstr/reports/cs/tr/80/796/CS-TR-80-796.pdf (which describes Stanford’s “E”, a predecessor/inspiration of Emacs) may also be informative, in particular how it describes the DataMedia terminal (which seems to be a conventional ASCII terminal) vs the DataDisc (which one can find via other sources, was the iconic SAIL keyboard that was the ultimate inspiration for the Space Cadet Keyboard)
My *guess* is that the Stanford character set consisted of (roughly) 128 graphical characters (the SAIL keyboard has 95 glyphs printed on its 48 graphical keys, adding lowercase letters makes 121), selectable with Shift and Top [Top may well have done the same bit-masking that CTRL does today, if the character set structure was what I suspect it to be], and that Control and Meta each applied a modifier bit to make a 9-bit character set.
So, that’s a bust on my “Top performed bit masking” theory, but a confirmation on most of the non-ASCII characters being in the same “region” as ASCII control characters (It also neatly explains most of the compatibility mappings used on the DataMedia terminals.)
> That’s pretty solid, then. That version was reviewed by Guy Steele, who’d used one.
But it also explicitly describes five glyphs per graphical key (of which there are, in fact, 50 – and it’s not clear that the non-alphabetic keys had distinct glyphs for shift vs top) and four independent modifiers, which adds up to exactly 4000. Allowing a generous enough set of other combinations to justify over 8000 puts the number over 10,000, raising the question of why not pick the bigger round number. And, I’m not sure having used one is really a good enough qualifier – this is basically down to someone’s judgement that something “sounds about right” regarding a keyboard that, after all, no-one would dispute had a whole hell of a lot of available combinations, without any real evidence that he’s cared to enumerate all 8000 supposed combinations.
As far as I can tell, the Lisp Machine documentation says that, at least that version of it (which doesn’t seem to use “front/greek” modifiers, but there’s more than enough room for those in the 8-bit table) had an 8-bit character set (of which 159 positions were used), and four additional independent modifiers (which were not stored as part of strings or files, but were considered part of a “character”). Which would make 4096 total possible values, regardless of if they could actually be entered in with the keyboard or not. Maybe there was some version that had an additional modifier that made for 8192.
@senior citizen:
> Anyone who spent some time around modems soon learned what the happy song (the modem negotiated the connection and connected successfully) sounded like which meant you knew whether you got through before your terminal told you.
>If you had connectivity problems, you also learned several sad modem songs and could start diagnosing the problems based on which particular set of beeps and whistles you heard.
This bit is probably too recent for Eric’s list of things every hacker once knew. All but the very youngest hackers will remember 56k dialup, and while those about my age may not have been able to diagnose issues based on sound, I certainly learned to tell a good connection from a failure.
“the relatively useless and sometimes dangerous octal syntax […] may never be entirely eradicated”
Eric, in the 21st century the “zero means octal” gimmick not only hasn’t been eradicated, but has expanded into new territory.
In the Go language, command-line arguments are parsed as octal if they start with zero.
I think you’d have to go very far back into the previous century, to get to a time when it was normal for end users (not programmers) to be expected to know that zero means octal!
$ bottlesong -startAt 0100 | head -n 1
64 bottles of beer on the wall, 64 bottles of beer.
$
$ grep -in startat bottlesong.go
14:var startAt = flag.Int(“startAt”, 99, “initial bottle count”)
41: bottlesOfBeer = *startAt
$
$ go version
go version go1.7.5 linux/amd64
Check carefully – was that Go expanding the argument, or your shell? Test by single-quoting the arg, echoing out the raw arg inside of the Go code, or carefully reading your shell’s documentation for (probably an obscure) explanation of how it handles “octal” strings in its command line.
“Check carefully – was that Go expanding the argument, or your shell?”
I used a normal bash shell, which just passes “0100” as a four-character string.
To see how Go implements “zero means octal” for end users, you can download and unpack go1.7.5.<anything>.tar.gz, and look at lines 52 and 117 of go/src/flag/flag.go, and lines 141-143 of go/src/strconv/atoi.go.
When you deal with firmware / hardware, you still have to know all that and far more. Like how to use a timer input capture to create a UART.
Hardware was simpler back then too – but there are very simple micros that in cost sensitive (or power usage) also need to be understood.
> VT – In the days of printing terminals this often caused them to scroll down half a page
To my understanding, this actually worked in much the same way as a horizontal tab (the ECMA-48 standard makes it clear this is the intent of the standardized character), in that it would move to the next increment of a specific number of lines. At one point I saw a statement that it was specifically to the next multiple of six lines, which was supposedly the size of a pair of bars on green-bar paper.
Some printing terminals and some CRT terminals use it as the command to move up one line.
> SO (Shift Out), SI (Shift In) Rarely used (and never natively on Unix) as escapes to and from an alternate character set.
I’m not quite sure what you mean by “natively on Unix”, since they are supported by the VT100 and many terminals to this day that emulate it (though there’s something of a movement to “these or UTF8, pick one”), and used by curses for box drawing and other miscellaneous special symbols.
> Sometimes used as a packet-framing character in binary protocols. That is, a packet starts with a DLE, ends with a DLE, and if one of the interior data bytes matches DLE it is doubled.
I once saw a proposed extension to the IRC CTCP protocol that used it in the same manner as backslash – i.e. following it by 0, n, r, or itself to embed null, carriage return, line feed within a message.
Wikipedia claims it was used as “DLE STX” and “DLE ETX” as the packet start/end in some unspecified serial protocols.
> termios(2)
termios is in section 3 or 4 of every manual I’m familiar with.
> DB-9
It’s commonly called that, but the proper name is DE-9.
> “as Google Groups”
Whatever one may think about Usenet as it is now, it does have an existence separate from Google.
>Whatever one may think about Usenet as it is now, it does have an existence separate from Google.
Yeah, this is a tough call – because Google has a fairly big chunk of the historical archives, something the free-floating remnants don’t.
Field notes from someone who works with crazy point-of-sale hardware and legacy (or modern wrappers, because nobody dares touch the base systems) payment processors:
FS and sometimes GS/RS and the like are pretty common in binary blocks built for payment processing backends (probably because in their core there’s stuff going back to punchcards on mainframes).
(My response to this is usuall “oh, for God’s sake, would it kill them to at least pretend it’s 2017 and they have an API?”)
You still see RS232 in some uses in restaurants (e.g.) because they’re electrically noisy places and RS232 supports long cable runs and noise tolerance better than USB or Ethernet.
(Obviously even more so in industrial embedded stuff, but I’m limiting the content to “stuff people do today you might actually see and that uses commodity retail hardware”.)
When you talk about ASCII, for ACK and NAK, I’d have noted that they were used as single-byte affirmative or negative responses in a few different protocols, most notably XMODEM and its variants. If you weren’t in the unix circles in the late 80s/early 90s, but were hacking DOS boxes, you used these extensively. In my circles, it was very common to respond to queries with just ACK/NAK, and everyone understood you. I remember sometime in the late 90s being disturbed that the younger guys had no idea what I meant, and associated ACK with Bill the Cat, not protocol answers.
> I remember sometime in the late 90s being disturbed that the younger guys had no idea what I meant, and associated ACK with Bill the Cat, not protocol answers.
Heck, I got upset the same way. So it wasn’t just DOS people…
This & the previous discussion had me thinking about how much closer everything used to be tied to physical reality – the physical keyboard, the physical pin-out of the serial port connection. It amazes me to think how many layers of indirection & very abstracted we are now, even just w/ this type of (still physical) peripheral equipment; let alone virtual machines that are now old hat. It also reminded me of the TED talk “No one in the world knows how to build a computer mouse.” Even in the hardcore hacker community where we do share a lot of common knowledge & culture, we’re becoming more & more specialized, and there’s less & less that you can count on “every” hacker knowing.
On CR-LF combo: I remember reading about how the CR tended to take longer than the LF to actually run on printers, so it was sent first to give it that fraction of a second more time, while the LF was still being sent over the wire. Some older printer drivers would send LF-CR, until someone noticed it slowed down the overall print time a measurable amount.
Also, in today’s *nix terminals, CR can be used w/out LF to overwrite the same line. e.g. echo -n “Hello World!” ; sleep 1 ; echo -e “\rGood bye World!”
Specific thoughts to your doc:
“CR (Carriage Return) Still does what it says on the tin.” For the target audience (younger hackers), it may not be clear what it says on the tin. What is this carriage that’s being returned?
Off-by-1: under the ASCII table “code points 0-32” and again later “mapping it to the 0..32 rqange” should be 0-31 (and range is misspelled).
> What is this carriage that’s being returned?
Good point – needs explaining under current conditions.
BEL (Bell) … but is generally not supported on software terminal emulators.
You sure about that? I thought most could ring a bell.
Sigivald: “(Obviously even more so in industrial embedded stuff, but I’m limiting the content to “stuff people do today you might actually see and that uses commodity retail hardware”.)”
Some, but RS-485, either point to point or multidrop (which it supports well), is far more common as a serial protocol – though Ethernet is finally supplanting it in complex control systems. Still, speaking MODBUS over RS-485 will get you talking with an amazing array of industrial sensors and control systems.
> before that displays were monochromatic, typically with white characters on a green screen.
Not sure what you are referring to here. I’ve seen green on black and it’s inverse with the slow phosphors, and later there was amber.
Might be worth noting that there were multiple ACSII versions, both standardized and unstandardized and every so often you’d find old terminal equipment that uses some bastard mixture.
Also: bit-paired keyboards.
> BEL (Bell) … but is generally not supported on software terminal emulators.
Most of the emulators I see in the wild respond to BEL visually (e.g. flash the window or title bar) rather than audibly by default. The traditional “make a bellish noise” behavior is often still available, but needs to be manually enabled–and then promptly disabled, because everyone who has done a nontrivial amount of work on a terminal with audible bell enabled has endured the experience of somehow accidentally triggering an embarrassingly long sequence of BEL characters at some point in their lives.
A less common behavior upon receipt of BEL is raising the window, possibly in addition to flashing or noise, or performing some more modern notification process (like the combination of overlay text, sound, and vibration found on smartphones).
Completely mute terminal emulators are somewhere in the top four most common cases, but I’m not sure where.
IDEs for embedded devices with “serial output” windows are often far from complete terminal emulators (they wouldn’t be able to sustain a usable vi session, for example), and will more likely print the BEL as some indecipherable glyph instead of treating it as a control character.
>Hackers of a certain age still tend to have this stuff cluttering their toolboxes or gathering dust in a closet somewhere.
Yeah, you caught me.
I don’t know if you want to mention the nightmare of parallel vs. crossover cables? One of the reasons we had so many adapters laying around…
In addition to SO and SI isn’t ^H still used by curses libraries? Like scp and curl progress bars?
Also, remember when any time you spewed binary data to your terminal and the bell would ring once out of every 256 chars? Good times, good times…
Finally, as I alluded in the prior thread, you might want to mention how “\r\n” confusion still crops up to this day. Some bits of software try to hide it from you while others don’t. So it can still bite you in strange ways. Windows notepad still formats unix files to one big long line. And I seem to remember an obscure VxWorks bug that stemmed from someone checking in a DOS ending file. Can’t recall the details anymore though.
You’re telling me that I don’t actually need that bin of cables, connectors, and adapters that’s sitting in my garage?
Delightful document. Thanks for creating it. I’m not even a hacker, just a hobbyist, but still knew most of that stuff because of my age. The things we used to have to go through just to play computer games… (I first learned Unix just so I could play moria on a SPARCstation)
Regarding BEL, gnome-terminal supports it, but it depends on the configuration of your DE and audio stack (if playing the bell through your sound chipset), and ISTR it also depends on Compiz configuration as well if you’re running that (though I’ve forgotten what needs to be configured, if anything in Compiz actually needs to be configured, and where that option is). If you aren’t getting anywhere with playing it through your main sound chipset, you can get a gratifying squarewave beep from the PC speaker, depending on the presence of the PC speaker kernel module, module blacklists, presence of PC speaker hardware, presence of firmware emulating the PC speaker with the main audio chipset, etc.
Both paths depend on the phase of the moon, the primality of the Saros number for the last lunar eclipse, the remainder from dividing the Saros number of the next solar eclipse by 17, and the sum of the mean anomaly of Phobos and the true anomaly of Callisto.
>The Control modifier on your keyboard basically clears the top five bits of whatever character you type, mapping it to the 0..32 range. So, for example, Ctrl-SPACE, Ctrl-@, and Ctrl-` all mean the same thing: NUL.
Don’t you mean the top three bits (leaving 5)
Otherwise you’d just get code points 0-7.
>Don’t you mean the top three bits (leaving 5)
Oh, good catch. I had those swapped around.
Oh, man — talk about a trip down my memory lane. I cut my first serious teeth on DEC-20s & Primes followed by CMS and older IBM mainframe operating systems (after grade school teletype machines) until the world changed. Stayed in the IT business until recent retirement.
Still have fond memories of EMACS for editing.
A lot of the ASCII control characters were used by the ASCII dialect of IBM’s bisync protocol. A typical 3270 text message was SYN SYN SOH header_byte+ STX payload_byte+ ETX parity pad. There are other protocol messages that use other control characters. It’s been a *long* time since I had to code a device driver for this (~1975). Bisync was obsoleted by SDLC. Wikipedia has a good article on bisync called Binary_Synchronous_Communications.
>A lot of the ASCII control characters were used by the ASCII dialect of IBM’s bisync protocol.
This definitely not a thing all hackers once knew.
RS-232, sentence beginning “This, in particular” has unmatched close parens.
“It does, however, retain one advantage over USB and Ethernet”–and also the advantage of raw simplicity. The flip side of “can’t tell quiet from missing” is that an output device (e.g., a multimeter) can just spit data out a serial port with no configuration or cooperation from the nonexistent receiver. You can hook up a computer or even an old TTY midstream and read the output without the device’s ever needing to know about it.
UUCP section ends in comma.
“white characters on a green screen”–do you have a picture of this? I’ve only ever seen green, amber, or white on black.
period after “vector graphics”
“general-purpse”
“could assume the character to have”–terminal?
BEL has been supported on every terminal emulator I’ve encountered. Modern ones usually have configurable behavior, but Konsole (as of the ancient version I stubbornly use) still has audio playback as default.
In VT, the word “up” is in blue but isn’t a link–weird stylesheet?
FF still works as advertised on line printers, which hang around for carbon forms and some industrial environments.
TCP handshake should probably be “SYN SYN-ACK”
Note that Escape is “^[“? It still prints occasionally, and it can be useful to know they’re equivalent.
Typo in “afterlife”… in the changelog. ;-)
>“white characters on a green screen”–do you have a picture of this? I’ve only ever seen green, amber, or white on black.
I’m going to take this out. I was thinking of the Wyse 50 and 75, which I believe were probably the most widely distributed type (I’ve seen more of them than I’ve seen VT-100s, and I think I still have some 75s in my basement) but there’s a perception problem here – I think what reads to a lot of you as black looks to me like very dark green.
I’ve always seen certain kinds of CRTs as just faintly green too, so you’re not alone.
I’ve never seen one that produced white lettering though, they all did just green. The ones that did white lettering were always solidly black when not active.
[In the current parlance]
^
|
THIS!!!
I’m no spring chicken, but even this one caught me a little off guard. (Obviously, “on the tin” means what it says on the can of dog food you are about to eat.)
Like a floppy-disk icon equating to “Save” or a Ma Bell handset icon equating to making a phone call, cultural commonality didn’t quietly evaporate–it fell off a fucking cliff!
Not to be an old fuddy-duddy, but if there is ANY chance that this epistle can strike bone with the current generation of “hackers”, one might really need to distill the abbreviated, semantic, and metaphorical logic structures down to easily-digestible Millennial bytecode, if there is such a thing.
>> I remember sometime in the late 90s being disturbed that the younger guys had no idea what I meant, and associated ACK with Bill the Cat, not protocol answers.
> Heck, I got upset the same way. So it wasn’t just DOS people…
Well, if it’ll make you feel better, I can tell you that ACK and NAK as affirmative/negative responses are still quite common at Google. I do it.
> Modem speeds increased from 110 bits per second back at the beginning of interactive computing to 56 kilobits per second just before the technology was effectively wiped out by wide-area Internet around the end of the 1990s, [Emphasis added]
Hm? That’s not quite how I remember it. ISTR using a 56k modem to get onto the Internet–well into the 2000s. I didn’t get a DSL until ~2004. Then again, 1999-2000 is about when I first started seeing phone companies advertising DSLs… (Prior to that, if you wanted megabit Internet in the 90s, you needed an expensive T1 line.)
> The PDP-7’s successor as a workhorse Unix machine, the PDP-11, had 16-bit words – but the damage had been done. C wasn’t adjusted to prefer hex, and the surprising interpretation of leading 0 wasn’t removed.
I thought C didn’t appear until after the transition to the PDP-11. (Around 4th/5th edition PDP-11 Unix, I believe. I’m not entirely sure; this was all before my time, so I only know what I know thirdhand.) I suspect that the convention predates even that–probably going back to the earliest Unix assemblers for the PDP-7. Old habits die hard, I suppose… (As an aside, there is still one good use for octal, though: Unix file modes. The bits are grouped in threes, which is nicely represented in octal. Imagine how they’d look in hex!)
>Hm? That’s not quite how I remember it. ISTR using a 56k modem to get onto the Internet–well into the 2000s. I didn’t get a DSL until ~2004. Then again, 1999-2000 is about when I first started seeing phone companies advertising DSLs…
Yeah, we could argue the fine points of the transition timing all day. And it wouldn’t matter a bit. There was enough variability in DSL deployment that you have to give “just before” a couple years of slack. Also, we could wrangle over whether “wiped out” means “vanished” or “development money ran the hell away because everybody could see what was coming”.
>I thought C didn’t appear until after the transition to the PDP-11.
I’ve actually forgotten the details here. I think the way it went is that octal syntax got embedded in the B interpreter and then rapidly inherited by C.
> If you know what UTF-8 is (and you should) every ASCII file is correct UTF-8 as well.
I assume that you mean 7-bit ASCII here, as 8-bit ASCII includes bit sequences that are invalid UTF-8.
A lot of the framing characters – ETX, STX, etc are still used in Point of Sales protocols.
[continued]
> confusingly, DB-25 came to be used for printer parallel ports
You know how to tell ’em apart, right? Serial ports are male: the socket on the hardware has the pins. Parallel ports are female: the socket has the holes. For the cables, of course, you reverse that.
> After 1978 there was an ANSI standard for terminal control codes, based on the DEC VT-100. By the early 1990s ANSI conformance was close to universal in VDTs, which is why that’s what your software terminal emulator does.
Ah, good old ANSI.SYS… (Eh, you wouldn’t know, Eric. You never ran MS-DOS–or if you did, it was for very short periods of time while cursing its very existence and plotting to replace it with something actually serious. :)
> Windows, other non-Unix operating systems, and some Internet protocols (such as SMTP) tend to use CR-LF as a line terminator, rather than bare LF.
Apple stuff, on the other hand, tended to use a bare CR as a line terminator. It’s not just pre-OS X Macs, either; all Apple OSes did this (prior to Mac OS X, of course). I suspect this goes back to the Apple II–the
[Return]key generated a CR there. (And now you know why Apple’s keyboards all have a[Return]key instead of an[Enter]key.)> and XON (DC1) was used as a requast
Typo “request”. (You weren’t kidding when you said you were a poor typist! :)
> As Ctrl-S and Ctrl-Q these were implemented in the Unix terminal driver and long outlived their origin in the Model 33 Teletype.
It wasn’t just Unix. The Apple II firmware supported this, too. (Why is this relevant? Well, there was once a time when Apple was a hacker’s company, but that’s another story.) I wonder how many other systems supported this…
> However DOS and Windows use Ctrl-Z (SUB) as an end-of-file character; this is unrelated to its ASCII meaning.
This actually goes back, like a lot of things in MS-DOS (and therefore, Windows), to CP/M. Since CP/M could only allocate whole disk blocks, there needed to be some way to mark the end of the file’s content, and ^Z was it. (Why ‘Z’? Probably because it’s the last letter of the alphabet.) Naturally, MS-DOS, which was originally built to be ~95% backwards compatible with CP/M, inherited this convention.
> If you have a Meta or Alt key, and it’s not being diverted to do something else, it adds 128 to the ASCII keycode for whatever it’s modifying. How that will be interpreted depends on whether you’re set up to use an extended character set, and which one it is.
Well, that explains why Mac/IIGS
[Option]gets mapped to[Alt]. :)8-bit character sets aren’t ASCII. They’re often supersets of ASCII, but they’re not the same. :)
Unicode goes one step beyond: the first 256 codepoints are Latin-1, which itself is of course a superset of ASCII. However, Latin-1 documents (ones that aren’t simultaneously just ASCII) cannot be UTF-8. All codepoints beyond 007F must be encoded specially in UTF-8; two bytes are required for 0080 through 07FF.
wow. what a trip down memory lane!
and i still have the cables and at lease one computer with a working db-9 serial port, just in case.
uucp. the last few i setup was almost 20 years ago for a store and forward mail system. i think i could still do it, except i think all my modems have gone to hardware heaven.
thanks for writing that all down.
>i think all my modems have gone to hardware heaven.
Heh. I came very close to inserting a mention of the Telebit Trailblazer there.
One area where RS-232 (and RS-422) communications is still widely used in machine control. I work for a company developing CAD/CAM software for plasma/waterjet metal cutting machine. I still have a bag with serial cable test, gender benders, db-25 to db 9 adapters, etc, etc.
However since 2000, the machine controllers are mostly industrial PCs running various flavors of embedded windows. Their software open CNC files over a Ethernet network. Right now most can also download CNC files over a RS-232 link but since 2010 the number of Ethernet only models is rising.
My company is the odd duck where we always controlled the machine directly with a workstation or PC. In the mid 80s it was a HP 300 series workstation with a GPIO board running stepper motors. Now it is a Dell PC with a specialized PCI motion control board or talking to a specialized motion control box via ethernet. Functionally it doesn’t make a different as the drives present both setup in the same way.
Any in the embedded world of machine control, you have to know pretty much everything in ESR’s list. We are dealing with resource constrained device, along with hardware designed to last for decades designed decades ago.
One factor is that while the Ardinuo and Raspberry devices are great for hobbyist right now change is too rapid to use for a production machine. It hard to get the same model from the same vendor for more than a year. Hence the prevalence of decades old design in the control industry.
Looking through the terminfo database, it looks like VT/^K for line-up is mainly a “non-ANSI VDT” thing rather than printing terminals – the ADM-3a and Wyse 60 being notable examples.
On the subject of things that do what they say on the tin:
Backspace: Some mention of overstriking for accents and underline on printing terminals might be useful (and nroff still outputs this for bold and underline, with less taking care of translating it to terminal-specific bold and underline codes)
Tab: Of course, everyone knows what a “tab” does, there’s a key on the keyboard that does more or less the same thing in text editors and word processors. Might be worthwhile to mention that this comes from “tabulation” and was originally intended for making tables – which also explains why terminals [and modern word processors] have arbitrarily configurable tab stops, and every eighth character or half inch is just the default.
Bell: I don’t think I’ve ever actually used a terminal emulator that doesn’t use an audible sound by default, so much so that I suspect that the people who say it is uncommon are being more influenced by sound configuration problems (or they have their system on mute and it perhaps additionally uses a visual display) than actual design choices of the terminal apps.
Carriage return: “so this needs explanation: “carriage return” is the operation of moving your print head or cursor to the left margin” Or, when there was an actual carriage, moving the paper to the right so as to place the left margin under the fixed “print head”. Did any printing terminals do this, or is this mainly a feature of conventional typewriters?
Random832, you are succumbing to a temptation I too am having to fight – throwing in stuff that, while interesting, was not common knowledge.
>Did any printing terminals do this, or is this mainly a feature of conventional typewriters?
The latter. I never saw a printing terminal on which the carriage moved rather than the print head. It is worth remembering that the Selectric worked like this too – the typeball moved, not the carriage. I am almost sure that the moving carriage was peculiar not just to typewriters but to non-electric ones (which could be what you meant by “conventional”).
Update: I now think this not only didn’t but could not have happened. If you tried to build a moving-carriage device with the duty cycle of the printers from which these printing terminals were derived, it would shake itself apart.
The typewriter I used for school reports as a kid was electric and had a moving carriage. There was a whole period where they basically just put solenoids and switches on the manual designs. To get the print head small enough that it makes sense to move the head and not the carriage needs a daisy wheel or type ball, or some other striking method that’s more compact than the old “two characters per striker” used for manual typewriters.
Some of the early teletypes did move the paper, but I rather suspect they were probably never attached to a computer.
As a young’un(I’m 31), and someone whose coding skill consists of farting around in C# to make baby applications once every couple years, I found this a rather interesting historical document, though after years of reading ESR, I’ve learned to gloss over Unix-speak any time it gets beyond my ability to parse. I’m sure glad I don’t need to know it all, though.
Might be worthwhile to mention that [“tab”] comes from “tabulation” and was originally intended for making tables – which also explains why terminals [and modern word processors] have arbitrarily configurable tab stops, and every eighth character or half inch is just the default.
Tab’s role in making tables also explains why “tab” has informally become shorthand for “move to the next field in a web form”.
Other errata:
“UUCP stands for Unix to Unix Copy program.” Should probably capitalize “program”.
“tham” -> “them”
I wish I knew enough to do semantic checking on any of this. Downside of being a child of the 1970s.
I will at least say that this article sounds like the title doesn’t quite fit. This is “Things Every Hacker Once Knew WRT ASCII and A Few Related Artifacts”; TEHOK sounds like it could be a series of articles you could write, applying not just to ASCII, RS-232, Unix, DEC, etc., but also early Internet customs, certain hardware commonalia (5.25″ vs. 3.5″ vs. 8″, tape drives, etc.), programming practice (including old VCSes like SCCS), and so on.
A lot of this starts to overlap with The Jargon File, in fact.
Nearly all typewriters except the Selectric, manual and electric both, used moving carriages. Even IBM’s pre-Selectric electrics did that. That was what made the Selectric so special.
Printing terminals/output printers couldn’t use moving carriages for another reason: either you have to lug that heavy roll or stack of formfeed paper back and forth with the carriage, or else put up with the feeding issues not doing so would cause.
That’s the reason to use the Arduino for prototyping and go straight ATmega for production!
It’s surprisingly enough how much of this I actually know. I went online in 1989, so my computing habit dates from that era.
I had a post on the history I’ve read on octal in C and Unix that doesn’t seem to have taken. Did it get caught in the spam filter, or did it disappear in transit?
>I had a post on the history I’ve read on octal in C and Unix that doesn’t seem to have taken. Did it get caught in the spam filter, or did it disappear in transit?
I don’t see it in the mod queue. Please resend.
I’m sad that I’m adding to this… but “A Random Googler on 2017-01-27 at 03:54:08 said”
>> However DOS and Windows use Ctrl-Z (SUB) as an end-of-file character; this is unrelated to its ASCII meaning.
>This actually goes back, like a lot of things in MS-DOS (and therefore, Windows), to CP/M. >Since CP/M could only allocate whole disk blocks, there needed to be some way to mark the >end of the file’s content, and ^Z was it. (Why ‘Z’? Probably because it’s the last letter of the >alphabet.) Naturally, MS-DOS, which was originally built to be ~95% backwards compatible >with CP/M, inherited this convention.
CP/M took a bunch of stuff from DEC’s operating systems (especially RT-11). ^Z meaning end of file was one of those. Really, I found CP/M pretty comfortable after using the PDP-11. The fact that MS-Dos has ‘\’ for directory separators because ‘/’ was the introducer to command switches stems from that tangled history also.
Drat, I’ll have to rewrite when I get home.
Sigh, I still have *two* 300 baud “data couplers” (modems) – one is a box with two circular cutouts embedded in rubber padding in which you put your telephone handset. One cutout has a microphone/pickup and the other cutout has a speaker.
The other data coupler is two rubber cups on wires that connect to the (surprisingly small) modem box. I used the latter when away on trips. Not every client had a modem, though everyone had phones :-). Plug the other end into the VT-52 or -102 or whatever they offered me, then away I went.
> The PDP-7’s successor as a workhorse Unix machine, the PDP-11, had 16-bit words – but the damage had been done. C wasn’t adjusted to prefer hex, and the surprising interpretation of leading 0 wasn’t removed.
In my original post that got eaten, I said “I wasn’t born yet at the time, but from what I’ve read…”, but now that I’ve got more time to work with, I’m tracking down “what I’ve read” to have a more solid source, which turns out to be, for my first comment, Dennis Ritchie’s “Early Unix History and Evolution” at https://www.bell-labs.com/usr/dmr/www/hist.html .
As I read it, I don’t think the PDP-7 was never really a “Unix workhorse”. It was the environment that they conceived and first developed Unix on, but I don’t get the impression from EUHaE that more than one PDP-7 ever ran Unix, or that any production or externally distributed version of Unix ever ran on the PDP-7, or that the PDP-7 was any more than a stopgap until they could get somebody to flip them a couple quarters (+/- a few orders of magnitude) to buy a real computer. I don’t even really get the impression that PDP-7 Unix, or early PDP-11 Unix was a very recognizable Unix by modern standards (no HLL kernel, no pipes, etc.) and dmr even says of the kernel rewrite in C “It was at this point that the system assumed its modern form”.
My second comment is sourced from DEC manuals and front panels:
I believe that the usage of octal in C and Unix on the PDP-11 was more a matter of DEC carrying it over from their other lines with mulitiple-of-three word sizes when they designed and documented the PDP-11 than it was of Thompson and Ritchie carrying over the use of octal in PDP-7 Unix onto an architecture that would have been better suited by hexadecimal.
With the exception of branches, which are unusual, and condition code operators, which have six one-bit fields, PDP-11 instruction words consist of fields that are a multiple of three bits long (with the leftover bit added to the opcode field, making it a multiple of three, plus one), octal notation is used throughout the DEC documentation for the PDP-11, and the front panel switches are colored in groups of three.
Thompson and Ritchie might be said to have carried over the use of octal from PDP-7 Unix to PDP-11 Unix, but only in the trivial sense that they continued using it. The actual carry-over (in terms of using octal because of tradition rather than because it was the most logical choice) happened at a lower level (the ISA design of the PDP-11), although I’ll give DEC the out that, from toy instruction sets I’ve drawn up on scratch paper in my free time, it’s really *hard* to design a really satisfying 16-bit instruction set that works well with hexadecimal. The PDP-11 *is* really satisfying except for being a @#$%!!! octal architecture on a non-octal word width.
Early electric type writers and the Flexowriter that was the original console for computers that had consoles moved the carriage and had standard typewriter type typing rather than a print head.
Some stuff at http://www.blinkenlights.com/classiccmp/friden/
Teletype, moved the print head, but, IIRC, a more limited character set, upper case only for example.
> from toy instruction sets I’ve drawn up on scratch paper in my free time, it’s really *hard* to design a really satisfying 16-bit instruction set that works well with hexadecimal.
The MSP430 ISA is somewhat similar to the PDP-11, but contains almost no three-bit fields (see chapter 3 of http://www.ti.com/lit/pdf/slau049 ). Of course, that’s easier with 16 registers …
One thing I’ll say about “carriage return” is that its may not actually be entirely unknown to younger hacker(oid)s: My first typing classes in kindergarten (early 90s) were on typewriters, and one of the DOS games I played as a child had things like “Press CR to continue” all over the place. Asking my dad what that meant was where I learned the term “carriage return”. So I’d say that anybody born in the late 80’s or earlier has at least a fighting chance of having learned the term before they were exposed to ASCII.
> The following table describes ASCII-1965, the version in use today. It used to be common knowledge that the original 1963 ASCII had been sightly different (lacking tilde and vertical bar) but that version went completely extinct after ASCII-1965 was promulgated.
Largely true of course, but a few quirks in the PETSCII character set used in some early micros, namely the ? (up arrow) and ? (left arrow) characters, can in fact be traced to ASCII 1963. The ZX Spectrum set shared the ? character, but not the ?. (Of course, these early character sets had plenty of _other_ quirks besides!)
Hmmm… maybe the named entities ↑ and ← will work better?
Additions:
That “very different” parallel printer connector was known as a Centronics connector (after its maker), specifically the 36-pin version. The 50-pin version would become familiar to a later generation as the SCSI-1 connector (inherited from SASI, Shugart Associates System Interface; Shugart himself later founded Seagate).
The serial interfaces were even more complex than you mention. RS-232 used odd, by today’s standards, signal levels. Mark (1) was -3 to -15V, space (0) was +3 to +15V. I usually saw +/- 12V used before the differential standards became popular. The Mac introduced to the microcomputer world the differential RS-422 standard; this used a 5V difference between +/- lines to signal. USUALLY… USUALLY… you could make this work with an RS-232 device by tying Tx- to Rx, Rx- to TX, letting Tx+ float, and grounding Rx+. Sometimes this wouldn’t work or would work only in one direction. And if you worked with components rather than machines, there were a lot of things claiming “RS-232” which actually used “logic level” RS-232, where 0V was 0 and +5V (later +3V or thereabouts) was 1.
And that’s without getting into DCE (Data Communications Equipment) vs DTE (Data Terminal Equipment), where the signals were called the same things but Tx on a DCE was an INPUT whereas Tx on a DTE was an output (as one would expect), and so on for all the pins. This is reminding me how much I don’t miss that mess. The advantage to this was that to connect a DCE to a DTE just required a straight-through ribbon cable. Anyway, this ended up leaving 4 different configurations (not counting odd ones or the Mac), all of which were used — DB9 female DCE, DB9 male DCE, DB25 female DCE, and DB9 male DCE. Which meant an essential thing for hackers to have were sufficient gender changers, 259 adapters, and null modem cables to make anything talk to anything else.
Oops, make that 8 configurations — all the ones I mentioned plus the same ones in DTE. Modems being DCE and computers being DTE was the rule but sadly not without exceptions.
That was a nice trip down memory lane. It reminds me of a midnight lecture Steve Russell gave to a few of us around 1973. That got all the way down into how stop bits tied into the whirring machinery in old TTY’s.
Today, in the embedded world, RS-232 is still around. I have long done firmware for audio equipment. These use 8 bit MCU’s, and RS-232 comms, maybe front-ended by a telnet to RS-232 bridge, or a USB bridge. But, down in the guts, the same old stuff, right down to character-at-a-time interrupt handlers.
It’s kind of fun – not many abstraction layers.
Right on time for this article, I found a GitHub repo for ITS. Yes, PDP-10 ITS, the OS of MIT hackerdom before Unix came along and ate everything. Now young hackers (even I count as “young” for this purpose) can boot — and play with and hack — the OS where Stallman got his start. (Do I see TECO Emacs in this bundle? Why yes, I believe I do!)
C got it’s octal number syntax from B which in turn got it from BCPL. The question is did BCPL get it from CPL? I don’t know anything about CPL except that BCPL is its parent. ALGOL 60, CPL’s predecessor, doesn’t have octal numbers.
Bliss, another system programming language developed around the same time, also has octal numbers, but uses ‘#’ as a prefix.
[meant to include in previous comment]
Having a way to write constants in some power-of-two form is pretty useful for a systems programming language, so it’s not surprising that BCPL and Bliss have it.
@Jeff:
Back when I was first coming into contact with hacker culture in late 2009/early 2010, I thought “gee, it would be fun to port ITS to a HLL and more modern hardware platform, just for laughs”.
Since you’re talking about physical equipment here, surely “sex changers” is the more accurate term (and “gender benders” the more amusing one).
Extra a word.
Thank you for the article! I’m in your target audience and I found it informative, particularly the RS-232 and ASCII control character sections.
@Sam P: are you sure about BCPL’s octal number syntax being leading zero? According to Martin Richards’ book (which should be the definitive reference), the prefix for an octal constant was # and for a hex constant was #X. I can’t remember seeing the leading zero used anywhere other than in C.
I would like to point out that SOH charactors are still in use as a field delimiters for the FIX (Financial Information eXchange) protocol.
This 90s vintage protocol was designed with modems in mind, for sending securities prices and orders. It is still used for derivatives trading, although these days it mostly gets sent over tcp/ip.
It’s a godawful mess of a protocol due to the fact that no one is in charge and it has metastasized new features semi-randomly.
James M: Never used BCPL, was relying on an old online BCPL Reference Manual, but I misread it. Though what is in the manual doesn’t make much sense, since it uses a prefix of ‘8’.
Ah, now I’ve found Martin Richard’s site with a much newer language guide, and as you say, it is ‘#’ or ‘#o’ for octal and ‘#x’ for hexadecimal.
> There was a time when 36-machines loomed large in hacker folklore
Don’t you mean “36-bit machines” here?
> It had three symbols per keycap, no fewer than seven shift keys, and could generate over 8000 distinct 9-bit characters
I don’t grok this at all. With a 9-bit symbol table, you get 2^9=512 possible 9-bit characters. In order to be able to represent over 8000 distinct characters, you either need 13 bits or something involving “Code Page Shift” symbols to redefine the meaning of some or all of the others.
Maybe a UTF-9 thing where 0xxxxxxxx defines 256 codes, 101xxxxxx,11xxxxxxx gives you 8192 more, (and room to grow 1001xxxxx,11xxxxxxx,11xxxxxxx, etc.) but those are arguably 18-bit characters.
>I don’t grok this at all. With a 9-bit symbol table, you get 2^9=512 possible 9-bit characters. In order to be able to represent over 8000 distinct characters, you either need 13 bits or something involving “Code Page Shift” symbols to redefine the meaning of some or all of the others.
You’re right. Because I don’t know the details, I’ve weaseled out by saying “8000 glyphs”. I conjecture that some kind of code paging was involved.
I actually had my hands on one of these at MIT in…I think…1984, but didn’t know what questions to ask then.
With 7 shift keys, you could in theory bust the nine-bit limit with just two non-modifier keys. Dang. I wonder if how it actually worked is documented anywhere?
I’m not sure if the 8000 glyphs is supportable. The Wikipedia page says “over 8,000 different characters”, but doesn’t say these were graphical characters, or that they were representable in any 8- or 9-bit character set with or without “code page shift”.
The 8000 claim dates back (via an early Wikipedia import of FOLDOC) to the Jargon File version 1.5.0, but the reasoning it provides (five glyphs per key with shift/front/top, four other modifier keys) only supports ~4000. Doing the math myself I got anywhere from that at the low end to 10,624, depending on what keys were allowed, what modifiers were allowed [were top and front allowed in combination with each other, and top in combination with shift? They have to be to break 8000, but the entry makes no suggesting this combination was meaningful]
Also, since “control” just seems to have been a modifier bit, I doubt that keyboard provided any way to generate arbitrary ASCII control characters, which is otherwise a running theme in this document.
This may be useful https://deskthority.net/wiki/Symbolics (page 279 mentioned here is physical page 294 of the linked PDF, and defines an 8-bit character set (or possibly the bottom half of a nine-bit one), with extra graphical symbols at (octal) 000-037, and special characters (some of which seem to be in the same relative position as the ASCII control characters with the same meaning) at 200 onward. No thousands of glyphs here.
> With 7 shift keys, you could in theory bust the nine-bit limit with just two non-modifier keys. Dang. I wonder if how it actually worked is documented anywhere?
Like I said, I’m almost certain I’ve read somewhere that the modifier keys set bits *outside* the character representation, in a *word* that was sent to the system.
>The 8000 claim dates back (via an early Wikipedia import of FOLDOC) to the Jargon File version 1.5.0
That’s pretty solid, then. That version was reviewed by Guy Steele, who’d used one.
>Also, since “control” just seems to have been a modifier bit, I doubt that keyboard provided any way to generate arbitrary ASCII control characters
I would be astonished if this were true. We can tell some things about this keyboard from its influence on the design of Emacs. I think it’s safe to assume that the Control key was the same modifier it us today.
> For the longest stable period of modem technology after 1970, about 1984 to 1991, typical speed was 9600bps.
Even after that, 9600 bps, being the top speed the fax manufacturers standardized upon in the late 80s, was the practical standard for long-distance data transmission. If your phone lines couldn’t handle 9600 bps, you’d complain to the local telco, and they’d fix the line. Anything above that (14.4, 28,8, … 56K) was gravy.
Re. Bill the Cat, it may be sobering to realize the latest generation barely knows what Bloom County was, and probably associates ACK with Mars Attacks instead.
> Very old keyboards used to do Shift just by toggling the 32 bit; this is why the relationship between small and capital letters in ASCII is so regular. The ASR-33 even let you generate some punctuation characters it didn’t have keycaps for by shifting capital letters; thus, for example, Shift-K (0x4B) became a [ (0x5B).
Toggling the “32” bit (0x20) would turn k=0x4B to K=0x6B, so you must mean something else here.
>Toggling the “32” bit (0x20) would turn k=0x4B to K=0x6B, so you must mean something else here.
Yikes. Off-by-one error. Fixed.
@The Monster – The ASR-33 was an uppercase-only terminal. The other thing missing from the explanation is that the shift function in bit-paired keyboards could be a different bit on each key, so on a normal upper/lower keyboard it would be 0x20 on letter keys and some symbols like [{ ^~ @`, and 0x10 on numbers and other symbols (1!, 2″, 3#, ;+, :*, /?).
http://www.quadibloc.com/comp/kybint.htm has a good discussion of bit-paired keyboards (and the relationship of some parts of the layout with manual typewriters, which influenced the character assignments in ASCII)
@Random832
So, “something else”.
Sigh. I’m old.
One more bit of trivia is that modems worked by encoding information into audio — early modems actually had cups into which you placed a regular telephone handset — and so a working modem emitted a series of whistles and beeps. Anyone who spent some time around modems soon learned what the happy song (the modem negotiated the connection and connected successfully) sounded like which meant you knew whether you got through before your terminal told you.
If you had connectivity problems, you also learned several sad modem songs and could start diagnosing the problems based on which particular set of beeps and whistles you heard.
@ESR, but toggling “32” is indeed what’s done for the alpha keys to toggle upper/lower case. Based on Random’s description, the specific example is for a different sort of “shift”.
>@ESR, but toggling “32” is indeed what’s done for the alpha keys to toggle upper/lower case. Based on Random’s description, the specific example is for a different sort of “shift”.
I’ll go read the documentation now…
> I would be astonished if this were true. We can tell some things about this keyboard from its influence on the design of Emacs. I think it’s safe to assume that the Control key was the same modifier it us today.
Well, Emacs would have to have adapted itself to ctrl as it is today through decades of Unix ASCII terminals, regardless of its origins, wouldn’t it? And its insistence on its own meanings of C-h, C-s, and C-q would seem to show it only adapted as much as it was absolutely forced to.
Did you look at the deskthority wiki page that I linked, and the lisp machine documentation it links to?
http://infolab.stanford.edu/pub/cstr/reports/cs/tr/80/796/CS-TR-80-796.pdf (which describes Stanford’s “E”, a predecessor/inspiration of Emacs) may also be informative, in particular how it describes the DataMedia terminal (which seems to be a conventional ASCII terminal) vs the DataDisc (which one can find via other sources, was the iconic SAIL keyboard that was the ultimate inspiration for the Space Cadet Keyboard)
My *guess* is that the Stanford character set consisted of (roughly) 128 graphical characters (the SAIL keyboard has 95 glyphs printed on its 48 graphical keys, adding lowercase letters makes 121), selectable with Shift and Top [Top may well have done the same bit-masking that CTRL does today, if the character set structure was what I suspect it to be], and that Control and Meta each applied a modifier bit to make a 9-bit character set.
And not ten minutes after I posted it, I found the SAIL character set: http://www.saildart.org/allow/sail-charset-utf8.html
So, that’s a bust on my “Top performed bit masking” theory, but a confirmation on most of the non-ASCII characters being in the same “region” as ASCII control characters (It also neatly explains most of the compatibility mappings used on the DataMedia terminals.)
> That’s pretty solid, then. That version was reviewed by Guy Steele, who’d used one.
But it also explicitly describes five glyphs per graphical key (of which there are, in fact, 50 – and it’s not clear that the non-alphabetic keys had distinct glyphs for shift vs top) and four independent modifiers, which adds up to exactly 4000. Allowing a generous enough set of other combinations to justify over 8000 puts the number over 10,000, raising the question of why not pick the bigger round number. And, I’m not sure having used one is really a good enough qualifier – this is basically down to someone’s judgement that something “sounds about right” regarding a keyboard that, after all, no-one would dispute had a whole hell of a lot of available combinations, without any real evidence that he’s cared to enumerate all 8000 supposed combinations.
As far as I can tell, the Lisp Machine documentation says that, at least that version of it (which doesn’t seem to use “front/greek” modifiers, but there’s more than enough room for those in the 8-bit table) had an 8-bit character set (of which 159 positions were used), and four additional independent modifiers (which were not stored as part of strings or files, but were considered part of a “character”). Which would make 4096 total possible values, regardless of if they could actually be entered in with the keyboard or not. Maybe there was some version that had an additional modifier that made for 8192.
@senior citizen:
> Anyone who spent some time around modems soon learned what the happy song (the modem negotiated the connection and connected successfully) sounded like which meant you knew whether you got through before your terminal told you.
>If you had connectivity problems, you also learned several sad modem songs and could start diagnosing the problems based on which particular set of beeps and whistles you heard.
This bit is probably too recent for Eric’s list of things every hacker once knew. All but the very youngest hackers will remember 56k dialup, and while those about my age may not have been able to diagnose issues based on sound, I certainly learned to tell a good connection from a failure.
https://youtu.be/abapFJN6glo is a pretty interesting multimedia explanation of what all the modems were singing to each other.
“Papa, what was the Internet like when you were a boy?”
“Eeeeeee…”
http://imgur.com/gallery/WXJaQnE
Eric, in the 21st century the “zero means octal” gimmick not only hasn’t been eradicated, but has expanded into new territory.
In the Go language, command-line arguments are parsed as octal if they start with zero.
I think you’d have to go very far back into the previous century, to get to a time when it was normal for end users (not programmers) to be expected to know that zero means octal!
$ bottlesong -startAt 0100 | head -n 1
64 bottles of beer on the wall, 64 bottles of beer.
$
$ grep -in startat bottlesong.go
14:var startAt = flag.Int(“startAt”, 99, “initial bottle count”)
41: bottlesOfBeer = *startAt
$
$ go version
go version go1.7.5 linux/amd64
@robertm –
Check carefully – was that Go expanding the argument, or your shell? Test by single-quoting the arg, echoing out the raw arg inside of the Go code, or carefully reading your shell’s documentation for (probably an obscure) explanation of how it handles “octal” strings in its command line.
I used a normal bash shell, which just passes “0100” as a four-character string.
To see how Go implements “zero means octal” for end users, you can download and unpack
go1.7.5.<anything>.tar.gz, and look at lines 52 and 117 ofgo/src/flag/flag.go, and lines 141-143 ofgo/src/strconv/atoi.go.