6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sun Nov 10, 2024 5:04 am

All times are UTC




Post new topic Reply to topic  [ 75 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next
Author Message
 Post subject: Re: M50734 code
PostPosted: Sun Nov 03, 2019 6:13 am 
Offline
User avatar

Joined: Fri Dec 11, 2009 3:50 pm
Posts: 3367
Location: Ontario, Canada
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


Top
 Profile  
Reply with quote  
 Post subject: Re: M50734 code
PostPosted: Mon Nov 04, 2019 5:16 am 
Offline
User avatar

Joined: Thu Mar 11, 2004 7:42 am
Posts: 362
RogerRabbit wrote:
Attached are the code extracts.

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.
Dr Jefyll wrote:
I should clarify. With 6509, it is only lda (ind),y and sta (ind),y which are affected. 6509 does not bank-switch for other instructions which use (ind),y address mode (although perhaps the M50734 does -- it's unknown).

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.


Top
 Profile  
Reply with quote  
 Post subject: Re: M50734 code
PostPosted: Mon Nov 04, 2019 7:12 am 
Offline
User avatar

Joined: Fri Nov 09, 2012 5:54 pm
Posts: 1431
RogerRabbit wrote:
[IC28 (40H138)] shows a completely different pattern where three of the outputs are low at the same time.

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):

Attachment:
TC40H.png
TC40H.png [ 90.13 KiB | Viewed 2102 times ]


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).

Attachment:
ic28.png
ic28.png [ 339.41 KiB | Viewed 2102 times ]


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 ?


Top
 Profile  
Reply with quote  
 Post subject: Re: M50734 code
PostPosted: Mon Nov 04, 2019 9:19 am 
Offline

Joined: Wed Oct 16, 2019 8:23 am
Posts: 30
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?


Top
 Profile  
Reply with quote  
 Post subject: Re: M50734 code
PostPosted: Mon Nov 04, 2019 10:10 am 
Offline
User avatar

Joined: Fri Nov 09, 2012 5:54 pm
Posts: 1431
RogerRabbit wrote:
IC28 was easy to change because I use Lonco flux to freshen the old solder and then use a Pace desoldering iron.

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.


Top
 Profile  
Reply with quote  
 Post subject: Re: M50734 code
PostPosted: Tue Nov 05, 2019 12:56 am 
Offline

Joined: Wed Oct 16, 2019 8:23 am
Posts: 30
Here is IC32 pin11. Looks okay.


Attachments:
IC32Pin11.jpg
IC32Pin11.jpg [ 2.14 MiB | Viewed 2061 times ]
Top
 Profile  
Reply with quote  
 Post subject: Re: M50734 code
PostPosted: Tue Nov 05, 2019 7:39 am 
Offline
User avatar

Joined: Fri Nov 09, 2012 5:54 pm
Posts: 1431
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€


Top
 Profile  
Reply with quote  
 Post subject: Re: M50734 code
PostPosted: Tue Nov 05, 2019 7:59 am 
Offline

Joined: Wed Oct 16, 2019 8:23 am
Posts: 30
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.


Top
 Profile  
Reply with quote  
 Post subject: Re: M50734 code
PostPosted: Fri Nov 08, 2019 7:20 am 
Offline
User avatar

Joined: Fri Nov 09, 2012 5:54 pm
Posts: 1431
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.


Last edited by ttlworks on Tue Nov 12, 2019 3:21 pm, edited 1 time in total.

Top
 Profile  
Reply with quote  
 Post subject: Re: M50734 code
PostPosted: Sat Nov 09, 2019 8:16 am 
Offline

Joined: Wed Oct 16, 2019 8:23 am
Posts: 30
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.


Attachments:
T+967Loop.jpg
T+967Loop.jpg [ 267.85 KiB | Viewed 1968 times ]
T+964Loop.jpg
T+964Loop.jpg [ 250.09 KiB | Viewed 1968 times ]
T+941Loop.jpg
T+941Loop.jpg [ 269.84 KiB | Viewed 1968 times ]
T+941.67.xlsx [13.93 KiB]
Downloaded 70 times
Top
 Profile  
Reply with quote  
 Post subject: Re: M50734 code
PostPosted: Sat Nov 09, 2019 1:25 pm 
Offline
User avatar

Joined: Fri Dec 11, 2009 3:50 pm
Posts: 3367
Location: Ontario, Canada
RogerRabbit wrote:
There are so many loops I don't know where the fault actually begins to show up.
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


Top
 Profile  
Reply with quote  
 Post subject: Re: M50734 code
PostPosted: Mon Nov 11, 2019 4:00 am 
Offline

Joined: Wed Oct 16, 2019 8:23 am
Posts: 30
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


Attachments:
PBBankSelectIC3a.jpg
PBBankSelectIC3a.jpg [ 366.14 KiB | Viewed 1933 times ]
Top
 Profile  
Reply with quote  
 Post subject: Re: M50734 code
PostPosted: Mon Nov 11, 2019 6:08 am 
Offline
User avatar

Joined: Thu Mar 11, 2004 7:42 am
Posts: 362
RogerRabbit wrote:
At 941mS from boot there is a large loop which repeats infinitely.

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.


Top
 Profile  
Reply with quote  
 Post subject: Re: M50734 code
PostPosted: Tue Nov 12, 2019 7:34 am 
Offline

Joined: Wed Oct 16, 2019 8:23 am
Posts: 30
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.


Top
 Profile  
Reply with quote  
 Post subject: Re: M50734 code
PostPosted: Tue Nov 12, 2019 7:53 am 
Offline

Joined: Wed Oct 16, 2019 8:23 am
Posts: 30
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.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 75 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next

All times are UTC


Who is online

Users browsing this forum: Yahoo [Bot] and 7 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: