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