side project - IBM 3278 terminal restoration - planning for keyboard substitution

TERMINAL IS MISSING ITS ORIGINAL KEYBOARD

The 3278 terminals used the IBM beam spring type keyboards (type B), the most prized by keyboard afficionados for its feel. Thus keyboard pirates will find listings for devices like the 3278 and use only the keyboard. More often, recyclers or sellers of old gear will separate the keyboard as they can get 1-2 thousand US dollars for the keyboard itself. This leaves essentially useless terminals since the supply of keyboards has been hoovered up. 

The type B keyboard on the 3278 delivers a scan code in parallel on its interface for each key depression. These codes are associated with the position of the key-stem on the keyboard and therefore with the character printed on the keycap. 

The successor terminals like the 3178 made use of the 'type F' keyboard from IBM which is second best to the beam spring, but still desirable. Fortunately, not absurdly desirable and thus these can be found either together with their terminals or even separately for much more reasonable prices. 

The type F keyboard delivers a serial scan code, much like the later keyboards such as PS2, but the codes assigned to key-stems (and keycap characters) are different on most keys. It is feasible to read the scan code from a type M keyboard and translate that to a 3278 keyboard scan code, so that when the keycap with the character A is pressed, in the same key-stem position, the key code seen by the 3278 terminal will be the one that would have been sent by the beam spring keyboard. 

COMPLICATIONS TO DEAL WITH IN THE KEYBOARD SUBSTITUTION

The interface has wires for the seven bit scan code, power (+5, +8.5, -5, ground), power-on-reset, data available, make/break, keyboard ack, clicker, and four keyboard identifier bits. The identifier bits indicate the type of 3278 keyboard that was connected to the terminal. These include 75 and 87 key versions with different layouts. 

Many of the keys on the keyboard are called 'typeamatic', an IBM term that means if you hold the keycap down it will repeatedly emit that character, for example the space bar or a letter. Some are not. 

Some keys on the type B issue a different scan code for make (when it is pressed down) and break (when it is released) while most only issue one scan code. The type F indicates whether a keypress or a key release has occurred but we see both events. For the keys that don't have two scan codes on the type B, I can send only the make type scan code and drop the release. For those that will receive two scan codes on type B, I can map based on whether it was a make or break key action. 

There is an ALT button which changes the scan code issued for a key-stem. This only happens for the non-typeamatic keycaps; use of the Alt key involves emitting an Alt make code, the other key's scan code when it is subsequently pressed, and then the Alt break code when the Alt key is released - three scan codes emitted. 

The bottom right keycap (Enter key) is typeamatic on the type F but only emits one time no matter how long it is held down on the type B. I can resolve this by blocking repeated Enter scan code until a new character's scan code arrives from the type F. Since there is no Alt character assigned to this keystem, the fact that it is typeamatic and won't send the Alt make - Enter - Alt break sequence doesn't matter. 

The type F is a serial interface with one protocol, while the type B uses a parallel interface with a different protocol. I will need the two connector types and a microprocessor to handle the protocols on each connection, as well as handling the scan code mapping and other special handling mentioned above.