Vintage Synth Repair

On Saturday 19 April 2008 15:36, Brendan Haley wrote:
> Is there anyone out there that has experience troubleshooting problems with
> the Prophet 600, specifically the digital side of things?

Is there any service information on this unit available online to download?

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

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....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.
  
I'd say the rom is ok if you still have a problem with the test rom..

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. 

Phil.




--- In vintagesynthrepair@yahoogroups.com, "Brendan Haley"
<b.haley@...> wrote:
>
> Is there anyone out there that has experience troubleshooting
problems with the Prophet 600, specifically the digital side of things?
> 
> I have a broken Prophet 600 that powers up. I get no sound out of
it, and "gibberish" on the numerical readout. With the standard eprom
in it it doesn't even really respond in any discernable way to
pressing any of the keypad numbers.
> 
> I have the diagnostic eprom from Wine Country, which also does not
act as expected although with the Diagnositc chip in the keypad does
produce reproducable results, or in other words, the "gibberish"
changes in a systematic way when I press the membrane keypads.
> 
> So I am assuming that whatever is wrong with this is mostly on the
digital side (I think....). Of course, I am not so good with digital
stuff (though I do have a logic probe, and a scope, etc.)
> 
> Any thoughts, or anyone out there willing to give me some hints, or
maybe tell me some more directed things to try?
> 
> Also, is there any way to kind of "bypass" the digital side, to just
get a sense that the "analog" side is working properly (I see the
waveforms I think I should see on the appropriate pins on the
Oscillator chips so I THINK they are good....

> 
> -brendan
>

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

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

Forgot to say I wouldn't remove the 8253..I think its the I/O timer..

Phil.

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

On Saturday 19 April 2008 16:35, Brendan Haley wrote:
> Wow! Thanks, this is AWESOME info....and quick too. (From Everyone....)
>
> I really appreciate it. I will give it a shot and let you know what I find!
>
> -brendan

:-)

Hey,  it made me feel pretty good to look at those diagrams and know exactly 
what I was looking at and to be able to come up with all that just off the 
top of my head like that,  particularly since in spite of me hanging out in 
these litsts it's been too damn long since I've done much of anything 
technical.

Glad I could help,  there.

>   ----- Original Message -----
>   From: Roy J. Tellason
>   To: vintagesynthrepair@yahoogroups.com
>   Sent: Saturday, April 19, 2008 4:24 PM
>   Subject: Re: [vintagesynthrepair] Re: Prophet 600
> troubleshooting....Digital Side.
>
>   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

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

On Saturday 19 April 2008 16:47, Philip wrote:
> Good info Roy...

Thanks.

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

Looks nifty,  but it'd have to be *way* cheaper than what he's talking about 
there for me to even think about it.  :-)

And then there's the time spent hooking it up and such.  Sometimes a scope is 
not all that much slower...

> --- "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
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
-- 
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

Well like I say it's way cheaper than that guy sells them for...they
come on ebay a lot...I used to fix a lot of old arcade machines like
space invaders etc from the same era's and it is invaluable when you
have big banks of ram..Pull the processor out, plug in the relevant
pod then simply enter the ram address ranges and it runs some tests
like read and write compare etc amongst others..it spots things a
scope simply can't. It can also scan and generate a memory map from a
known good board. You can simply run the BUS,RAM,ROM and I/O test
routines or get more deep with it and program scripts for specific
boards/jobs..etc It is quirky but definitely is very capable. Just
another tool in the box really..

There's some more info here if you're interested:
http://tech.quarterarcade.com/tech/Fluke/9010A/



> > 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..
> 
> Looks nifty,  but it'd have to be *way* cheaper than what he's
talking about 
> there for me to even think about it.  :-)
> 
> And then there's the time spent hooking it up and such.  Sometimes a
scope is 
> not all that much slower...
> 
> > --- "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
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
> -- 
> 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
>

--- In vintagesynthrepair@yahoogroups.com, "Brendan Haley" 
<b.haley@...> wrote:

 
> I have a broken Prophet 600 that powers up. I get no sound out of 
it, and "gibberish" on the numerical readout.

> Any thoughts, or anyone out there willing to give me some hints, or 
maybe tell me some more directed things to try?

> 
> -brendan
>

Hi,

I do not have a P600 but my Matrix 1000 suddenly started to behave 
exactly the same way. By touching the chips I found the CPU is 
running hotter than all the others. Like, BURNING hot. I checked the 
voltages and they´re OK, so it looks like the chip is fried and has 
to be replaced by a new one, which is what I am going to do. These 
things probably have a short lifespan.

Paulo.