L3 KeyAT-4 PS/2 input tool working with X16

[voidstar]

I'm trying this out, a device from L3 KeyAT-4.

It's a little expensive - but it does work. By default it is setup to function at 9600 baud (that wasn't clear in the manual).

It lets you TYPE from a terminal of one computer and enter keys straight into the PS/2. Doing this, you can then script a lot of inputs into the physical X16 hardware. And you can use the regular PS/2 keyboard at the same time.

So I load ZOC on the PC, do a serial connection, and anything I type in the terminal then appears in the X16 BASIC prompt.

I'm still learning about it - have a few ideas in mind on how it might be useful.

[voidstar]

Ok, I finally got this working. It's not perfect - it still drops out a character every now and then. I tried RTS and Xon/Xoff control flow stuff, tried faster/slower baud rates, tried shorter wire cables, tried moving cables further from power supply, tried using a single PS/2 connection rather than a dual pair. It's 99% fine, just once in awhile has a drop-out. Waiting on L3 to see if they have any other suggestions - maybe just old firmware.

I tried using the ZOC Terminal program to try to script up what I needed. But then there is a flaw in ZOC where the Send Text File speed isn't throttled correctly. And even if that were fixed, then I realized a "smart terminal program" is needed in order to busy-wait during any DELAY commands.

So - I made one in C# since that was just the readily available API with SerialPort support that I was aware of. It's a little confusing here - the KeyAT-4 itself will operate at 9600 baud. But that baud rate doesn't really matter much - people can't type anywhere near that speed. You're sending commands to the KeyAT-4 at this speed, which it in then in turn interprets on what to send off over to the connected PS/2 device. Those relayed commands need to be "not too fast" (overrun the keyboard buffer) and "not too slow" (as the KeyAT-4 itself has a limited buffer).

Basically this only really started to matter when scripting input from a file. You can obviously read and xmit a file stream of data very quickly - but we have to throttle that down to "keyboard speeds". 300 baud is right around where machines were now starting to be faster than typing (granted even back then they didn't have very good keyboards -- well, they were nice keyboards, but just very bulky and clunky metal levers and such; if you typed too fast, they'd jam!).

So that's the job: taking an input stream, and throttle it to a speed the PS/2 interface can work with. That means about a 30-40ms delay between keystrokes. And one more thing: the KeyAT-4 supports user defined pauses/delays. So you also need to pause the file streaming when those pause commands are specified.


NOTE: If you screw up the settings on the KeyAT-4, you just tap LEFT SHIFT and then RIGHT SHIFT alternating about 10 times to reset it back to the Default 9600 8-N-1 setup. It'll flash the keyboard LED lights when doing so. I thought that was a clever way they offered a settings reset.


Ok, enough explanation:

Here's a sample video of it working on the X16, basically to do some automatic software demonstration playback. Sorry poor quality, but it's just a brief demo to convey the general idea. Hard to explain in a static image - we're not just typing from really far away, all the typing is scripted so it can be repeated over and over for hours (testing or demonstration), but it can be used to just CTRL+V code from your laptop over to the actual hardware.
https://www.youtube.com/watch?v=mZKjZ7GJeAQ

Here's the supporting code (C#) that I put together, with a prebuilt Wintel Release executable, and a simple script input (a script input isn't required, you can also use this free-form and engage interactive mode yourself):
https://github.com/voidstar78/KeyAT4SerialHelper

This "SerialHelper" mainly helps throttle things down when user-defined Delays are being used (and that it can Repeat an input, so can leave a demo going for hours).

[voidstar]

Diagram if it helps.

Can use an older laptop that has a native/onboard RS232 port. Or heck, use another X16 or some vintage system

[voidstar]

I finally got time to drag out an older Win10 PC I had in storage that still had a PS/2 keyboard port on its mainboard. It's a system from about 2008.

I wanted to see if this L3 KeyAT-4 device would work with that, and if it had any of the similar "drop out" issues I saw on the X16. And the result is: it does not. I scripted up a sequence (that I could also later play on the X16), and I never noticed any drop out on the Win10 box using its PS/2 input (and just scripting the text into regular notepad.exe). It went overnight, hundreds of repeats of the sequence, no issues.

