The 44 keys on a conventional electric typewriter commonly had this arrangement on typewriters in the United States and the English-speaking part of Canada:
! @ # $ % ¢ & * ( ) _ +
1 2 3 4 5 6 7 8 9 0 - =
¼
Q W E R T Y U I O P ½
: "
A S D F G H J K L ; '
?
Z X C V B N M , . /
An electric typewriter, therefore, can have a large, double-height, carriage return key.
On a computer keyboard, however, the ¼ ½ key is replaced by the { [ key, which has the } ] key to the right of it, and so the Enter key is only a single-height key, located to the right of the " ' key, so that you get:
~ ! @ # $ % ^ & * ( ) _ +
` 1 2 3 4 5 6 7 8 9 0 - =
{ } |
Q W E R T Y U I O P [ ] \
: "
A S D F G H J K L ; '
< > ?
Z X C V B N M , . /
On the previous page, various possible alternative keyboard arrangements for the IBM PC were explored; in some of them, there was a double-height Enter key, and the { [ and } ] keys were kept side-by-side, either by placing the } ] key to the left of the ! 1 key, or by placing the } ] key where the Caps Lock key is located.
Is a reasonable re-arrangement of the keys on a keyboard possible that would allow having the { [ and } ] keys side-by-side, while also allowing a double-height Enter key, which does not extend the keyboard to the left as much as those arrangements did?
One extra key would still be needed, though; and the ~ ` key, to the left of the ! 1 key, in the traditional Esc key location, would be the most suitable for that.
Recently, I saw a photograph of an old IBM Executive typewriter with the following keyboard arrangement:
[ @ # $ % ¢ & * ( ) _ +
] 2 3 4 5 6 7 8 9 0 - =
!
Q W E R T Y U I O P 1
: "
A S D F G H J K L ; '
?
Z X C V B N M , . /
as opposed to the more conventional arrangement from before the typewriter-pairing keyboard was modified to handle braces and square brackets in the same way as the bit-pairing keyboard, as seen in a pure form on the Tandy Model 100 portable computer:
! @ # $ % ^ & * ( ) _ +
1 2 3 4 5 6 7 8 9 0 - =
]
Q W E R T Y U I O P [
: "
A S D F G H J K L ; '
< > ?
Z X C V B N M , . /
So, if the location of the ~ ` key on a typical PC keyboard, traditionally used for the Esc key on computer keyboards is available, one possibility might be this:
{ } @ # $ % ^ & * ( ) _ +
[ ] 2 3 4 5 6 7 8 9 0 - =
!
Q W E R T Y U I O P 1
: "
A S D F G H J K L ; '
< > ?
Z X C V B N M , . /
While this arrangement might have historical precedent behind it, moving the ! 1 key from the position that provides a uniform numerical progression of the keys with the digits on them would be too radical for many, I fear.
One other somewhat reasonable possibility exists:
+ ! @ # $ % ^ & * ( ) { }
= 1 2 3 4 5 6 7 8 9 0 [ ]
_
Q W E R T Y U I O P -
: "
A S D F G H J K L ; '
< > ?
Z X C V B N M , . /
but again, I fear that this is too radical a rearrangement.
However, perhaps these keyboard arrangements might still be useful as alternatives to an arrangement that splits up this pair of keys:
} ! @ # $ % ^ & * ( ) _ +
] 1 2 3 4 5 6 7 8 9 0 - =
{
Q W E R T Y U I O P [
: "
A S D F G H J K L ; '
< > ?
Z X C V B N M , . /
which would be the default during IBM PC-compatible operation, while an arrangement based on the typewriter-pairing keyboard:
} ! @ # $ % ^ & * ( ) _ +
{ 1 2 3 4 5 6 7 8 9 0 - =
]
Q W E R T Y U I O P [
: "
A S D F G H J K L ; '
< > ?
Z X C V B N M , . /
would be the default during normal operation, when that constraint did not apply.
Further thought has led me to feel that the issue of the square brackets and curly braces can be dealt with by providing two extra keys, so that both the old typewriter-pairing arrangement, for compatibility with APL-ASCII, and the new arrangement, for IBM PC compatibility, are present. A reasonably-sized keyboard can include room for both arrangements, as shown below:
In some ways, the diagram above is a bit disingenuous. Typewriters with expanded keyboards will usually have either a pound sign and 3/4 key, or a superscript 2 and 3 key, but not both... but in either case, they will also have a key with both square brackets on it... but that key won't be in the convenient location reserved for the 1/4 1/2 key.
Something more conventional might be:
moving the square brackets out of the way, so that something else is replaced with 1/4 and 1/2. But that interferes with one of the primary motivations behind this type of keyboard. The intent is to reconcile preserving compatibility with typewriter-pairing APL-ASCII:
also illustrated here:
with compatibility with the Model M keyboard for the IBM PC:
which, like the original keyboard for the IBM PC,
incorporated the arrangement of the braces and square brackets that had been previously seen on the HP 9845A calculator and the DEC VT100 terminal.
But all this focuses on the English-language keyboard!
If one wishes to keep the Ä, Ö, and Ü keys in their right places on the IBM PC keyboard, then one has to keep not just the :; and "' keys in their existing positions, but also the {[ key has to stay exactly where it is!
Thus, if the ambition is to have an improved keyboard compatible with the legacy ASCII arrangement for communicating with an old APL program that can't be modified, one must reconcile oneself to having to switch the keyboard's scan code assignments when it is being used with Windows on a PC-compatible computer - real or emulated.
So the keyboard design will depend on the intended application; is this a Windows PC that will also have, as an addition, a keyboard arrangement more congenial to terminal emulation for communication with some emulated legacy system - perhaps with Hercules - or is the keyboard primarily for a new computer for which emulating, or communicating to, a Windows PC is an additional feature for use of legacy software on that system?
Is it the Windows PC that is the legacy platform, or is the other platform the software for which is being accomodated the legacy platform?
Mixing in a word-processing keyboard, and considering foreign-language keyboards as well, makes it even more difficult to reconcile all the conflicting goals.
If compatibility with the keyboard for the IBM PC is not a concern, but simply being able to use the full ASCII character set with 44 keys is instead the goal, then things become easier. Returning to the Tandy Model 100 computer,
! @ # $ % ^ & * ( ) _ +
1 2 3 4 5 6 7 8 9 0 - =
]
Q W E R T Y U I O P [
: "
A S D F G H J K L ; '
< > ?
Z X C V B N M , . /
The additional characters in ASCII not directly marked on the keyboard were available by using the GRPH shift key:
! @ # $ % ^ & * ( ) _| +
1 2 3 4 5 6 7 8 9{ 0} -\ =
]~
Q W E R T Y U I O P [`
: "
A S D F G H J K L ; '
< > ?
Z X C V B N M , . /
along with many other characters on other keys.
In my opinion, a good placement for the additional ASCII characters that would be possible using only the CTRL key, without the need to add an additional shift key, would be the following:
! @ # $ % ^ & * ( ) _ +
1 2 3 4 5 6 7 8 9 0 -{ =}
]
Q W E R T Y U I O P [|
: "
A S D F G H J K L ;~ '`
< > ?
Z X C V B N M , . /\
In addition, the control characters not available as CTRL-A through CTRL-Z could be assigned as follows:
NUL to CTRL-0 ESC to CTRL-3 FS to CTRL-4 GS to CTRL-5 RS to CTRL-6 US to CTRL-7
Of course, there would be an ESC key, but then there is an Enter key, yet carriage return can also be generated as CTRL-M.
Additional programming and mathematical characters might be available as shifts of the letter keys when the CAPS LOCK state is active. In addition, as a possibly quirky idea, the , and . keys might still produce , and . when shifted, normally, with < and > requiring the control key, but in the CAPS LOCK state, the less-than and greater-than characters would also be available with just a shift.
The only character in basic 7-bit ASCII that this would not provide for is DEL. That could be assigned to CTRL-SHIFT-7: indeed, a number of alternative assignments are possible:
NUL to CTRL-0 CTRL-SHIFT-P ESC to CTRL-3 CTRL-SHIFT-K FS to CTRL-4 CTRL-SHIFT-L GS to CTRL-5 CTRL-SHIFT-M RS to CTRL-6 CTRL-SHIFT-N US to CTRL-7 CTRL-SHIFT-O DEL to CTRL-SHIFT-7
following the practice on many bit-pairing keyboards for some of these characters.
Another possibility is using control-shift-minus for the DEL control character, since that associates it with the underscore.
Using the CTRL key to add only one of the extra ASCII characters to each key, rather than using the GRPH key in conjunction with the SHIFT to add two characters, invites comparison to another keyboard instead of that of the Tandy Model 100:
The keyboard of the PCjr used the ALT key instead to add one additional character to several keys to make the full ASCII character set available, but from a keyboard with 45 keys for normal characters rather than 44.
In making a diagram of a keyboard of this type, I've wrestled with some of the remaining issues:
The BREAK key needs to be moved to the left side of the keyboard, in order to make it more compact and more nearly rectangular.
There should be a CTRL key on the right side now as well, because of its increased role.
As there is no good place for the DEL character, a separate RUB OUT key is needed. Fortunately, there's room for it. Oh, wait a moment; it could always be Ctrl-Backspace.
There is room, to the left of the space bar, for a CODE key if desired.
Putting the BREAK key on the right of the keyboard, in its traditional place, with the elimination of the RUB OUT key, makes room for cursor keys in a compact layout, as shown below:
And here's how APL could fit in:
Note that the handling of the less-than and greater-than signs has to change; now they're back to being shifts rather than being accessed with the Control key.
If the ALT key is used for overstrikes, Alt-Tab can be domino, and Alt-Backspace underscore del.
Some languages don't fit well on a 44-key keyboard. At first, I thought that German would be no problem, since while three keys, needed for Ä, Ö, and Ü would no longer be suitable for placing additional printable characters above, the four numeral keys with no control character above them could be used to make up for this. However, while this would allow German to retain all the special graphics from the basic 7-bit ASCII set, and even add the Euro symbol, there is no room left for the eszet!
Actually, to see the issue involved here in more detail, let's look at the various forms of ISO 7, or ITA #5, the internationalized form of ASCII in which some character positions are designated as for "national use", and hence subject to change:
If the three letters with umlauts get keys to themselves, so that both upper-case and lower-case forms are accessed by the shift keys, then the codes for {, |, and }, which were banished to access with the control key in order to achieve a 44-key keyboard, are now brought back to prominent positions.
However, since we're now dealing with a 7-bit code, the total number of characters is the same, and therefore the only consequence is that some other characters will instead be the ones reached with the CTRL shift. Of course, the modern German computer keyboard, based on ISO 8859-1, includes additional characters besides those in the German 7-bit code, but that keyboard already requires the use of the AltGr shift even with a keyboard the primary typing area of which involves 48 keys instead of 44 keys.
Therefore, it appears that while the problem of mainstream European languages may seem daunting, it will be solvable.
For languages like Armenian, though, the problem is considerably more severe.
But I have come up with a solution that doesn't require adding keys to the keyboard.
Instead, for languages with such issues, have both CTRL keys instead function as AltGr keys normally. However, if the CAPS LOCK feature is on, then the CTRL key can be used for control characters; and, in addition, instead of the SHIFT keys taking the upper-case letters to lower-case, which I think is rather useless, they can be used to access additional special characters primarily useful for computer programming; in fact, this should happen for languages that don't require the CTRL key to be modified as well.
In the case of Armenian, the digits from 0 through 9 would have to be accessed using the CTRL key on a 44-key keyboard. As they shouldn't become hard to access in CAPS LOCK mode, I think the best move is to adopt the obvious solution of accessing them with SHIFT instead of CTRL in that mode.
There is, however, another way to ensure that the backspace, enter, and shift keys are reachable in the normal fashion by the right hand without shrinking the keyboard to 44 keys in the main typing area. The Japanese keyboard suggests how it can be done, and so I've illustrated the principle with a rearrangement of the Japanese keyboard:
One of the four keys on the right-hand edge of the main typing area is moved to where the tilde and the open single quote are on the U.S. keyboard, which has led to the Half Width key being moved where the ESC key was, and the ESC key being moved to the right, over the numeric keypad.
The other three keys on the right-hand edge of the main typing area are moved to the middle of the keyboard, between the left-hand portion of the keyboard, and the right-hand portion of the keyboard. So the home keys for the left hand remain ASDF, and the home keys for the right hand remain JKL;, but the two hands are now one key further apart, so the right hand, having moved one key to the right, is now in its proper relation to the right-hand backspace, enter, and shift keys.
Because the key for the digit 6, although officially a key to be struck by the index finger on the right hand, involves a long reach for that finger, some authorities instead recommend striking it with the index finger on the left hand, and, indeed, you will see some ergonomic keyboards laid out to favor that recommendation. Hence, I've increased that key to a double-width key to avoid that issue; however, that does mean the key will need the appropriate support so that it will not bind when struck off-center.
Perhaps what is going on would be clearer with an illustration of what that means when applied to the U.S. keyboard:
Of course, all this trouble would have been saved if they had designed ASCII properly in the beginning, as shown in the diagram to the right!
In the two columns containing lower-case letters, only define the lower-case letters. Also, subtract out the backslash; replace it with PCE: "printable character escape", so that ASCII text could be encoded with only six bits per character, and PCE could be used to reach other characters.
This way, with only the space plus 62 other characters, and then the 26 lower-case letters, 62 plus 26 is 88, so a normal 44-key typewriter keyboard with one shift can be used.
But in addition, where all those control characters nobody ever uses are... still give the null the all-zeroes code, as delete gets the all-ones code, and also retain the most basic control characters that are useful, like carriage return and line feed.
In the 26 positions that correspond to letters, though, put mathematical and programming symbols, with the idea that a 44-key keyboard with one shift could operate in two modes: one mode where unshifted is lower-case, and shifted is upper-case, for typing text, and another mode where unshifted is upper-case, and shifted gives extra mathematical symbols for writing programs!
Shift-out and Shift-in would still be present, for example for switching to APL characters.
The control characters are shown in yellow; light blue-green highlights the space and the control character within the basic 64-bit code, printable character escape.
Two control character positions are left undefined; I'm not sure which additional control characters would be the most badly needed. Since "Who Are You?" or WRU is included in 5-level code, it's possible that the characters ENQ and ACK should be the ones used in those positions. Other control functions would require the use of the ESC character.
But how does one handle alphabets with more than 26 letters?
This is illustrated in the center of the diagram, with the Armenian alphabet. The first 26 characters are placed where those of the Latin alphabet are.
The next 10 characters can be placed, in their upper- and lower- case versions, side by side in the first two columns of the code chart.
But the next two characters cannot be placed quite so neatly; in upper-case, they continue on from the ten which preceded them; in lower-case, they are placed in other code positions that are still available. Note that this pattern could be continued for an alphabet with both upper- and lower- case and only one more letter; after that, the regular special characters in the main 64-character area would also have to have their codes re-used.
And then, on the right side of the diagram, it is shown that the code would be a perfect fit for APL/ASCII, following the typewriter-pairing convention; only the extra characters added to APL so that there would be something on the extra keys of an ASCII terminal are left out.
As the revised version of ASCII shown above has nearly all the codes in the same positions as the upper-case only version of ASCII, presumably it is imagined that while it would be too late to adopt it now, it could have been proposed when ASCII added lower-case letters.
However, since it involves changing the codes for carriage return and line feed, it would have been too late to adopt it at that time. Given, therefore, that this is a change to ASCII that would have needed to be considered at the very beginning, then shouldn't the characters be re-ordered so as to eliminate another issue: the distinction between the simpler bit-pairing keyboards and the more attractive typewriter-pairing keyboards?
FIELDATA, not the 6-bit version used by Univac, which is the most well-known, but the 7-bit version used by the U.S. military, was designed around the typewriter keyboard from the beginning, as can be seen from the illustration below:
Taking my modest proposal for a modified ASCII, and changing it further so that a keyboard with a typewriter-like arrangement would be a natural bit-pairing keyboard for the code, produces the code shown at right.
In order that the basic structure of the code, a 64-character central core, with shifts of the alphabet being the only printable characters outside that core, is maintained, two pairs of characters intended to be on the same key, while their codes differ by only one bit, differ in their least significant bit instead of in one of the more significant ones. Those two pairs are the single and double quote, and the vertical bar and logical not (which replaced the square brackets as part of the central core of the code - in order to forestall another issue, ASCII ! being made equivalent to the EBCDIC vertical bar, instead of the EBCDIC !, in order to allow PL/I programs to be entered from upper-case only terminals; the cent sign replaces ASCII ^ and it is expected to be equivalent to the EBCDIC cent sign, and not the EBCDIC logical not, as ASCII ^ was made, as well).
Note that to make this possible, the Printable Character Escape character has had its code changed from X'5C' to X'5B'.
If allowing an additional bit to be inverted by shifting adds too much to the complexity of some types of terminal, however, the second code chart in the diagram is shown the change that would have to be made to avoid this.
This would add slightly to the complexity of converting the external 7-bit code to a 6-bit internal form, but placing that burden on the computer, which as a natural result of its function can manipulate data in powerful and general ways, in order to lower the cost of terminals would seem not unreasonable, even in those days when computer time could be expensive.
If that form is useful, the normal full form with a 6-bit nucleus would be changed slightly, so that those two character pairs are still distinguished by the shift of a less significant bit, but now it would be the second least-most significant bit, not the least significant one, and this change is shown in the third code chart in the diagram, and the fourth code chart shows how APL characters would be allocated corresponding to that code.
The diagram to the right shows how this code is intended to work on a keyboard.
Looking at the code charts on the bottom:
In one mode the letter keys generate the lower-case letters, the positions of which are shown in red, and, when shifted, they generate the upper-case letters, the positions of which are shown in orange.
In another mode, the letter keys generate the upper-case letters, in the orange code cells, and when shifted, they generate the special characters which have yellow backgrounds in the first code chart.
Only the special characters and the upper-case letters, with yellow and orange backgrounds, are shown on the diagram; that the lower-case letters can also be produced from the same keys seemed obvious enough.
The second code chart shows how most of the special character keys work. Unshifted, they generate the characters shown with blue backgrounds. Shifted, they generate the corresponding character in the same row of the chart with a green background. The positions of these characters on the keyboard are shown by also coloring the faces of the keys with those backgrounds.
The third code chart shows how two of the keys work instead. Here, the characters on the keys as unshifted appear with purple backgrounds, and two spaces above, with a light blue-green background is the corresponding shifted character. The positions of the characters in this category are also indicated by the same colors in the keyboard diagram.
Of course, since obviously only a less radical modification to ASCII is possible at present, let us suppose that the proposed code illustrated above were instead a different code, call it, say, TERMCODE, for Terminal Code, and have the computers to which such terminals are connnected translate from TERMCODE to a slightly modified version of ASCII, modified only so as to include the same character set.
This is illustrated by the diagram at left; the modified ASCII is shown on the left, and the TERMCODE to which it corresponds is shown on the right of the diagram.
On this page, however, I examine making a further slight modification to TERMCODE in order to make it applicable to languages requring up to three additional keys on the keyboard to be dedicated to alphabetic characters with both an upper-case and a lower-case, such as German.
However, the modification shown there compromises the design principle of having a central core of 64 characters. Thus, the further modification shown at right, which avoids this, at the cost of the additional letters for German and the Scandinavian languages no longer being contiguous, but which allows further control characters to be pre-empted so that up to six keys can be re-assigned to additional letters, with the new letters all having an additional printable character as their shifted value when Caps Lock is in effect, just like the original 26, may be preferred.
The backspace could also be moved to x'60' so that it would not be subject to pre-emption; but, come to think of it, while the backspace is used from the keyboard, in some operating systems, the tab character is allowed in text files as an alternative form of whitespace, and therefore it might be more desirable to protect the tab character from being pre-empted so that it would not become an escape sequence.
Copyright (c) 2014, 2017, 2020 John J. G. Savard