Damn, for a brief hour or two this evening, I thought I'd made a breakthrough with the DX100.

But it turns out I get a really neat and crips data signal when I plug in a blank ROM by mistake :)

Still I think I've ruled out the ROM, RAM, sound generator, and probably the ADC...

So that really is pointing back to the display I think...

I've written up the latest minor increment forward here.

But fundamentally it still isn't working :)

https://diyelectromusic.com/2025/07/08/diagnosing-and-attempting-to-fix-a-yamaha-dx100-part-4/

#DX100 #MakerFail

Diagnosing and attempting to fix a Yamaha DX100 – Part 4

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 looks like a massive improvement! So why isn’t this working now then?

Not so fast… I messed up the ROM

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.

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.

Mind you, I don’t know what allowed me to get the LCD trace if there was no code in the ROM… but I guess the CPU could have been doing anything at that point.

So About that ROM

At this point I wondered what it all looks like if I unplug the display. And yes, sure enough, the signal is a lot cleaner again.

So, does unplugging the display fix things because the display is causing the issue? Or does not having a display change what code is running so the problematic peripheral or mode is missed out (like it was when the ROM didn’t even have code)? It’s a little hard to say.

At this point I thought I may as well go back to the original ROM. After all it is a lot nicer to have one stamped Yamaha than one stamped 29C256. But then something else interesting happened. Here are two traces still without the LCD connected:

The one on the left is the replacement, reprogrammed 29C256 flash EEPROM and the one on the right is the original Yamaha mask ROM. In both cases the ROM is enabled when the yellow trace is LOW and the blue trace is D0. As we can see, there is still something not right about the original ROM…

LCD Enable and Data

Assuming that the ROM is now fixed, there is something odd about the LCD. I’m not convinced my Heath-Robinson mashup of a breadboard and 1602 LCD is giving me any results I can rely on, but I did one last experiment.

As I wasn’t sure if removing the LCD prevented the actual issue or just stopped the code from enabling a different problematic peripheral, I wondered what would happen if an LCD was connected, but I just removed its ability to drive D0 whilst I was monitoring it.

Here is the result. On the left, with D0 connected to the LCD, on the right with D0 unconnected.

It does seem to be better when D0 can’t be driven from the LCD (LCD enable, and other data lines are all functioning normally). There is a single access on power up, then another one maybe a few 100mS later, and then a burst of activity, and then nothing at all.

I wondered if maybe the logic controlling the E (enable) line for the LCD might not be working properly, so I went back to the original LCD and took at a look at LCDE.

Homing in on IC17, I should be able to see a LOW signal on pins 5 and 6 generating the HIGH E (enable) signal for the LCD, and yes, that appears to be working fine as far as I can see. This is a sample of the “busy” set of accesses just prior to everything going silent.

So going back to looking at the data lines (D0) whilst this is going on…

Sp there doesn’t seem to be an issue with the data lines whilst the LCD is being poked (left). But when the accesses to the LCD appear to stop (right), then the data line seems to be all over the place once again – it gets worse after this initial activity.

But there does seem to be some kind of pattern here, which implies to me that everything is stuck in a loop somehow. Here is the zoomed-out version of the last trace, showing the last of the LCD Enable lines and the following patterns in data (zoomed back in on the second trace).

Conclusions for now…

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

It would appear that with the display out of the loop there was something screwy about the original Yamaha ROM. But I’m not convinced that the display isn’t causing issues too.

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.

Either that, or I might return to the power circuit as that 5V line does seem pretty noisy to me.

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

Kevin

#dx100 #eeprom #lcd1602

Diagnosing and attempting to fix a Yamaha DX100 – Part 3

At the end of part 1, I’ve established that the basics all seem ok (PCB, interconnections, power) and that basic digital logic stuff is happening.

In part 2 I checked the ROM, reflowed a number of the solder joints, and started to look at the connectors between the main PCB and the LCD, but still with no luck.

Now I’m finally getting around to looking properly at those data signals to see what my next steps might be.

Oh and nope, still not fixed. Sorry.

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.

Replacing the LCD – Continued

In part 2 I thought that it would be worth seeing if I could replace the LCD with an alternative, seeing as it appeared to be just a common HD44780 based display, but the connector used was giving me trouble.

In the end I just took the plastic shrouds off some Dupont style jumper wires and poked them directly into the connector on the PCB.

This finally gives me a way into some of the control signals and data lines on the main bus. First things first, I connected up a replacement display. Usefully the pinout of this connector matches exactly the pinout of a LCD1602 display.

