CTM / Cherry 601-1518

MMcM

08 Sep 2020, 01:35

This keyboard is from some CTM system in 1988. Its part number seems to be 680-1114HAC/03.
CTM-case.jpg
CTM-case.jpg (338.94 KiB) Viewed 240 times
I am not familiar enough with CTM product lines to say what it was part of and didn't find a comprehensive source online. It says Series #32, A26.
CTM-back.jpg
CTM-back.jpg (384.01 KiB) Viewed 240 times
The design is rather striking with large bevels and interesting layout and key legends, particularly the various icons. It is clearly a descendant of the older CTM keyboard discussed here. It is more or less the same keyboard as the one branded ITOS discussed here. That one being the German layout and this one being Swiss, since I got it from tentator's sale.

The switches are vintage Cherry MX blacks. In fact, it was manufactured by Cherry. The PCB is 601-1518 Rev. 01, again the same as the ITOS.
CTM-top.jpg
CTM-top.jpg (924.44 KiB) Viewed 240 times
CTM-bottom.jpg
CTM-bottom.jpg (1.24 MiB) Viewed 240 times
The circuit has two active components, a 74LS240N driver and a 6801 controller. The cable ends in a DE9 male. Tracing the signals shows:
  • Ground
  • 5VDC
  • an input to the driver and then to P23
  • another input going through the driver twice and then to RESET
  • an output coming from P24 through the driver
There are also capacitors, inductors, and diodes along the data lines for protection and AC filtering. Going through the driver twice just inverts the signal twice so that it ends up with the same polarity.

The 6801, one of the first of what we would now call a microcontroller, has, as one of its additional subsystems beyond the 6800 microprocessor, a Serial Communications Interface, that is, a bare-bones UART. And it's probably not a coincidence that appears as Rx on P23 and Tx on P24.

So, since there are only two data lines, it's going to be some kind of bit serial protocol. And since there's a good bet that the SCI is doing it, it's going to be standard serial, but with the normal NRZ inverted.

With just power applied, nothing shows up on the output line when keys are pressed. And the serial input line is pulled up high. It's probably expecting to be low (inverted NRZ idle high). Doing that yields a single 9600 baud byte.

Since it looks like it's going to be 9600 baud with inverted polarity, I got out the last of the Teensy 3.2s. (Fortunately, there are more on order from Adafruit, whose prices are even better than PRJC's own.) And, indeed, just enabling the serial port is enough to make the one byte show up.
CTM-converter.jpg
CTM-converter.jpg (412.18 KiB) Viewed 240 times
But no more, so the controller is expecting some kind of ack. And the second thing to try -- a 1 byte (after first trying a 0 byte) -- seems to work. Now there is a steady stream of scan codes for each key press.

The scan codes are assigned more or less in order, top-to-bottom, left-to-right.

But what about CTRL and SHIFT? Try as I might, I can't seem to get the scan code to change.

Finally, after figuring out how to turn on the LED under the top-right key and a few other status-like to-keyboard commands, I had the presence of mind to try the right SHIFT key instead of the left. And, indeed, that changes the code.

The key switches themselves are all working. A couple had dirty contacts, but these were "cleaned" using the tried-and-true method of banging on the key hard and fast a few hundred times.

But the PCB has issues. In fact, I wouldn't be surprised if some people reading along here already noticed that in the photo above, in the lower right around the Cherry sticker. It looks like somewhere along the line coffee or maybe cola was spilled into the keyboard and there's a patch where it's corroded through.

The traces are a little thin for a conductive pen, which seem to me not to be a very precise tool. So, instead, I added some old-school patches with 30 AWG wire-wrap wire. The fourth trace up was actually good enough to get continuity, but I did it anyway while I had all the tools out.
CTM-repair.jpg
CTM-repair.jpg (459.95 KiB) Viewed 240 times
And that gets things back working: left and right SHIFT both change the scan code and CTRL sends a prefix byte before the (possibly shifted) scan code.

The exact details of the shift change are interesting:
  • Keys are divided into three sections: the main typewriter keys, the space bar, and the rest (function keys).
  • Within each section, codes are just assigned top-to-bottom, left-to-right.
  • The overall order is function (1 - 53), space (54), main (55 - 103).
  • Then come the shifted versions, but in the order main (104 - 152, shifting 55 - 103), space (153 shifting 54), function (154 - 206, shifting 1 - 53).
All of which should be enough for a QMK implementation. However, that doesn't work at all at first. Turns out, once again, the Chibios GPIO support isn't as good as Teensyduino. Specifically, the output lines, RESET, which needs to be pulled low for a bit to get the keyboard controller all set, and Tx, which needs to be idle low, have low at about 2V, due presumably to pull-ups in the keyboard. The crucial setting looks to be the DSE (Drive Strength Enable) bit in the PCR, which Teensyduino sets, while Chibios only selects the mux. With that enabled, low is 0V and everything is fine. Per the data sheets, while the Input High Voltage for RESET on the 6801 is 4V, it's only 2V in the 74LS240N.

Post Reply

Return to “Workshop”