Unicomp PS/2 controller quirk (New Model M)

User avatar
an_achronism

04 May 2021, 03:45

I posted about this elsewhere but I suspect most probably have the USB version of this board rather than the PS/2 one, so I didn't get much of a response. I'm wondering if perhaps I might have slightly better luck here. I'm looking for PS/2 Unicomp Model M owners to try something and report back in this thread, for Science! (This is also my first post around here. Hi! Incidentally, if you happen to have any old IBM and/or Alps boards that would be considered "fixer uppers", let me know; I'm on the hunt for some projects.)

The gist is basically that my New Model M (manufactured less than a month ago) fails to perform a Break with the Pause/Break key. It appears that it is neglecting to treat the Ctrl modifier correctly: instead of switching from the Pause scancode sequence to the Break one when Ctrl is held, it just performs a modified version of Pause (which isn't really a thing) which does nothing other than releasing a Pause if one is held at the time, which you could do by hitting just about any other key, I think (e.g. Enter, or Space, or whatever). Pause works just fine, but Break doesn't work at all. This can of course be worked around by just using Ctrl + Scroll Lock instead, which is the legacy (PC/XT/AT) way of performing a Break. However, it nonetheless slightly bruises my plums to have a "Model M" that doesn't have a working Pause/Break key, considering the Pause/Break key was – unless I am mistaken – a Model M invention in the first place.

Image
Liar!

I already mentioned it to Unicomp but they are apparently understaffed at the moment so it's taking them over a week to respond from one message to another (there are other issues I have with my New Model M as well, to be fair, so there are a number of things they're working to address). In the meantime, I'm curious to try to identify roughly when the problem seems to have begun. They told me that their PS/2 controller code had been locked down for years, and claimed that they had never heard of this being an issue before, but I'm definitely not crazy here because I've tested multiple other boards and they all work just fine on the exact same system, port, and OS (Pause/Break performs Pause and Ctrl + Pause/Break performs Break). But yeah, to quote Unicomp:
Unicomp wrote:The PS2 code hasn't been touched for a long time, and I have never heard this complaint before.
(...)
Unicomp wrote:A replacement board would be the only way to fix it, but I'm not sure the engineers would be willing to break the freeze on that code to update something for which there is already a workaround.
(This isn't necessarily true, as it would be very easy for me to just switch out the controller PCB if they wrote a new one of those and shipped that... which would be significantly cheaper because I'm in Scotland, nowhere near Kentucky.)

Anyway, here's how it goes...

PAUSE:
Spoiler:
1. Pause/Break key is pressed, sending a "make" scancode equivalent to pressing and holding either Ctrl key followed by the Num Lock key. This executes a Pause immediately, regardless of whether the key is pressed and release or pressed and held. In AutoHotkey, the reported "scancode" is 045, which (in "set 1" terms) does appear to relate to Num Lock. The reported virtual keycode is "13". SharpKeys reports it as "00_45", which it identifies as "Num Lock" (whereas it reads the actual Num Lock key as "E0_45", which it calls "€").

