Why is ASCII this way?
First of all, there is no one best sorting order for everything. For example, should UPPER or lower case be first? Should numbers be before or after letters? Too many choices, and no way to please everyone. So they came up with specific pieces that "made sense":
0x30–0x39 - Easy bit mask to get your integer value.
It all dates back to typewriters, but the two layouts aren’t ASCII v. non-ASCII, they’re mechanical v. electric.
The !" etc. layout was common on mechanical typewriters, based on the layout used for the Remington No. 2 in 1878. This is the layout that ASCII was based on; that’s why “!”, “"” etc. received consecutive encodings, aligned with the encodings of ...
According to ASA X3.4-1963 Appendix A, one of the design considerations was:
(7) Ease in the identification of classes of characters
A4.4 The character set was structured to enable the easy identification of classes of graphics and controls.
And on page 8:
A6.3 To simplify the design of typewriter-like devices, it is desirable that ...
Which OS was the first to use Ctrl-S and Ctrl-Q on the console for pause and continue?
It's been developed independently of anything one might call an OS (*1). It's (nowadays) called Software Flow Control and has been around since the early days of computers using ASCII I/O, as the Model 33 Teletype used the device control codes DC1/DC3 (CTRL-Q/CTRL-...
man 7 ascii of Linux Programmer's Manual says,
Uppercase and lowercase characters differ by just one bit and the ASCII character 2 differs from the double quote by just one bit, too. That made it much easier to encode characters mechanically or with a non microcontroller-based electronic keyboard and that pairing was found on old teletypes.
There is a clue in the name - BCD stands for "binary-coded decimal", where 4 bits are used to represent 1 decimal digit (0-9). The hexadecimal values A-F are not used in BCD.
EBCDIC is an extended version of BCDIC, and it shifts BCDIC alphanumerics, and inserts characters in some of the non-decimal positions. But there's a simple relationship to ease ...
If you go back a lot before the x86, this technique wasn't unusual at all. In fact, writing programs using printable letters and symbols was pretty much the norm for early computers, except that there was a number of encodings for words of varying bit size, and that encoding was not ASCII.
On the IBM 1401 (1959), a program that looked like
That's how the shift key sometimes worked on old terminals and ASCII is designed around it.
But on a modern keyboard, the SHIFT key just does exactly the same as every other key on the keyboard: it sends a 'key down' signal and a 'key up' signal.
This doesn't affect any other signalling and the computer it is connected to determines the net effect.
First OS is hard to say. The codes go back to the 1960s with the Teletype Model 33. I have a hunch the original usage was not part of an operating system but at a lower level. In later times, certainly by the 1980s, there were plenty of devices that functioned with software flow control at the hardware level.
Microcomputer operating systems that supported ...
The "PETSCII" encoding is based on keyboard positions of the original PET chicklet keyboard (*1):
(Taken from Wikipedia)
The keyboard is made similar to basic typewriter keyboards, but ordered in a square fashion, including a top row of symbols but not numbers and a separate numeric keyboard. By every key holding only a single ASCII equivalent ...
As pointed out by Jon Custer, part of the reason is due to the input at the time being punch cards. If holes were close together there was a risk of the card being unreadable or ripping.
In addition, this punch card from the Wikipedia article helps explain why both uppercase and lowercase end at 0x_9. The punch card only goes from 0 to 9. I don't know how A ...
“Intended as means of indicating on paper or magnetic tapes that the end of the usable portion of the tape had been reached.”, if en.wikipedia.org/wiki/C0_and_C1_control_codes#EM is to be believed.
ASCII was codified internationally as ISO/IEC 646 which in turn was ratified by ECMA as ECMA-6. Section 8.12 EM END OF MEDIUM of a PDF image ...
IBM started using ASCII before 1970; the 2260 terminal, released in 1964, used the unpublished (but ratified) 1965 version of the ASA X3.4 standard.
IBM mainframes still use EBCDIC, so I don’t think their popularity had much bearing on the popularity of ASCII (but other encodings’ popularity influenced IBM mainframes: their instruction set includes ...
ASCII was never intended for processing, just as an interface standard for data exchange (hence the name American Standard Code for Information Interchange)
IBM never switched, it still uses EBCDIC within mainframes and ASCII for communication.
IBM was a major proponent for ASCII, but not the sole force, and especially not international.
ASCII soared ...
This chart (showing the hexadecimal values of ASCII characters) outlines manassehkatz's answer graphically:
Numbers are at 0x30 + the value of the number
Capital letters are at 0x40 + the value of the letter (A=1, B=2 etc)
Lowercase letters are at 0x60 + the value of the letter.
EM (or EOM as in early documents - and Unicode as well) was and is widely used in data transmission to mark either
The physical end of a medium,
The end of the used portion of a medium
The end of meaningful (wanted) data on a medium.
(Like Scruss already described in his answer)
It was used with next to any RJE station as well as terminal. The ...
It was nothing to do with an OS as such. Ctrl-S and Ctrl-Q are simply XON and XOFF in ASCII.
These codes are used in serial communications to pause and resume sending.
With hardware handshake on RS232 and similar communications standards used the RTS (RequestTo Send) & CTS (Clear To Send) handshake lines.
Many comms links were, and still are, three ...
I found the explanation in chapters 23 and 20 of Mackenzie, Charles E, Coded Character Sets, History and Development (Addison-Wesley, 1980), which was linked in a footnote to Wikipedia's ASCII article.
In the early 1960s, 7-bit ASCII was being standardized as an communication format (the last I in the name comes from "interchange"), but this does not ...
It all dates back to the age of typewriters.
Using an ASCII-based layout made the design of computer keyboard encoders simpler, as the output of any key while holding Shift (capitals, symbols) differs from the the normal output by just one bit. For this reason, these keyboards are also known as bit-paired keyboards.
Mechanical typewriters had used a large ...
It was standard practice on the Sinclair ZX80 & ZX81 to put executable code into a REM statement at the beginning of a BASIC program.
REM statements are, of course, text comments, so this meets the spirit of your requirement for executable ASCII.
The ZX80 (1980) and ZX81 (1981) predate your question about the early 1990s by about 10 years and used the ...
It can be done in any environment that:
Allows the remarking of data files into program files,
Has a loader format that's either primitive enough or all readable
Has a character set (doesn't have to be ASCII) that has a sufficient number of encodings that produce valid opcodes
Has an address space layout that fits the possible encodings
If you want to read it as octal, having the low order 3 bits grouped together is handy. Many of the early ASCII tables showed the codes in octal. HEX makes more sense once your computers begin to work on 8 bit bytes, but earlier computers had units like 36 bit words that were divisible by 3, and this led people to use octal for a few years.
Punched cards ...
I remember doing this on the university mainframe around 1975. This was on an ICL1904S. Note that the 1900 series had been around for more than 10 years at that time. I don't know when the feature came out but it had been around for some time.
You could list out any executable in card reader format. It would produce the executable in 6-bit characters in ...
I think the codes were laid out so that when laid out sensibly on the PET keyboard, the shifted and unshifted forms of each key would have a consistent relationship. When the VIC-20 reduced the number of keys but added the Commodore key, this made it necessary to rearrange the placement of graphics on the keys; since Commodore kept the same arrangement of ...
For a slightly interesting twist on this concept, consider Control Data mainframes.
These beasts included not only a CPU, but a "peripheral processing unit" (PPU)1--and the CPU sent commands to the PPU via normal I/O channels.
The CPU was a 60-bit processor that used 6-bit character codes. The PPUs were 12-bit processors, so the CPU sent a stream of 2 ...
Oldstyle ASR-33 teletype machines (telex machines) only handled 7-bit codes. They only handled uppercase English-language characters, the ten digits, and some punctuation.
They printed with this little cylindrical print head with a limited number of characters available.
Later, tons of terminals, both printing and screen-based, came on the market using the ...
From a pure hardware point of view, a significant amount of computers keyboards see each keypress as a bit set in a matrix of rows & columns, so with another operating system you could theorically map "shift" to another key.
So one could say that only the operating system makes the shift/control/alt keys different from others.
However there are some ...
I believe the only way we can answer this question is by members finding 'the earliest' such description.
DEC's first CRT terminal device, the DEC VT05 terminal (1970), had tab stops fixed at 8-character intervals.
The DEC VT50/VT52 terminals (1974) had tab stops fixed at 8-character intervals.
The DEC VT100 terminal, (1978) which replaced the VT52, had tab ...