Simple DIY Electronic Music Projects<p><strong>Diagnosing and attempting to fix a Yamaha DX100 – Part 4</strong></p><p>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…</p><p><strong><em>And no, after all this time, it still isn’t working…</em></strong></p><p><em><strong>Warning!</strong> 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 🙂</em></p><p>If you are new to microcontrollers and electronics, see the <a href="https://diyelectromusic.wordpress.com/getting-started/" rel="nofollow noopener" target="_blank">Getting Started</a> pages.</p><p><strong>Pulling D0 to LOW</strong></p><p>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.</p><p>So with the replacement LCD attached from last time, I hooked up the following:</p><ul><li>Oscilloscope GND to GND.</li><li>10K between GND and D0.</li><li>Oscilloscope tracing LCD E pin.</li><li>Oscilloscope tracing D0.</li></ul><p>Unfortunately whilst it did stabilise the data signal a little, it still wasn’t really clear what might be causes the issue.</p><p>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).</p><p>So I abandoned that and tried something else…</p><p><strong>Closer look at the Data Lines</strong></p><p>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.</p><p>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).</p><p>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.</p><p>So, starting with the two RAM chips, /CE is on pin 20 and the trace I obtained looks like this:</p><p>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.</p><p>A similar pattern was observed for the other RAM chip and the Yamaha OPP’s /CS signal.</p><p>The ADC is a little more complicated as can be seen in the extract from the schematic:</p><p>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.</p><p>/ADCH and /ADDAT come from the address decoding logic:</p><p>But the upshot of all this is that when any of these signals is active, D0 looks pretty similar to the RAM trace.</p><p>So at this point, I’m feeling a lot more confident that the two RAM chips, ADC and OPP are probably not at fault.</p><p>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:</p><p>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).</p><p>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.</p><p>But regardless, I’m now very suspicious of this ROM.</p><p>The inverter is IC17 and also drives LCD E, which also doesn’t seem to work very well.</p><p>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.</p><p>That seems to speak for itself. Yes, /CE is still LOW for larger periods of time, but those data signals are massively improved.</p><p>Spoilers: it turns out this wasn’t what I thought was happening, but I’ll get back to that in a mo…</p><p>So this is now what the LCD E triggered trace looks like.</p><p>That looks like a massive improvement! So why isn’t this working now then?</p><p><strong>Not so fast… I messed up the ROM</strong></p><p>So now I have half the display showing blocks, a flashing power LED and still no other signs of life.</p><p>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?</p><p>Measuring the voltage from the test pins, it is reading 2.7V, when I think it is meant to be 3V.</p><p>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.</p><p>So the question is now:</p><ul><li>Has the CPU got stuck in a loop with the flashing LED? It’s certainly possible.</li><li>Or is the display not functioning properly?</li></ul><p>Well it turns out there is another condition where the LED flashes.</p><p>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.</p><p>It turns out another condition where the LED flashes is if there is no code in the ROM…</p><p>Yes, I’d put in a blank ROM by mistake. Sigh.</p><p>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.</p><p>I guess that probably means it isn’t the ROM that is at fault.</p><p>But that probably points to something that isn’t enabled properly until some code is running on the CPU from the ROM.</p><p>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.</p><p><strong>So About that ROM</strong></p><p>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.</p><p>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.</p><p>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:</p><p>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…</p><p><strong>LCD Enable and Data</strong></p><p>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.</p><p>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.</p><p>Here is the result. On the left, with D0 connected to the LCD, on the right with D0 unconnected.</p><p>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.</p><p>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.</p><p>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.</p><p>So going back to looking at the data lines (D0) whilst this is going on…</p><p>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.</p><p>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).</p><p><strong>Conclusions for now…</strong></p><p>So where does this leave me? To be honest I’m not sure. Maybe back where I started.</p><p>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.</p><p>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.</p><p>If I can find a robust way of plugging in an alternative display I might give that another go.</p><p>Either that, or I might return to the power circuit as that 5V line does seem pretty noisy to me.</p><p>When I decide on next steps, I’ll come back and add to this post again.</p><p>Kevin</p><p><a rel="nofollow noopener" class="hashtag u-tag u-category" href="https://diyelectromusic.com/tag/dx100/" target="_blank">#dx100</a> <a rel="nofollow noopener" class="hashtag u-tag u-category" href="https://diyelectromusic.com/tag/eeprom/" target="_blank">#eeprom</a> <a rel="nofollow noopener" class="hashtag u-tag u-category" href="https://diyelectromusic.com/tag/lcd1602/" target="_blank">#lcd1602</a></p>