RickNel
Veteran Member
The Soroc keyboard is a sturdy, metal-sprung passive keyswitch array soldered directly onto a PCB, with all traces terminating at a 24pin header joined by a 24-pin strap to the original motherboard. Pin 24 is not used, so there is a matrix of 8 rows by 15 columns. The Soroc polled these matrix lines and delivered internal switch codes to its terminal and display logic.
The re-created terminal would bypass all that logic and instead mate the switch matrix with a PS/2 controller.
The laptop providing the intelligence for the recreated terminal would need to receive compatible signals at its PS/2 port. A salvaged controller module from a sacrificed Honeywell PS/2 keyboard would need to be able to interpret the Soroc switch matrix as connected at the keyboard header.
Through a long process of experiments and advice from Forum discussions, I found that the apparently simple process of delivering a keypress signal to a BIOS is in fact multi-layered and not necessarily standardised.
The protocol is like this:
1. PS/2 keyboard controller polls switch matrix and registers switch state (one or more keys may be pressed for combinations with shift, control, alt).
2. Controller firmware validates switch state against its internal keyboard map and ignores any unmapped switch state.
3. Controller maps switch state to a 2-byte keycode held in its firmware table, and sends that keycode via serial to the PS/2 keyboard input on the host. THIS KEYCODE IS NOT ASCII.
4. Host keyboard controller and OS reads the keycode and REMAPS it to the corresponding address in whatever ASCII Code Page is registered by the operating system. The exception is the Control+Alt+Delete combination, which triggers a direct hardware RESET interrupt (on older machines) or the Reset software interrupt routines on later operating systems.
5. Host then delivers whatever glyph in the Code Page has been mapped to the received keycode to the console service routines of the host BIOS.
This layered system allows for different keyboard layouts to be mapped to standard keycodes, and for the standard keycodes to be mapped to different character or glyph sets, while using a standard serial interface. But it means that the controller chip in a particular keyboard is programmed specifically for the locations and functions of that keyboard alone. This constrains the use of such a controller for a different physical keyboard, such as the Soroc.
The Soroc layout has many differences from the standard AT Extended keyboard, including almost all the non-alphanumeric keys, absence of ALT and some IBM-standard keys.
View attachment 11741
The first task was to solder a 24-way cable to the edge connector blades of the controller, where it had originally been clamped to its plastic matrix membrane. The other end is a header plug made up for the 24-pin socket on the Soroc keyboard PCB. For sturdiness, I used rows of machined pins through a piece of perf board rather than piggy-backing a ready-made flimsy socket.
A number of corroded traces were either bypassed or repaired with a silver polymer trace pen. Only one keyswitch had been damaged beyond repair by corrosion. Unfortunately, this was the space bar. Fortunately, there was room inside the space bar to install a standard sturdy mechanical contact switch which is invisible from above, and wire this back to the traces (see the blue wires).
I buzzed out both the Soroc PCB and the Honeywell membrane and tabulated both matrices.
The differences between the row/column addresses of keys were so many that it was best to completely re-map the PCB to deliver switch states as like as possible to what the Honeywell controller was programmed to expect. Almost all PCB traces were cut to isolate the switches, but I was able to use a number of the existing traces to distribute the signals and reduce the wiring load. This is the PCB, rewired with transformer winding wire. Excuse some bodgy soldering.
The Honeywell controller, like standard PS/2 controllers, includes debounce circuits, so no debounce components were needed on the rewired board. At one point I thought I had debounce problems, but the causes were just the usual dry joints, shorts or circuit errors to be corrected.
View attachment 11751
REMAPPING ISSUES
The first stage of remapping was to ensure that every keypress would generate a matrix address recognised by the Honeywell controller. This was the rewiring stage. The second stage would be in software on the PC, using NANSI.SYS, to redirect keys to the desired character or function.
The Soroc emulation does not use the ALT key, but it is needed to provide access to the PC inside the FrankenSoroc for reset, or to use DOS applications for maintenance and programming. I mapped the Soroc RESET key to ALT in hardware, mapped Soroc DelChr function key to DEL, and then in software re-mapped Ctl-Alt-Del to call a small DOS program that just reboots the PC. So pressing Ctl-Reset-DelChr gets the same result as Ctl-Alt-Del on a normal keyboard.
The row of terminal-specific function keys on the Soroc were physically mapped to Honeywell F5-F12. Where possible, these are then re-mapped in software to equivalent ANSI escape sequences for screen management such as deletion and cursor positioning. Some issues are discussed in the related Software post.
The re-created terminal would bypass all that logic and instead mate the switch matrix with a PS/2 controller.
The laptop providing the intelligence for the recreated terminal would need to receive compatible signals at its PS/2 port. A salvaged controller module from a sacrificed Honeywell PS/2 keyboard would need to be able to interpret the Soroc switch matrix as connected at the keyboard header.
Through a long process of experiments and advice from Forum discussions, I found that the apparently simple process of delivering a keypress signal to a BIOS is in fact multi-layered and not necessarily standardised.
The protocol is like this:
1. PS/2 keyboard controller polls switch matrix and registers switch state (one or more keys may be pressed for combinations with shift, control, alt).
2. Controller firmware validates switch state against its internal keyboard map and ignores any unmapped switch state.
3. Controller maps switch state to a 2-byte keycode held in its firmware table, and sends that keycode via serial to the PS/2 keyboard input on the host. THIS KEYCODE IS NOT ASCII.
4. Host keyboard controller and OS reads the keycode and REMAPS it to the corresponding address in whatever ASCII Code Page is registered by the operating system. The exception is the Control+Alt+Delete combination, which triggers a direct hardware RESET interrupt (on older machines) or the Reset software interrupt routines on later operating systems.
5. Host then delivers whatever glyph in the Code Page has been mapped to the received keycode to the console service routines of the host BIOS.
This layered system allows for different keyboard layouts to be mapped to standard keycodes, and for the standard keycodes to be mapped to different character or glyph sets, while using a standard serial interface. But it means that the controller chip in a particular keyboard is programmed specifically for the locations and functions of that keyboard alone. This constrains the use of such a controller for a different physical keyboard, such as the Soroc.
The Soroc layout has many differences from the standard AT Extended keyboard, including almost all the non-alphanumeric keys, absence of ALT and some IBM-standard keys.
View attachment 11741
The first task was to solder a 24-way cable to the edge connector blades of the controller, where it had originally been clamped to its plastic matrix membrane. The other end is a header plug made up for the 24-pin socket on the Soroc keyboard PCB. For sturdiness, I used rows of machined pins through a piece of perf board rather than piggy-backing a ready-made flimsy socket.
A number of corroded traces were either bypassed or repaired with a silver polymer trace pen. Only one keyswitch had been damaged beyond repair by corrosion. Unfortunately, this was the space bar. Fortunately, there was room inside the space bar to install a standard sturdy mechanical contact switch which is invisible from above, and wire this back to the traces (see the blue wires).
I buzzed out both the Soroc PCB and the Honeywell membrane and tabulated both matrices.
The differences between the row/column addresses of keys were so many that it was best to completely re-map the PCB to deliver switch states as like as possible to what the Honeywell controller was programmed to expect. Almost all PCB traces were cut to isolate the switches, but I was able to use a number of the existing traces to distribute the signals and reduce the wiring load. This is the PCB, rewired with transformer winding wire. Excuse some bodgy soldering.
The Honeywell controller, like standard PS/2 controllers, includes debounce circuits, so no debounce components were needed on the rewired board. At one point I thought I had debounce problems, but the causes were just the usual dry joints, shorts or circuit errors to be corrected.
View attachment 11751
REMAPPING ISSUES
The first stage of remapping was to ensure that every keypress would generate a matrix address recognised by the Honeywell controller. This was the rewiring stage. The second stage would be in software on the PC, using NANSI.SYS, to redirect keys to the desired character or function.
The Soroc emulation does not use the ALT key, but it is needed to provide access to the PC inside the FrankenSoroc for reset, or to use DOS applications for maintenance and programming. I mapped the Soroc RESET key to ALT in hardware, mapped Soroc DelChr function key to DEL, and then in software re-mapped Ctl-Alt-Del to call a small DOS program that just reboots the PC. So pressing Ctl-Reset-DelChr gets the same result as Ctl-Alt-Del on a normal keyboard.
The row of terminal-specific function keys on the Soroc were physically mapped to Honeywell F5-F12. Where possible, these are then re-mapped in software to equivalent ANSI escape sequences for screen management such as deletion and cursor positioning. Some issues are discussed in the related Software post.