Piano World Home Page Forums Our Most Popular Forums Digital Pianos - Electronic Pianos - Synths & Keyboards GEM RP90 successful repair

The password is 2571 (also 5069 for some).

The NiCd can be replaced with a Varta 3.6V 80 mAh NiMh (green, rechargeable) or equivalent. A lithium battery may work if it is 3.6V and rechargeable, but the NiMh is the same form factor, and no mods necessary, just solder it in and go.

Small update - for all of You who will read this thread in the future hoping for repairing Your GEM RP90 (and similar).

Including mine, I have now two confirmed cases of repair.
In both cases, cleaning/repairing the board and replacing the static RAM chips solved the problem.
Battery can be either replaced by a NiMH one or just removed if You don't care about on-board note recorder. The piano is working fine without it.
The RAM ICs supply voltage is separated from the rest of the board by a transistor because of the backup power. Maybe this is the reason that only the RAM is damaged by the leaking battery.

According to schematics, the two RAM ICs to replace should be HM628128 - Hitachi CMOS static RAM 128k-word x 8-bit (1Mbit). SOP-32 (32-SOP-525) form factor. CPU is afaik 16MHz so access time should be probably 55ns.
For battery data retention You should use low power versions.

On my board actually there were two Samsung KM681000CLG-5L chips.
I couldn't buy them so I used Lyontek LY62W1024SL-55LLI and they're working as well.
Any memory with the same specs will do.

Flash ROM should be ok.
The type is AM29F800BB-90EC - AMD 8 Mb (1M x 8-Bit / 512K x 16-Bit) TSOP-48 CMOS 5V flash memory with bottom boot sector. The firmware should be still available somewhere on the GEM USA support pages.

Many thanks for this update. I do not need to make these repairs, but maintaining an ongoing catalog of repairs that work is extremely valuable. We can keep these great instruments working!

