A 3-to-8 line decoder with multiple outputs active at the same time?? That shouldn't be possible ever! I think you've discovered a red-hot clue, R.R.!

But of course before replacing that chip, you'll firstly wanna check that it's not lacking anything it requires for proper operation. Does it have valid logic levels (measured with a 'scope) on all the inputs? Solid 5V, measured right at the supply pins? In particular, I'd wonder about a bad solder joint to pin 16. (Lack of Vcc would tend to send all the outputs low.)

40H138 might be pretty hard to find, but 74HC138 is easy to get and ought to be an acceptable substitute. But I suggest you do not solder it in. Instead you might want to install an IC socket just in case you decide to try a different substitute later.


--- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

The BOOT spreadsheet is just the code as it's executing the RESET handler starting at $27B0. It's initializing various memory locations and it looks perfectly normal.

The CODE 1, 2, and 3 spreadsheets are similar to the earlier spreadsheet. It appears that it's waiting in the loop in the $5F3C routine, which, as mentioned above, is waiting for bit 4 of memory location $1800 to be zero.

I'm pretty sure addresses $1C00 to $1FFF are I/O, not RAM. I'm not sure whether (non /DME) addresses $1800 to $1BFF are RAM or I/O, but they may be I/O.

$1800 is written to and read from in ROM1. None of those writes appears to ever set bit 4, suggesting that $1800 may be I/O. Bit 4 appears to function as either a Busy flag (where zero means not busy) or a Operation Complete flag (where zero means the operation is complete), and the $5F3C routine waits until not Busy (or until Complete).

It's not clear what would ever set that bit. Most of the writes (in the ROM1 code) to $1800 are preceded by a LDA immediate and the immediate value has bit 4 clear. (Example: at $27F6 in the RESET handler is a LDA #$0F STA $1800) There are a couple of places where memory location $51 (almost certainly RAM) is copied to $1800, so I looked into what gets written to memory location $51.

All writes to $51 are preceded by a LDA immediate, and that immediate value is either $05 or $09, so in both cases bit 4 is zero. Again this suggests that memory location $1800 is I/O, i.e. something in the hardware sets bit 4, and either it is cleared by a write to $1800 (with bit 4 zero), or writes to bit 4 are ignored.

ROM3 does not reference memory locations $51 or $1800 (and it uses no (zp,X) addressing). I don't think it accesses either memory location via (zp),Y addressing, but I haven't examined all of the (zp),Y addressing in detail. It's possible I've missed a reference to $1800 (or $51) somewhere, but I think it's most likely that all reference use absolute (without an index register) addressing (and zero page addressing for $51).

Likewise, it's possible that ROM1 writes to $1800 using (zp,X) or (zp),Y addressing. I doubt that it does, but again, I have not examined in detail all of the places where such addressing is used, i.e. the same caveats as ROM3 apply here.

It's likely that's the case for the M50734 also. There are only a half dozen (zp),Y instructions in ROM1 and ROM3 combined that are neither LDA nor STA, and the addresses in the zp pointer when those instructions execute are all well below $2000 (mostly $3xx to $5xx).

I suppose we don't really have a good way to verify that theory, but for this application, it doesn't matter. /DME makes sense now.

Only one output is supposed to go low at a time.
To me, it looks like IC28 is defective. //Jeff is right about testing VCC at IC28 first.

Found no TC40H138 datasheet in the internet. //The block diagrams in the DX7 manual were an interesting read.

Found something about the Tosiba TC40H family at Bitsavers, but again no TC40H138 datasheet.
From the PDF page 17 (16):



To me, it looks like the TC40H138 could be replaced by a 74HCT138.
Nevertheless, I would suggest to solder a precision DIP socket into the PCB (just in case you might have to try a different substitute later).



But extracting IC28 out of the DM board without damaging the DM board would be going to be difficult.
The incredibly thin traces on top of the PCB would be going off pretty fast when not taking a lot of care.
One option would be cutting the pins of IC28 close to the package with a scalpel or such, then to solder the individual pins out of the PCB after removing the package.

Jeff, any second opinion on this ?

ttlworks: I have now changed out the 40H138 for 74LS138 with no change to the organ or signals so I have refitted it in a socket. I think I might have been misled by what I see on the LA because when I check with a scope all levels are high when not active. IC28 was easy to change because I use Lonco flux to freshen the old solder and then use a Pace desoldering iron. They come out clean as a whistle when the flux is used as you probably know.

dclxvi: I am really interested in your progress with the firmware. The next bit is how to find where $1800 location is. If I continue with the LA in the loop that includes $1800 I should be able to use the unused data lines to look at the chip select lines one at a time and find which one is active if it trying to write to some I/O. When I looked before at the rd/wr lines there were no active /wr cycles in the loop. I check again. Would it be helpful to you if I include the data to go with code3?

Considering what the traces on the DM board look like, it's nice/comforting to know, that you have good/professional workshop equipment.

Sorry to hear, that replacing IC28 didn't fix the problem.

While we are at it: what does the signal at IC32 pin 11 look like ?
//That's the /OE and /CE of the IC12 slave CPU RAM.

Here is IC32 pin11. Looks okay.

Looks OK.

Now that's bad, because I'm running out of ideas what else to check.

We don't know for sure, if the master CPU is getting stalled by a slave CPU going "off track".

If we would be able to inject, let's say, a 125kHz clock into IC4 pin 20 (MI-1 /OS) for faking a slave CPU responding to a master CPU communication,
and the master CPU would condescend to leave the endless loop because of this, we would know for sure that the problem is related to the slave CPU
(or to the circuitry attached to the slave CPU).

Unfortunately, /SO is a push/pull output of the slave CPU, so we can't "inject" a signal there.
Cutting the /SO PCB trace isn't a good idea.
Trying to pull the slave CPU out of the socket isn't a good idea.

So we better wait until the "software department" went smarter about the code, sorry.

BTW: DIP64 sockets with a 70mil (1.778mm) pitch seem to be very exotic stuff:
Farnell: Harwin D8864-42 precision socket, 5.77€
Mouser: 3M 264-1300-00-0602J ZIF socket, 31.90€

I have quite a lot of that sort of stuff left over from my working days. I really liked those turret socket ones. I have a lot of the 40 pin strips with the same sockets in. At the moment I am generating a new spreadsheet with Address/data and the /RD/WR lines. It just takes a bit of time. This new one is 2.45mS after the start and as dclxvi said, there are beginning to be more /WR's. There are so many loops I don't know where the fault actually begins to show up.
Appreciate you help in sticking with this.

You are welcome.

Nu-Source Technologies seems to be a distributor for obsolete Yamaha chips.
Can't judge from here, if that company is trustworthy.
Anyhow, when buying Yamaha chips (from obscure sources), I highly would recommend to make some X-ray pictures,
just to be sure that the chips are no fakes. //There _were_ fakes of the C64 SID chip.

John McMaster has some decapped Yamaha chips in his collection, but not the chips we are looking for.
YM2??? probably means NMOS, YM3??? probably means CMOS.

Yamaha is fabless, chips were manufactured by other companies (Fujitsu, Sharp, Hitachi etc.).
It doesn't come out clear, if the chips were designed at Yamaha, by "subcontractors", or by evil space aliens.

Service manuals for other Yamaha gizmos containing chips like used in the HS-5 appear to be a dead end.

As of 2019, Japanese Wikipedia doesn't know more about these chips than English Wikipedia. //It was worth a try.

Found the datasheet for the YM3012, in the HS-5 that's IC26, the DAC fed by the Rythm Generator.

Edit:
A search for YM3804 (IC18, digital signal processor) gave me a link to the Audio Engineering Society.
The article costs $33 for non_members, can't tell if the YM3804 is covered in this article (or how detailed it is covered).
No hits at the Audio Engineering Society for all of the other Yamaha chips we have in the HS-5.

I am still working at trying to find useful info from the LA and have moved further into the time scale to get past all the initialise steps. At 941mS from boot there is a large loop which repeats infinitely. Some of the code it's executing is in T941.67.xlsx. I will add more to complete the loop. I have also included a couple of snaps from the LA to show how it looks at T941, T964 and T967. It is repeating in less than 2mS. I'm going to go back to the .lst tomorrow see what I can figure out.

As you may already be aware, the fault might not show up (on the LA traces, I mean).

It may be that a switch is active, or the operator (musician) has pressed some keys, and these events are not visible to the CPU as they ought to be. Or, possibly the events were detected properly -- and the CPU responded -- but the response failed to reach the outside world (in the form of a sound or an illuminated LED, for example). In both cases the main CPU has no idea anything is wrong.

The LA traces help us understand the chains of cause and effect from the CPU's POV, but the CPU's POV is limited, and we may need to take a wider perspective. Apologies if I'm stating the obvious.

Thanks for posting the LA snaps. Can you tell me, please: which bus do the traces B0 - B7 represent? I notice they go to all-zeros during certain periods, which leads me to suppose the CPU is accessing a device on a bus other than the one from which the trace was taken.

The multiplexed address/data bus at CPU pins might be a more fruitful place from which to collect data, but there are pros and cons. On that bus we're guaranteed to see all accesses the CPU is making. But the presence of address info makes the data info harder to decipher.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

While still reading address and data from IC6 ROM1. I have found what the CPU is during during the data quiet spells. It is accessing the Rhythm Generator IC3 Bank Select Pin 37 marked as /CTO in the trace it is marked in violet as PB which is the signal from IC13 ADEC. Yes I do see that this fault may never show up on the LA or a scope but I have hopes that as I post things someone smarter than I may see something I haven't. Next I think I will transfer data lines to IC3 to view using the /rd/wr lines

The main (background) loop is located at (ROM1) addresses $5940 to $5968. Reset vectors to address $2048, which jumps to $27B0. At $29BA, it jumps to $5940. (Interrupts are enabled by the CLI instruction at $29B4.) At $5940 are 13 JSR instructions followed by a branch always to $5940. The fact that you are seeing it access those ($5940 to $5968) addresses, indicates that it's not stuck; it made it through initialization and is running the main loop as expected.

I don't know what sort of capabilities your logic analyzer has, but if you're able to trigger (in the sense of triggering an oscilloscope) on (e.g.) address $5940, you should see it hitting that address periodically; it sounds like that's what you are seeing.

Another address you could look for is $4576. That's the Timer 1 ISR, and I believe that should occur every 320 us (or so). It's used to transmit the next byte (if any) in the UART transmit queue, i.e. it checks the queue every 320 us. The UART is configured for 31250 baud, i.e. 32 us per bit, so 32 us * (1 start bit + 8 data bits + 1 stop bit) = 320 us. Anyway, if you see that address, then you'd have some confidence that the ISRs are functioning.

It sounds to me like the microprocessor isn't stuck and the code is doing something more or less reasonable.

You are correct about the address $5940. It is appearing frequently in the code. Do you need me to check the time between calls or is it enough that they are called?
The second address of $4576 has never appeared. I will check IC1 pin1 for output (output of timer 1) and will post a reply shortly.

I have just rechecked and $4576 never appears in the trace. I also checked IC1 pin1 and there is no output from timer 1. Am I correct in looking at pin1?

I have just been rechecking $4576 and it is not appearing , neither is $3D8C but $2038 is and is occurring frequently. I will try to look at the timing between and try to follow what's happening. Beginning with $2038
2038 RD 4C
2039 RD 8C
203A RD 3d
3d3A RD 3d
3d8C 19 EF RD 48
3d08 49
3d8d AF 8A RD 8A
01F8 WR 8A
3d08 FF
3d8d 8A RD 8A
3d8A 8A C8 48 RD 48
This part is the same for every $2038 that occurs.