[A Project to interface a PS/2 keyboard to a 68hc11 microcontroller]
Well, wouldn’t you know it? What a day for my 17-year-old Omnibook laptop to decide that it doesn’t want to work anymore! The darned thing will charge the (brand new) laptop battery happily, but refuses to recognise that it is holding any charge – the bloody BIOS battery calibrator insists that the charge capacity is -384 mAh. You read the right: a negative capacity! And of course, coming from a Tier-1 manufacturer, it refuses to boot past BIOS if the (miscalculated) capacity is too low.
Strangely, there is a perverse logic at work – I can see why it would think that a negative capacity is too low! Too clever by half.
Even after a whole day of BIOS-recalibrating the nominally 2100mAH new battery, without any joy, I tried same with the spare somewhat aged battery, which the laptop itself rated as 1530mAh a few weeks ago. Nope – it now also rates this one with negative capacity. Went through the whole re-calibration process again and again, with the docking-station detached, and then again and again with the alternate spare docking-station attached. Nothing doing.
I guess that will teach me not to blog about how wonderful my development platform hardware is…
A Delayed Solution
Given the absolute need for an RS-232 serial-port to talk to the target SBC, there was only one choice left – decamp the whole show onto my 24-year-old SPARCstation-10. Fortunately, I had the project program code on a USB stick (and also on my website), so at least I didn’t have to go rewriting the programs.
However, it seems I have misplaced my 25-pin serial cables (and the RS-232 port-splitter for the SS10, oh no!), and spent ages hunting through storage boxes, drawers, underneath the cupboard, et al, trying to find suitable cables. Eventually I dug one up from underneath the bedside cabinet – the requisite cable was attached to an old POTS modem, and somewhat cobwebby, but at least it works.
Meet the Cherries
Late afternoon, back in action, thank goodness. Now although this project description refers to “PS/2” keyboard, ie: any such keyboard, I feel that given the title, it is reasonable to prove it using a Cherry keyboard. Or even better, two of them. It seems that many retro-computing enthusiasts regard Cherry keyboards very highly. Although that could be about to change…
Probably the oddest pair of Cherry PS/2 keyboards one could find. The large kiddy-coloured one is missing a lot of standard PS/2 keys, although for the keys it does have, it reportedly delivers standard PS/2 scancodes, no special software-drivers needed or anything like that.
The other, super-compact keyboard, has all the usual early-1990s PS/2 keys (no “Win” key, or media-keys, but I am not a big fan of either of those) and also delivers standard PS/2 scancodes. Mind you, it is extremely dirty:There be lumpy green stuff in there – a new form of life?
On The Trail
In the previous episode, counting incoming clock-pulses from the keyboard was almost, but not quite, working perfectly: getting 33 pulses per keypress+release, instead of 22 (11 for press plus 11 for release), in spite of somewhat-guessed RC-damping to prevent ringing.
My initial thought, due to an old posting on a ‘net forum, was that 18pF was not enough capacitance – the suggestion there was 100pF, although my own calculations suggested a much smaller value would be appropriate, something below the 18pF I was using (I don’t have any smaller caps to hand). So the next step is to try more capacitance-to-ground at the 68HC11 pin, as per that forum post. Not really what you could call an improvement: 54pF didn’t do the trick. Worse, the large Cherry keyboard just delivers a steady stream of clock interrupts, but not in multiples of eleven, and not as fast as 10KHz – somewhat erratically, rather like the Dell keyboard from the last episode. On the other hand, the compact Cherry keyboard seems to be delivering a reliable stream of 33 clock-pulses for each keypress+release, every time.
After spending six hours fiddling with the interconnect (removed current-limiting, tried stronger pullup, experimented with powering the keyboard from the SBCs own regulator [cripes 275mA extra power-up load], tried 10nF smoothing capacitor instead of 18pF [getting desperate now]). Absolutely no differene whatever.
I had prepped a program to capture the dataline-bitstream, synchronised on the falling clock-edges, and decode it into a buffer of incoming scancodes (byte-sync on start-bit, ignore parity-bit, and store on stop-bit); I figured it might be worth
seeing what that program could report.
For the K key, the bytes recieved were: 42 0F 42. Wait a cotton-picking minute, let’s take a look at the scancode table documentation again – that sequence is correct!!!!
I had forgotten that the release-codes are a 0F byte followed by the same code as the press-code, so of course there are 33 clock-pulses, there are supposed to be!
Not Quite Victory
However, not all keys are reporting the correct codes: S, Q, and space are reporting a reliable unique code, just the wrong one. The Insert key seems to be reporting a nibble-swapped code, reliably. But K is a solid and correct 42 hex. I need to check the alternate scancode tables (set 1, and set 3), just in case; and put the interface circuit back the way I had it originally… but at this time of night, sleep is the first order, live to fight another day – the last day of RetroChallenge.