Data bus line and D-type behaviour/issue

GroupDIY Audio Forum

Help Support GroupDIY Audio Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.

zamproject

Well-known member
Joined
May 11, 2010
Messages
1,502
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
 

Attachments

  • Roland Juno-60 Panel B .pdf
    1.2 MB · Views: 0
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
 
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
🙃
 
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
 
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.
 
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
 
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
 
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.
 
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 😇
 
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
 
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
 
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
 
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...
 
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
 
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.
Yes, seem the extra 16 patch for test mode are in the CPU mask ROM...
RAM changed now, work fine !
But new issue appear (probably here before but without RAM I don't see it...)
The Tape interface don't work, I can save to tape but can't load them back ...
I don't play the Juno that much recently, but used to save patches to a track in my DAW in the same project/song so I can recall the whole setting if requested or if memory battery fail...
I hope it's just a buffer/filter issue and not the uC...I'll see

Cheers
Zam
 
Two IC's (OpAmps) and one Transistor + two Testpoints (one for Save and one for Load) - that ought to be simple (famous last words) ....
 
that ought to be simple (famous last words) ....
as you say... signal is fine at all buffer/filter stage...so this become little more complicated 😬
With proper level input (load & verify) and proper square wave shape at CPU pin 1 (TP2) the error message appear ...

The sequence start by a long 2k38 signal (before transfer routine with 1k36 4 cycle for bit 0 and 2k38 7 cycles for bit 1), as soon as I play start from the tape (DAW) error is in, like the CPU don't recognise it.

I try sending various freq from REW, as a start tone from around the two bits frequency window, error take hand at about 1k8.

I'm out of ideas, faulty CPU, clock issue, or another thing ?
I can try to pitch and/or slower the stream to see what happen...
 
Onestly - I have only changed the Filter and VCO Modules + a battery (or two) in those .... so I never had to repair the Tape function ...!

... But - what is the Levels of the Square @ TP2 ? + are the Edges clean and fast ?
If those don't go High or Low enough => Trouble .... and Dirty or Slow Edges - has similar problems -> they might not be read as correct values.
I'm pretty sure that Low MUST be below 0.8Vdc. ...!!!
If the CPU behaves as a TTL -> High MUST be higher than 2.4Vdc. ..... and if it is a CMOS -> Higher than 3.5Vdc. to be good ....
I kind of expect that it is a CMOS to use a Bipolar Transistor to pull the signal Low - as they often get stuck around 1-1.2V as Vsat.

I hope that some one who has actually repaired the Tape function will step in here ...!

Per
 

Latest posts

Back
Top