Yahoo Groups archive

Vintage Synth Repair

Index last updated: 2026-04-28 23:41 UTC

Message

Re: [vintagesynthrepair] Re: Prophet 600 troubleshooting....Digital Side.

2008-04-19 by Philip

Good info Roy...Brendan, the circuit looks quite
simple compared to a lot of things i've seen so you
should be ok! I actually have a thing called a Fluke
9010 microprocessor trouble shooter..see:
http://artfromny.com/fluke%209010.htm it's great tool
for helping with this sort of problem..takes like 2
seconds to test the data bus..ram etc..

Ignore the prices this guy charges, you can get hold
of these systems for very little money now..




--- "Roy J. Tellason" <rtellason@...> wrote:

> On Saturday 19 April 2008 16:00, eggwheatis wrote:
> > If it were me and I know nothing about this synth
> by the way...I'd
> > start by looking at the PSU with a scope....
> 
> Yup,  I looked through the diagrams pointed at, and
> the behavior described can 
> only be a matter of the last couple of them in
> there...
> 
> First thing I'd do is to check the power supplies. 
> The +5 needs to be within 
> a quarter volt of +5 or things won't quite work
> right.  A scope may show 
> *some* hash on the power supply pins,  depending on
> how good the actual 
> design is,  and some of that may be normal.  Not if
> there's a lot though.
> 
> > then assuming this is perfect I'd be looking
> around the CPU to see what
> > activity I have going on again with a scope or
> logic probe referring back to
> > the schematics, reset lines..clock, ports etc etc.
> I'd then check the
> > circuit around the rom and ram etc..chip selects
> etc etc write enable
> > blah blah..theres so much it could be..you only
> need one dead node in
> > the logic circuit and the whole thing won't work.
> 
> Yup. A scope is *much* better for this sort of thing
> than a logic probe.  I'd 
> start out by scoping the data bus pins,  DO-D7 on
> the Z80.  Look for valid 
> logic levels and transitions between them,  but not
> much time spent in the 
> middle (though I have seen designs like the c64
> where stuff regularly did 
> spend short bits of time in the middle. 
> Nanoseconds...
> 
> If there's a bad chip on the bus somewhere and it's
> messing things up to give 
> the symptoms described this will be one way to find
> it.
> 
> Next is scope the address bus pins.  Depending on
> where the software is taking 
> things there may or may not be activity on all of
> them.  A logic probe with 
> the ability to "catch" very short pulses might be
> handy here as well.
> 
> Here's a trick you can try with that Z80. 
> Temporarily solder a bit of wire 
> across all of the data bus pins and to a ground
> point somewhere.  This is a 
> whole lot easier if there's a bus buffer in the
> system,  but the diagram 
> doesn't show one.  What this does is it feeds the
> chip NOP instructions,  and 
> it just keeps on cycling through _all_ of the
> addresses and keeps 
> on "fetching" them.   You should then see a square
> wave on each address bus 
> pin,  with each time you go to the next higher bit
> the frequency is going to 
> be half of what it was.  If you don't see this
> somewhere then there's a 
> problem,  as something ks making one of those lines
> get "stuck".
> 
> I don't know these instruments and don't know what's
> likely to be socketed or 
> not.  From what I can see you should be able to
> remove the 68B50 and maybe 
> the 8253 as well,  as the former is just for MIDI
> and I'm not sure what 
> they're doing with the latter.  You should also be
> able to remove one or both 
> RAM chips and see if there's any change in behavior
> -- if there is then you 
> have a problem pinpointed.
> 
> If you don't find anything in particular this way, 
> start looking at the 
> outputs of the decoders,  the memory address decoder
> especially -- a "stuck" 
> output on any of the decoding circuitry can cause
> some bus contention,  check 
> the outputs of the 74LS138s and also the outputs of
> the gates that connect to 
> those outputs,  and figure out what they _should_
> be.  Like that ROM select 
> line shouldn't be low _all_ the time unless the CPU
> never gets there.  
> The "feed it NOPs" trick above will help you get
> there.
> 
> > I'd say the rom is ok if you still have a problem
> with the test rom..
> 
> Maybe.  Or maybe there's a fault which has done
> something to one of the bus 
> lines and has ended up trashing them both.  One
> hopes not.  :-)
> 
> > I don't see any benefit in bypassing the digital
> side even if it were
> > possible..what with the garbage on the screen
> there is quite clearly a
> > logic problem.
> 
> Yes,  and in an instrument like this I don't see how
> it's possible,  or at 
> least not practical.
> 
> -- 
> Member of the toughest, meanest, deadliest, most
> unrelenting -- and
> ablest -- form of life in this section of space,  a
> critter that can
> be killed but can't be tamed.  --Robert A. Heinlein,
> "The Puppet Masters"
> -
> Information is more dangerous than cannon to a
> society ruled by lies. --James 
> M Dakin
> 



      __________________________________________________________
Sent from Yahoo! Mail.
A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.