Diagnosing and attempting to fix a Yamaha DX100 – Part 1

I was very lucky to be offered a non-working Yamaha DX100 from Simon Walters. On arrival I can see it attempts to boot but apart from the odd character on the screen, I wasn’t really getting anything useful happening.

My thinking here is that as it is a pretty nice synth with most of its functionality on a single PCB with connectors to the peripherals, if all else fails I could stick a Pi inside and turn it into a DX100 shaped MiniDexed DX7!

But I’ve decided to have a proper look to see if I can do some “proper” digital electronics fault-finding for once to see if I can get anywhere.

Spoilers – it still isn’t working, but I’m still working on it! This is a post of what I’ve looked at so far. A massive thank you to the various synthdiy and electronics people on Mastodon who answer my (sometimes) silly questions!

• Part 2 – Reading the ROM, checking the connectors, failing to find a matching connector for further fault-finding and testing! It’s still not working 🙂

Warning! I am not an electronics person. I strongly recommend that you don’t base your own attempts at fixing a beloved vintage synth on anything I’ve said here. I was given this synth rather than it being sent it to a recycling centre so this is a low-risk learning activity for me. I am not responsible for any damage to expensive or irreplaceable electronic musical instruments! There are plenty of places to take something for a proper repair 🙂

If you are new to microcontrollers and electronics, see the Getting Started pages.

Reference Information

I’ve found the following so far:

• DX100 user and service manual and programming guide.
• DX100 schematic (not to be confused with the HealthKit DX100 transmitter that has a lot of schematics published online!).
• DX100 repair and review video.
• DX100 on Circuit Benders.

The DX100 is effectively a “minikeys” version of the DX27 and the PCB itself would appear to be shared between the two.

There is a test mode which apparently is initiated by powering up with voice select 1 and 2 pressed. The thing itself is powered from either a 12V centre-positive supply or 9V worth of C-cell batteries.

As I started exploring it, its ability to show anything on the screen appeared to get less and less and finally it reached the point of showing nothing except some “power on” blocks on the display at all. I don’t believe I did anything to cause that other than turning it on and off a few times with various buttons being pressed as part of my initial exploring.

At this point I decided it was time to actually take the thing apart and take a look.

Disassembled

The repair and review video linked above shows the insides in detail. Here are my own photos.

A couple of things I really liked and noted about this synth:

• The battery connections has a connector so it can be easily detached from the main PCB to allow the casing to be set aside.
• The PCB is single sided with link connectors on the rear which are also indicated on the silkscreen on the copper side.
• Each device is labelled on the copper side, including pin numbers for all the ICs.
• everything from the PCB to the peripherals uses a connector so can be disconnected.

You really get the feeling that this synth was built to be fixed and maintained!

The only negative I’ve discovered is that the service manual is more of a disassembly manual and parts list. At least the version found online doesn’t even include a schematic but I did (thankfully) find an independent copy of the schematic online when doing an image search.

But weirdly the service manual does include a memory map for the CPU, RAM and ROM and a pretty good high-level description of the key circuit features! Go figure 🙂

The other thing of note: the board appears pretty clean – I can spot no evidence of corroded tracks, leaked battery, broken traces, or other signs of wear or damage. The boards seem in pretty good condition to me!

Diagnostic Approach

Seeing as the synth is not booting at all, I started from what I considered to be the basics. This is the block diagram from the service manual.

There is a 6303 CPU, 32K ROM and 4K RAM, a Yamaha OPP FM tone generator and supporting functions (DAC, A/D, clocks, power, key scanning, etc).

So the plan is to check the power, then basic logic signals, then get more into the digital CPU side of things and see how things go.

Onboard Battery

There is a PCB-mounted battery to maintain the contents of the RAM when in operation. Now as I understand things, the synth should boot successfully with a dead battery and give a warning on the display, so I really didn’t think this was the issue, but as the battery was essentially reading zero voltage, that was an easy thing to replace straight away.

The service manual lists the battery as “Lithium battery, 3V – CR2032T”. I found a similar one online, but the pins were in a slightly different place. But a small bend and this could be replaced quite easily.

Note: there is a solder bridge that presumably allows the batter to be disconnected if required. Once again, the PCB is nicely labelled to ensure the battery is connected the right way round and there are two test points on the easily accessible side of the board if required.

The battery itself is on the non-copper side so the PCB has to be fully removed to replace it.

Main and Digital Power Supply

Whilst on the topic of power, and seeing that replacing the battery made no difference, the next thing to check was the power circuit.

There is a section in the service manual that explains that the power circuitry creates +5V and -3V supplies from the provided 12V. This is provided using a 7808 and 7905 (IC19 and IC20 in the schematic).

Interestingly there is an unpopulated connector on the PCB (CN12) that doesn’t appear in the pcb diagram in the service manual, so I’m now wondering if there are different editions of the board…

Either way, measuring the voltages I can see 8V coming out of the 7808 and 5V and -3V being produces from the combination.

One thing I did notice though – none of the capacitors appear to match the physical footprint left for them on the PCB itself, so I wondered if someone has been through and replaced all the electrolytics at some point in the synth’s history. If you look at the photo of the regulators, you can see how there are shorter, upright capacitors compared to those in the repair video that had longer capacitors bent over to fit the space left on the PCB.

Following the schematic, I then went through and measured the VCC/GND connections on all the main chips and they all checked out. As far as I can see, they are all connected to +5V and measurements confirmed this. Again having the pin numbers printed on the silkscreen side of the PCB made this very easy to do!

Basic Logic Operations

So the next thing to look at was the basic logic operations. By that I mean checking the following:

• The reset (RST) circuit.
• The clocks
• Chip enables (CE) and chip selects (CS).
• Read/write pins (RW).
• Address lines.
• Data lines.

This is the reset circuitry:

So that was fairly easy to check on an oscilloscope. Reset is an active low signal and once again the service manual has a detailed paragraph on its operation. I’ve not checked the exact timings, but I can certainly see it being low on power up and changing to high to allow everything to proceed.

The only thing to verify is that this behaviour is actually observed at the CPU itself. /RST is on pin 6 and that all seems ok.

There are two clocks: a “main” 3.58MHz clock which drives the CPU (and is further divided by 4 internally) and a “sub clock” of 500kHz which apparently goes through a divider to give the 31250 required for MIDI.

The main clock can be found on the EXTAL pin of the CPU (pin 3) and the sub-clock appears to go to the CPU’s pin 11 (P22). Both were measured and appear fine.

The photo shows the main clock signal. The initial measurement was very rounded to the point where I couldn’t imagine it working as a clock at all, but then it turned out I’d inadvertently set my scope probe to x1 rather than x10. x10 gives a much sharper signal.

The sub-clock was an almost perfect square wave, so I considered the clocks were fine.

Basic logic operations

The next angle of attack was to check for some kind of activity on the various chip select pins.

The TL;DR version is that I can see activity on all the CE/CS/RW type pins I could see so that suggests the various RAM/ROM and other chips are being accessed at least as part of the startup activity.

Similarly for the address lines – I can see good clean signals on the address lines. Note that I’m not using a logic analyser here, I’m just checking for general activity using an oscilloscope at this stage.

It is worth taking a short diversion into the operation of IC14 and the main ROM/RAM.

The service manual includes a memory map and if this is mapped onto the address lines A11-A15 we can see how that logic is implemented via IC14, which is a 40H138 3-to-8 line decoder, to generate the various chip select lines.

There is a general enable (E, pin 6), two additional enable lines (/G2A, /G2B, pins 4 and 5), three selection lines (A, B, C, pins 1,2,3) and eight outputs (/Y7 to /Y0, pins 9 to 15). Given this knowledge and decoding the addresses in terms of A11 to A15 we can see how the decoding works.

The key points being:

• If A14 or A15 are high then IC14 is not enabled, so A11-A13 are ignored.
• If A15 is high then the ROM is selected and A0-A14 are significant for reading the contents of the ROM only.
• Both A14 and A15 have to be low for A11-A13 to be significant for IC14, then the various outputs are selected based on the values of A11-A13.
• A13=0 selects the RAM (both Y1 and Y2 select the RAM).
• A13=1 selects the other peripherals, depending on the value of A11 and A12: LCD, A/D converter, or OPP sound chip.

The mapping of address lines to chips matches the address ranges and sizes:

• The ROM is 32kB: $8000-$FFFF
• The RAM is 2kB: RAM1 at $0800-$0FFF and RAM2 at $1000-$17FF

So double checking activity both on the inputs and outputs of IC14 and on the various signals when they reach the appropriate chips seems to suggest that address decoding is happening.

So generally, the signals on the address lines seem quite sensible on first pass (again only with an oscilloscope) but the signals on the data lines are a little odd.

On closer examination, the behaviour of the data lines on power up is interesting too. This is one of the data lines from switch on.

Looking more closely at the transitions that can be seen in the above trace:

The first might be considered passable; the second starts to get a little dodgy; the final transition though does seem to be total garbage.

Now I did read somewhere (I forget where) that if not selected and actively being driven/read then data lines will float all over the place, so it may be that an oscilloscope measurement on a single data line isn’t helping. Even though there are similar traces for all lines I’ve looked at, I probably need to trigger off the CE lines to see what is going on when the data is meant to be valid.

One other thing of note though – the data lines are pretty much fed directly into the LCD controller chip, which is a HD44780 device on a separate PCB and connected using wires. This means that all data lines are available on a connector on the edge of the PCB…

Another I’ve noticed is that the data lines too clean up a little if the LCD is disconnected so that might be significant too.

Onboard Links and Connecting Wires

There are a couple of interconnecting wires for longer cross-PCB connections, and at least one of these carries some of the data lines across the board!

I checked them for basic continuity and they seem ok, but a comment from Paul on Mastodon suggested they are prone to cracking and recommended reflowing the solder joints on them anyway.

So I did but it doesn’t seem to have solved the issues unfortunately, but it was worth a check – on close inspection I could see there might have been issues with the solder joints.

Summary So Far

It’s still not working 🙂

What I think I know so far:

• Power seems ok.
• Basic clocks, reset and logical signals seem to be doing something.
• Address line decoding is doing something, but data lines appear indeterminate.

So the next angle of attacks are:

• Attempt to get some proper data line traces triggered off one of the chip enable pins.
• Consider testing the HD44780 display independently, e.g. with an Arduino to ensure it works. If it doesn’t consider testing an off-the-shelf display instead with the DX100.
• Using an Arduino (e.g. following Ben Eater’s circuit) attempt to read the ROM contents to see if they seem…. sensible. The ROM is the only IC that is socketed so that should be fairly straight forward. The ROM appears to match the pin-out of a 27C256 EPROM, which is slightly different to the 28C256 EEPROM. There is a (apparently discontinued) 29C256 that is largely pin-compatible… so some research is required here.
• Getting a logic analyser on some of those address and data lines to try to see what is going on.

As I say, if it turns out to be beyond my capabilities, and I run out of people to pester, then my own project might be to hook up a Pi Zero and give it a MiniDexed inside. That should be possible to do in a non-destructive way which means at some point in the future I might be able to revisit the PCB and have another go.

Kevin