Data bus line and D-type behaviour/issue

[zamproject]

Hi all

I'm troubleshooting my JU60 that have issue read/write memory
I think I find the data line of the DB bus which cause problem, bit 4
Those 8 lines read/write pot, set switches (read is from matrix on other ports) and read/write RAM

At this line I can scope the cycle , and there is one data which is NOT at 0 or 5V but somewhere around 3
It's also the line that set/latch switches for chorus II and HPF, the exact data that don't store properly.

This line connect from/to uPD to a latch (40H373), which handle 8bit pot DAC, and RAM address,
to a flip-flop (40H273) that handle switch data out, and finally the RAM data I/O

The question is about the suspect.
Can an input from a the CMOS D-type latch or flip-flop be -altered- only at clock or control port call ?
I mean if a -cell- is dead I should have this -pulldown- all the time right ?
But this DB line is not always pulled down, but only at on bite of the uPD cycle.
Same question for the RAM, can a CE or W/R command alter the I/O buffer behaviour ?

See attached, suspect DB line in red (blue is further latched/flipped data)

Cheers
Zam

 

[JohnRoberts]

Hi all

I'm troubleshooting my JU60 that have issue read/write memory
I think I find the data line of the DB bus which cause problem, bit 4
Those 8 lines read/write pot, set switches (read is from matrix on other ports) and read/write RAM

At this line I can scope the cycle , and there is one data which is NOT at 0 or 5V but somewhere around 3
It's also the line that set/latch switches for chorus II and HPF, the exact data that don't store properly.

sounds wrong

This line connect from/to uPD to a latch (40H373), which handle 8bit pot DAC, and RAM address,
to a flip-flop (40H273) that handle switch data out, and finally the RAM data I/O

The question is about the suspect.
Can an input from a the CMOS D-type latch or flip-flop be -altered- only at clock or control port call ?

D type FFs Latch data during the appropriate clock transition.

I mean if a -cell- is dead I should have this -pulldown- all the time right ?

If one of the chips attached to that data line is faulty it could be loading that data line

But this DB line is not always pulled down, but only at on bite of the uPD cycle.

It is not unusual to strobe data lines briefly only as needed to read valid data

Same question for the RAM, can a CE or W/R command alter the I/O buffer behaviour ?

Not sure I understand the question

See attached, suspect DB line in red (blue is further latched/flipped data)

Cheers
Zam

I don't see an obvious fault. Are the sundry ICs in sockets or soldered into the PCB? The 3V is clearly invalid state for 5V logic.

Good luck.

JR

 

[zamproject]

sounds wrong

yep...

D type FFs Latch data during the appropriate clock transition.

If one of the chips attached to that data line is faulty it could be loading that data line

It is not unusual to strobe data lines briefly only as needed to read valid data

Yes I get that, that's what I see on the scope, I'm just puzzled that the fault is only valid at one bit of the whole stream/uPD loop. So related to one clock pulse from one of the 3 chips.
I'll have to see if I can sync my scope to those CLK/EN lines, to catch which chips is pulling down by locate/identify the 3V bit in the whole stream, for now suspect it's somewhere at the end of the word, so not the pots value for DAC and multiplexing (16 first in 6ms)
but more at the end which according to manual is switch data out...so the latching chips ?

Not sure I understand the question

In the RAM, ChipsEnable and Write/Read switch I/O port from IN to OUT, maybe the internal switching is faulty and the port is loaded by IN and Out buffer.

So to repeat mysef, I'm maybe not that clear, which chips is -by construction- more prone to defeat an input, only at clock transition, not before nor after...

I don't see an obvious fault. Are the sundry ICs in sockets or soldered into the PCB? The 3V is clearly invalid state for 5V logic.

Soldered...if they were socketed I would have already removed one by one to see which one pulldown this DB line for a fraction of the loop.
That's why I try to ask and understand before de-soldering 3 IC where two are potentially OK. I find this single sided PCB not that robust, and despite my care I have bad souvenir from the recapping years ago

Good luck.

JR

 

[zamproject]

Ok...find the faulty IC it's the RAM
Was hoping for the flip-flop or the latch

It's the pin 11, data I/O n°4. I was able to unsolder this pin without contact to the trace.
Not sure if it's the in or out buffer but when one of them is active it pull the bus down.

Now it's time for the shopping

Cheers
Zam

 

[zamproject]

Hello
I have some side question regarding RAM storage, I'm not used to how this work.
When you have two RAM chips, is a single stored preset writed in two part at the two chips, or half of the presets are at one chips and second half in other chips.
I try to find if there is some preset n° that can be write and read properly, with only one ram installed.

 

[JohnRoberts]

It depends on what the software intends. Are they two identical memory chips, are they in series or parallel?

Were there cheaper versions with less features. That might work with just one memory chip.

JR

 

