Roland D-50 D50 keyboard repair forum..

[pecorporation]

Does anyone have any expertise or know of a great keyboard repair forum?
I have a Roland D50 where the memory backup battery leaked and died (no circuit board damage) but all sounds were lost. Replaced battery & tried to reinstall sounds, but now only the 'up' stroke of each and every key motion makes a sound, like only the second half of the sound plays...no sound when any key is initially hit.

Any advise greatly appreciated! Thanks!
Steve

[Enzo]

Did you reinitialize the keyboard? And did you use the factory recommended procedure for reloading it?

And try "vintage synth forum" into google. Looks like 1.6 million responses to me.

[pecorporation]

There is no factory reinitialization proceedure for this keyboard as specified by Roland and yes, I did the bulk upload and bulk dump per factory spec.

"Vintage", Enzo? Seems like only yesterday... :-) I'll give it a shot.

[g1]

TUNE/FUNCTION AND MIDI DATA INIT: HOLD 0 AND DATA TRANSFER, POWER ON. PATCH + REVERB MUST BE LOADED FROM CARD OR SYSEX FILE.
Appears to be the reset/reinitialization.

[pecorporation]

Still no change in play problem. May have to give the folks at Roland a call.

[Steve L]

I have the service manual if you want a copy.
I would need an email address since it is about 5MB.

Steve

[pecorporation]

Thanks, but I already have the SM. Appreciate the offer,though.


Steve

[SPARESROLAND]

Hi Steve

The D-50 used to have a factory preset card which enabled you to reset the D-50 to it's original. These over the years have been hired by uses and not returned to Roland.
Have you tried this site to restore your settings? D-50/550

very best regards
Steve

[kooroshi60]

Hi there , I have the same problem with my roland d50. Please let me know if you found how to fix it. Any help would be appreciated.

[niteowl]

Me three. My D-50 was in a closet for many years. I recently got it out and had the same odd keyboard problem as described here. Everything else
seems okay. I opened it up, checked out the keyboard and it seems fine from the keys to the 4 connectors on the keyboard itself. There are no shorts and
pressing keys makes the expected keyboard matrix contacts. I suspected the dyna-scan board (still do..) so I touched up all the solder joints but that didn't
help. Last night, I found the D-50 service manual online. It has a pretty complete schematic and describes the internal diagnostic mode. I was shocked to
see that the cable going from the main board to the dynascan board actually runs the mux'ed address/data lines from the main processor. No wonder they
needed to wrap foil around that bundle! So the diagnostic mode is very helpful. You press 0 + Decrement and power it on and can test all buttons including
the keyboard with the Panel test. On mine, I noticed that pressing the leftmost key (C2) doesn't register as C2 all the time, but sometimes gets confused with
(E2). Pressing E2 shows confusion with C2. The pattern is the same over the whole keyboard: every group of 8 keys has an alias +/- 4 keys away. This
seems like an intermittent cable problem, most likely in a single wire.

I would be interested if either of the people who have this problem can run the panel test and see if there are similar problems.

[Enzo]

Sounds more like a short in the matrix to me. Without me looking it up, are there not a long row of diodes all along the key contact board? Pull the ribbon cable off the key contact board or otherwise disconnect the keybed from main circuit board. Now go down the row and check each diode for shorted condition. Really only takes a few minutes.

If you haven;t pulled the contact board off the keybed, you ought to to give it a good cleaning, and look to see if there is any drink residue hiding on it.


And as always, make sure the ribbons are on the right pins the right way.



Matrixed keyboards group the keys. then there are strobe lines and return lines. A pressed key connects a strobe and a return. SO the main processsor sees its strobe signal coming back up a return when the key is pressed. The strobe lines will all look the same on a scope, you can;t see it but each one is one step later than the last. If you sync the scope to one of them, then the pulse you see on each other line will be moved over some amount. What you want to see is all 8 strobe lines looking the same, a nice clean pulse. If the pulses look doubled or there are any half-height pulses, that is problem. The strobe lines should look dead until a key is pressed. Then the pulse should appear. Scope each return line and see if any look odd.

[niteowl]

Hi Enzo, thanks for the reply.

I had already checked all the diodes and they seem okay.
I did remove all the keys and checked for dirt on the contacts but didn't see any.
This D-50 never left my house and never had anything spilled on it. I just put it away (working) many years ago and just got it out recently and this is the way it was.
The keyboard matrix is done as 2 8x8 arrays. The left 32 keys are one matrix and the right 29 are the other, with each key taking up 2 spots in the 8x8 matrix.
I ohm'ed out each 8x8 with no keys pressed and see open circuits on all 64 row/col combinations. I can press each key and see the resistance drop on the expected 2 points in the array. The key-down resistance is high, maybe 700K ohms, but all the keys are like that.
The oddness in the keyboard panel test isn't explained by a short, I don't think. I will inspect the solder joints again for opens, and probably put a scope on it
to see if the active scanning shows anything weird. I tried this a while ago but didn't really have the circuit figured out.
I'm wondering what the static RAM chip is for. It's a 6116, which is a 2Kx8. I guess it needs to buffer the keyboard presses until the main processor can
read them, or maybe stores some keyboard state. I could replace that chip, but if the main custom chip has gone bad I guess I'd need to find a replacement board.
probably got moved a few times so I would think it was bumped and something is dislodged.

