# Why?

My motivation for this entire thing is simply that I used to work on one of these back when I was working in the film and television industry. I still think it's a cool piece of technology that would be fun to have around. Not for video editing -- that era is firmly gone -- but as a toy, or a console for home automation, and surely as a conversation piece (I have thought of wall-mounting it. It's not as subtle as a Z80 next to a Firefly doorframe).

In my opinion, the key switches are frankly quite too crummy for any serious typing. The acoustics are unpleasant and the linear travel give zero tactile feedback when a keypress has registered. That means I won't ever use this as any sort of "primary" keyboard, but nevertheless this is a fun project that will certainly be a learning experience.

I'll say this: my kids love to pretend-type and fiddle around with all the knobs. This thing is practically begging to have a whack-a-mole style reaction game built into it. Also, those dials and displays look like they might be used to make a fine controller for Kerbal Space Program, do they not?

---

# Director's commentary

I originally started this project in August of 2022 when, after having dreamt about this for several years, I finally managed to snag an old console from an online auction. It cost around 270 USD including transatlantic shipping and was missing a power supply, but I figured I'd be able to work something out. Also, the listing was only for the console and did not include its back-end video editing "brains" (which I wasn't going to need anyway).

As life events happened, this project got put on hold for over a year but was eventually resumed. This was going to be my first reverse-engineering, firmware-tinkering, microcontroller-programming endeavour so I made copious research and notes. Initially I chose a Teensy 3.5 board because of its plethora of 5V-tolerant GPIO pins and easy USB HID device mode. I had success implementing the "regular keyboard" part as well as mapping some of the extra keys ("Eject" obviously, but also "File Manager" and such), and even got the display output working. But, alas, shortly after I resumed work on the project the Teensy stopped responding over USB and some of the power-regulating circuitry was clearly roasting. Conceding that the 3.5 is now obsolete (and just as hard to come by as the console) I then switched horses to an STM32 device which set my implementation back a bit while I figured out how to make it safely interact with 5V TTL components.

I figured it was time to take a moment to take stock and condense my meandering newbie logs into something more presentable. So what follows is a rewrite of a number of my original project logs.

# Open source

Not that there was ever any doubt, it just took me a moment to have something worthy of sharing: this project is naturally open source insofar as that even makes sense, given that the intended hardware for it is both rare and expensive. As of this writing, the code resides at GitHub and is under a 3-clause BSD license.

---

# Origin