So then I ran the same sequence on the X16. And basically it couldn't go two repeats in a row without having some minor mishap. Once in a while the full sequence did go flawlessly. But every once in awhile, it would either repeat a character (stutter), drop a character, or misinterpret a character (including adjustments to modifiers like shift and CTRL).


There is thought this may be related to the second 6522 being moved from NMI to IRQ, and maybe two devices are throwing an interrupt at the exact same time. (note: also seeing this when slowing the clock down from 8mhz to 4 and 2mhz)


Has anyone noticed, during regular typing while on the H/W system, any odd character behavior? In the automated typing KeyAT-4 provides, the fastest between keystrokes it about a 30ms delay (simulating the time of fully depressing a key and waiting for the return back up). But I've tried many slower delays also - I'm thinking next to try a "random" amount of delay (say between 45 and 80). I do think that on-system (on the X16) I've noticed a couple times a character mishap when typing in some BASIC - but it's been awhile, I'll just pay extra attention if it ever happens again.


The demo sequence is 508 bytes. If it appears to be having a mishap on 3 characters per that sequence, that's still over 99% accuracy. But it's enough error to mess up a scripted sequence.

IMG_1550A.jpg (541.62 KiB) Viewed 4667 times

[Stefan]

Interesting work you’ve been doing.

The SMC is responsible for the communication with the keyboard. VIAs or 65c02 interrupts shouldn’t affect.

A keystroke (key down+up) puts two key codes in the SMC keyboard buffer. If the X16 is running normally, it fetches one keycode per 16.67 ms. The theroretical max speed before key code drop outs are inevitable is thus one keystroke per 33.33 ms. If you’re going any faster, the SMC buffer will fill up

But then you have keystrokes that are misinterpreted. It’s really hard to debug without a capture of the ps/2 transmission.

If you could make a table of the misinterpreted keys (sent key -> received key) that could be used to begin analyzing the issue

[voidstar]

Actually in the one I marked GREEN as "OK" - it has one mistake, one of the "F" came out as "D" (but there are instances where the full sequence did make it through ok)

Also to be clear, it's no issue about X16EDIT - it'll happen at the BASIC OS also, just the X16EDIT is just easier to show inputs without treating anything as "syntax error."

It's not very consistent, like "4" became "e" once, "A" to "a", "2" to "left pointing arrow". Sometimes letters get interpreted as CTRL characters (like it would randomly show the X16EDIT help now and then, so CTRL+G somehow even though no CTRL inputs are in the scripted input).

[Stefan]

Ok, let’s look at 4->e

ps/2 scan code for 4 is 0x25

e is 0x24.

So the SMC lost the least significant bit.

Making even a small table of failed transmissions will tell us a lot. Is it always bit 0? Is it always a 0 bit instead of 1, and never the other way?

[Stefan]

Missing a bit every now and then suggests that the SMC can’t keep up with the speed of transmission. It’s important that the SMC fuses are set to run it at 16 MHz.
You need an external programmer to verify the fuse settings. You could also use an Arduino Uno

[voidstar]

Wanted to report that with SMC 47.1.0 this KeyAT-4 PS/2 device is working fine.

I ran it on two X16 systems overnight, and the key-input-script was still repeating the expected sequence perfectly (including both typing in a simple BASIC program, exercising EDIT, exercising movement in KG3D, then resetting the system and repeating that sequence).

For the "SerialHelper" program described previously, I was able to set the "key delay" from 70 down to 40 (ms delay after each key stroke). Dropping it to 20ms was "too fast" and the script would start to stutter there. Attached is one of the example scripts, showing how to issue delays (Z-code) and key presses (down and up, using specific key scancodes), running EDIT and handling exiting back out of it, and issue a CTRL-ALT-DEL.

So a neat option, if you just want to set the X16 off doing "interesting things" throughout a presentation (or really any system with a PS/2 kbd input).