The Korg CX-3 is one of the most popular and best sounding Hammond C3 clones. (I am talking about the vintage version from the 70s, not the digital reissue) I consider myself lucky to own one because it’s great for playing the 70s hard rock cover songs that I do with my band.
Since the CX-3 was born in the late seventies it does not have a MIDI output like most other keyboards nowadays … which is a great pity because the touch and feel of the keyboard is amazing! So I was wondering if I could teach my compact organ some MIDI, e.g. adding a real MIDI output to my beloved analog organ baby. This plan was accomplished with an Atmel ATTiny 2313 microcontroller.
I was wondering if it was possible to get this job done without soldering wires to each key contact because that would make my organ a mess. So I crawled the web for information and found myself gazing at the following page with awe:
Thank you Robert Weathergreen for maintaining this website, it is !exactly! what I was looking for. Apart from mere schematics there are sketches of the PCB and even theory of operation/service manuals.
In the “theory of operation” section I found this graph here:
So I learned that there are two ICs (SM-304A) inside the organ that are directly connected to the keys and do nothing else than repeatedly generating a serial data stream (with a length of 65 bit) that tells me which keys are pressed and which are not. The corresponding output signal line is called “D” for data in the block diagram. These shift register ICs are receiving control signals, i.e. a clock signal “T” and some kind of reset signal “U” that marks the beginning of the sequence (bit 1).
If we could somehow eavesdrop on these three signals that would give us all the information we need to generate our MIDI signal.
First we have to find the desired signal lines in the schematic:
An there they are, T, D and U according to the labels in the schematic symbols for the shift register ICs. You can see that there are three NPN transistors (Q1, Q2 and Q3) functioning as emitter followers. Q1 and Q2 seem to buffer the U and the T signal coming from the control unit before they are distributed to both shift registers. Q3 buffers the D signal coming out of the second shift register. So I would propose to tap into the signal lines right at the emitters of these three transistors in order to capture a strong and stable signal whilst interfering as little as possible with the organ electronics. Thanks to robert.weathergreen.com we even have a map at hand to locate the transistors on the organ’s main PCB.
Now we just solder wires to the emitters of the buffer transistors plus a wire for ground connection. You probably can steal some +12V as well to power your microcontroller through a 5V fixed voltage regulator. For example, there are +12V at the collector of Q3. I used an external power supply though, because I already installed a supply for my tube overdrive modification. Don’t power the microcontroller board with the +12V from the main PCB if there should be strange noises.
Question: How do we feed the signals into the microcontroller? If you look at the signals on an oscilloscope you realize that they are not very TTL compatible, in fact the logical HIs are approx. +12V. So we need to convert them to TTL. Therefore we employ the (HEF)4049 or 74HC4049 IC. (NOT the 74HCT4049, because it has TTL input) The 4049 is a hex CMOS inverter with the nice property that the input voltage can be higher than it’s supply voltage. That makes it suitable for high to low logic level conversion. Consequently the signal is logically inverted, but that is not a serious problem as the microcontroller can invert it back in software.
Here’s the schematic of the microcontroller board I designed for this project:
And a nice picture of the actual board:
And the place I permanently installed it:
I first had the signal lines going out the other way; i.e., from under the right side of the PCB. That was not such a good idea, because the rapidly changing high level signals induced some noticeable humming sounds into the sound-generating section of the organ. The way it is installed now, the modification disturbs the organ not the slightest bit.
So what does the microcontroller do to generate the MIDI data?
For each rising edge of the T signal the logic state at the D pin is read and stored at a certain position in an array in the microcontroller’s memory. The position naturally corresponds to the number of the timing pulse of the T signal, which in turn corresponds to the number of the keyboard key that the D signal is telling us about at this very moment. When the U signal displays a falling edge the array index is reset to zero, if not the array index is continuously incremented and we overwrite the same memory with a digital “snapshot” of the whole current keys pressed/not pressed situation.
Let’s say the program is dealing with the status of key #20 at the moment. Before the new key state is written to the memory, it is compared with the old state from the previous “round”. If the memory says “0” and the new state is “1”, then it is clear, that the key has been pressed in the meanwhile. So let’s generate a MIDI message that contains this information and send it via the UART, previously configured to a baud rate of 31250 baud (THE MIDI baud rate specification). A MIDI message for a note on event of key #20 consists of three bytes:
byte 1: 0x90 (shown as hex): “I announce you the beginning of a note on event on channel 0”
byte 2: 20 (shown as integer): “It’s about key #20”
byte 3: 64 (shown as integer): “The key was struck down with a velocity value of 64” (possible values are 0-127, an organ keyboard has no velocity sensitivity)
If the memory says “1” and the new state is “0” then the key has been released and a similar MIDI signal is generated. But it now begins with “0x80″ which means “I announce you the beginning of a note off event on channel 0”. There is a velocity information, too, but it does not really matter. I just send a zero.
For a detailed howto about MIDI and AVR microcontrollers see “MIDI and the AVR” on avrfreaks.com.
EDIT: I recently tried to recompile the firmware after doing some minor changes. This led to unpleasant behaviour (freezing of notes, glitchy sounds), because the microcontroller lost sync with the input signal. I suppose it is because I use a different (newer) version of gcc-avr now, which compiles the code differently so the timing is different. Sadly I heavily rely on the timing of the original machine code. I know this sucks. But hey, the original hex file in the firmware zip-file still works!
Microcontroller code/hex files and PCB layout can be found here: