Repairing a Yamaha CS20m mono synth
11All right, so just in case you were wondering why an analogue monosynth from 1979 has a CPU board in it, it's because the synth has a really simple memory recall function. You can either use the sound live from the panel knobs, or you can save and recall the panel settings to one of eight memory slots which are on buttons.It's really very primitive, with the biggest restriction being that the panel controls are disabled when you're using the saved settings, which means you can't edit or fully manipulate your saved sounds. I generally used to keep it set to 'panel' for this reason.*But since all the controls pass through the CPU board, this is the next thing that needs to be working before I can move on to anything else. Initially, the lights are flashing nonsense and buttons are unresponsive which is not cool.So here I have replaced whichever generic logic chips on the PGM board that were cheap and easy for me to obtain in small quantities. Don't they look nice in their new sockets? Maybe it's overkill but these are nearly 40 year old ICs, they only cost a buck each to replace and the socketing should make future repairs so much easier. If this board starts working I'll probably do a bulk order and rechip all the boards. Capacitors have already been replaced in an earlier repair attempt. I also checked the connection to each nearest neighbour when putting the sockets in, so I know those parts of the circuit trace are all good.Plugged it in, fired it up... and the memory buttons still seems unresponsive. Dang. The lights aren't going nuts like they used to, but they aren't behaving correctly either.Well hey, now I get to use the oscilloscope to analyse it. I used the oscilloscope to observe a correctly-encoded 8 bit number being sent from the buttons on the panel into pin 4 of the CPU when that button was pressed. Neat! Another test point on the board shows that this value is being correctly registered and stored when the button is released. Good!I connected to another test point and saw the analogue controls being correctly multiplexed. A few of the individual knobs and sliders are responding a bit weirdly but most are good and the multiplexing itself seems to be working fine.And wait... I said earlier that the LFO trigger light was blinking and responding to the LFO speed knob. Well, the LFO speed knob is one of the parameters stored by the CPU, by golly. I check again and I see that the light does indeed respond to the speed control when the CPU is set to 'panel'. And when I push the memory buttons, the light becomes unresponsive to the knob and starts blinking at different speeds. It's using stored values! Furthermore, I discover that I can set the speed on 'panel' and then write it to the memory slots.Conclusion: the brains are working fine now. The lights on the panel board must be malfunctioning. Very good news. Over to the panel board next.* One possibility for a future project would be to replace the entire CPU board with an arduino-based system which I could program with a custom OS - one that supported live editing of stored settings, memory expanded from 8 patches to 64 or 128, and the ability to control all panel settings via MIDI would be three really useful things that could be done with that. You could even go nuts and program in additional software oscillators and patching options if you had an arduino in there. This is obviously a big step up in difficulty but it was something I was considering looking into if I couldn't get the original CPU to work, and it would still be fun to attempt one day.]