[Enzo]

It may not be a short of course, but they are not always detectable with an ohm meter.

The way it can happen is if two lines are shorted together, for example two returns, then when one key is pressed, then when the CPU strobes, it sees the strobe return not only wher it should but also on the line shorted to it. Same thing can happen when two strobes are hooked together. A switch closure can be read by the CPU as the other line's switch. And if ther is a shorted or leaky diode, when its switch is closed, that can wind up shorting two lines together, and THEN the next switch pressed can confuse the readings. But in that case there is no hard short between lines, it is only caused when the switch with the shorting diode is closed.

WHen I used to train pinball technicians, this exact thing was always one of my training exercises. There would be a circumstance where hitting the left target would cause the right bumper to fire, or hitting the left target would cause the game to go to "tilt." But it would only happen when the ball was siting in a kickout hole or a drop target was down, which was where the shorted diode was. In a case like that in a keyboard, such a thing might only occur when playing chords, for example. This may not be what you have, but it is a reasonable thing to consider.

Another thing that can happen is when a certain arrangement has pullup resistors on each return, so they remain logic high until strobed low. On a lot of stuff I service, those pullups would generally be in resistor packs - those flat things with 9 legs, and they are something like eight 10k resistors with one end common. In any case, if there is an open pullup, then that line that now lacks pullup can drift to an unsteady state and seem like it is transitioning logic states.

All this is why the scope should tell you a lot.

I don't know the scanning in the D50, but in some other things, the CPU scans the switch matrix looking for closures. It sees them right away, but what it does is keep checking, and only after it sees the same switch closed three reads in a row does it act on it. SO in those cases it keeps a scan of the keyboard in scratchpad memory, keeping the three most recent reads. The reason they do something like that is so the system won;t react to every little static glitch or transient that comes along. The matrix scan operates at a high enough speed that there is not a wait for a response that is discernable. That might explain some RAM on the key assigner.

Were it mine, I would still have large ICs down my list after a lot of other things.

When you say a closed switch measured 700k, are you measuring right at the contacts? Or could that be inclusing a diode in series, as in measuring at the ribbon connectors? Does reversing the meter leads change that 700k?

[niteowl]

I'll drag my scope out this weekend and see if it helps. I think I looked at the keyboard scan signals before but I didn't
know what to look for. I do remember seeing a signal that was high for 7 periods and low for 1 which is what you would expect
for an 8x8 keyboard scan. Now that I have the schematic it should be easier to debug. To look at the cable going to the
motherboard I would need a logic analyzer since it is muxed address/data. I can probably look at the chip select for the
keyboard to see how often the CPU is checking the keyboard scanner. There is also an interrupt line but it may be common
to all the devices on the main board.

I looked at all the cables going to the dyna-scan board and they seem okay. I traced them from the far end of each connector
to the pins on the main gate array.

I found this description of the keyboard scanning in the Roland S-10 Service Notes:

Major tasks of the CPU:
Keyboard Reading
Transfers the velocity curve data to IC36 (SRAM
HM6116). The key scanner IC37 (63H139) refers to
this table for determining a key dynamics and writes
it into IC36 together with the key number and the
key event (on or off). The CPU reads these data
through IC37.

The schematic and pinout for the S-10 and D-50 look the same so I think it likely they reused the keyboard design.
It looks like the CPU loads something into the SRAM so if the path between the CPU and keyboard is bad then
it would load bad data. This seems more likely to me at this point. Maybe 'key dynamics' just means debounce delay?

Also, during the panel test, the reported keyboard velocity is either zero or 127. I never saw any other value even though
I tried to vary the speed I was hitting the keys with.

I measured 700K at the keyboard connector so that includes the diode drop. Reversing the leads reads 'open' as expected.

[Enzo]

REally ought to use the diode test funtion rather than ohms for that.

Keyboard dynamics to me means velocity.

If all your strobe lines look OK, I doubt the timing is off. You could always trigger off the end one and see. You don;t need a data analyzer to see if the return lines look screwy. They either cleanly transfer the strobe signals to the return lines or they don't, and contention is easy to see since it reults in a step in the middle of what should be logic highs and lows.


You are free to convince me otherwise, but I don't so far like the bad data line theory. By the time we get to the data bus, SO many other things are involved that we would have may more trouble than just a few funny key responses.

I have a hard time imagining the problem is any further inland than the key assigner.

Just my opinion.