Diagnosing and attempting to fix a Yamaha DX100 – Part 4

By Kevin on July 8, 2025

I decided to have one more look at the data pins, largely inspired by this oscilloscope trace from part 3. I figured if the address and select pins were working (yellow, cyan and purple) what could I do to try to work out what is driving the data pins (darker blue) wobbly...

And no, after all this time, it still isn't 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.

Pulling D0 to LOW

My first thought was to see if I could use a weak pull-down resistor on one of the data pins (I was using D0) to see if that stabilises the signal and then see what the data trace looks like as I move around monitoring the various chip select/chip enable lines.

So with the replacement LCD attached from last time, I hooked up the following:

Oscilloscope GND to GND.
10K between GND and D0.
Oscilloscope tracing LCD E pin.
Oscilloscope tracing D0.

Unfortunately whilst it did stabilise the data signal a little, it still wasn't really clear what might be causes the issue.

It did give one other clue though. When testing the RAM chips, I could see the data signal was actually quite clear when the RAM /CE was active (LOW).

So I abandoned that and tried something else...

Closer look at the Data Lines

So given the observation about the RAM chips, I decided to take a proper look at the data lines (well D0) when the various chip enable/chip select signals are active.

Handily, as the PCB is a single sided PCB with bridging wires, it was relatively straight forward to find wire links for both GND and D0, so I used these for the oscilloscope GND and blue trace (for D0).

The two probe GNDs are pushed under the link on the bottom left and D0 is the first of those block of links after the first three top right. This leaves a free-floating probe wire for me to use to prod the various select lines and see what D0 is doing at the time.

So, starting with the two RAM chips, /CE is on pin 20 and the trace I obtained looks like this:

On the face of thigs that still looks pretty chaotic, but actually the data signal (blue) is stable for the duration of the /CE signal being low, so that is probably actually ok.

A similar pattern was observed for the other RAM chip and the Yamaha OPP's /CS signal.

The ADC is a little more complicated as can be seen in the extract from the schematic:

There are sort of three relevant pins here: 6 (START), 9 (OE) and 22 (ALE). IC17 is acting as an inverter so that when ADDAT and RD are both LOW OE is HIGH.

/ADCH and /ADDAT come from the address decoding logic:

But the upshot of all this is that when any of these signals is active, D0 looks pretty similar to the RAM trace.

So at this point, I'm feeling a lot more confident that the two RAM chips, ADC and OPP are probably not at fault.

The ROM is next on the hit list. Now again, looking at the schematic we can see that the ROM is enabled when A15 is HIGH (address $8000-$FFFF) and this happens thanks to another gate in IC17:

So the ROM is active when /CE is LOW, meaning A15 is HIGH. But when traced on the scope, D0 is all over the place (blue), especially when /CE is low (yellow).

It is curious to see that the ROM seems active for a lot longer than any of the other accesses I've examined. But I guess if the CPU is running from ROM it will be continually reading instructions whilst shuffling data between the other peripherals.

But regardless, I'm now very suspicious of this ROM.

The inverter is IC17 and also drives LCD E, which also doesn't seem to work very well.

So even though I tried a new ROM and nothing seemed to change, I replaced the ROM again and actually took a proper look at the signals on the bus.

That seems to speak for itself. Yes, /CE is still LOW for larger periods of time, but those data signals are massively improved.

Spoilers: it turns out this wasn't what I thought was happening, but I'll get back to that in a mo...

So this is now what the LCD E triggered trace looks like.

That is a massive improvement!

So why isn't this working now then?

Status Update

So now I have half the display showing blocks, a flashing power LED and still no other signs of life.

A flashing LED apparently indicates that the backup battery is low. This in and of itself is probably progress as the LED is connected to an IO pin of the CPU, so this seems to indicate the CPU is actually running code as it is making the LED flash. So why isn't it booting?

Measuring the voltage from the test pins, it is reading 2.7V, when I think it is meant to be 3V.

I've not managed to get a replacement display running by plugging wires into the socket instead of the original LCD. But scanning all the data lines of the display when it is enabled, seems to show they are all working ok.

So the question is now:

Has the CPU got stuck in a loop with the flashing LED? It's certainly possible.
Or is the display not functioning properly?

Well it turns out there is another condition where the LED flashes.

As I was poking around I noticed there were some fairly regular repeated patterns on the address bus, and it seemed like the RAM wasn't being accessed anymore.

It turns out another condition where the LED flashes is if there is no code in the ROM...

Yes, I'd put in a blank ROM by mistake. Sigh.

Unfortunately when I program the ROM (and verify it) and plug that back in, the black squares on the display have now gone, but the data bus is messed up again.

But I guess that probably means it isn't the ROM that is at fault.

But that probably points to something that isn't enabled properly until some code is running on the CPU from the ROM.

Conclusions for now...

So where does this leave me? To be honest I'm not sure. Maybe back where I started.

Maybe it is the display after all causing issues. I'd like to take the display PCB apart and check connections and clean it, but it has one of those flexible connectors between the controller PCB and the LCD display, so I'm not sure I want to mess with that right now.

If I can find a robust way of plugging in an alternative display I might give that another go.

When I decide on next steps, I'll come back and add to this post again.

Kevin