This is part of a console for a film/tv editing system. This is just the control panel; the actual brains of the thing, including the interfaces to the rest of the production equipment, reside in two separate rack-mounted chassis (yup, that's plural), which I don't have. Not that it matters; those cost several times as much as the control panel itself, which is already plenty expensive. Besides, I don't plan to use it for film production anyway, although back in the day I used to work with ones just like this.

The manufacturer, Accom, folded in late 2005. Their web site is now defunct, and their documentation is not that easy to come by since the archive does not include their FTP site. I have since found that support continued under the Abekas name, which was eventually acquired by Canada-based Ross Video. I have reached out to current and former staff at these companies, contacts listed as international distributors, and repair centres around the world -- in the hope that someone, somewhere, has kept some of the old paperwork around and is willing to share. So far, no luck. This means I'll have to reverse engineer it.

## Physical appearance

The control panel is fairly hefty: The thing weighs around 7.7kg, is 78cm wide, 16cm tall, and 32cm deep.

In total, there are 189 buttons, 23 of which are individually lightable. The majority of the keys are, according to keyboard enthusiast Chyrosran22, Cherry MX Black switches topped by DSA-style Cherry M8 key caps, which are in three shades of grey with lettering that is engraved and painted. Of the lighted buttons, 18 use specialty switches of frankly underwhelming feel and caps with replaceable labels.

All of this is arranged into a full qwerty layout, a combined numeric/navigation block, five banks of 12 keys each, other minor clusters, and a 2x40 character VFD display with a blue-on-black colour scheme surrounded by six sets of lighted switches, dial knobs, and keys. There's also a large trackball (although with no mouse buttons nearby), and a solid-metal jog wheel.

On the back there is a 6-pin XLR socket for power and a DE-9 socket for the RS-422 serial connection to the comms chassis (neither of which I will end up using). On the inside, there is plenty of space to hold a new microcontroller and additional modern electronics necessary to repurpose this thing.

---

# My plan

In short, my plan was to convert this console to be useful as a glorified keyboard in the context of a modern pc. I will eventually make use of the display and other blinkenlights (plus SD card storage on the new microcontroller board) to have some form of onboard configuration (or even mini-games), but I have zero intention of this being "a computer" in its own right, nor primary keyboard for my main computer.

## Do I keep it original, or rip out the guts?

Keeping the original hardware functional could be a nice touch -- although this thing is unlikely to ever again see the inside of an editing suite. The sentimentalist in me says to keep it original; the realist says screw it. In reality, this thing runs on a Zilog Z80 CPU taking instructions from firmware chips that I have neither the inclination nor the skills to reprogram. Further, it talks a very domain-specific language over an RS-422 connection, which is not exactly the plug-and-play interface that would make this useful on a modern pc.

So I'm keeping whatever hardware is needed to drive the keys, knobs, trackball, and lights. Everything else stays in place for structural reasons but will get electrically disconnected so as to not interfere with the new functionality.

## Additional functionality

This thing has a lot of blinkenlights, and it would be a shame to not use them! Just off the top of my mind, the display and those dials could be used to select audio in/out devices and adjust volume levels; per-app tool setting adjustments; media center integration; home automation; etc.

Sidebar: Stream Deck I came across the term "stream deck" which is apparently a highly polished macro keyboard that costs just over half as much as my entire console. As with everything, it has its pro's and con's, and "of course" it has no Linux software. But hey, here's the keyword should you be searching for it. Of course, there are free alternatives, such as deej. I haven't looked too closely at that yet; I might be able to make use it or some of its ideas.

---

# First look

I've taken the thing apart, mostly in order to clean it and identify its components. I had a bit of trouble getting the jog wheel off, as it's fastened to the rotary encoder by two deep-set 1/16th-inch hex screws -- and nearly all my tools are metric. I got it off, but now it's not very tightly affixed. No matter.

Wowza, that thing is solidly built! The enclosure is bult of 4mm aluminium sheet that seems to have been either laser cut or machined; the way that the blue-tinted plastic sheet covering the display is recessed from the inside makes me think at least that opening was machined, so probably the entire thing. The sides are solid 10mm aluminium that've been machined to mate with, and welded to, the edges of the sheet metal. Also welded to the enclosure are a significant number of stand-offs for the circuit boards as well as the trackball brackets which also has mounting screws flush welded to them. The plate covering the bottom and back is 2mm aluminium sheet with ventilation louvres. To this plate an angled recess has been welded which holds the sockets for power and communication.

While I had the enclosure stripped of its components, it occurred to me that I could take the opportunity to give it a new paint job. But nah, I'm going to keep the original look to retain the Accom and Axial logos, in spite of the scratches (err, I mean, to preserve its patina).

As for the guts, there are four separate boards:

• (upper left, as seen from bottom) display, knobs and dials on the main board with power, comms, and CPU)
• (upper right) function clusters
• (lower left) jog/shuttle wheel buttons, with separate jog wheel and trackball
• (lower right) keyboard, numpad and surrounding keys

tied together by a 34-line ribbon cable.

The circuit boards are all double-sided, single-layer, and obviously bespoke; curiously, some are dated 1991 and some 1994. Thankfully, the components are regular off-the-shelf items, which makes it easy to obtain datasheets:

• the regular keys use Cherry MX Black switches
• the square white ones are labelled "LKS-2-A 9406"
• the jog/shuttle wheel is backed by an HP HEDS-5701-I02 rotary encoder
• the character display is a stock NEC FC40X2EA-AB VFD daughter board with 2 rows of 20 characters
• the dial knobs are backed by Avago HRPG rotary encoders
• the trackball is a 50mm Disc Instruments LQ200-192-50 which, according to the datasheet, somehow "supports up to three button inputs"

I ended up replacing these but just for completeness, here is a shot of the power and communication sockets on the back.