[zamproject]

The software is another -issue- in the Juno 60, it's a mask ROM, uPD80c49c, I hope it never fail

Regarding the DB wiring, everything is in parallel, 2 same memory chips (10bit address), with 2x4 RAM I/O and 8 MSB from/to DB, the two LSB address from port 2

There is no version of this synth with downgraded memory feature like less program slot available.
There is the JUNO 6, which is the same syth without memory at all.

I'll completely unsolder the faulty RAM and will see how it behave

 

[JohnRoberts]

Sounds like an approach to increase size of memory by alternating reads and writes between the two memory chips, this will give 2x the data storage.

JR

 

[zamproject]

Ha ? not sure about that (but as I say I'm not expert...) the R/W and CS lines are the same for both
Now that I'm thinking more about it, address are parallel but not I/O.
So might be they use the 2*4bit ram for 8 bit word ? with same address for both chips.

 

[JohnRoberts]

Are all of the address line in common? If the MSB is separate they could turn it into two same sized banks. Or not...

JR

 

[zamproject]

Yes all address lines are common
Now I'm puzzled again...There is 72 memory -slot- for user program preset.
With 16x 8bit fader it's already 128 bit for one preset, 9216 bit for the whole? and there is switch data to store too, some with 4position (4bit)
How this work with two 4096 bit RAM ?

again...this is side questions thinking out loud for total curiosity...
I should probably read and do my home work a little before asking

 

[Admiral-dk]

10 Bit Address = 1K and in this case 2x4 bits = 1 Byte => 1KB of RAM ...!

And to my big surprice - they can still be had and are very cheap - less than €1 here in Denmark, TC5514P sale

Per

 

[zamproject]

Tks for the link
unfortunately there is no suffix at this one, so don't know the speed ?
Service manual notes ask for 100 or 200ns (and a change if 5514-3 is installed)

10 Bit Address = 1K and in this case 2x4 bits = 1 Byte => 1KB of RAM ...!

1KB is still 8192 bits right ? 16x8bit value fader need 128bits data, there is 72 patch
But maybe the 2 hidden extra bank (16 patch) are in the uPD ROM/RAM ?, those are only accessible in debug/test mode.

The RAM I remove is a TC5513-20
Writing patch is more crazy than before, so the answer to the previous question is probably that the two RAM are used as a single 8bit word stream

Cheers
Zam

 

[Admiral-dk]

1KB is still 8192 bits right ?

Yes - 1024*8 = 8192 (1 Byte = 8 bits).
I honnestly don't remember - but if memory is somewhat true - I think the a number off those 72 are in ROM only (can be copied elswhere by user) and those ROM positions can't be changed ....

The TC5513-20 is pin compatible with the TC5514AP & TC5514APL - but only the APL versions are Low Power/Current and delivers a long Backup Battery Life. Of course if you only can get the AP versions now - that will still be much better than no Working Synth.

As both /WR and /CS lines run to both RAM IC's => you got 8bit RAM as a result.

Service manual notes ask for 100 or 200ns (and a change if 5514-3 is installed)

OK - so the schematic has an error then .... here it says to use either the TC5514AP (funnily not the Low Power APL) or the µPD444C-1 and the later is a 300nS ....
But they might had too many Warranty problems, and as a result changed the specification to the 200nS version ....

I have written to the company I gave the link to and asked them to provide the missing details in their listing - let's see if they reply ....

Per

 

[zamproject]

OK - so the schematic has an error then .... here it says to use either the TC5514AP (funnily not the Low Power APL) or the µPD444C-1 and the later is a 300nS ....

ha yes ! my fault, I thought the uPD444-1 mean 100ms

Yes - 1024*8 = 8192 (1 Byte = 8 bits).
I honnestly don't remember - but if memory is somewhat true - I think the a number off those 72 are in ROM only (can be copied elswhere by user) and those ROM positions can't be changed ....

So there is an -issue- with memory !
to my calculation a preset word take:
128bits (16*8 bits fader)
14bits (for the switches, some with 1bit some with 2bits like HPF 4 positions)
total patch = 142bits
72 patch = 10224 bits
This can't fit.

Fader are 8bit (256 value) in real time/manual setting with AD and DA read/write mux/demux
There is no mention for data structure of a memory patch in the service manual.
It may be possible then that RAM stored patch reduce fader data to 6bit ?!?

I'll try to check that as soon as I replace the SRAM, to see if fader LSB value at DB bus change or not between manual and patch recall...

 

[Admiral-dk]

ha yes ! my fault, I thought the uPD444-1 mean 100ms

Me Too - but I found the Data Book, and the µPD444C has it's 'Numbers going the other way' -> lowest number are slowest ....
I had a look and the Juno 60 can only Store 56 Patches in RAM - the rest are in ROM .... that probably adds up to less than 8192.

Per