Close
0%
0%

Repurposing an Accom Axial Control Panel

Turning an obsolete video editor console into a mothership-sized keyboard + trackball + stream deck

Public Chat
Similar projects worth following
Back in the 1990s, the Accom Axial was an awesome video editing system, but things turned digital and non-linear, and Accom became obsolete and closed up shop.

My plan is to convert this console to be useful in the context of a modern pc.

This is a write-up of a project I've been meaning to do for several years. This is my first ever serious reverse engineering endeavour, so this project log will likely be rather verbose and contain a lot of steps that are "obvious" to tinkerers more seasoned than yours truly.

# 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 I even want them; those cost several times as much as the control panel itself, which is already plenty expensive -- and 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.

Control panel (from original brochure)
Control panel (from original brochure)

In total, there are 189 buttons, 23 of which are individually lightable, arranged into a full qwerty layout, a combined numeric/navigation block, five clusters 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.

## What am I building?

My plan is to convert this console to be useful in the context of a modern pc. How to achieve this depends on whether I can work with the original guts.

I want to make the control panel work as a USB HID input device. However, 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.

I expect to need some form of configuration tool so that keys can be mapped to keystrokes or macros, and dials to various scalar controls. Hopefully, I'll be able to use the VFD to offer on-device management of macros and configuration, because that section just begs to be used for that purpose. Wouldn't that be something?

I also expect to need a small (desktop/cli/daemon) program running on the pc in order to provide whatever data might be useful to indicate on the VFD and lighted keys.

### Y U No Stream Deck?

I came across the term "Stream Deck", which is apparently the product name of a glorified macro keyboard that costs just over half as much as my entire console did. 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.

pin converter pcb.zip

Helps connect the Axial 36-pin ribbon to a Raspberry Pi 40-pin header.

Zip Archive - 156.85 kB - 09/16/2022 at 14:22

Download

diagram keyboard matrix.jpg

An artful representation of how "rows" and "columns" (terms used loosely) map keys to demultiplexers and ribbon lines.

JPEG Image - 72.18 kB - 09/15/2022 at 22:58