Instead of these two, I installed a C7 ("figure 8") socket and connected it to a power supply originally intended for 12V drop ceiling lights, the output of which was split, one half going into the Molex connector powering the main board, and the other half going the same place by way of a 5V step-down converter.

---

# Main system board

How can I not start by diving into the big scary rectangle of complication?

Shown here without the VFD daughter board, this board holds 18 lighted keys and 6 dial knobs.

What I initially thought of as the "VFD section" is really the main board, as it includes the CPU, firmware, communication, sockets for the trackball and jog wheel, and power input. There are also a few bodge wires that I have no ambition to understand, and an intriguing little 4-gang piano on the underside; I wonder what it does? Oddly, the long green patch wire connects to pin 31 on the VFD daughter board; this is not used by the VFD (it's marked as "N/C"), so what was its purpose?

## Power

Diving into the traces of the Molex power socket, it's clear (and unsurprising) that all of the logic runs on 5V. The incandescent bulbs in the 18 lighted key switches are rated for a higher voltage and glow rather dimly if supplied with a measly 5V. Although the bulbs are rated for 14V I am still unsure what this "higher power" voltage is meant to be. I'm going with 12V until I find out otherwise.

## Computing

As mentioned, there's a Zilog Z80 in there, alongside an AMD AM85C30 serial controller (these are the two square chips above the Molex socket on the left side of the board), and a bit to the right of them there's a 20MHz crystal. The large brown chip above the serial socket is an AMD AM27C256. Under the 12-button cluster, there's a flock of PALCE16V8H chips.

For sure, the large brown AMD AM27C256, being a 256kb EPROM, must be the control panel's main firmware.

I am somewhat unsure, though, what the PAL chips represent; according to their datasheets, they are programmable but, as far as I understand, only once (as these do not have windows for UV blanking). As I will find out later, these are involved in reading kepresses of the 18 lighted key switches, as well as for lighting them.

## Drivers

Close to the serial controller, there's a small daughter board marked SHUTTLE ENCODER BD which may prove useful for, obviously, decoding the jog wheel. That's for later, though.

To the centre-right (which would normally be underneath the VFD daughter board) are four SN74LS374N edge-triggered flip-flops, two (equivalent?) CD74ACT374E flip-flops, and three TI SN74LS244N line drivers. To the right of the 12-key cluster, and to the left of the leftmost above-the-VFD key, there are two DM7406N logic inverters, plus (curiously) a third one all the way down in the right-hand corner. Between the two leftmost dial knobs sits a single AD557 8-bit DAC.

I've had no luck finding datasheets for the LKS-2-A 9406 lighted buttons. It's not really important; they're just switches with incandescent bulbs in them, but they are oddly tall and have a sort of military or soviet look to them. The switches contain AML7382 bulbs rated 14V 80mA; apparently, they're typically used in aircraft instruments (so illuminating all bulbs would draw just shy of 1.5 amps). I am still unsure what voltage the original power supply delivered, but I'm going with 12V until I find out otherwise.

As a first-ever reverse engineering project, this is all very complicated. So I'm putting the system board aside for a spell.

---

# Tracing the keyboards

The obvious place to start is taking a good look at the actual keyboards to see how they're implemented. There is clearly some form of encoding going on to get signals through the 34-pin ribbon cable to and from those 189 keys which are spread out across four separate boards. As it turned out, all the regular keys (not the LKS ones, we'll get to those later) are in several sets of matrix layouts that can be scanned in a methodical fashion.

## Function key board

Let's start with the orderly-looking function key board. This board holds 48 keys.

Arbitrarily numbering things:

• function clusters
  • cluster A-D as seen from left to right from the front (Note: cluster E is located on the main board, more on this later)
  • columns 1-4 as seen from left to right from the front
  • rows 1-3 as seen from top to bottom from the front
• key switches (red frame in above image):
  • pin 1 is connected across the whole column
  • pin 2 is connected across the whole row
  • pin 3+4 are shorted to pin 2 when the switch is pressed
  • between pins 1 and 2, there is a diode within the switch casing.
• ribbon cable
  • standard numbering; pin 1 is closest to [LIST IO] and pin 34 is closest to [MACRO 3/6]
