It's because 0x7F is all ASCII bits set to "1". Back in the early punch card (and telegraph?) days, if there was a typo, you couldn't "unpunch" a hole to make it a 0 again, but you could punch out all the rest of them, indicating "ignore this char, I've deleted it" -- 0b1111111.
source: http://www.trafficways.org/ascii/ascii.pdf which is a really neat read if you like that sort of thing :)
One feature I like is that you can neatly cut out a 64-character 6-bit all-uppercase encoding (like DEC's) if you don't need lowercase.
Wikipedia covers some of the design choices here: https://en.wikipedia.org/wiki/ASCII#Internal_organization
> One feature I like is that you can neatly cut out a 64-character 6-bit all-uppercase encoding (like DEC's) if you don't need lowercase.
When you have to design a device that does ASCII entirely mechanically then this is a efficient way to structure it. I would not be surprised to hear that mechanical considerations had a influence on the question of what bits went where.
Added: OK, I have managed to not entirely surprise myself:
This seems to say that the influence was partially mechanical typewriters but the Teletype Model 33 entirely followed ASCII.
Your comment inpired some googling. I found this chart, which although likely not the one you carry around, is pretty doggone cool too:
Mine is the one designated "Model 33/35 ASCII".
For example, note that the numerals map to their direct binary notation plus a 011 in front. 0 => ...0000, 1 => ...0001, 2 => ...0010, etc.
Now I wonder, why don't they start in the zero row? In other words, why is 0 = 0110000, instead of 0100000?
Why are the parens not in the same row as braces and brackets?
Why isn't "&" (ligature of "et") not in the same row as "e"? "$" ("dollar") is in the same row as "d".
In this instance the more common 8-column presentation actually better reflects the design. It's important that the low 4 bits of '0' are 0. The 0x2X column and 0x3X column are related by shift (on some devices²).
Is this it?
It matches old mechanical typewriters. I have one with the shift-characters over the numbers being exactly what was 16 characters (one bit flip) away in the table.
(BTW, for anyone curious, you match a newline in a regexp in emacs by using ^Q ^J, the first is the quote operator and the second is the character you want, ^J, or newline)
So, yes, you normally push CR to enter the LF character.
The confusions between CR and LF run deep and wide, even in the UNIX world.
So I don't quite understand how that table explains it. I mean aside from the fact J character code being the LF code with first two bits zeroed.
It's a bit easier (for me) to read, if it's on one page. Also, it makes a bit more explicit that digits start at 0110000.
It's a bit confusing to me that the column header bits are added to the LEFT of the row identifiers. Might be helpful to report the row ids as "__00000" or similar.
It also expl^H^H^H^H^H^H
I wonder if 00-1F could be added to the summary, using the Unicode Control Pictures range for added irony.
https://en.wikipedia.org/wiki/Control_Pictures (␀ ␁ ␂ ␃ ␄ ␅ ␆ ␇ ␈ ␉ ␊ ␋ ␌ ␍ ␎ ␏ ␐ ␑ ␒ ␓ ␔ ␕ ␖ ␗ ␘ ␙ ␚ ␛ ␜ ␝ ␞ ␟)
Like the author, it blew my mind when I realized that all the Ctrl+? keys were assigned their letters due to a single bit flip.
vim also does this; this is why nul is ^@.
The Linux version has two columns; ever wonder escape (0x1b) visualizes as ^[? because it's a single bit off the actual character "["; all the control characters are; they're visualized by essentially flipping a single bit, and displaying ^ + that letter. This was the point of TFA.
The author's four column layout also makes the 1-bit difference between upper and lower case ASCII readily apparent, which the Linux man page regrettably does not.
iTerm2, in vim 1.8
Control-@ is 0.
Control-A is 1, through control-Z is 26.
Control-[ is 27, escape.
Control-\ is 28.
Control-] is 29.
Control-^ is 30.
Control-_ is 31.
CTRL does not actually modify the character code sent from the keyboard. For letters, the same keycode (which maps to ASCII with a constant addition of 0x3D) is always sent. Another byte in the HID report contains bit flags for modifier keys (L/R CTRL, SHIFT, etc); the OS decides what happens after that.
Note that this holds under USB HID.
Obviously it shows how the ASCII committee used the first two bits as control bits and the remaining bits as a mixture of control and data bits, but I’d never seen it displayed this way.
I think the horizontal layout is a lot more readable, especially with the ability to read the bitstring more-or-less left-to-right. Only thing is that it's pretty wide—maybe too wide. The document that screenshot is from is meant to take up an A3 sheet split in half lengthwise. Someone willing to spend more time on it than I was would probably be able come up with helpful notes for the bottom half, or shift things around so elements corresponding to the low bit in the upper nibble are nestled below the items where that bit is off.
Bug report, your table has an error at 1111110.
Which makes it clear why the Apple I, II and II+ did the same.