(I still haven't replaced my display. I plan to try later this year, and I will post the results.)

Hello - I have a Baldwin RP100 with the same battery leaking issue and have determined my RAM chips need to be replaced.

I can't find the lyontek or the Samsung chips you mentioned for sale in the USA. I am amateur at these types of repairs and I did my best to search the internet and found this chip - SRAM Chip Asynchronous Single 5 Volt 1m-Bit 128k X 8 70ns 32 Pin Molded SOIC

link to the chips webpage at Jameco electronics USA:

http://www.jameco.com/webapp/wcs/stores/servlet/Product_10001_10001_391831_-1

My question...can you help me determine if this chip is compatible and will work in this piano's cpu? As far as I can tell the specs match up except for the 70ns instead of the 55ns. I don't know if that speed difference will cause performance issues or not, or if there is another difference I haven't discovered. I found other chips that met the specs but the physical dimensions were not 11mm x 20 mm which is the size of the Samsung chips on the CPU.

If anyone could tell me if this chip would work I would be very appreciative. If it won't work maybe you could suggest a company in the USA who sells the correct chip. I prefer not be buy overseas because I assume shipping costs would be high.

I've taught myself to solder and have the supplies needed to make install the chip and I would like to bring the piano back to life if anyone could help with their advice.

Thank you for your time.

Imho 70ns will be too slow for the CPU clock speed and may cause problems.
1/(16MHz) gives 62.5ns - therefore 55ns memory should be used.
Low power CMOS, 5V, 128K x 8.

You can use mentioned Lyontek, Samsung, Hitachi.
Samsung K6X1008C2D-GF55 (or -GB55) should work too (they are on ebay), or Alliance Memory AS6C1008-55SIN - there are many types of compatible chips.

PS. In the past I bought some IC's on ebay across the ocean so it's really not a big deal

Wow, Michael, wow!

If you put half as much energy into learning the piano as you must have with electrical engineering, I think you'll get plenty of great moments out of it .

It must feel awesome to have such a close connection with your instrument. After all, most pianists don't even know how their pianos work :$.

Not so. RAM speed need not match CPU clock speed.Most CPUs devote several clock cycles to a RAM access cycle.

Consider a fast PC running a CPU with a 3 GHz clock. Your method of computation would require RAM speed of 0.333 nsec. There's no such thing!

Your "most CPUs" is right - but not "all CPUs".
Modern PC (or better to say modern PC's CPU) has a special memory controller just because there's no such thing as 0.33 ns memory. Yet. The rising speeds of memory chips are going to reduce the waitstates to minimum. To achieve one clock cycle access.
But You still have to match the memory access time with the memory bus speed. All the numbers on DRAM sticks indicate the access time, the waitstates and such, it's also programmed in the SPD chip. The controller can accomodate to that.

And here we have something "oldschool" - not modern "the most".
I'd say - back in the day it was "the most" but now we have 1GHz quad-core phones

Inside GEM's board is a 16MHz microcontroller, most probably running the direct memory bus with zero waitstates.
The factory chips with 55ns, which is less than CPU cycle time, suggest just that.
Also - async static RAM is fast enough and is often used just for that purposes - small and fast embedded systems, and it does not need the extra controller needed for memory refresh in dynamic RAM.
I know such designs, I programmed similar ones years ago at university (it'll be >20 years already).

Maybe the 70ns will work - but maybe not.
H8/3003 can work with or without waitstates, with different memory configurations, it's programmable and versatile CPU.
I don't know how the firmware is written and if the hardware won't go off-time.
But why bother? The price difference is negligible and I think it's better to have a direct replacement with 55ns.

I could joke "Trust me, I'm an engineer" but I really have the MSc in that field
Know a bit about sound synthesis too.
Unfortunately, in playing the piano I'm not that good... still a way to go...

Hi,

This is my first post. My name is Ed, I'm from the Netherlands.
I've played piano as a kid until I was 18 years old. At that point, I didn't like the weekly piano lessons. Also, the piano I played on was a bit irritating with stuck keys, being out of tune and other problems. So, I stopped playing. But a few years later, like my teacher had predicted, I wanted to play again.

This time, I bought a digital piano, a General Music Realpiano 2. I was able to buy it 2nd hand in very good condition for 600 euros if I remember correctly. It was 2004 or 2005 I think.

About two years ago it started to give problems. While playing, the sounds would distort.
Luckily I mostly used it with Steinberg the Grand II VST, which is a wonderful VST by the way.

The problems got worse, but the MIDI-Out still worked, so with volume at zero I could still enjoy it.
Over time I heard about the battery-leak problem, so I decided to open up the piano and check the mainboard.
And, yes, the battery had leaked. So I removed the battery and cleaned up the print a bit.
And then, it stopped working altogether.. No more MIDI-out. No more sound. No LCD display. Oops.

Attached, please find a photo of the mainboard and one of the damaged area.
The damage is definitely in circuit around the SEC/Samung memory chips. Actually, these seem to be waveform ROM chips. That explains the scrambled sounds. Those would be a lot more difficult to replace, as I don't have the ROM contents.
But also a few pins of the EPROM might have been damaged, but the EPROM might have survived.

So, I will probably have to replace the ROM memory chips.
Kudoos for Micheal by the way! Great work and very nice of you to document it all so well. Thanks!

Even if I would be able to source the ROM chips, with the waveforms in it already, doing SMD soldering myself is a bit too much for me (normal soldering I do, but SMD is a step too far).

So, I thought of an alternative, as I mostly use the piano for connecting it to the Steinberg The Grand VST.
I was wondering if it would be possible to use the signal coming from the keybed and then wire it straight to the MIDI-Out port.
Perhaps it might need some signal adjustments (resistor?), and I have to be lucky that the serial signal coming from the keybed is indeed MIDI and not some other serial protocol.
If it's not MIDI coming from the keybed, then I could use an Arduino microcontroller to convert the keybed signal into midi and then connect it to the midi-out.

**EDIT**
It seems the signals from the pedals and the keybed are combined and then sent to the microprocessor. See last photo, which I got from the service manual page 7. The keybed calbe has these pins:
1. RX
2. NEXT
3. GET
4. RST
5. TX
6. GND

Michael, you seem to know a lot about this.. Perhaps you can give me some pointers?
Am I correct that the cable from the keybed, is the grey/blue cable coming from the right (directions like on the photo), and which connects to the mainboard on the bottom left, with a red connector?
Another similar cable runs, also from the bottom-left part of the mainboard to the board which is mounted above the LCD screen and all the buttons.
I reckon the cable on the top left of the mainboard has the Midi-signal, as it connects to the midi-panel on the back of the piano (north-west of the mainboard in the photo).
Another bigger cable, in the center on the top of the mainboard probably carries the analog sound output and connects to the amplifier/power board north of the mainboard in the photo).

I have also added an annotated photo. The wiring diagram is from the service manual which I got from http://www.generalmusic.us/GEMFiles/Service/ with password 2571 .

Hi Ed.

I looked into this service manual and schematics and here I have some thoughts about it.
The main board has a H8/3003 microcontroller ("server"), the 2 other boards have H8/329 uC each, lets call it "clients".
The internal communication is done via some serial protocol. It might be MIDI on the TTL level (0-5V, not current loop), but not necessarily - the same protocol is used here for the local control buttons, LEDs and LCD display. I'm not sure if GEM used MIDI control messages for that. Probably not, and using 115 Kbps from RS232 standard (for example) will be faster than 31 Kbps from MIDI.

Both clients are connected to the same serial port of the server CPU (TXD1/RXD1)
Both connectors on the keybed/control panel side have the same pinout (below they're not in order)
1. TXD - transmit data. This pin sends the data to the main CPU board (where the pin is labeled RX)
5. RXD - receive data. This pin receives data from the main CPU board (where the pin is labeled TX)
4. ~RES/~RSTV/~RST - different description, but common function - negative reset. This is connected to the standard RC circuit for power-on-reset.
Might be also forced from the main CPU, don't know, the signal is connected to pin 113 of H8/3003, but the ~RES pin of it is on pin 71 with separate reset circuit.
6. GND/NC, from the main CPU side also connected to GND.

There are also 2 pins, labeled GET (3) and NEXT (2) - and they're looped and crossed on the mainboard between CN3 and CN4 connectors.
To me it seems like some token network - one client is programmed after reset to set the "NEXT" signal, then the second (via the loop) gets GET signal - the permission to transmit data to the server. Probably so, looking at the names
After transmission, it sets the NEXT signal, so the first client gets GET signal and switches off the NEXT. Atter transmitting data, it switches the NEXT signal on, giving the permission to the other client and so on.

Actually, I was wondering why on my GEM there's a loop between two pins on the keybed connector, only via 10 ohm resitor.
Now it becomes clear, my GEM has buttons and LCD connected directly to the main CPU and only the keybed uC is connected to the serial lines.
This way, the keybed uC always has GET signal when sets the NEXT one.

It may be possible to reverse-engineer this protocol.
Probably the GET signal should allow the client uC to transmit somehing (like key press on the keybed), but You must find the correct baudrate and figure out the data format.
There is also a receive in on both clients. I don't know, what kind of data the CPU might send to the keybed controller. Maybe only "loopback test" message during startup and nothing more and the keybed controller will work fine without it.
The GEM FAQ states, that for example You need to connect the pedals (and release them) before switching on the piano, because in other case they will work in reverse. It means, the pedals are checked during init/reset and then only transmitted when a position change is detected.
You can try and connect an Arduino board, and try to capture something on the RX pin. Later using SoftwareSerial library You can probably use both boards (keybed and control/pedal) with one Arduino. Or just connect the pedals directly to Arduino and write functions for it
(I made a MIDI triple pedal from a similar KORG unit and Arduino board)
I have a Saleae logic analyzer and some time ago I thought about checking the protocol inside my GEM, but just now I totally don't have a time for that, sorry... orz

***

As for the damaged board... I learned SMD soldering just to be able to repair my GEM.
Repairing such board is possible, but it requires patience and time - any service shop will charge You a lot for that, so I did it myself. Like I wrote, I practiced on some junk boards, like old DRAM sticks.
"SMD drag soldering" is quite simple to learn, and do not require any special and expensive tools.

The board is only two-sided, no hidden traces or layers, everything can be repaired.
Everything can be (and should be) checked with a multimeter/low voltage continuity tester.
You has the service manual and schematics - I did it even without that.
The distorted sound probably came from data or/and address lines shorted together and there is a high possibility, that the waveform and program memory is still good, just the board has breaks and shorts. And probably RAM to replace.
In my case, and in the second confirmed repair (user from Holland), the only really damaged thing was the static RAM.
In both cases careful board repair and RAM replacement solved the problem.
The static RAM is a CMOS chip and quite prone to damage.
On RP2 board they're also near the battery and use the same battery backup circuit like on RP90.
I think, if You spend a little time, You might be able to repair Your GEM too

Thanks a lot, Michael, for your extensive reply! I really appreciate your help!

I'll first try and interface with the keybed controller.
I'll try and hookup an Arduino to the TX/RX lines and see what I can discover.
The GET and NEXT line of the keybed interface, I can connect together with a 10 Ohm resistor, I assume.
With some luck, the keybed controller might send some data when I press keys. If I'm unlucky the controller will first wait for some special unknown code before it starts transmitting. I'm afraid using a logic analyser won't give results on my now defective mainboard.

I'll let you know the results.
If that doesn't work out, I'll try and learn the SMD soldering.

Ed

Hello Michael and all
I Am Sandro and I'm from Italy.
Sorry for my poor English.

I read with admiration your repair of Generalmusic RP90.

I'm a teacher in italian school, music fan.
I have a Piano arranger Generalmusic PS1300 with a similar problem: loss of acid from the battery. The piano went to freeze.
After replacing the battery, the piano worked, but after a while disappeared the written on the screen and the lighting of the LEDs of the buttons on the control panel.
I state that my piano has the CPU board-motherboard separate from the and power amplifier board..
My attention was focused on the RAM. I noticed that the one that is on my motherboard (KM416C1204CJ-L6) is different from the original chip as shown in the schematic (HM5118160A LJ 16 Mbit DRAM, Ta = 70 ns). This suggests to me that has already been replaced once.
Both are now unavailable.
So, could you tell me a chip equivalent because I'm going to change the RAM (I know that may need just a reballing, but, like you said, these are very fragile RAM).
2) A last question, for your kind patience: the relay on the power board don't activate; I do not know if I even a power problem that comes from the final stage chips (TDA7294) or even if this is caused by the failure of RAM.
Confident in a reply illuminating

Thanks
Sincerely.
Sandro

Hello.
Looks like I'm becoming sort of a guru of old GEM repairs

The dead battery probably caused the freeze of the CPU - the memory wasn't working because of low voltage.
Replacing the battery solved this problem, but in the meantime the acid probably destroyed some traces on the board and then the memory stopped working for the second (and last) time.

I don't think the memory was replaced.
GEM factory could use different ICs with the same function, coming from different manufacturers.
My GEM also had different chips than stated on schematics.
HM5118160A is a Hitachi 1Mx16 static DRAM with fast page mode. There are similar chips still available.
Current replacement are for exaple Integrated Silicon Solution ISSI IS41C16105C available from Mouser Italy http://www.mouser.it/Search/Refine.aspx?Keyword=IS41C16105C
or Siemens HYB 5118160BSJ (on ebay).
(I'm not sure about the package version used in GEM, SOJ-42 or TSOP-44/50, You must verify it by yourself)

The relay is connected to the "Muting" signal - it's connected to the CPU pin so I'm 99% sure, that it does not function because the CPU board is not working properly (hangs in the middle of startup sequence)
Again - the RAM should be unsoldered, then the board carefully cleaned of even small traces of battery acid, then any broken/shorted traces should be repaired. If the acid damaged bigger area (under other chips), You can unsolder them too and clean the board.
Maybe there are some chemicals to neutralise the NiCad acid, don't know.
I just used a fair amount of IPA, but I unsoldered both RAM chips and the flash memory, so I could clean and check the whole damaged area.
Then You can solder the new memory chip.
I hope You will be able to repair Your piano.
Good luck

Hi Michael thank you very much for your precious wanted response, which gave me important tips.
Sorry for my late reply, but I'm Czech Republic for work.
I'll buy Ram chips on the web.
Thanks for equivalent model names of it.
I'll say you what's happening...
Thanks a lot..
sincerely..

A post on the Gearslutz forum links to an announcement that GeneralMusic is being restarted. I kid you not. Here's the link to the very brief GeneralMusic announcement:

http://www.generalmusic.com/

Here's the link to the thread on the Gearslutz forum:

http://forums.musicplayer.com/ubbthreads.php/topics/2652758/Generalmusic#Post2652758

Could be great news, yes?

Some company from Finland bought the rights - it could be great, yes.
If only they're fans of the old GEM gear, not only want the logo.

Hi Michael, and to all of you!

I'm Csaba from Hungary. Thanks to your instructions I could repair (almost) a GEM RP220. The CPU board of it looks the same than your RP90's, just some more components on the empty places.

[img]https://drive.google.com/open?id=0BxXLhgubTrcybGwwQXJLb3VjSEU[/img]

Same issue: can't switch on, leaked battery on the CPU board. I've replaced successfully the two RAM chips, and hallelujah, it's working! I was really happy, it's a great digital piano. I don't really like the grand piano sound of it, but it has 64 internal sounds and 64 programmable sound, huge song library and almost everything is settable. But during testing I realized that it has still some problem. 9 out of the 64 internal sounds, and more of the programmable sounds sounded really bad, like some digital noise, and playing in these sounds, keys sometime worked, sometimes not. Other sounds worked perfectly, but I wanted to repair this.

I made the self tests written in the service manual, everything looked OK. I've found a program on the old website of General Music, with what I can upgrade the operating system in the flash ic to version 2.02 through the computer port of the piano and the serial port of a PC, if I have at least the 2.0 version of the operating system in the piano. I already had the 2.02 version in the piano, but I thought, maybe there are some faults in the content of the flash, maybe it's injured. So I made the cable for that, and made the upgrade. It erased the flash and rewrote. Unfortunately there aren't any change.

Maybe there are some broken or shorted traces still. The flash is the closest component to the battery, but I really didn't want to solder it if not necessary, it has so small legs. So first I resoldered the three generalmusic ics: wave 98, wave 3, library rom. These had some dirt over there legs, but looks like they worked fine, because there weren't any changes.

OK, no other way, only the flash is left, I have to resolder it. After the first resolder, the piano doesn't switch on. Oh, goddamn piano, why didn't I left it in peace? It was working already, I've spoiled it just because of some not working sounds. I really would have liked to bang my head to the wall After calming down, I started to search for the fault. I've checked all the 48 miniature legs of the ic using a multimeter and the schematics. All connections OK, but I've found a short between the last two legs (47-48). One of them is the 5V. Fine, there's hope still. I could not see the short even with my magnifier that I used to use for smd components, and could not get rid of it with solder sucking wick. I have to resolder the whole ic again.

After that I checked again all the 48 legs with the multimeter. Looks ok. Can go back to the piano. Praying. Switching on. It's alive!!! Text on the LCD!!! But wait, not the usual. It says: Ready to upgrade, OS not valid. Jumper settings on the board are ok, I didn't chnage it. No problem, I can upgrade it through the computer port, I've done it already once successfully. The upgrade procedure starts with a test, everything looks ok. But after that it stopped at erasing the flash. Oh, no! Trying again, it's ok, erased and rewrote the program. But after switching on the piano, the text is the same: OS not valid. I kept trying on more and more, but it always stopped at erasing the flash, i never could rewrite it again. And at the last time, it's dead again, no text on the LCD, without that I can't write it through the computer port. Going back to the wall, to bang my head in it

I think my flash is dead forever now. But hope is not dead yet. I can buy empty flash ic. I can't write it through the computer port, because I can do it only if I have a working OS in it. But I would be able to do it with an eeprom programmer. But for that i will need the content of the flash. In the programs library, there is a file: "Rp200 Grp300 Rp220.mor" Can this be the content of the flash that I can use with the eeprom programmer? I hope so, but I'm not sure about it. I know there are eprom files with the extension .rom .hex etcetera. But I don't know what is the .mor extension. How could I get to know this? I don't have an eeprom programmer yet, but I will buy one with a TSOP48 socket, if I can save this piano with it.

Here are the upgrade program's installer, the "Rp200 Grp300 Rp220.mor" file and the service manual (password: 2571):

https://drive.google.com/open?id=0B...Qb180bzBReXdqd3Q0cUVvMU1ILUZtNnF5TmdNRzQ

The flash ic is 29F800BA-90PFTN. Can I use any of these instead of that?

http://hu.farnell.com/webapp/wcs/st...;storeId=10162&gs=true&st=29f800

Thanks in advance for your help!

Cheers,

Csaba

Hi

Have some bad news and some good news

First, the flash - only two of them are designed to operate at 5V and they should work.

Second, the firmware.
It was a very bad idea to reprogram the chip, when the whole thing is not 100% working and You don't have a backup.
I bought a flash programmer before I even started to fix my piano, and made a backup twice (and compared) to be more sure.

I checked the firmware update program for RP100 version (v2.03 in this case) against my own firmware (v2.00).
Then compared to the plain v2.03 firmware file, which is still available for download.
Unfortunately, there isn't a RP200 not-upgrade-version, or at least I did not found it.

Looks like the mor file is not the whole thing, there is more to it

The mor file is only a part of the firmware, but it's a main part, starting from address 0x8000, after it there are only 0xFF values almost to the end (it means erased, unprogrammed area).
I suspect, that the beginning of the flash chip is some kind of a bootloader, probably with the OS update procedure and such.
I think, the update program does not erase this block, so it should be still there, and the board stopped working from other reason than dead flash. I hope so.
The bootloader is probably present only in v2.00 chips, because the v1.00 firmware was shipped in half smaller flash chips (the service manual mentions AM29F400B-90EC 4Mbit flash memory in the part list)
Because the v2.00 is too big to fit in the 4Mbit, they switched to 29F800B 8Mbit (1MB) version later.

In the upgrade package there is another mor file, named Entry200.mor (Entry100.mor in my case) - these 4 bytes are going to the very end of the flash memory, to the 0xFFFFC - 0xFFFFF address range.

So, if Your flash file is still readable (in the programmer) and You have this first block intact, You can read it and reflash the firmware to the new chip.
The bootloader (0x0000 - 0x7FFF), then the big mor file at 0x8000 and the small one at 0xFFFFC.
If not, well, You'll have a problem and we will try to think of something.

Thanks a lot for the very extensive reply! Then the next thing: I'm going to get a Willem eprom programmer with a TSOP48 socket. I think I will be able to use it for other projects in the future too. And helps not to make this fault again

If I won't be able to read the chip:
- Don't you think that because of the similar structure of my RP220's and your RP90's CPU board, the bootloader part can be the same?
- I try to reach Dave McMahan, and ask if he may have the whole eprom file, somewhere hidden in his drawers.

I'm going to write as soon as I have the programmer, and tried to read the flash ic.