In today’s installment, we will deal with the numeric keypad (NumLock mode), making it more configurable and revisiting the ergonomics of the keypad placement.
The data flow is as follows. The keyboard matrix consists of 18 columns, with up to 8 keys in each, allowing for a theoretical maximum of 144 keys (of which TECK uses only 88). The physical key index is the column number multiplied by 8, plus the index of key in the column. Here’s the layout as I believe it to be. (It has remnants of the Megawin reference keyboard design in some positions, incl. keypad codes; these are not used anywhere in the TECK firmware unless the wiring is physically modified.)
Col00 | | | Intl4 (Del) | | | Euro2 (´¨) | `~ | |
Col01 | | | | | | | | |
Col02 | A | 2@ | Tab | ❖ | 1! | Q | Z | |
Col03 | RBlank | | Caps | Space | | LCtrl | RCtrl | |
Col04 | | → | | App | ↑ | | | |
Col05 | LAlt | | | Num | | | | RAlt |
Col06 | | | | | | LShift | RShift | |
Col07 | | | | | Fn | LBlank | | |
Col08 | | | | | | | | |
Col09 | W | F1 | PgDn | F2 | PgUp | Esc | X | S |
Col10 | | F3 | Del | F4 | | | | |
Col11 | D | 3# | E | 8* | I | K | ,< | C |
Col12 | G | 4$ | T | 5% | R | F | B | V |
Col13 | J | 6^ | U | 7& | Y | H | M | N |
Col14 | \| | F5 | Enter | F6 | =+ | ]} | ⌫ | ← |
Col15 | [{ | F7 | -_ | F8 | 9( | O | .> | L |
Col16 | '" | F9 | ↓ | F10 | 0) | ;: | P | /? |
Col17 | | F11 | End | F12 | Home | | | |
Anyway, the key index (stored in data variable at #3B) is used with the
PC and Mac keycode tables to yield a keycode (stored at #3C), which is then
checked against 16 values, and if any matches, the corresponding keypad keycode is substituted instead. This all happens in the routine at 084B–095F.
The code that does the translation starts at 08AB and goes all the way through 094C, occupying 162 bytes. This gives me an idea…
08AB 783B MOV R0, #3Bh
08AD E6 MOV A, @R0
08AE 90xxxx MOV DPTR, #xxxxh ; // to be filled later
08B1 93 MOVC A, @A+DPTR ; byte num_keycode = num_keycodes[key_index];
08B2 6002 JZ L9001 ; if (num_keycode) {
08B4 08 INC R0
08B5 F2 MOV @R0, A ; keycode = num_keycode;
L9001: ; }
The code to take a key index from #3B, fetch a keycode from a table and store it into the adjacent variable #3C takes 9 bytes; I also add a zero-check so that one table fits both PC and Mac modes, for a total of 11. Then I’m left with 151 bytes of free code space which will nicely accommodate the
num_keycodes table. I’ll need to LJMP over it:
08B6 02094D LJMP L9002
num_keycodes:
08B9 DB 144 DUP (0)
CSEG AT 094D
L9002:
Now let’s see what this has gained us. Firstly, we are no longer keycode-dependent; we can remap both PC and Mac layouts and the numpad will stay its place. Secondly, we are not limited to 16 keys; if our heart so desires, we can add another keypad for the left hand, or add KP(, KP), KP=, and generally the whole block of keypad usage codes from B0 to DD. I won’t go into this, but I want to reconsider the placement.
The idea of embedded keypad comes from notebooks/laptops. Who was the first to come up with the idea that 7-8-9 stay in their usual place and other keypad keys are arranged around that I don’t know; but this has carried over to Truly Ergonomic without an ergonomics review.
When you use the keypad on a conventional keyboard, the home row position is 4-5-6; KP5 even has a tactile bump on it. However, on TECK in stock configuration, the home row produces 1-2-3; 4-5-6 are entered from the top row; and to type 7-8-9, you have to reach into the digit row.
I therefore propose that the keypad be shifted one row down. While we are at it, also move KP- and KP+ from their intuitive but remote place in the top right corner to somewhere around the main grid.
Before | After |
789 -+ 456/ 123* 0 . | /*- 789+ 4560 123. |
I have mixed feelings about the zero. If you are a left-spacer, you may want to put zero on the right space, as that’s where it is on the traditional keypad, under the right thumb. I myself am a right-spacer so I put zero on the remaining finger on the home row, as it is statistically the single most used digit.
:1008AB00783BE69008B993600208F202094D00000C
:1008BB00000000000000000000000000000000002D
:1008CB00000000000000000000000000000000001D
:1008DB00000000000000000000000000000000000D
:1008EB0000000000000000000000000000000000FD
:1008FB0000000000000000000000000000000000ED
:10090B0000000000000000000054605D5A00000071
:10091B000000000000005C005F6700005900000051
:10092B005800000000000000000055615B5E630092
:10093B000000566257000000000000000000783CE9Again, I warn that this hack is untested (yet).