• TI SN74LS138 3-line to 8-line decoder-demultiplexer

Examining the board traces, I am relieved to find that the keys are in fact laid out in a matrix, and that the four clusters are logically aligned in an interlaced square so that columns 1-4 are shared between clusters A+C and B+D, and rows 1-3 are shared between clusters A+B and C+D. Further, the diode in each key ensures that each keypress can be detected no matter how many are pressed simultaneously.

The key switches are wired such that the 8 logical columns (pin 1 on the key switches) are run directly to 8 "return" lines of the ribbon cable. So on my microcontroller, I have 8 GPIO digital input pins dedicated to sensing (active LOW) keypresses on these return lines. As the multiplexer is active-low, I expect all these pins to sense HIGH unless a given key is pressed.

The 6 logical rows (pin 2 on the key switches), on the other hand, do not come directly from the ribbon cable. Instead, a few lines of the ribbon cable send signals to a demultiplexer which then activates each individual row.

That demultiplexer is instrumental in minimising the number of "outgoing" lines when scanning the keyboard. An important note as I explain how the keyboard signals work, this is an "active-low" component (here is a fine short primer on logic levels).

The way the demultiplexer works is, it has three "input enable" pins to make it do anything at all. Two of these are hardwired ("G1" to HIGH, "G2B" to LOW) so in practice we can enable this chip by setting its "G2A" pin LOW. As such, the 34-pin ribbon cable dedicates one line to each demultiplexer, of which we have four in total, and on my microcontroller I thus have 4 GPIO digital output pins dedicated to enabling each individual demultiplexer.

Further, the demultiplexer has three "Select" inputs that, when interpreted as a binary value, tell it which one output (out of 8) to enable. If the "G2A" input is not active, all 8 outputs will also be inactive (HIGH). These outputs are then routed to the keyboard switches, and that is how the keyboard return lines are set HIGH (when there are no keypresses). So activating all of "Select A+B+C" (binary 000) means that the first output ("Y0") will go LOW, while activating only "Select B" (binary 010) takes output "Y5" LOW.

By the way, the chip is rated to switch within 40ns, so scanning each row can be expected to work reliably at up to 250Hz.

## Jog wheel board

This board holds 24 keys and 5 LEDs.

The keys on this board are far from as orderly laid out as on the function board, so mapping them is also rather more messy.

Arbitrarily numbering things:

• key switches (red frame in above image):
  • pin 1 is connected across various keys
  • pin 2 is connected across various keys
  • pin 3+4 are shorted to pin 2 when the switch is pressed
  • between pins 1 and 2, there is a diode within the switch casing
• lighted key switches (yellow frame in above image):
  • pin 1 is connected across various keys
  • pin 2 is connected across various keys
  • pin 3 is negative terminal for LED
  • in this case, the pin 1 diode is external to the switch casing

As mentioned above, this board uses the same demultiplexer select lines as the function board, but has its own G2A line on the ribbon cable.

As before, pin 1 on the key switches are run directly to the ribbon cable, and pin 2 on the key switches are run through a demultiplexer. I won't go into the mess of how the "rows" and "columns" map, but will note that they are logically separated into 8 columns (to take full advantage of the return lines) but only 3 rows. This means that we don't need to "count to 8" on the demultiplexer to do a full scan of this board.

Five keys hold internal LEDs. These are supplied with 5V but the cathode (negative pin) is being driven HIGH. There are then 5 lines on the ribbon cable that can pull these LOW. So on my microcontroller, I have 5 GPIO digital output pins dedicated to lighting these keys.

## Main keyboard board

This board holds 99 keys total, spread out across a qwerty layout (64 keys), a "function key" row (14 keys), and a combined numeric/navigation block (21 keys).

On the other boards, the switch casings themselves are merely soldered to the boards; they are not mounted onto a panel. Here, though, the key switches are mounted onto a separate 2mm steel plate which is screwed in place covering a large cut-out in the enclosure, making this board by itself weigh more than 1.25kg. This is obviously great for stability, but also prevents access to the front-side traces unless I either desolder all the switches from the board, or unclip all the switch casings from the plate, neither of which I'm going to do.