The only additional connections required are an extra +5V/GND for the backlight (marked as “K” and “A” on my display). All the other connections match as shown by the schematic.

Hooking up an oscilloscope as follows:

• Yellow = E = LCD Enable pin (decoded from A10-15=0; A13=1)
• Blue = R/W (low = write)
• Purple = RS = register select (maps onto A0 on the address bus)
• Darker blue = D0

and triggering off the enable pin gives me the following trace:

The darker blue line is D0 and as can be seen – it is basically all over the place. It definitely looks like something is breaking the data lines, so the question now is what. I also checked D1-D7 and they all look pretty similar.

From my previous experiments the fact that I can read the ROM successfully, and now have replaced the LCD implies one of the other devices. So I think that leaves the following options:

• The CPU itself
• RAM
• A/D
• OPP – the Yamaha FM tone generator itself

But as all these are soldered down, it makes the next step a little tricky.

I’ve triggered the scope of the various CS/OE lines for the RAM, ADC and OPP and checked the local equivalent of D0 and the pattern seems the same everywhere.

Interestingly I don’t ever see a CS/OE line for the ADC or OPP – but then if it is failing to boot then the CPU will never get around to trying to access either of those I’d imagine.

By the way, on startup, there are there points where the LCD “E”nable pin is accessed. Two single instances, and then a large block as shown below.

Removing the ROM

Just out of interest I thought it was worth seeing what the signals looked like with the ROM removed (seeing as it is socketed and easy to remove). I triggered of the CE for one of the RAM chips and checked the signals.

The RAM isn’t accessed as much, but then with no ROM I don’t know what the CPU would be doing anyway…

But when it is, D0 (dark blue again in the trace below) looks a lot more like a sensible digital signal to me.

So now I’m thinking I really ought to eliminate the idea of a problem ROM chip before desoldering any of the RAM to test that…

Aside: at one point, when just monitoring the data signal, I got a much cleaner signal, but very definitely appearing to show three distinct states, which again reinforces the fact that something, somewhere is trashing over the data lines…

Replacing the ROM

As discussed last time, the DX100 uses a 27C256 style ROM which isn’t quite the same pinout as the more common 28C256 EEPROM that can be found relatively easily these days. However there is also a 29C256 which does have essentially the same pinout as the 27C256.

I happen to have some, but I don’t know if they are any good! I also have my Arduino EEPROM Reader but I’ve never tried to write with it and certainly not tried to do anything with a 29C256.

I took the plunge and bought myself an XGecu T48. Downloading and installing the software was a bit of a leap of (hopefully not misplaced) faith as some of download links went off to a media file download site which was constantly playing “download button roulette” but with a bit of care I was able to find the .rar file for the installer.

I programed an Atmel 29C256 with the binary image I found, but unfortunately it made no difference – it was still completely dead.

Just out of interest I tried to read the Yamaha ROM using the XGecu, but I couldn’t find a manufacturers 27C256 setting that worked. I kept getting a “pin 1 error” whenever I tried to read it. Funny that it worked ok with my Arduino reader though…

I tried it with the replacement LED but then plugged the real one back in – but still nothing unfortunately.

One Last Probe…