2. Pause/Break key is released, sending the appropriate "break" scancode (as in key-up, not as in Break function) to indicate that.
BREAK (normally):
Spoiler:
1. Either Ctrl key is pressed and held, sending the associated "make" scancode (varies depending on whether it's left or right Ctrl).

2. Pause/Break key is pressed, sending a different "make" scancode from before, which is related to the original way of obtaining a Break by holding Ctrl and pressing Scroll Lock (as just as the Pause code is related to holding Ctrl and pressing Num Lock). As with Pause, the action is executed instantly, whether the key is held or pressed and immediately released, it's just that this time it executes a Break instead of a Pause. AutoHotkey reports the scancode here as 146 rather than 045, which does indeed correlate it with Scroll Lock; I believe the actual scancode is E0_46 and AutoHotkey is for whatever reason displaying the hex "E0" as "1". The virtual keycode AutoHotkey attributes to this is "03", and it identifies its function as "CtrlBreak".

3. Both keys (Ctrl and Pause/Break) are released, in either order. Sends the appropriate break / key-up codes.
... buuuut my New Model M does this instead...

BREAK on New Model M:
Spoiler:
1. Either Ctrl key is pressed and held, sending the associated "make" scancode (varies depending on whether it's left or right Ctrl).

2. Pause/Break key is pressed, sending a scancode that AutoHotkey reports as "145" (I think meaning "E0_45"), virtual keycode "FF", and describes as "not found" rather than the expected "CtrlBreak". This fails to generate an actual Break. Instead just acts like pressing another key (e.g. Enter, or Space), which releases a Pause if there is one in place, otherwise it does nothing (it doesn't create a Pause if there isn't one active, because the scancode is changed, but isn't valid for Pause).

3. Both keys (Ctrl and Pause/Break) are released, in either order. Sends the appropriate break / key-up codes.
When I asked this elsewhere, the one reply I got verified that a 2013 Unicomp Classic did perform a Break from the Pause/Break key correctly, although I don't (yet) know if that was an ANSI or ISO board.

If you have a post-2013 PS/2 keyboard from Unicomp that has a Pause/Break key, could you please do me a favour and see what happens if you hit Ctrl + Pause/Break? Doesn't massively matter how you verify this, as long as you can verify it: you could look at the results in AutoHotkey or something else that can look at scancodes, or you could just run some command or another that you can stop with a Break in order to verify whether it actually does stop or just Pause instead.

I'm wondering if part of it might be to do with mine being a UK ISO board, which may be treated as something of an afterthought next to ANSI. It could be that it's borked on every board they've sold with PS/2 for years, though, and just never noticed because it's a really specific thing. I'm guessing that it's a really small subset of their customers who will use Pause/Break routinely, and of those, some probably have USB boards instead of PS/2 ones (and for all I know, their USB controller might be fine).

User avatar
sharktastica

04 May 2021, 21:21

Familiar face, eh? :D Good luck getting to the bottom of this. As I said on r/ModelM, I couldn't replicate this issue.
an_achronism wrote:
04 May 2021, 03:45
I'm wondering if part of it might be to do with mine being a UK ISO board, which may be treated as something of an afterthought next to ANSI. It could be that it's borked on every board they've sold with PS/2 for years, though, and just never noticed because it's a really specific thing. I'm guessing that it's a really small subset of their customers who will use Pause/Break routinely, and of those, some probably have USB boards instead of PS/2 ones (and for all I know, their USB controller might be fine).
That shouldn't matter though since the language/layout functionality of modern keyboards is usually handled by the OS, thus the membrane and controller should be the same (for a given product/generation, of course). On that same keyboard I tested for this issue, if I remove the ANSI enter or left shift keycap and press the membrane contacts underneath the stab inserts whilst Windows is set to UK English, it outputs #~ or \| as expected for a UK ISO keyboard.

User avatar
an_achronism

04 May 2021, 22:18

sharktastica wrote:
04 May 2021, 21:21
Familiar face, eh? :D Good luck getting to the bottom of this. As I said on r/ModelM, I couldn't replicate this issue.
Hahah, hi!
sharktastica wrote:
04 May 2021, 21:21
That shouldn't matter though since the language/layout functionality of modern keyboards is usually handled by the OS, thus the membrane and controller should be the same (for a given product/generation, of course). On that same keyboard I tested for this issue, if I remove the ANSI enter or left shift keycap and press the membrane contacts underneath the stab inserts whilst Windows is set to UK English, it outputs #~ or \| as expected for a UK ISO keyboard.
Aye, to reiterate what I said over there, I knew this, so I dunno what the hell I'm talking about here: clearly if you stick flippers and keys into the unused spots on an ANSI board you get input and ditto if you split the ISO Enter so it makes no sense that the controllers would be any different. Brain fart, evidently.

Nonetheless, I haven't heard from Unicomp in a week, again. I don't know how much of the delay is due to short staff and how much is due to them trying to figure out what to do about this (i.e. how to tell me "deal with it", but politely).

I guess at some point in between your 2013 board and my 2021 board they changed the PS/2 code for reasons unbeknownst to us and accidentally borked Break in the process, but because you can just get Break with Scroll Lock instead they aren't especially motivated to fix it. I realise it's a really minor niggle but it's still rather irritating...

User avatar
an_achronism

Yesterday, 13:26

Quick update on this. Unicomp finally came back to me again (it's >7 days between messages each time so far) saying they are at least forwarding it to "the" engineer, but said the guy was way overworked so it's going to take ages to investigate. Fair enough. Clearly it isn't a high priority issue. They also said they would happily write any corrected controller to a PCB for me rather than having to replace an entire board, which suits me fine (it was me who suggested doing that). They also asked for scancodes though, which I already gave them, but I guess they missed that in amongst me *also* giving them virtual keycodes from AutoHotkey as supplementary info. So I took screenshots of Switch Hitter showing not only the scancodes but also the BIOS codes. I figured I may as well stick them here as well.

Click the thumbnails for full size...

Pause from Pause/Break key (works normally):
Image

Break from Pause/Break key (totally borked on New Model M):
Image

Break from Scroll Lock key (works normally):
Image

Post Reply

Return to “Keyboards”