This board also uses the same demultiplexer select lines (23, 25, and 27) as the other boards.

On this board, pins 1 and 2 are switched around compared to the others: here, pin 2 on the key switches are run directly to the ribbon cable, and pin 1 on the key switches are run through a demultiplexer. However, the large number of keys on this board exceeds the capacity of a single chip, so there are two of them. About 2/3rds of the keys are run through demultiplexer 1, with the remainder being run through demultiplexer 2. Demultiplexer 2, interestringly, shares the "G2A" line on the ribbon cable with the one for the jog wheel board, and these two then work together so that each board uses their own set of output lines.

## Keyboard scanning & mapping

So all in all, to test for keypresses on the function board I'd need to set the G2A pin of its demultiplexer to LOW, then cycle through all binary combinations of the "Select A/B/C" pins, and for each combination check if there's a return line that's gone LOW. Because the function board only has 6 logical rows, we can have the demultiplexer "count to 6" and save a few cycles. It would be the same for the jog wheel board if it was truly distinct, but it shares its addressing with one of the demultiplexers on the main keyboard so we do a full scan anyway.

Here's my first connection, with an old RasPi and a bodge of a breadboard-to-ribbon interface. I wrote some code to cycle through all these combinations, and had it log the current combination when I pressed a key. In this manner I could build a keymap of all 171 regular keys (that aren't the LKS ones, stay tuned).

After having completed the mapping, this 2nd iteration is much more durable but obviously still not the final placement or design. It did work well until PCBway offered to manufacture a proper board for me.

Summing everything up so far, I need 8 (return lines) + 4 (G2A enable) + 3 (SELECT) + 5 (LEDs) = 20 digital GPIO pins to implement keyboard scanning. The console now works as a USB keyboard for most standard keys; non-standard keys are reported as [TEXT] with press/release events. MuahahaHAHAAH! I can do this!

## Keyboard scanning: LKS issues

"Hey wait a minute," I hear you say, "how long I gotta 'stay tuned' for? I want an update about that last quarter, those LKS thingumbobs!" Fair enough, in fact so do I. It's not working yet, but I can say that although the overall approach is the same, they are wired differently than the other three because they're entangled within the rest of the system board. Up until now, whenever I attempted hooking into that 4th demultiplexer, it would cause havoc on my return lines and my keyboard firmware would spew incorrect ghost presses.

---

# VFD panel

This display is a NEC FC40X2EA-AB with two rows of 40 characters. I couldn't find a datasheet for this exact model, but I got the one for the 1x20 FC20X1SA and the 2x20 FC20X2JA. Together, they give me a pretty good idea: it has both a parallel and a (9600 baud) serial bus, as well as additional pins to blank the display ("BL"), interpret received bytes as commands ("A0"), and indicate internal processing ("Busy", ie. a "CTS" signal). There's also a "WR" for telling it to read a byte of parallel data, along with 8 pins for said parallel data. The ribbon cable socket was a convenient place to wire in another 34-pin ribbon cable and map those pins to GPIO pins on my microcontroller.

I got the serial connection working and created a small utility library to provide the rest of my code with some higher-level functions. Originally the display was used as six separate read-outs, so I also created functions for setting "slot text" and "slot value" data.

The serial connection gets the job done but isn't particularly quick, so updating the entire display does show noticeable flicker. Summing everything up, I need to dedicate 4 digital GPIO pins for blanking and serial, plus another 9 for parallel communication -- except, that's not straightforward.

## VFD parallel data conundrum

The display has the potential to be much faster over parallel, but I'm having issues. I'm supposed to set 8 registers for a byte of parallel data, then trigger a LOW signal on the "WR" pin -- but toggling that pin does not read the input but rather reset the whole display.

The 1-page data sheet for the NEC FC20X2JA (with 2x20 characters) merely mentions "many control commands are available" but does not provide further details. It does say this about timing, though:

Alas, I have tried a zillion different approaches including asking the hivemind, but no matter what I do, setting WR active seems to perform a reset instead of a byte read. 🫤 I have yet to find a way around this.

Any ideas?

---

# Platform change

