[SOLVED] DX7ii FD - Verify Error on sound bank factory reset after board repair

[Tsioumpiou]

The Story so far,

some months ago i got my hands on a DX7ii FD for around 150 Euros.

The board was toasted as someone tried to get the E! expansion card and failed tragically on the wires that attach to the ICs.

The result was damaged traces all around IC25 and IC 26 and the Toshiba memory chips were dead during the process.

Moreover, the previous owner failed the battery replacement resulting in damaged traces both on the + and – trace.

The keyboard would still boot even severely damaged at this point and the screen would display random hieroglyphics.

At this point and due to the fact that the keyboard was almost in perfect shape besides the board damage I delved into the restoration process.

Got new Toshiba TC5564PL-15 Chips to replace the memory ROMs, got a battery holder to add to the board so to not further stress the upcoming retracing and also got IC mounting boards to make my life easier in the future should the TC5564PL fail.

Following that got the board to a friend that is a microsoldering guru and retraced the damaged traces of IC25 and IC26, fixed the traces of the battery + and – and in general did the tedious job that I had nor the skills, the equipment and the willpower to undergo.

Now, the keyboard boots normally and plays all the sounds from the external ROM cartridge. The memory chips though are blank so there is no way to access any sound banks from the internal memory.

When I try to restore the internal memory from the cartridge, I lift the copy protection for the internal ROM following the instructions and then when I get to the load option after and accept the overwrite of internal memory I am getting an error that reads “verify error”.

I have looked everywhere for this error code and I can not seem to find anything related to this particular code.

Anyone with experience in loading the default sounds to the DX7ii FD or with experience to troubleshoot what is going on there would be a saviour at this point as I don’t want to operate the synth with the card loaded in the card slot 24/7.

Best,

Nikos

 

[Youngwhisk]

You could get a sysex copy and try to load it via midi?

 

[Tsioumpiou]

You could get a sysex copy and try to load it via midi?

I tried this.

Used Midiox and got patches from the yamahablackboxes site. Got the 2 files sysex for voices 1-32 and 33-64. I succesully send the sysex to the keyboard but when the dump is complete the sounds are corrupted in the keyboard and the name of each sound bank is in hieroglyphics.

If anyone has any solid sysex files for this i'm up to try them

 

[Youngwhisk]

There is a bunch of stuff here for a DX7 but may apply to the DX7 II FD as well:

Yamaha DX7s Sysex!!!! Please Help DX7s Users! - Gearspace.com

One of the suggestions is to slow down the sysex transfer speed. In Midiox, in the Sysex window under Configure there are options regarding delays. Look at the help file for this as that may be the cause of corruption.

 

[Tsioumpiou]

There is a bunch of stuff here for a DX7 but may apply to the DX7 II FD as well:

Yamaha DX7s Sysex!!!! Please Help DX7s Users! - Gearspace.com

One of the suggestions is to slow down the sysex transfer speed. In Midiox, in the Sysex window under Configure there are options regarding delays. Look at the help file for this as that may be the cause of corruption.

Thank you for your responses.

I did try this and i even used sysex librarian on my mac. Went down to as low as 10% transfer speed and even tried with as low as 4 Bytes buffer but nothing worked.

I used different sysex files for DX7ii and DX7s and nothing worked.

I guess will keep on troubleshooting this and let you know if i get a break on it.

N.

 

[Youngwhisk]

If yours has version V1.6 or later you could try this:

https://www.deepsonic.ch/deep/docs_manuals/yamaha_dx7ii-d-fd_service_bulletin_419.pdf

 

[ccaudle]

and I can not seem to find anything related to this particular code

I would go back over all of the connections to the ROM chip, and also verify that the exactly correct ROM devices were used.
The usual process would be to write the data to the device, then read back all of the data to verify it was written correctly. Verify error presumably means that the data did not match, so it could be something as simple as a solder bridge on one data or address pin, or an entire device not working properly. The reliable way to check would be connect a logic analyzer to the address and data pins and check that the data is being written properly (no address or data lines stuck high or stuck low), and then check the data as it is read back to see if one chip is not responding or one data line is not being driven properly.

 

[Youngwhisk]

Got new Toshiba TC5564PL-15 Chips to replace the memory ROMs, got a battery holder to add to the board so to not further stress the upcoming retracing and also got IC mounting boards to make my life easier in the future should the TC5564PL fail.

Also check for a bent pin that is not making contact in the chip sockets.

 

[Rob Flinn]

You should join this facebook group, There are a lot of people there who specialise in repairs to these sorts of keyboards Vintage Synth Repair And Mods. | Facebook

 

[Youngwhisk]

Have you made any progress on this?

 

[Tsioumpiou]

Have you made any progress on this?

I had the project parked for a while but about 2 months ago i found the mental strength to complete it.

Long story short the DX7 is now running.

Apparently the issue was that the tiny wire that was used in one of the micro-soldering retraces was not enough and although there was an active connection to the write enable pin of the respective IC (was tested for continuity and it was working) but after ruling out everything else i made an guerilla style jumper cable from one pin to the other and it just worked. The verify error was this way confirmed to be related by the failure to trigger write enable function on the chip.

After fixing the chip though i also bumped to the classic MIDI compatibility issues so the transfer speed issue i was getting was also related to the tools i was using. After trying multiple midi interfaces the one that did the job for me was Midimate EX from ESI (had to buy it as i also bought 3-4 other interfaces).

To trouble shoot the "verify" error i followed the following steps that ruled out connection issues and pointed out the write enable possibility

My process was

• Made a matrix on an excel spread sheet with all the connections from RAM1 (IC25), RAM 2 (IC26), EPROM (IC23), PSRAM (IC22), MPU (IC16) and all the secondary ics (IC 5, 9, 12, 13, 17, 19, 24, 27, 28, 29, 30, 32, 33, 34, 35, 39 and YA3). The reason for those ICs is because RAM1, 2 EPROM and PSRAM are in series and all connect to the MPU via the secondary ICs. Since the main ICs are in series the issue of the DX7ii failing was not in the connections.
• After reverse engineering the circuit with the help of a friend that is an electronics engineer we broke down the functions of each part of the the chips and concluded that the only possible issue should be the chip not being forced into write enable mode.
• Replaced RAM1 (IC25), RAM 2 (IC26), EPROM (IC23), for a second time to rule out possible "hardware" failure
• After testing for a last time with the fresh ICs installed and failing the test i literally pulled up the chips from the sockets and placed a DIY jumper cable from one pin to the other (write enable pin) and it worked (it is the red cable in one of the attached pictures).
  
  
  An interesting side story to that is since i had to delve that deep into the DX7ii main-board and how the chips interact i got some knowledge on whats going around so with a friend now we are developing some custom cartridges to expand the storage capacity.
  We will send out the order for the PCBs and components within the next few days
  
  Also attaching some picture of the PCB with the ICs removed that if you zoom enough you might be able to see the damage to the IC lanes as well as the battery lanes and with how the repair looks.
  It's not the cleanest job but after having this project open for 6 months with constant trouble shooting and the extensive damage it had when it came to my hands i am more than happy with it.