I thought I’d have one last poke about for continuity with a multimeter. I checked the ribbons that connected different parts of the PCB together. I checked a whole range of GND connections (the additional, unpopulated header in the top right (from the underside) for E, +5, -3 was really useful there.

One oddity I did find, is that I couldn’t find continuity between the VCC pin on one of the RAM chips – IC13. I tried tracing it through to see where things broke, and it got a bit confusing linking into some transistors and eventually the on-PCB battery.

It turns out, looking at the schematic, that this is the RAM battery-backup store:

So I guess that means that RAM1 is for voice data and RAM2 is working RAM for the CPU. Curiously, /CE2 for RAM1 is connected into the battery or reset (or both) circuit somehow too, whereas for RAM2 it is tied to GND. I must confess I’m not quite sure what is going on there.

Ah, turns out I should just RTF(service)M. Wiring /CE2 into the reset circuit like this ensures that RAM1 can’t be selected during the reset period and so inadvertently get written to, to override the stored contents. RAM1 is thus disabled until the reset is complete.

/CE1 for both chips is connected to IC14 which does the address decoding (see Part 1).

Anyway the upshot of all this is that I powered the thing back up to check the VCC signals and yes, both pin 24s on both RAM chips are reading 4.99V and the battery itself is reading ~2.5V.

Further Thoughts

I feel like I’ve made a little more progress in appearing to have eliminated the LCD and probably the ROM as a source of the issue.

But I think I’m essentially out of options now. Assuming (and this might be a big assumption of course) everything I’ve said so far is true, I think this only leaves one of the soldered chips as possibly causing an issue. For that, I have the choice of:

• The main application processor itself.
• The two RAM chips.
• The Yamaha YM sound processor.

I think at this point ideally I get some traces from a working synth to see how it compares before desoldering chips. But that probably isn’t going to be possible. Another option might be to look out for a “spares or repairs” DX100 so I can do some mixing and matching.

It might be worth replacing the ROM with hard-wired pull-ups/downs on the data lines to force the code for a NOP onto the bus as the CPU starts up. That at least might show that the CPU itself is still ok. But really, if something is messing with the data lines, the only option really is to remove some of the chips until they start looking sensible again.

But I’m not sure I’m confident enough in my diagnosis so far to start getting destructive so I suspect this might be the end of my journey attempting this myself and I might have to find someone who knows what they are doing.

Of course, if you spot any other options do feel free to let me know.

Kevin

#dx100 #eeprom #lcd1602

At the end of part 1, I’ve established that the basics all seem ok (PCB, interconnections, power) and that basic digital logic stuff is happening.

I rounded off my write-up with the following ideas for what to investigate next:

• Get some proper triggering from the chip enables to check for valid data signals.
• Check out the HD44780 display.
• Attempt to read and verify the ROM image.
• Break out a logic analyser.

This is the next stage of my experiments and investigations. Spoilers: It’s still not working and I’ve still not found out why! 🙂

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.

An Arduino (E)EPROM Reader

I found a design from Ben Eater for an Arduino EEPROM reader so I thought I’d tailor it slightly and see if I could use it to read out the contents of my DX100’s ROM. I happened upon a ROM image of v1.1 at the same place I found the schematic, so whilst I might not have the exact same version, it gives me an idea of what kind of data to expect.

There are certainly plenty of ASCII strings in there to spot the voice data starts at a known location ($CDA0 in the memory map, which is address location 0x4DA0 in the ROM itself).

Most Arduino EEPROM programmers are designed for 28Cxxx compatible electronically, erasable, programmable read-only memories. But in a lot of vintage technology you’ll find 27Cxxx style EPROMs – erasable, programmable read-only memories, which have a window for UV erasure prior to allowing them to be re-programmed. Or even “mask ROMs” which are one-time programmable.

The pinouts of the two devices are almost the same, and there is a variant of EEPROM with the same pinout (29Cxxx) but these are apparently discontinued and quite hard to come by. The differences for the 27C256 equivalent in the DX100 are:

• Pin 1: VPP (27C); A14 (28C); /WE (29C)
• Pin 27: A14 (27C); /WE (28C); A14 (29C)

So to read the ROM requires A14 mapping to pin 27 and VPP (pin 1) tying HIGH. All the other connections should be as shown in Ben Eater’s schematic (with the addition of pin 28 – VCC – to 5V and pin 14 to GND).

Other points to note:

• The design uses two cascading shift registers (74HC595s) for the address lines and directly connects the data lines to the Arduino.
• The design uses one of the shift register outputs as Output Enable, which I initially tried, but then switched to using a dedicated IO pin.
• The design includes a Write Enable connection to allow for programming. I skipped this as I was just reading (and there is no /WE pin on the 27C256).
• The schematic shows the Arduino 5V as being unconnected, but actually this has to power the shift registers and device to be read.
• Normally when in use there will be capacitors across the power and GND for the ROM, so I added one to help stability.

I built the circuit on solderless breadboard. But the issue I was always going to have was how can I be sure the circuit is working correctly if I get what looks like corrupted data? If I read out a good image, I’ll know it is fine. But if it looks problematic, then it might just be problems in my wiring, code or unreliability in the reader circuit somehow.

To get some degree of confidence as a test (i.e. with no actual ROM device plugged in) I connected the data lines to some of the address lines via 10K resistors. This means that as the code is cycling through all the addresses, the address line patterns should be read-back on the data lines.

My initial attempt was not encouraging – there were snippets of good data but large areas of rubbish. I was just about to give up on the solderless breadboard when I realised I’d not actually connected the GNDs on the two halves together… sigh. But once that was done the tests worked fine and I was able to read the ROM. It appears ok.

The first test (A7-A14 connected to D0-D7) I wired up by hand. The second test (A0-A7 and D0-D7) I soldered the resistors to a piece of protoboard.

The patterns read back from these tests showed everything was working fine. I added some of the “1-byte LED bar” things I have (they have a common ground) that make excellent indicators for the shift registers, especially when Q0 (on pin 15) is routed round to be next to Q1 (on pin 1). It is really handy that GND is on pin 8.

The cursory visual inspection of the read data from my ROM and the binary file image of V1.1 that I found on the Internet appear to match. Here is a sample of the start of the voice data.

I also found the text “V1.1 02-Aug-85” in my read data so I guess from that I have V1.1 installed.

I wrote a simple python script (based on this hexdump code) to dump the ROM bin image in the same format as the Arduino output and compared them in a difference tool – they were the same, so the ROM contents are fine.

Find the code and Fritzing diagram on GitHub here.

After performing the above experiments, I decided that an Arduino (E)EPROM reader would be quite a useful thing to have lying around, so I’ve built an Arduino EEPROM Reader PCB shield.

Solder Reflowing

At some point around here I opted to simply reflow the solder joints for some of the connectors. I’d already reflowed the joints for the ribbons that pass many of the signals across the board, so now I did the same for the connector for the LCD and a few other things whilst I was at it – the links to the potentiometers and keyboard matrix for example.

Unfortunately this didn’t seem to make any difference that I could see.

Replacing the LCD

As the data pins all go off to the LCD via an on-board connector (C2), I thought this would be a really good place to tap into the data lines to attempt to do some more tests:

• I could try triggering off the select/enable pins to see how the data signals look when legitimate transactions are underway.
• I could attach a different HD44780 display to see if that works any better.
• I could try driving the Yamaha display from an Arduino.

My plan was to build a simple breakout board to sit between the cable to the LCD and the main PCB. However those connectors are proving somewhat difficult to get hold of.

The appear to be very similar to JST XH 2.5 connectors, but there are some key differences:

• First of all, many of the JST XH 2.5 connectors available have their pins with a 2.54mm pitch. The connectors in the DX100 really are 2.50mm as far as I can see. Now I’ve read that the XH specification calls for 2.50mm, but there really doesn’t seem to be much agreement online or at suppliers. Either way, so far, I’ve not been able to find any with a 2.50mm pitch.
• The pins on the connectors are actually flat not square, with the long side aligned across the connector (not in line with it).
• The physical width of the connector appears slightly smaller than common JST XH connectors.

Here are a few photos showing what I mean, comparing the connectors to the JST XH 2.5 connectors I found; showing the flat pins; and putting one alongside an Arduino Nano, showing that although the first 4-5 pins could be seen to match in pitch, pin 14 is definitely out. The nano has pins a the common 2.54mm pitch for inserting into solderless breadboards.

It would appear that many of the Yamaha DX synths from the period use these connectors, but so far, having examined the service manuals of the DX7, DX9, DX11, DX21 in addition to the manual for the DX27/100, I can find no mention of the connectors or any clue as to where to get them from.

Any articles I’ve seen in forums seems to show people just cutting wires off faulty units and soldering them onto replacements. It isn’t clear to me what aftermarket replacement LCD parts are using – none of them specify the connector as far as I can see.

I’ve had several people send me links to a couple of online sites to help identify unknown connectors, but so far I’ve had no luck, so at present, unfortunately, this is still unresolved.

Further Thoughts

So I haven’t managed to get much further so far, but as I’ve had a couple of queries since my first post, I thought I’d pop up what I have so far – this post has been sitting in draft for a few months now!

I’d really like to find some compatible connectors, but so far no luck. I have wondered about finding an old “for spares” Yamaha synth that might have the same connectors… I’ve also wondered if I could 3D print something useful.

Rather than cut wires, I might even resort to soldering on some extra cables to link it up to a JST XH connector to allow me to investigate further. Ironically it feels less intrusive to solder on some extra wires that can be removed later than cut the ribbons!

But I’ve also wondered about cutting them and making a Yamaha to JST XH converter.

Watch this space. I guess I’m still hoping I might be able to find some connectors…

Kevin

https://diyelectromusic.wordpress.com/2024/03/18/diagnosing-and-attempting-to-fix-a-yamaha-dx100-part-2/

#dx100

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

https://diyelectromusic.wordpress.com/2023/12/31/diagnosing-and-attempting-to-fix-a-yamaha-dx100-part-1/

#diagnostics #dx100 #logicAnalyser #oscilloscope #repair #yamaha