It was about at this time that, as I said, the Teensy stopped responding over USB and some of the power-regulating circuitry was clearly roasting. Conceding that the 3.5 is now obsolete (and just as hard to come by as the console) I then switched horses to an STM32 device, and I don't know whether I was really surprised by how much I had to do to adapt a "modern" 3.3V-based STL with a "legacy" 5V-based application.

That red board (sponsored by PCBWay) is merely a socket for the Teensy and provides pathways to two 34-pin ribbon cable box headers. In the other corner, we have the STM32 F4VE board, along with a handful of level shifters (and that's not even half of them, pictured).

For every 8 GPIO pins I want to use, I'll need to use such an auxiliary board, a faggot of rainbow cables (19 in total: two for each voltage, plus ground, plus two for each of the 8 channels), plus a way to mount or stash all this away securely when it comes time to integrate it into the console enclosure.

What a mess. It really does drive home just how convenient the Teensy platform is, and just how much extra "noise" one needs to deal with when crossing era boundaries.

Sidebar: A note on developer's usability With a Teensy, you just code something, click "Upload" in the Arduino IDE, and watch it execute and send log messages to your serial console. There's a button you can press to reboot the thing. You can upload new code whenever you like, and it will just accept it and reboot. With the STM32, you'll need to short two pins to take it into programming mode, then click upload, and watch it execute. But to get your log messages, you need to take it out of programming mode by shorting two pins otherhow and rebooting the device. But the serial connection won't auto-connect, you'll have to do that manually once the thing has booted ... so you end up building a delay into your setup code to give you time to attach your serial monitor so you can see what's going on during setup. This may sound silly but quickly becomes aggravating: rebooting requires you to physically unplug and reinsert the USB cable (which, by the way, uses a "very modern" mini-USB plug, so I'm glad I had an old cable still around) and if you wait to long to upload your code the programming mode times out so you have to re-un-and-replug the USB cable. The contrast is staggering. Paul Stoffregen deserves all the praise he's getting for his Teensy devices, as well as his stellar personal customer service.

---

# Main system board

It's time to take on the big scary rectangle of complication.

This board holds 18 lighted keys and 6 dial knobs. Shown here without the VFD daughter board.

There are so many ICs on this board, I'm going to label them:

1. A-C -- DM7406 Hex Inverting Buffers
2. D-G -- SN74LS374N Octal D-Type Edge Triggered Flip-Flops with 3-State Outputs
3. H, I -- CD74ACT374E Octal D-Type Flip-Flops with 3-State Outputs
4. J-L -- SN74LS244 Octal Buffer with 3-state Outputs
5. M, N -- SN74LS138 3-line to 8-line Decoder-Demultiplexer
6. R1-R6 -- HRPG-ASCA Rotary Encoder
7. S -- AD557JP Latching 8-bit DAC
8. S1-S18 -- LKS-2-A 9406 Lighted Key Switches
9. T-Z -- PALCE 16V8H/16R8ACN Programmable Array Logic

Remember the scene where Indy is confronted by a foe, considers his whip, but then just pulls his gun and shoots him? I'm going to ignore most of what's on this board. I found that lifting a strategic selection of ICs out of their very convenient sockets disables much of the componentry that I want my microcontroller to interface with instead. Brilliant. Thank you, Accom!

## Forays into signal paths

If you think my description of the keyboard wiring and control was messy, maybe you should brace yourself. This one is way more complicated.

All in all, here is a wiring table of the 18 lighted keys on this board:

I have soldered some lines from a ribbon cable into two loose chip sockets. The T-Z chips seem to all receive the same input signals, so I have simply taken out all of them and placed one of my ribbon-sockets into the socket for the "T" chip, and I'm wired into the system. The other ribbon-socket goes to the inputs of the "N" and "M" demultiplexers.

The switched pins (pin 1) of all the LKS keys are pulled HIGH via a resistor ladder (right of "L"); closing a switch pulls its signal LOW. This output is fed into the SN74LS244 buffers ("J", "K", and ¼ of "L"), whose output enable pins are controlled by one of the demultiplexers ("N"). The buffer's inverted output then goes to both PAL chip ("T") and to the latching DAC ("S").

Meaning, whenever a key is pressed and the corresponding output enable pin is pulled low, the PAL chip gets a HIGH signal on a partucular pin. Keys 1-8 correspond to pins 12-19 on "T" when pin 13 on "M" is high; keys 9-16 correspond to pins 12-19 on "T" when pin 14 on "M" is high; and keys 17 and 18 correspond to pins 12 and 13 on "T" when pin 15 on "M" is high. Thus I can send inputs to "M" and read return signals on "T". Cool.

So for instance, to test whether the [VFD Menu 1] key (#13) is being pressed, I should set the VFD ribbon line 13 to LOW to enable the pertinent demultiplexer, then set lines 9-11 to HIGH-LOW-HIGH. Then I can finally check for a LOW return on ribbon line 5. Why this is, is a bit convoluted:

Pressing LKS #13 sets pin 11 on "K" to LOW. To enable the output pins on "K", we'll also need to set K's G2A (pin 19) LOW, and the output cannel for the LKS switch (pin 14) to LOW. This latter signal we get from pin 14 on "N", where configuring its "DMX SEL" to "H/L/L" (corresponding to ribbon lines 9-11). Now that "K" has a LOW input from LKS #13 and its outputs are enabled, it can pass that LOW state to pin 16 on the "TVXZ" sockets, which is connected to VFD ribbon line 5. And breathe.

## Noise cancellation

Right, the entire keyboard (minus the lighted keys on the system board) was working fine with the one ribbon cable; the VFD was working fine with the other ribbon cable; but whenever I'd connect both ribbons at the same time, all hell would break loose in the form of spewing loads of keypresses when there clearly weren't any. For a while I thought this was caused by the LKS return lines disingeniously being active-high (as opposed to the other ribbon), and I'd even purchased a cheap(ish) digital oscilloscope and a few components with the intent of making an inline daughter board for the 34-pin connector to invert those 8 return lines.

Looking at it again (and again), I realise that the Accom engineers weren't the ones being disingenious, and the return lines are in fact compatible. However, something else was going on.

This being an existing product that I'm commandeering, the system board is populated with all sorts of components doing who-knows-what (no seriously, who knows? I'd love a diagram of this thing). I powered up the system board with neither its keyboard nor my microcontroller connected, and started poking around among connections between the Select pins of the DMX'es (chips "N" and "M") and the keypress return lines (on PALCE chip "Z") -- and could identify solid connections as well as others clearly switching on distinct frequencies. Oho, so I was having company in talking to the DMX, no wonder I had weird results. But who? Turns out that liberating the IC in the socket silkscreened with "C112" (a Motorola MC74AC74 flip-flop) would cut the noise.

Of course, I should have verified that my inputs were clean long ago, but I was naive and/or made some careless assumptions. And you know what they say, I made and ass of me and some umptions.

## Dial knobs

As for the dial knobs, they're HRPG-ASCA #19R 9323 rotary encoders which provide 120 pulses per revolution. The datasheet recommends combining each with an "HCTL-2016/2020 Quadrature Decoder/Counter", but here they are routed to the two ACT374E flip-flops ("H", "I") whose outputs are wired into the PAL chips. #TODO I've yet to look into sensing these dial knobs.

## Summary of current state

I would rather not comment on the amount of time finding this all out has taken me. Ugh, I am all too aware of my poor understanding of electronics (I pretty much just follow traces and read datasheets) ... but I bet that even so I can make this work as envisioned.

So far, I have cleared up usage of 6¼ of the 9 chips underneath the VFD, all of the other chips on that side of the board (except what the DAC is used for), and one half of one of the (at least) 7 PAL chips.

What the output of the DAC is used for I've not yet investigated. #TODO Given that it's a latching DAC (and that the keys are sensed through multiplexed scanning), it's likely that the DAC serves to store which combination of the 18 keys are active (which will then be used for lighting them, as well as letting the operating system know which mode-specific VFD output to provide, and what control inputs are to be interpreted as).

It seems that the PAL chips can be used as outputs as well as inputs; I'll have to investigate more to see just how. But clearly, the same PAL chip pins are used both to read key presses, and to toggle lighting. This might just be clever enough so that pressing a key "automatically" also toggles lighting?

---

# To be continued...

...