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

Popular posts from this blog

Open Genera VLM on Linux

FPGA selection for beginners

Restoring the Heathkit Jr 35