PIC-based Symbolics keyboard adapter

This page is to capture the (still rudimentary) design of a PIC-based adapter for the Symbolics keyboard.

The overall vision I have includes
  • Using the ESUART in synchronous mode with the PIC as a master device to clock key matrix data out of the keyboard
    • [UPDATE] The ESUART in master mode produces a symmetric duty-cycle clock which does not work with the Rev. C keyboard microcontroller. Instead, I may have to use a PWM output from the PIC to create a asymmetric duty-cycle, and hope the ESUART in slave mode will respond to it properly.

  • Accumulate the ESUART input data bytes into an 16-byte "working buffer"
    • [UPDATE] 15 bytes should be sufficient for 120 scan codes. Potentially, these can be compressed to 11 bytes for the 88 scan codes actually used, if the time for compression is outweighed by the time-savings in debouncing 88 bits instead of 120.

  • Debounce the working buffer data by comparing against a "last-stable buffer"
  • Translate the debounced key matrix into key-up and key-down events
  • Either include support for the computer-side protocol in the same PIC, or communicate to a separate PIC through the SPI; I think the keyboard side would be master
  • Somewhere before reaching the computer, translate the key-up and key-down events into a host-compatible format, probably involving the accumulated modifier state + platform-dependent key-down and key-up events

The tricky parts are going to be the overhead of debouncing, the frequency with which the 128-bit key matrix data has to be scanned, and the complexity of translating the Symbolics keyboard to "modern" systems that don't incorporate Super and Hyper modifiers, as well as multi-byte keystroke events. This page shows how Symbolics did the reverse, mapping a Mac keyboard to emulate Symbolics.

Looking at Microchip's ADB app note, I'm left to wonder exactly how much time is available to service the keyboard side. I might have to crank up the microcontroller frequency to be able to continuously move the key-scanning data into the work buffer. As far as I can tell, the minimum processing for an interrupt is going to be about 20 instruction cycles: with an ADB bit interval of 100 microseconds, and a need to bit-bash and monitor an interval of about 65 microseconds for bus-collisions, and a 1 microsecond instruction rate, there doesn't seem to be much lee-way at the 4 MHz clock rate.

The example ADB application explicitly grants a few hundred microseconds to the non-ADB task at a couple of points in the transaction. That hopefully will be enough to do the debounce processing, massaging of the keyboard serial data into ADB format, communicating data to the ADB task and handling all the non-interrupt based keyboard serial port stuff.

Comments

Post a Comment

Popular posts from this blog

Open Genera VLM on Linux

There are some existing guides to setting up the (unauthorized) Open Genera VLM on x86-64 Linux, but I wanted to tweak them a bit, and came up with a couple of items that diverge from the existing advice. Note that a bunch of URLs on that link should point to https://archives.loomcom.com/  not the static.loomcom.com address. My general goals were to avoid having to run the genera binary as root, and run as a distinct user to have some sense of security (even if the sense is misplaced). I also wanted to change the network addresses, and don't want to use the standard pathnames for the Unix system files and the user directories, and the changes to do so were only in screenshots. My setup Ubuntu 18.04.4 LTS, amd64 My Linux machine is named ubuntu I want all this simulated Genera stuff to happen on  subnet 10.0.10.x  with my Linux host under the name  genera-ubuntu  at 10.0.10.1  and the virtual Lisp machine genera  at 10.0.10.2  (...
Read more

Restoring the Heathkit Jr 35

Image
Heathkit Jr Electronic Workshop "35", Model JK-18 The Heathkit Jr 35 evidently had been stored with batteries in the battery holder, which corroded badly. I replaced it with a plastic RadioShack 4 D-cell battery holder (270-389), wired into the negative power rail and the hot side of the power switch (which is part of the variable resistor). Corroded battery holder Replacement battery holder mounted I mounted the replacement battery holder with a dozen "heavy duty" 1 inch foam double-stick mounting squares (rated to hold 900g), stacked in four groups each three high to overcome the various screws protruding through the main board. The remote speaker station The rubber foot used to protect the relay from being crushed when you turn the kit over was stuck to the remote speaker station. I put it in its rightful place. Relay with the brown rubber foot Earlier, I had built a couple simple circuits, which showed the meter and new battery pack w...
Read more

FPGA selection for beginners

I'm not particularly expert on FPGAs, but I feel like sharing some of the thought process and research I did in getting into tinkering with FPGAs to help other people contemplating such things. Why FPGAs? FPGAs are the go-to solution for "digital things that can't be done with Raspberry Pi, Arduino, or other microcontroller plus software." If you want more than a handful of discrete digital devices in your project, an FPGA (or its smaller cousin, a CPLD) can be whatever collection of gates you need. From a more industrial perspective, they are a stepping-stone to the kind of large-scale digital design that goes into developing ASICs and high-powered DSP solutions. I'll probably discuss later some of the things that are probably not suited for FPGAs and assume for now you at least understand what they are, what they can do, and you just really, really want to use one. You want to buy an FPGA for good reasons and can't decide which: how to choose? Choo...
Read more