It's time to implement keypress detection for the 18 lighted switches. The two demultiplexers "M" and "N" share a number of their inputs; "DMX SEL" (pins 1, 2, and 3), as well as "G2B" (pin 5) and "G1" (pin 6). Again, both these demultiplexers are socketed, allowing me easy access to tap into their pins. However, "G2A" (pin 4) are addressed separately; and the respective outputs go to the "output enable" pins ("G1" and "G2", pins 1 and 19) on the bulb control chips "D", "E", and "F" (for "M") and the key sensors "J", "K", and "L" (for "N").

As stated previously, I'll need to provide DMX SEL signals for the LS138 "N", and read out signals on pins 12-19 of one of the PALCE chips ("T", "V", "X", and "Z" -- they're all connected in parallel). I'm going to solder leads from the ribbon cable to a chip header which I can then drop into one of the sockets on the board.

On the Teensy side, I can re-use the same pins for the "DMX SEL" and return signals as for the rest of the keyboard interface, and I'll dedicate two pins for "G2A" signals. Oddly, the long green patch wire connects "B Select" from "M"/"N" to pin 31 on the VFD daughter board; this is not used by the VFD, so what is its purpose?

For example, pressing [VFD Menu 1] (key #13) signals pin 11 on "K", which will output a signal on pin 9 to pin 16 on one of the PALCE chips (as well as pin 4 on "S" but we don't care about that just yet). However, that is only the case when the "Output Enable" (pin 1+19) on "K" is active, which is controlled by pin 14 on "N" by setting its G2A low, and configuring its "DMX SEL" to "H/L/L".

I've expanded my existing kepboard driver to include the "G2A" pin of demultiplexer "N" to scan the lighted keys. The "DMX SEL" signals are used differently than for the other keyboard parts; rather than using the entire binary sequence they are simply addressed one-by-one. Therefore, I've modified my driver's sequencing to not run through the full 0b000-0b111 sequence but only 0b000, 0b001, and 0b010, so that the scanner doesn't waste time checking dead leads. For code efficiency, on the "L" chip 6/8th of the return line scan will be superfluous, but in terms of response time that's (hopefully 🤞) negligible.

I've yet to do the solder work to see if it works as intended (ominous foreshadowing).

(This did, in fact, turn out to not work, as I'd somehow ignored that the keyboard uses active-low signalling, but the main board switches use active-high signalling, thus borking decoding entirely.)