Preview
Download

  • 1 × Axial Accom Control Panel This, of course, is the foundation for the rest. It's not easy to come by though.
  • 1 × Teensy 3.5 Or other 5-compatible microcontroller

  • Main system board

    noughtnaut4 days ago 0 comments

    # Main system board (log resumed from 2022-09-08)

    (Yes, this keeps getting pushed further into the future. Soon I will have nothing else left to work with though, and eventually will "have" to get this one done.)

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

    Main board, front
    Main board, front
    Main board, back
    Main board, back

    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's also an intriguing little 4-gang piano on the underside; I wonder what it does?

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

    ## 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 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.

    Pin 4 of the Molex connector is wired to 3 places: pin 5 ("+V(s)") of the op-amp jutting out over the edge of the board in the top-left side; to the corresponding solder pad of an empty space that might be intended for another op-amp; and to a power choke (RL1283, labelled "L2", the other side of which eludes my tracing attempts).

    The L165 power op-amp is connected thusly:

    PinDatasheet
    Actual connection
    5
    +V(s)Pin 4 (yellow): 12V ??
    4OutputGND (wtf really??)
    3-V(s)Pin 2 (black): GND
    2Inverting input
    ?? (not yet traced)
    1Non-inverting input
    ?? (not yet traced)

    I don't understand the L165 datasheet well enough to understand what the output on pin 4 is supposed to be. Should it be half-way between the voltages on pins 5 and 3 (so half the voltage on pin 5)?? Are pins 3 and 4 supposed to be tied together, and connect to ground (or is this component busted, or is this just he powered-off state)?? And are pins 1 and 2 important on this board??

    Curiously, the final Molex signal (pin 3, white cable) seems to be connected to pin 3 (" -V(s)") of the omitted op-amp; and to another power choke (RL1283 again, labelled "L3"). It must be used for something, but what?? I'm assuming it's just a ground connection.

    ## Brains

    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.

    Close to the serial controller, there's a small (soldered-in) daughter board marked SHUTTLE ENCODER BD which may prove useful for, uh, 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. There are two DM7406N logic inverters between the 12-key cluster and the leftmost above-the-VFD key, plus (curiously) a third all the way down in the right-hand corner. Between the two leftmost dial knobs sits a single AD557 8-bit DAC.

    ### Firmware

    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).

    ## Switches

    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.

    LKS-2 key switch
    LKS-2 key switch

    These keys are not wired into the ribbon cable. A pity; that could have provided...

    Read more »

  • VFD success (preliminary version)

    noughtnaut11/13/2022 at 14:52 0 comments

    # VFD daughter board

    I probably don't need to investigate this too much as it is a stock component; a NEC FC40X2EA-AB with 2 lines of 40 characters and a serial interface. I just wanted to include the pics for you.

    VFD daughter board, front

    VFD daughter board, back
    VFD daughter board, back

    I have not yet found the datasheet for this specific character display, but I have the ones for the related single-line 20-character (FC20X1SA) and 2x20-character (FC20X2JA) boards. I expect the control interface will be identical; the daughter board has a 9600 baud serial interface and a power supply socket. Apparently, the 1x20 VFD requires 4.75-5.25V and draws 700mA, which frankly is less than I expected -- just shows how little I really know.

    ## My implementation

    I've grabbed another old floppy drive cable and picked it apart. For one thing, this allows me to prototype things with my existing board by using this cable in place of the one for the keyboard. For another, the display doesn't require so many leads, leaving plenty of capacity to be used for interfacing with the rotary encoders and the trackball.

    On the VFD daughter board, all of the even-numbered pins are connected, and so my ribbon only provides GND on pin 34. Since I am using the serial data connection, I also don't need the 8 pins for parallel data. Additionally, the "T(0)" signal for test mode let me verify that the display is, in fact, functional ... and then I have no further use for it. Finally, the "CS" should always be set low (which makes me wonder why it's even there?) so it will be simply connected to GND on the VFD side. In total, I need 6 leads (and only 5 Teensy pins) to drive the VFD, leaving 28 leads free to be used later on.

    I've spent some time experimenting with the protocol. There are still some odd bits where my code doesn't work even though I seem to have done everything to spec.

    According to the datasheet, the 34-line ribbon cable is used as follows:

    Ribbon line
    Signal
    34
    GND
    17WR, Write data to display (set high when sending commands, low when sending data)
    19A0, Activate input (set low while sending serial data, then set high)
    23Not connected: CS, Send command (should always be set low)
    25Not connected: T(0) (set high at power-on(!) to enable test mode)
    27Busy signal from VFD (unable to receive data when high)
    29BL (set low to blank display, high to unblank)
    33Rx, Serial data
    Data packet is one start bit ("0"), then 8 data bits (LSB...MSB), then one stop bit ("1").

    It took me a while to figure out which signals were active high and which were active low, as this does not seem to agree with the datasheet. By the way, using the default 9600 baud setting means working with pulses of 105µs which the Teensy can easily churn out.

    I've implemented some simplistic code to "put this string of text at this position", but some of the commands still refuse to work as described; namely, the cursor (an underscore) refuses to be hidden and ignores my commands for absolute positioning. In the meantime, I have implemented a workable but flicker-ful work-around which involves keeping a separate display cache and updating the entire display when a change is needed -- this is sufficient to verify that I can talk to the thing, but is absolutely not good enough for displaying changing values while adjusting a setting using a dial knob.

    VFD showing test message
    VFD showing test message
    VFD showing menu slots
    VFD showing menu slots

    In this last image, you get an idea how the original system used to operate: the top row would have menus such as "colour balance" or "timing", and pressing one of the white buttons would then load that menu, for instance showing "Black Level", "While Level", "Red", "Green", "Blue" in the top line and their individual values in the bottom line -- which could then be adjusted with the dial knobs and committed with the black buttons below them (not shown here).

  • USB keyboard feature - proof of concept OK!

    noughtnaut11/13/2022 at 13:02 0 comments

    # It's alive

    After restructuring the firmware code to work with the Arduino IDE, 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!

    I've published the code to github. I haven't yet considered whether all the files (diagrams, etc.) should be there, too, so for now they're just here at Hackaday.

    I have a few minor issues with the hardware keyboard being capped with a US layout, which is not what I'm using logically on my workstation, which is why a few keys are seeminglymapped incorrectly. Also, the Teensy keyboard library seems to be lacking an [Alt Gr] keycode, so for now I just have two [Alt] keys.

    Next up (beyond mapping the row above the keyboard to be function keys) is either working on reading the trackball and jog wheel, or resuming my work on the main system board so that I might light up the VFD and those additional 18 keys.

  • USB keyboard feature so very nearly done

    noughtnaut11/11/2022 at 14:59 0 comments

    You know when you're 🤏 thiiis close to completing a feature, and then you hit that "one tiny snag"? Yeah, that.

    I have all the keys mapped out and can accurately report key press/release events. However, I have 189 keys which is quite a bit more than a "standard USB keyboard", so my plan was to report the "standard" keys using a built-in library (including mapping [REV] and [FWD] to [CTRL] and [ALT], etc.), and have the remainder of the keys send text macros until I write a host-side serial driver to interpret them (for instance, [FILE MNGR] could map to [WIN]+E, but I don't want to be that specific at the firmware level).

    Anyone who's tinkered with microcontrollers knows that the Arduino IDE has, uh, lots of potential. That is to say, it works but phooey is it cumbersome as an editor. So I'm doing my coding in IntelliJ (using the CLI version of the compiler and using the Teensy loader to connect to the hardware, and also still running the Arduino IDE solely for its simple serial monitor.

    Alas! Going off piste frequently means hitting bumps, and one such is that the standard Arduino headers are not implicitly available. So I can have `#include <Keyboard.h>` and have everything building just fine up until the moment I try to call `Keyboard.press(keycode)`. And yes, I have of course set the device mode in the Arduino IDE as per instructions, but those instructions don't take nonconformity into account. I imagine I can simply `#include "path/to/Keyboard.h"`, but I haven't found that path yet.


    To be continued...

  • Alive with a Teensy 3.5 microcontroller

    noughtnaut10/17/2022 at 22:32 0 comments

    ...would be an inaccurate title. But, I felt it about time to post an update.

    # New brains!

    Now that I've received the Teensy 3.5 that Paul Stoffregen was kind enough to sell me, what's actually going on is that I've got the ribbon cable (ie. three of the boards) hooked up to the new microcontroller.

    Teensy 3.5 connected to ribbon cable
    Teensy 3.5 connected to ribbon cable

    Obviously, that there is not going to be the final placement. The plan is to have it placed neatly inside and expose a USB device socket on the back. I have already installed a C7 ("figure 8") socket in the back and connected it to a repurposed half-broken USB charger, and to a power supply originally intended for 12V drop ceiling lights. This will provide ample 5V and 12V power for the main board.

    Without much planning, I chucked the Teensy onto a breadboard, placed a 34-pin ribbon cable socket next to it, and soldered away! There are no mistakes or shorts ... but there's a reason I'm only showing you the one side here. The rolled-up bundle of wires is with the intent to route the "reset and reload" button to a classic "reset hole" on the back of the enclosure.

    # Old woes...

    I admit it: I'm rusty! It must have been 1995 or so that I last wrote a line of C code. The Teensy (ditto Arduino and their compatibles in general) runs C++ which ... I may have read a book on ... long ago. Nevertheless, I've got a few threads going to run a heartbeat, cycle the demultiplexers and monitoring the 8 return lines for keypresses ... as well as a fun little light show on the 5 keys that have LEDs in them, because why the hell not.

    On the Raspberry, which supports Python, I had nice sets of key-value maps for the demultiplexers and a simple and neat csv file to store the keymap. C doesn't offer key-value maps, and although the Teensy has an onboard SD card reader, there's no built-in file system library. So I've been making all sorts of dumb mistakes in recreating the triple-for-loop from the Raspberry's Python to the Teensy's C. (Tip: it doesn't help to do this sort of work when you're tired. Who'da thunk?)

    Right now I'm (procrastinating) working on prototyping the USB device-mode keyboard output, implementing the keymap configuration, and investigating the need/interest of using event interrupts (rather than thread loops) to capture key presses. I've not made a final decision yet whether I'm going to re-use the existing decoding and multiplexing of the rotary encoders and trackball, or to reroute them directly to a bunch of GPIO pins on the Teensy which are still unused. Comments are welcome on this.

  • Prototype with RasPi and other updates

    noughtnaut09/14/2022 at 07:06 0 comments

    The plan now is to get the console to a workable state as a keyboard, excluding the track ball, jog wheel, and VFD section. Those are all related to the main board, which will be my next target.

    ## Preparing to test

    I've mounted all three boards (sans main board) in the enclosure again, intending to connect the ribbon cable to a Raspberry Pi and see if I can get keystrokes to register. (No, I won't be using a Raspberry for the final product, but for prototyping it's okay.) For that purpose, here's (one way) how the control panel's 36-pin ribbon cable can be connected to the Raspberry's 40-pin header:

    ribbon cable converter
    ribbon cable converter

    The thing is ... at the time of writing, I don't even have a proper breadboard for this. I only have a tiny 25x14 breadboard that absolutely doesn't have enough room for an additional 36-pin ribbon socket when the majority of it is occupied by an "Iduino GPIO Expansion Board". But, I did have an old FDD cable (34 pins!) lying about that tore up and made work more or less "dead bug style".

    ## All wired up

    pcb abomination
    pcb abomination

    Ain't she pretty? (Please say no.) The good news is, I've got the Axial's ribbon cable connected to my Raspberry Pi.

    ## Good and bad news from the outside world

    The good news is, I've been contacted by a possible sponsor willing to provide me with any pcb fabrication I might need! Clearly, I do have a need ... but it may not be very urgent, because of:

    The bad news: I would really, really like to run this project on a Teensy 3.5 (large GPIO count, 5V tolerant, good libraries incl. USB HID mode) ... but what with the global chip shortage, I can expect to have one in my hand by 2023Q2 ... maybe.

    In the meantime, I've ordered an Arduino Mega 2560 which at least has plenty of (5V tolerant) GPIO ports, but we'll see how much of a fight it will put up when asking it to be a USB HID device.

    The bestest news: Before ordering the Mega, I posted a query to the Hackaday Stack, asking if anyone had a spare Teensy 3.5 they would be willing to part with. Turns out, not only did I get a reply in time to cancel my Mega order, the reply was from Paul Stoffregen himself. Thanks, Paul, you truly are an amazing human being!

    The slightly bad news: Shipping the Teensy will take "1-3 weeks" (once it's handled and actually sent), and then probably another week or so when the local customs people want their slice of it.

    ## Key mapping

    I've thrown together a small program to repeatedly cycle through all combinations for the G2A, A, B, and C lines, while looking for signals on any of the return lines. With a bit of user input, this allowed me to map each signal combination to a specific key, which I've stored in a CSV file for now. That was easy enough (once I had debugged two crossed ribbon lines and another that had come loose). As it turns out, three or four keys are either dirty or close to being kaput, judging by their responsiveness.

    Next up would be translating this to "user input" for the Raspberry Pi itself, and after that I'll see about passing that input on to a USB host (but that's going to have to wait until I have a USB-device-mode-capable microcontroller).

    So for now ... I'm waiting on delivery of the Teensy, and in the meanwhile digging more into the main board logic.

  • Keyboard board

    noughtnaut09/12/2022 at 08:42 0 comments

    # 2022-09-14 Keyboard

    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).

    Keyboard board, front
    Keyboard board, front
    Keyboard board, back
    Keyboard board, back

    Sidebar: Oh yeah, this one's a bit out of chronological order.

    I don't know why I started on the main board before being done with all three input boards. Eh, just blame my adhd. Anywho, here's filling in the gap. After this, I should be able to hook the ribbon cable up to a Raspberry and use most of the keys; I'll then continue with the VFD section, the trackball and the jog wheel.

    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 aluminium plate which is screwed in place covering the large enclosure cut-out, 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.

    Arbitrarily numbering things:

    • keyboard
      • ugh, mapping these turned out to be a bit of a mess. Rather than describing them here, I'm providing separate files with some colourful schematics as well as a spreadsheet of the complete key matrix.
    • key switches (red frame in above image):
      • pin 1 is connected across the whole column-ish
      • pin 2 is connected across the whole row-ish
      • 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
    • demultiplexers
      • demultiplexer 1 and 2, with the one closest to the ribbon cable being chip 1
    • ribbon cable
      • standard numbering; pin 1 is closest to [3] and pin 34 is closest to [VIEW]

    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.

    As usual, G1 is pulled high and G2B is pulled low, but each demultiplexer has its G2A pin is routed to separate ribbon lines: demultiplexer 1 uses ribbon line 21, and should be pulled low when scanning; demultiplexer 2 uses ribbon line 23, and should be pulled low when scanning. Note that ribbon line 23 is shared with the jog board (effectively placing a third of the keyboard keys on the jog board).

    Curiously, the demultiplexer chips have no manufacturer or type printed on them, but are simply stamped with "Malaysia" and what is probably a serial number ("02M4" and "02G9"). I'm assuming they are compatible with the `SN74LS138` found on the other boards. Also, they're mounted upside-down on the underside of the board; the square solder pad is actually pin 8.

    I've mapped the matrix in this shockingly artful diagram:

    keyboard matrix diagram
    keyboard matrix diagram

    So in short, here is my new knowledge about the ribbon cable:

    Ribbon line

    Source

    Signal

    19

    Main board

    Keyboard board G2A chip 2

    21 Main board Keyboard board G2A chip 1

    Omitted: all of the bloody keys?! Well yeah, but they're listed in the spreadsheet file with the complete keyboard matrix.

  • Jog wheel board

    noughtnaut09/12/2022 at 08:28 0 comments

    # Jog wheel board

    This board holds 24 keys and 5 LEDs.

    Jog board, front
    Jog board, front
    Jog board, back
    Jog board, back
    Key switch pin-out
    Key switch pin-out

    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

    Surprise: this board uses the same demultiplexer select lines (23, 25, and 27) as the function board. Perhaps other G1/G2 settings, then? Yes: G1 is pulled high and G2B is pulled low as above, but G2A is routed to its own ribbon line  (19), and should be pulled low when scanning.

    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.

    Demultiplexer

    Pin

    In

    Out

    1

    Select A


    2

    Select B


    3

    Select C


    4

    G2A


    5

    G2B hardwired to GND


    6

    G1 hardwired to 5V


    7


    unused

    8

    GND


    9


    unused

    10


    unused

    11


    unused

    12


    unused

    13


    [REC/SRC], [MARK OUT], [JOG], [VAR], [SHUTL], [PLAY], [ABSLT], [SWR FADER]

    14


    [END], [SELECT], [NEXT PG], [STOP], [MARK IN] [VFD 1], [VFD 3], [VFD 5]

    15


    [START], [PREV], [NEXT], [PREV PG], [USER], [VFD 2], [VFD 4], [VFD 6]

    16

    5V


    So it would seem that, to scan this board, I need to run a binary sequence 0-2 through ribbon lines 23, 25, and 27 to power the jog board keys (pin 2) as follows:

    int

    bin

    r27

    r25

    r23

    IC pin

    output (to key switches pin 2)

    0

    000

    L

    L

    L

    Y0, pin 15

    [START], [PREV], [NEXT], [PREV PG], [USER], [VFD 2], [VFD 4], [VFD 6]

    1

    001

    L

    L

    H

    Y1, pin 14

    [END], [SELECT], [NEXT PG], [STOP], [MARK IN] [VFD 1], [VFD 3], [VFD 5]

    2

    010

    L

    H

    L

    Y2, pin 13

    [REC/SRC], [MARK OUT], [JOG], [VAR], [SHUTL], [PLAY], [ABSLT], [SWR FADER]

    3

    011

    L

    H

    H

    Y3, pin 12

    unused

    4

    100

    H

    L

    L

    Y4, pin 11

    unused

    5

    101

    H

    L

    H

    Y5, pin 10

    unused

    6

    110

    H

    H

    L

    Y6, pin 9

    unused

    7

    111

    H

    H

    H

    Y7, pin 7

    unused

    Any pressed key switches (pin 1) should then be signalled on (odd-numbered) ribbon lines 1-15:

    key switches pin 2 output

    ribbon line

    [PREV], [MARK IN], [REC/SRC]

    1

    [START], [END], [MARK OUT]

    3

    [SELECT], [NEXT], [PLAY]

    5

    [PREV PG], [NEXT PG], [JOG]

    7

    [VFD 1], [VFD 2], [VAR]

    9

    [VFD 3], [VFD 4], [SHUTL]

    11

    [VFD 5], [VFD 6], [ABSLT]

    13

    [USER], [STOP], [SWR FADER]

    15

    Additionally, 5 of the keys have LEDs; these are all supplied with the same 5V from ribbon line 6/8/10 and individually lighted by pulling pin 3 down via separate ribbon lines.

    So in short, here is my new knowledge about the ribbon cable:

    Ribbon line

    Source

    Signal

    1

    Jog board

    [PREV], [MARK IN], [REC/SRC]

    2

    Main board

    GND for [VAR] LED

    3

    Jog board

    [START], [END], [MARK OUT]

    4

    Main board

    GND for [JOG] LED

    5

    Jog board

    [SELECT], [NEXT], [PLAY]

    7

    Jog board

    [PREV PG], [NEXT PG], [JOG]

    9

    Jog board

    [VFD 1], [VFD 2], [VAR]

    11

    Jog board

    [VFD 3], [VFD 4], [SHUTL]

    13

    Jog board

    [VFD 5], [VFD 6], [ABSLT]

    15

    Jog board

    [USER], [STOP], [SWR FADER]

    19

    Main board

    Jog board G2A

    29

    Main board

    GND for [SWR FADER] LED

    31

    Main board

    GND for [ABSLT] LED

    33

    Main board

    GND for [SHUTL] LED

  • Tracing the function board

    noughtnaut09/12/2022 at 08:23 0 comments

    # 2022-09-06 Tracing the function board

    This board holds 48 keys.

    Function board, front
    Function board, front
    Function board, back detail
    Function board, back detail

    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 (see 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. This eliminates ghosting when multiple keys are pressed simultaneously.
    • ribbon cable
      • standard numbering; pin 1 is closest to [LIST IO] and pin 34 is closest to [MACRO 3/6]

    Examining the board traces, I am relieved to find that the keys are 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.

    The 8 column lines (pin 1 on the key switches) are run directly to the ribbon cable, but the 6 row lines (pin 2 on the key switches) are run through a TI SN74LS138 demultiplexer (which, by the way, is rated to switch within 40ms, so scanning should be at no more than 25Hz). The demultiplexer reduces the line count to 4, which are run to the ribbon cable.

    Demultiplexer

    Pin

    In

    Out

    1

    Select A


    2

    Select B


    3

    Select C


    4

    G2A


    5

    G2B hardwired to GND


    6

    G1 hardwired to 5V


    7


    C+D row 3

    8

    GND


    9


    A+B row 3

    10


    C+D row 2

    11


    A+B row 2

    12


    C+D row 1

    13


    A+B row 1

    14


    unused

    15


    unused

    16

    5V


    So it would seem that, to scan this board, I need to configure the G lines thusly:

    G1

    G2A

    G2B

    H

    L

    L

    and then run a binary sequence 2-7 through ribbon lines 23, 25, and 27 to power each cluster row's key switches (pin 2) as follows:

    int

    bin

    r27

    r25

    r23

    IC pin

    output (to key switches pin 2)

    0

    000

    L

    L

    L

    Y0, pin 15

    unused

    1

    001

    L

    L

    H

    Y1, pin 14

    unused

    2

    010

    L

    H

    L

    Y2, pin 13

    A+B row 1

    3

    011

    L

    H

    H

    Y3, pin 12

    C+D row 1

    4

    100

    H

    L

    L

    Y4, pin 11

    A+B row 2

    5

    101

    H

    L

    H

    Y5, pin 10

    C+D row 2

    6

    110

    H

    H

    L

    Y6, pin 9

    A+B row 3

    7

    111

    H

    H

    H

    Y7, pin 7

    C+D row 3

    Any pressed key switches (pin 1) should then be signalled on (odd-numbered) ribbon lines 1-15:

    keypress

    ribbon line

    A+C col 1

    1

    A+C col 2

    3

    A+C col 3

    5

    A+C col 4

    7

    B+D col 1

    9

    B+D col 2

    11

    B+D col 3

    13

    B+D col 4

    15

    So for instance, to test whether the [SYSTM] key (cluster A, row 2, col 1) is being pressed, I should set lines 23 and 25 low and line 27 high (for cluster A row 2), and check for a high on ribbon line 1 (for cluster A col 1). Similarly, pressing [LIST] (cluster B, row 3, col 1) should give a signal on ribbon line 9 when line 23 is set low and lines 25 and 27 are set high; and pressing [EJECT] (cluster C, row 1, col 4) should give a signal on ribbon line 7 when lines 23 and 25 are set high and 27 is set low.

    Meanwhile, G2A (on ribbon line 17) should be pulled low.

    Having seen this, I expect the other boards to use the same signal return lines, but separate demultiplexer select lines.

    Suppose I have four demultiplexers, and knowing that I should be hitting each demultiplexer at no more than 25Hz, on the CPU side I could then scan at up to 100Hz.

    According to the demultiplexer's data sheet, the voltage on ribbon pin 6/8/10 should be between +4.5V and 5.5V; the voltage on ribbon pins 23/25/27 should be between 2V and 5V; and the output voltage would be between 2.5V and 3.5V. These values indicate that it's safe to test with the RasPi2B+ that I already have.

    Update: Yup, that works as per datasheets. Good to know.

    This is what I now know about the ribbon cable:

    ...

    Ribbon line

    Source

    Signal

    1

    Function board

    A+C col 1

    3

    Function board

    Read more »

  • CPU and keyboard considerations

    noughtnaut09/12/2022 at 08:19 0 comments

    # 2022-09-05 CPU and keyboard considerations

    ## CPU

    I've thunk about possible solutions, and keeping the hardware original seems less and less likely. For one thing, there's really no reason to, and not doing it gives me much greater freedom to interface the hardware with a new controller.

    ### Out with the Zilog

    I'm not going to investigate re-using the Zilog Z80 CPU; it's just not something I'm interested in spending time or gaining experience with. Also, it's likely getting its orders from firmware EPROM chips that I have neither the equipment nor the inclination to work with.

    True, I'll have to isolate the Z80 and EPROM chips from the rest of the main board and wire in a replacement. Probably not too big of a deal; first I want to figure out how much of the rest of the components I can benefit from using as-is.

    ### In with a microcontroller board

    I expect I'll be using some form of microcontroller board for a number of reasons:

    • First, note that I'm saying "microcontroller board", that is, one of the (Arduino, Feather, Pyboard, Raspberry Pico, Teensy) family. That is to say, I prefer an off-the-shelf all-in-one board over creating my own microcontroller pcb with (only) whatever additional components are needed. That, obviously, would be interesting for a large production run, but not for a one-off toy.
      • This also means I get to program in a higher-level language (something C-like or even Python) rather than raw microcode. Yes please.
    • I'm leaning towards a Teensy, because it supports USB HID device mode which allows this thing to pretend to be a "regular keyboard" to any pc it's connected to. (It also has a USB host port, but that's not immediately interesting.)
    • I am not yet sure how many GPIO lines I'll need; this impacts which microcontroller board I could choose.

    ## Keyboard

    A crucial point is how the boards are currently wired up, or specifically, how keypresses are detected: are the boards designed to use matrix scanning? Examining the boards should reveal that.

    • The matrix design needs quite a lot of lines, but basically supports any number of keys in a reasonably straightforward manner. Keep in mind, the ribbon cable currently connecting all the boards has 34 conductors. Given that there are 189 keys, a single key matrix would need 28 pins (14 ✕ 14 lines) which is not unrealistic (but of course, these are spread out across several boards). In addition, there's also the the matter of reading the trackball, jog wheel, and six dials, as well as managing the 23 lightable keys (most of which, by the way, are incandescent and so might draw a non-trivial amount of milliamps). It is possible to drive 30 lamps from only 6 pins by using charlieplexing, but there would be severe limitations on which combination of lamps could be lit at any given moment.
    • An alternative to the matrix design is some form of masking or encoding, which would be much more difficult to use as-is. In this scenario, I might resort to cutting traces on the circuit boards and implement matrix scanning, but this might get really messy unless I replace the boards entirely (which I've already explained I want to avoid).

    If I/O pins end up becoming a bottleneck, then I might resort to using several microcrontroller boards that talk over a can bus, or maybe I²C.

View all 16 project logs

Enjoy this project?

Share

Discussions

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates