Commander X16

I've been following the progress of a pretty significant change to how keyboard scancodes are going to work, and saw that the pull request just got merged. I thought it would be pretty helpful to have a diagram of it (and needed something fun to do), so here it is:

,---,   ,---,---,---,---, ,---,---,---,---, ,---,---,---,---, ,---,---,---,
| 6E| 6F| 70| 71| 72| 73| | 74| 75| 76| 77| | 78| 79| 7A| 7B| | 7C| 7D| 7E|   o     o     o
'---'   '---'---'---'---' '---'---'---'---' '---'---'---'---' '---'---'---'
,---,---,---,---,---,---,---,---,---,---,---,---,---,-------, ,---,---,---, ,---,---,---,---,
| 01| 02| 03| 04| 05| 06| 07| 08| 09| 0A| 0B| 0C| 0D|!0E->0F| | 4B| 50| 55| | 5A| 5F| 64| 69|
;---'-,-'-,-'-,-'-,-'-,-'-,-'-,-'-,-'-,-'-,-'-,-'-,-'-,-----; ;---;---;---; ;---;---;---;---;
| 10  | 11| 12| 13| 14| 15| 16| 17| 18| 19| 1A| 1B| 1C|   1D| | 4C| 51| 56| | 5B| 60| 65| 6A|
;-----',--',--',--',--',--',--',--',--',--',--',--',--'-----; '---'---'---' ;---;---;---;   |
| 1E   | 1F| 20| 21| 22| 23| 24| 25| 26| 27| 28| 29|!2A-->2B|   4D  52  57  | 5C| 61| 66|!6B|
;------'-,-'-,-'-,-'-,-'-,-'-,-'-,-'-,-'-,-'-,-'-,-'--------;     ,---,     ;---;---;---;---;
| 2C<-!2D| 2E| 2F| 30| 31| 32| 33| 34| 35| 36| 37|!38---->39|   4E| 53| 58  | 5D| 62| 67| 6C|
;----,---',--'-,-'---'---'---'---'---'---'---',--'-,----,---; ,---;---;---, ;---'---;---;   |
| 3A | 3B | 3C |              3D              | 3E | 3F | 40| | 4F| 54| 59| |!5E->63| 68|!6D|
'----'----'----'------------------------------'----'----'---' '---'---'---' '-------'---'---'

!XX--->YY means, the position of XX is not used and the key actually triggers YY.
Between right ctrl and insert, the position numbers skip enough to add 2 extra columns of keys.

The other reason I made this is because I've never actually heard of IBM's key numbering scheme (I've only known the scancode sets), and looking at the way they logically distributed the key numbers around was really interesting to see. I like how even though the numbers skip around, the skipped numbers still correspond to the physical location an individual key would be, and indeed, even though this is the ANSI layout, the ISO layout ends up using the codes you'd expect.

It should go without saying, but anyone's free to use and modify this however they want.

This looks really great.

Thanks!

That chart looks legit! I've been using the new scan codes for the last couple of days, and so far it works great. I've only found one anomaly, but fortunately it's pretty benign. The scan code for the Num Lock button should be $5A, but it reports as $00 ($80 on release.) Is that code missing? It's not a deal breaker, I simply mapped all the numpad keys to their number mode and left it at that. It's not like any of those are the cool keys, like the Grave or the Underscore!

That sounds unintentional; the "zero" keycode is supposed to mean "no key". At least, that's what custom keycode handlers are supposed to return when we want to skip the kernal's built-in key-to-character handler. Maybe plop that in the bug report forum?

I made a pull request to the emulator project adding support for the NumLock key. This also fixes the 0x80 returned when releasing a key not supported by the emulator.

Well, as long as all the great minds of PS/2 scan codes are all here in one spot... I have a question!

There are two buttons that are odd birds, these are the Caps Lock and Num Lock buttons. The use is obvious: Each time they are pressed, they set the state of a key override to TRUE, then when they are pressed again ("Pressed again" is defined as pressed after released from the first press.) They set it to FALSE.

OK. That's pretty straight forward. Except for one thing... The KEYBOARD, completely independently of the computer, ALSO shows an LED connoting the state of the control. You can start them in sync as you can assume the initial state on a cold start, but an application cannot know a cold start just occurred.

It's a conundrum!

A PS/2 keyboard does not track the state of those keys. The host sets the status of the LEDs

Yep, I just confirmed that in the Kernal rom too. The CX16 receives caps lock keydown and toggles caps lock mode in the Kernal's keyboard handler, and sends the appropriate state for the LED back to the keyboard.

Next, the Kernal doesn't actually care about numlock. It's treated just like any regular key, and the key mappings leave it at 00, so numlock is nothing except a keycode for custom key handlers at the moment. The numpad keys are always mapped to numeric inputs, and the Kernal hardcodes the numlock LED to be always ON.

Scroll Lock is repurposed into the 40/80 Display key, and the Kernal does treat it like a toggleable modifier key but doesn't factor it into the key mapping table lookup (it's used somewhere else instead), and the scoll lock LED is hardcoded to be always OFF (unless some other part of the Kernal uses it, but the keyboard handler does not).


Finally, only tangentially related, the Kernal does treat caps lock as though it's a modern caps lock (i.e., some keys react like shift is pressed, but other keys don't), but on the official CX16 keycaps, you have "shift lock", which at least on the C64 was a latching key that just made the computer think left shift was constantly held down, meaning every key gives you the shifted character. So, the terminology might technically be wrong, which isn't a big deal, just a fun fact.