Need help with a Prophet 600 vintage synth that won't boot - Page 1
Forum section: electronics / repair

author: Midphase
author_rank: Regular Contributor
timestamp: September 16, 2025, 02:13:41 am
content: Howdy everyone,I'm repairing an old synth from Sequential Circuits called a Prophet 600. I'm running into a strange issue that I'm hoping someone might have some advice on resolving.Let's start with the basics, voltages are all pretty spot on (+/- 15 and =/- 5 are well within specs). Continuity to all of the main pieces seems to also be fine, and there aren't any visible weird signs like burn marks, corrosion, etc.I should also mention that I have a second Prophet 600 handy which is working fine, so I can run some comparisons on the scope.- What I have narrowed the issue to be from what I can tell is that Pin 20 on the Z80 which is the IOREQ line isn't receiving any pulse signals and rather is stuck on High permanently, whereas on the working unit there are definite high/low pulses happening.- There is a Timer chip on the board, the 8253. It appears to be functional when I put it into the working unit so I think the IC is fine...however I should be seeing some activity on the CS line at Pin 21 and I am not...once again stuck on High which means the chip is never getting polled.- This Pin 21 signal is coming from an OR Gate, a 74LS32 which should be outputting a pulsing drop on Pin 11...but it isn't. The OR gate on that IC is receiving a High signal on Pin 13 (IOREQ) and some Pulse activity in very regular intervals on Pin 12 (A3).- The CPU is getting a proper Reset and appears to be trying to do stuff, but seems stuck in a loop or something. I have several Z80 CPU's at my disposal which I have swapped out so I'm pretty sure the Z80 is not at fault.- The EPROM should also be good as I have swapped it out from the working unit and it seems to work fine on that unit.There is obviously something that is keeping that IOREQ line from going low and polling the 8253. Any thoughts where I should look next?I'm attaching the schematic for this PCB in question:

author: pqass
author_rank: Super Contributor
timestamp: September 16, 2025, 06:37:14 am
content: IOREQ goes active-low whenever an IN or OUT instruction is executed. This might be occurring but probably too brief for you to see. What tool are you using to monitor this line? An oscilloscope or logic analyzer is best to use in this situation.I was looking at the POWER DETECT circuit to understand how the CPU boots...It looks like U308, a NOR ("C02" CMOS?), is being permanently powered by Vnv(non-volatile?) which is either mains powered or via 3V battery (BT301). The 3rd NOR gate puts a permanent low on the RESET line while the mains switch is off. When the mains switch is turned on, the RESET line should continue to be low for about 200ms (keeping the CPU in reset) while the +5V stabilizes. The RESET line is inverted to provide PWRON which keeps the RAM CS disabled (high) (via U315 "C32" ORs) until out of reset.Confirm power to RAMs (U313, U316), ORs (U515), and NORs (U308); should be +5V when mains switch is on, and ~3V when mains switch is off. Dead backup battery is highly likely in vintage gear.So, if IOREQ truly never goes active-low, then while the mains switch is off, confirm that the RESET line is low and PWRON is high (~3V).A few seconds after the mains switch is on, confirm that the RESET line is high (+5V) and PWRON is low.If PWRON != invert(RESET) then U308 is bad.Given that you see activity on A3, it's probably executing code. Confirm the MREQ and RD lines go active-low.

author: neillnz
author_rank: Contributor
timestamp: September 16, 2025, 07:46:37 am
content: I am assuming that the static RAM ICs are not in sockets. I'm going to suggest that you swap them for the ones in your working unit but of course only if you are a confident about the desoldering process.I would put sockets in their place.This may sound a bit like a random guess. I'm suggesting you try this because it's very difficult to diagnose what the CPU is not doing correctly without going deep with a logic analyzer. This is something you can do quickly and there is a good chance it could be the issue.I have not worked on one of these synths before but similar vintage equipment that had faulty static RAM that being a player piano and Audi digital instrument cluster.

author: paulca
author_rank: Super Contributor
timestamp: September 16, 2025, 11:16:35 am
content: IOREQ is a CPU output.The fact it is not going active low is most likely because the CPU never executed the IN or OUT instruction.Working out why will be the hard part. The timer chip will need to be configured for anything to happen there and that will require OUT instructions. If they aren't happening, the timer is likely a red herring.It is likely stuck in an init routine waiting on something that isn't happening.Put an analyser on the address lines and see if you can work out if it's dead memory or if it's stuck in a tight loop, might give you a lead. Might be a bit more work, but you could log the databus and disassemble the code too.Also check the interrupt lines. INT, IEO, IEI etc. Int should be pulled high, the first IEI should also be pulled high. The interrupting chip will as a minimum pull INT low. That should be responded to with an M1+IOREQ. IEO and IEI are daisy change interrupt signalling between peripherals, though mostly "Z80 family" ICs. It is also relayed through chips, so if you have any removed that could cause interrupt blocking.

author: Midphase
author_rank: Regular Contributor
timestamp: September 16, 2025, 06:09:43 pm
content: The RAM IC's (6116's) are in sockets, as well as the EPROM, the 8253 Timer and the 69B50 UART, and I have already tried swapping them into the working unit and they all work as expected in the working unit.Could this be caused by a component on a different board? Unfortunately the Voice Board is hard soldered along with the CPU board, and I'm debating as a last resort, cutting it off to see if that might improve the situation, but only as a last resort because re-wiring all of those connectors will be very time consuming.I was thinking of tackling socketing U308 and U309 (74C02 (NOR Gate) and 74LS138 (Multiplexer) respectively) since those seem like reasonably suspicious possibilities.If someone wants to take a look at the schematics from the other boards as well the full service manual can be downloaded here:https://www.synthxl.com/sequential-circuits-prophet-600/

author: Midphase
author_rank: Regular Contributor
timestamp: September 16, 2025, 06:14:41 pm
content: Quote from: pqass on September 16, 2025, 06:37:14 amOn my scope, on the working sent, the IOREQ looks like a High line with occasional spike drops. On the non-working unit the line just stays high with no spikes.The low spikes on the working unit are also found on Pin 11 of the 74LS32 and Pin 21 of the 8253.The original backup battery has been replaced and put into a socket, however I noticed that it's been drained considerably on the non-working synth after a couple of days of installation compared to the working synth battery which still shows full charge. Could this be a hint at something?

author: Midphase
author_rank: Regular Contributor
timestamp: September 17, 2025, 02:41:23 am
content: Ok...some small progress today.Based on some of the suggestions, I pulled out the 74C02 NOR Gate, 74LS138 Multiplexer/Decoder and 74C32 OR Gate at U308, 309 and 315 respectively.The 74LS138 checked out on my XGecu tester, but both the 74C02 and the 74C32 returned errors. Thankfully I had a spare 74C02 that tested out correctly so I could replace it, but I don't have a spare for the 74C32...I do however have a 74HC32 which "should" be a suitable replacement...unless you guys think not.When I switched the unit on, the previous bad IC were giving me a bunch of garbage nonsense on the LED Display. With these new IC's, the unit goes straight into Tuning mode which is indeed what should happen when powering the Prophet 600 up.Problem is that it's getting stuck on the tuning and never comes out of it which is not what should be happening.My guess at this point is that the Z80 "should" be functioning correctly and running the firmware code, but somewhere along the Tuning loop it isn't getting to the proper tuning and it just stays stuck in a loop? Is that possible?I'm going to start taking a look at the circuit responsible for the tuning next and see if I can find some other faults:

author: Audiorepair
author_rank: Frequent Contributor
timestamp: September 17, 2025, 05:54:35 am
content: I think at this stage I would be assuming the Z80 parts now working.The manual contains unusually explicit descriptions of how the rest of the unit is designed and works, but I would be going to the CEM VCO chips and seeing what is coming out of them.The CPU sends control voltages to them to make them oscillate at set frequencies which it then measures to build a tune map, or at least that's what the Prophet 5 does.Anyway, you can see the oscillators going through this tuning procedure, as you can no doubt observe on your working one.It is not uncommon to find a dead CEM VCO chip - what the 600 does when it finds one I don't know offhand, it may just tune the working ones and then you will have a Prophet 500 or 400 or whatever, or if it is never able to send a tuning signal or measure the frequency of any the VCOs then it will probably just hang.You have two incredible sources to work on here - a truly excellent technical manual and a working synth.

author: Audiorepair
author_rank: Frequent Contributor
timestamp: September 17, 2025, 08:17:07 am
content: I repaired a Prophet 5 that was stuck in tune - it was a faulty DAC.It was not easily detectable as faulty, I suspect it had lost a bit and/or was not accurate enough to be used for tuning.I only changed it when I had run out of other ideas, as genuine ones are hard to find.

author: Midphase
author_rank: Regular Contributor
timestamp: September 17, 2025, 03:41:18 pm
content: I will swap out the DAC with the working one that I have and see what happens. I actually bought another DAC recently since I suspected that the original one wasn't working correctly, but the one that I bought should be fine.When I probe the CEM VCO's, I get activity on 3 of them, while the other 3 are completely silent on both A and B chips. It seems unlikely that both A and B oscillator IC's would fail on the same exact voices, while on the working ones they would both be functioning as expected. I suspect that whatever is activating them might not be firing them up. Could the Multiplexers be at fault in this case?

author: Audiorepair
author_rank: Frequent Contributor
timestamp: September 17, 2025, 04:17:20 pm
content: My experience with the CEM VCOs is that they pretty much always oscillate whether they have been part of a boot process or not. Often that will be either at very high frequencies or very low.If they are not oscillating at all I would suspect they are dead.I did recently find one that wasn't oscillating due to a shorter capacitor so this isn't always true.I would be inclined to swap a working one with a non working one, fitting IC sockets in the process. That will give you something to test others with.

author: Audiorepair
author_rank: Frequent Contributor
timestamp: September 17, 2025, 06:35:16 pm
content: You want some known knowns, not guesswork.Swapping 2 chips will tell you a lot.

author: Midphase
author_rank: Regular Contributor
timestamp: September 18, 2025, 12:08:15 am
content: So after swapping them around, it looks like a couple of the CEM3340's are partially not working (I say partially since the Triangle outputs, but not the Sawtooth, and vice versa).I swapped them with two working ones from the other Prophet 600, and they're all outputting both Triangle and Sawtooth, and yet the boot is stuck in the Tune mode and doesn't come out of it.I have to assume that there is something else going on which is preventing the CPU from finishing the tuning routine and remain in a loop.

author: Midphase
author_rank: Regular Contributor
timestamp: September 18, 2025, 01:24:58 am
content: Ok, as I continue to scope around the board, it looks like the Z80 is sending out data to the DAC, but it's not being received. The DAC71 works fine, as I swapped it out with the working unit and it works perfectly in there. So the issue lies elsewhere.So far the next likely culprit is the 40174 Flip Flop, the data is getting in, but it ain't coming out. It's weird since it seems like this is a 6 channel Flip Flop, and I would expect at least one of the channels to work but none of them do....but I suppose when they go they go?Unfortunately I don't have a replacement IC here, so I had to order online and it will take a few days to arrive. I'll keep everyone posted on the progress!

author: Midphase
author_rank: Regular Contributor
timestamp: September 19, 2025, 07:58:25 am
content: Quote from: Audiorepair on September 17, 2025, 05:54:35 amI am not quite sure that the Z80 is fully happy quite yet. When I probe between the working Prophet and the non-working one, on the non-working one the Z80 appears to freeze its activity about 2 seconds after power up while the working Prophet shows continued activity.I have been probing around to see if I can figure out some other possible failure points. Was looking at the 74LS138 at U322, specifically at the IOREQ on Pin 6 and there are distinct activity differences between the two units.My theory at the moment is not that the Prophet is getting stuck at the Tuning routine, I am not sure it's getting there in the first place which would explain why I get no activity on the output of the DAC at all.I can start replacing other IC's but all of my supply is not the LS type but the HC type and I worry that in this circuit I should stick with the LS TTL chips instead of the CMOS ones.

author: Audiorepair
author_rank: Frequent Contributor
timestamp: September 19, 2025, 11:26:27 am
content: Yes, but we don't know what the programmers wrote the unit to do should it fail the tune process.It might just be "sit down and shut up, this is not happening, bro".Edit: Or indeed how many VCO communications have to fail before it does so.

author: paulca
author_rank: Super Contributor
timestamp: September 19, 2025, 01:47:50 pm
content: Quote from: Midphase on September 19, 2025, 07:58:25 amThe 138 is the defacto device selector. The Z80 has a separate 8 bit IO address space.The 138 is usually wired such that "device select lines" are driven from the upper bits and the lower bits go to the device as "register selects".IORQ is not useful on it's own though. The multiple 138 enable pins often have "IOREQ" and "RD xor WR" and one of the address lines. Obviously different address topologies can be used. However, in a simple case one of the enable pins can be "bit 7" and two 138s can be used to handle 8 devices each out of 16.The point is, you would need to put an analyser on most of the 138s pins to work out if or how it's functioning.Correct activity of the 138 and the IO process requiresIOREQ + RD or WR + Valid addressOnly for the portion of time that all of those exist should you see a "active low" selected on the 138 output pin. That output pin is most often used to drive a "CS" or "OE" on an IO chip.I suspect an init routine has failed to complete and the CPU is either crashed, has jumped to a hard fault handler or is stuck waiting on an interrupt or IO device flag which is never being set.I would be trying to ascertain what the CPU is doing.Is it stuck in a tight loop?Is it randomly jumping around.Is it halted?Is it repeating the same task over and over again forever?My bets will be on the last one. If you find out what that is.... say for example the same IO IC is being repeatedly read from, that may point you to the failure.If it's crashed or gone off into an error handler, without the software docs it will be difficult to get any information. In this case you will need to log the start up states and working out what it did last before crashing.One option is to inject a signal generator as a clock and step it, or run it slowly enough for you to scope out signals.You are looking for things like "Memory reads" which MUST happen. Memory writes which are highly expected to the stack at least. More importantly is the IO bus and which ICs are being poked and prodded and if after proding one chip it "hangs" or fixates on it.Another thing as I mention to check is activity on the interrupt lines. "INT" line.A common start up sequence for an IC is as follows:Write config word to config register.Write RESET or CLEAR to the command register.Read and poll the STATUS register for "OK".If that IC is broken the init routine will hang in the last step and will loop there forever.You 100% need an logic analyser. Even a amazon 8 channel USB one with Sigrok would do.

author: Midphase
author_rank: Regular Contributor
timestamp: September 19, 2025, 05:16:33 pm
content: Quote from: paulca on September 19, 2025, 01:47:50 pmI believe you're right. Basically what I am seeing on the scope is a burst of activity for the first couple of seconds which then settles into a very regular high/low loop.The frustrating part is that when I swap out the primary components (Z80, 6116, EPROM, 8253, 68B50 and DAC71) it makes not a lick of difference, which tells me the fault is happening either in one (or combination) of the logic gates, flip-flops or the output decoder.I can brute force this by replacing each and every single IC on this board, but what I have handy are CMOS (HC) versions and not the TTL (LS) versions...do you think this is going to be a problem?

author: paulca
author_rank: Super Contributor
timestamp: September 19, 2025, 06:54:54 pm
content: Just a random idea, maybe it will help you.Break it more. Break it in predictable ways.When I built a Z80 computer and in the early days had no debug output, all I had where LEDs for address and data. I would put "HALT" instructions in the code I would migrate that halt instruction until it no longer hit. Now I knew where the bug was. This was after "single steping" or even "slow clock" was practical, when the "init" routines took too long. Eventually I added the 16x2 LCD as the first IO device. I learnt a lot about Z80 IO and bus timing.I know you can't change the rom... although, having said that, if it's socketed, maybe you can. "Diagnostic ROMs" are a thing. Maybe someone somewhere has one on github for the prophet. I know it was a very popular 80s synth?Without changing the rom it will be a lot harder, but working out what it is repeatedly retrying or stuck on or maybe the last thing it does before it gets stuck is where you need to "provoke".Signal analyser, will be your friend. This almost reminds me of watching "CuriousMarc" (and co et al) reverse engineering parts of the Apollo Guidance Computer.

author: paulca
author_rank: Super Contributor
timestamp: September 19, 2025, 06:59:18 pm
content: There is a slim change, btw, that the prophet uses "Memory mapped" IO and in that case it would not use IOREQ much at all. In that paradigm and the more common one, 138s and similar ICs are used in more complex arrangements to enable chip selects for memory requests instead. None of the IO chips you mentioned strike me as "z80 family" style chips, so "memory mapped IO" is not completely unlikely.

author: Audiorepair
author_rank: Frequent Contributor
timestamp: September 19, 2025, 08:13:22 pm
content: There is also the slim chance that the Z80 circuit IS actually poking a voltage to a VCO and giving up when there is no response.Since I don't have the expertise or tools to diagnose a faulty Z80 circuit, despite having built and machine code programmed one decades ago, I would be looking at the analogue side for at least a clue or two.Particularly since you have replaced one chip already and the Z80 circuit drastically improved its abilities.And also that I have found it very easy to diagnose a CPU signal line as non functioning using a scope, when actually it was just my inability to detect it.One might hope that the CPU circuit didn't somehow suddenly suffer more than one failure.Are all the VCO's all just hanging with their free running boot up frequency, or have one or two been modified by a tuning attempt?Can you observe any such attempts being made?Or categorically deny any such attempt being made, which would pretty much imply the Z80 was never able to send the signals in the first place?We need some more Known Knowns, these are sadly lacking.

author: Midphase
author_rank: Regular Contributor
timestamp: September 19, 2025, 08:48:13 pm
content: Ok...so one of my big red flags in this whole instrument is the fact that the DAC output (pin21) doesn't seem to be outputting any voltages. This is confirmed by also the OpAmp output that directly connects to Pin21 of the DAC...they're both inactive while on the working machine they are firing off a bunch of voltages.I do think that the Z80 is possibly in a hold and wait state, which would point to the cause being that the DAC isn't actually communicating to the rest of the sound oscillators.Now, I have confirmed that the DAC71 chip works fine by swapping it into the working instrument, and it does.This leads me to conclude two possibilities:1. The data isn't arriving to the DAC71 from the CPU or2. Could the Gain circuit in the DAC71 be faulty and not get the DAC to gain the signal to the level that is necessary?Am I crazy?I'm attaching the schematic for the Voice board.

author: Audiorepair
author_rank: Frequent Contributor
timestamp: September 19, 2025, 09:33:53 pm
content: If the DAC is a Current output device there will be no voltage you could detect.There are 2 versions, Voltage output, Current Output.They are not interchangeable.Ands maybe change the Op-amp that converts this current output to voltage to give you another Known.

author: pqass
author_rank: Super Contributor
timestamp: September 20, 2025, 02:48:26 am
content: I found the detailed technical manualhere, including the full schematics. Note the abstract schematic on page 24 and the tuning algorithm on page 38.Page 40, top:"Because the oscillator signals pass through analog switches and the filter, problems in these audio paths may appear as tuning problems. For example, if an open analog switch disables the oscillator output to the tune comparator, the tune circuit will not see the correct number of pulses. This failure mode causes the computer to set the CVs for all C notes for that oscillator to maximum, while all other keys will sound in the sub-audio range. (To isolate the problem, try using the voice defeat: hold the key then press RECORD and PROGRAM SELECT 7.)"Also,Measuring the DAC output (even after the DAC current output is converted to a voltage at pin 3 at one of the CD4051 MUXs) is a moving target because the code is probably constantly cycling through all 32 MUX outputs to keep the input cap to the buffers topped-up to the programmed level for that output. Given that it's stuck in the tune loop (varying frequency and other parameters), the post-MUX buffered outputs are constantly changing too. However, you can confirm that the MUX buffers are working using your oscilloscope to see if the output voltage=input voltage (ie. that they track together). Also the fact that the input voltage changes over time means it's getting new levels through the MUX which validates the MUX outputs.FYI: there is a 5ms (200Hz) interrupt clock (8253 timer-0 into Z80 /INT). Likely the basis of all multiplexing of the MUXs, piano key/sw/pot inputs, dual 7-seg. display output.You may have to de-solder all the un-socketed DIPs, add a socket, then individually test/replace with known good. It's a nice instrument. I think it's worth it.The operators manualhere. Blurb in "3-4 Retuning" on page 17 says it should take up to 4 seconds.

author: RJSV
author_rank: Super Contributor
timestamp: September 20, 2025, 03:02:34 am
content: Pins pins, sockets sockets, sockets; It's getting to be time for aTIME,-OUT ! By this I mean put your soldering iron down, and troubleshoot the dang CODE, running !Sorry if I maybe read wrong, but (I think) you indicated you have a disassembler. What's the CPU doing ? Can you just start up power, and capture whatever might be running, or looping, after a few seconds to start up ?Say your analyzer holds a few hundred lines, disassembled. Randomly stopping, say, (for conversation) let's say you repeatedly see instruction runs in:(Hex). 0240 thru 041A h. Ok, the code runs there.Maybe also, you observe stuff running at:(Hex). 21B3 thru 347Dh. Ok, code going there...maybe an I/O routine up there.Maybe those two memory blocks are repeatedly executed, so a little repetition and you can at least establish some better guesses, especially if you have the uh (apologies if seems rude) Z-80 program code experience, to start recognizing things, in the runs of code.It's very difficult, to disassemble somebody else's code, but you can at least make good guesses if it's in timer code, or sending to the DAC etc. SOMEWHAT. But you aren't looking to grab the whole functionality.What if: Suppose you THEN go back to your working unit, and try to disassemble around the same hex address(es) that you observed, during the couple hours playing with the bad unit.Set the analyzer trigger, to capture some of the good code.With luck, and familiarity, you could break this

author: Midphase
author_rank: Regular Contributor
timestamp: September 20, 2025, 08:22:34 am
content: Quote from: pqass on September 20, 2025, 02:48:26 amI'm leaning toward doing exactly that. I have repaired many vintage synths, but this one really has me stumped. Thankfully I have this other one which is working, so that I can use it as a frame of reference for what I should be seeing on the scope.What I can definitely determine is that the Z80 is running code until it enters the Tune routine which happens about 1-2 seconds after powering up. At that point, the CPU just goes into some type of standby mode as if it's waiting for some information before moving on.In a way, the Sequential Engineers who thought it was a good idea to always force the instrument into a Tuning Routine upon power up probably didn't foresee how this could cause issues should a situation like the one I'm experiencing happen.I wonder if perhaps the 4051 multiplexers might be worth replacing since they are well known to fail. Could a failing multiplexer be causing this type of freeze?

author: Audiorepair
author_rank: Frequent Contributor
timestamp: September 20, 2025, 09:17:55 am
content: I also find the 4051 type multiplexers, and also the op-amps that buffer their outputs, are a common failure on old synths.So maybe that would indeed be a good place to start.Faulty op-amps usually have their outputs at a full rail voltage - any that show zero or lowish output voltages are most probably OK.I still suspect you fixed the broken Z80, something in the tune circuit is not working.

author: pqass
author_rank: Super Contributor
timestamp: September 20, 2025, 03:53:36 pm
content: Hear me out....Rather than debugging a running Z80, instead, swap-out the CPU entirely with a Teensy++! See:P600fw; Teensy++ based Sequential Circuits Prophet 600 firmware remake. Follow the first link to the github page."The Teensy++ required a few hardware mods to fill the Z80’s shoes, including cutting off a pin and adding a few jumper wires. We really like the fact thatno changes to the Prophet 600 itself are required."The new software will probably tell you what's failed during tuning. You might just like the new features too.

author: Midphase
author_rank: Regular Contributor
timestamp: September 20, 2025, 06:53:27 pm
content: Actually that was my original plan. I never wanted to deal with the whole Z80 in the first place...but this happened:https://github.com/gligli/p600fw/issues/117#issuecomment-3304423910It's a mess of a situation with the whole GliGli mod unfortunately.

author: RJSV
author_rank: Super Contributor
timestamp: September 21, 2025, 08:07:14 am
content: Well I did hear you out, man. I swear I'm tempted to go back, and delete my whole post.At the factory, we technicians always had the source code listings, and any other help from Engineering, including a Z-80 test panel that could halt, with button push, or a set-point to stop. Such as stop at 312D h. We also got training which, (oops, I'm gonna say it): we had to know in detail how to use Z-80 code, and how the whole micro-code memory and UART function together.Required, (oops, again) actually reading and study, of a book !Sorry, but I think you, maybe need to socket the whole world. Too bad you dislike actually dealing with the central controlling mechanism.Too difficult, or just that you haven't learned about micros, really, and have no interest, there.Only other advice I had, was that your working board PROM might have different code and addresses, so a program running comparison wouldn't compare, one to one. Plus, this shit-can, everything is suspect approach might be because of some voltage overload, or bad static discharge, frying a large portion of the board.Wouldn't hire your ass, in any capacity. Now go, do it your way, ignoring the main functional element, due to.....

author: Midphase
author_rank: Regular Contributor
timestamp: September 21, 2025, 08:18:18 am
content: Hey man, I appreciate your advice, but maybe tone down the attitude a hair?I know my lane, and I'd like to stay in it. I know very little about coding or analyzing what is coming out of a CPU, that is way above my pay grade...not that I have one since this is my hobby and I don't do it professionally, so that should relieve you from not wanting to hire me since you wouldn't be able to anyway.I have successfully repaired dozens of vintage synths from the 80's, the way I see it is that components tend to fail after 40+ years of abuse, and I try not to get involved into anything where I don't have access to replacement parts relatively easily.Believe me, I wish I could understand the jargon that you're throwing around, or that I had enough free time from my day job to spend days studying up on how a Z80 functions...but the reality is that swapping out components and using my scope to figure out what might be causing something not to work are my only resources right now. Maybe some day I will learn even how to use a logic analyzer and study how processors work, but at the moment I have the use the skills that I have access to, so you acting all indignant that I am not following your advice is not helpful, but as I said above, I do appreciate you trying.

author: Midphase
author_rank: Regular Contributor
timestamp: September 21, 2025, 08:27:48 am
content: Quote from: Audiorepair on September 20, 2025, 09:17:55 amI am starting to have some doubts about that actually. I scoped out all of the digital lines Pins 7 to 15 and the pulses don't quite look right to me on the scope. Instead of being clean square waves, the shape is rounded with a small bump at 200mV before the peak at around 3.6v.When I compare those to the digital lines of the Z80 on the working synth, on that unit the pulses are clean squares as I would expect.Could this be due to a failing decoupling capacitor? Or is it normal for the digital lines not to be perfect square pulses?

author: Audiorepair
author_rank: Frequent Contributor
timestamp: September 21, 2025, 08:57:35 am
content: I have a reasonable idea of how Z80s work, and I even wrote Z80 machine code for a project that sent MIDI.However, one thing I have learnt when trying to troubleshoot non functioning systems such as this, is that a scope is not really the right tool to do it.I think it tends to throw up a lot of false negatives and positives.I cannot trust my "findings" to be an accurate diagnosis of what is actually going on, especially as my head says "this should be happening, but it isn't, therefore its broken".I don't think broken micros actually behave like my head when running a program.So I think you can forget stuff like the waveforms don't quite look the same.I would be looking at stuff the scope IS good for.The tuning process should send a CV voltage to one of the oscillators, so you should be able to observe a VCO at the op-amp that sums the Audio1 - Audio6 signals that then goes to the tune Comparator.So the Comparator output should be the VCO frequency which goes to Fake Clock and then the circuitry measuring the frequency.Can you observe any VCO being commanded to produce a frequency in the first place?Something like a dead Audio1-6 summing op-amp would prevent any tuning taking place.Etc.Edit: In addition, the VCO's go through the VCA's, so they also have to be working/commanded to pass the VCO.So if there is a problem where the VCA voltage is absent (e.g. multiplexer dead) the tuning again won't work.Etc.

author: RJSV
author_rank: Super Contributor
timestamp: September 21, 2025, 09:08:26 am
content: Again, Put down that solder iron, and learn something new. The hours and hours you speculate could be just one hour of study.You try to 'make up' theories, of how a processor works, while mentioning how you are too busy to study.Rodney Zak's: The Z-80 was a good starting book.As to makeup speculation, a processor like that DOES NOT 'hang' when it doesn't get a proper value or condition...it just executes line after line. Might be better to say:'CPU might be hung up running in a loop.'Or, also: 'Stuck waiting' might also be better said as circling in a loop, due to waiting, while repeatedly re-checking...'.Instead of speculating. Processors aren't so sophisticated that they just 'STOP' out of sheer unhappiness....they repeat the check, maybe in a tight loop of 10 to 20 instructions, including a....wait for it ..a branch back instruction (jump), to repeat the failed test. You speculate like a detective, for hours and hours, then claim 'too busy, sorry, you shouldn't criticize my wasting a bunch people's time!'Now, I'm the bad guy, I guess.Anyway, later you could put together a question package, like 'Whats a good way to expand my skill, but not take excess time ?'If you can get hold of the instruction set, and a map of the registers, that's a good start, and might encourage buying a book or doing some on-line study, even just 45 minutes every Saturday. (Instead of soldering the world).Lots of more patient readers here would love to answer some 'Z-80' questions, especially with a title that contains 'Z-80 board'. (Maybe you could have said: circuit board repair, and not get these reactions)No Z-80 learning possible, I read,...(So back-off).Repair the, uh, circuit board, then. Can't help you past that 74138 suspect IC.

author: Midphase
author_rank: Regular Contributor
timestamp: September 21, 2025, 04:52:39 pm
content: Thank you both...really.I retitled the thread because it has evolved past just being a Z80 issue, and you're both right.First of all, there is a semantics problem since I am not very familiar with CPU's and how they function. You are right, it's probably not stuck or frozen but rather in some type of loop awaiting for some input that isn't coming.Regarding my usage of the oscilloscope in this repair, it's useful in the sense that although it might not be perfectly indicative of what is going on, it can be a good tool for comparing between the two synths that I have at my disposal.The whole desoldering/socketing, etc. -- there is a method to the madness as well...but you're right that I should put the iron down for a bit. Having said that, removing the IC's and running them through my logic tester has revealed so far 4 IC's that had apparently gone bad, so it wasn't a complete waste of effort.I think the whole thing that has thrown me down this loop with the Z80 has been the lack of seeing any output from the DAC71. The messed up thing is that for some brief instances yesterday I did see activity on Pin 21 of the DAC but it's not consistent.After last night, I fully agree with you -- there's a pretty good chance that the CPU board is just fine, and the Z80 is doing exactly what it should be doing (especially since I swapped out several Z80's that I have here and they all behave exactly the same).I think the issue is in the Voice boards somewhere, and it's probably not sending back audio for the tuning process to do what it needs to do. I will explore that today and see what is coming out (I suspect I will find no signal coming out of the VCA's).Sincerest thanks to both of you!

author: nfmax
author_rank: Super Contributor
timestamp: September 21, 2025, 06:36:51 pm
content: The voice board circuit diagram shows the DAC output is multiplexed to a battery of sample-and-hold circuits, to generate (presumably) the control voltages used elsewhere. That circuit will need to be refreshed periodically. Regardless of whether the DAC is 'working' or generating the correct voltages, you should see the analogue multiplexer channel control signals regularly scanning through each channel. Do you see any regular activity on these lines?I suspect the refresh is controlled by a timer interrupt. If you see no activity on the channel signals, check if the INT pin on the Z80 shows any signs of activity: it should go low (briefly) at regular intervals (20ms?). If not, then the Z80 is probably stuck in its idle loop, waiting for something to happen. Compare with the working synth and look for differences in this area.

author: RJSV
author_rank: Super Contributor
timestamp: September 21, 2025, 08:29:52 pm
content: By the way, (and thanks for your patience with my smarty-pants crits!), friends can get nasty, with each other, but then dinner time comes and they often just take off their hats, and get along fine, through the evening."It's just words!", some older friend had said, when two of our group were quarreling. (That person, R.I.P. is a world known name, and knew how to manage groups of employees.)Stupid quarreling, hope that's over, now. Thank you for your thoughts on the details, (and you can also send PM s with questions. That is, Personal Message).

author: Audiorepair
author_rank: Frequent Contributor
timestamp: September 22, 2025, 07:52:18 am
content: Actually the VCA's I mention are actually combined VCA/VCF chips, the CEM3372.So the VCO signals have to pass through everything to get to the Tune circuit, they are taken from pretty much the main audio output of the synth, so everything has to work.I am more familiar with the Prophet 5, where the tuning is taken directly from just the VCO's themselves.But that means you could take an audio feed from the summing op-amp, and you should be able to hear any tuning attempt going on, which might be interesting.The Final VCA is turned off during tuning, so you can't monitor from the audio out, unfortunately.

author: pqass
author_rank: Super Contributor
timestamp: September 22, 2025, 04:08:49 pm
content: I'm confident you'll be able to solve the problem(s) with this synth as the only hard to obtain parts are the DAC and the 3340, 3372, 3360 analog chips. The rest are old CMOS logic and 8-bit microcomputer parts.You should be able to test BOARD 4 (voices) in isolation; away from BOARD 3 (CPU). See theTechnical Manualfor all references below.STEP 1:Add pins/sockets to all TB401, TB402, TB403, TB404, P401 interconnects. eg. 0.1" pitch headers/sockets but for P401 skip every other pin (looks to be 0.2" pitch).STEP 2:Connect the power supply to TB401 (all pins) and TB404 pin 8. You can bring these (GND/0V, +15V, -5V, -15V, +5V) voltages over from BOARD 3 while keeping all other wires isolated/disconnected from BOARD 3.STEP 3:Bring all wires from TB402, TB403, TB404 to a breadboard (including GND/0V and +5V). Connect 10K pullup resistors to all digital inputs on TB402 and TB403. Connect 10K pulldown resistors to all digital inputs on TB404. This assures that all inputs are in an idle state and aren't flapping around in the breeze causing oscillations and odd behaviours. Connect J402 (AUDIO OUT) to an amplifier+speaker with adjustable volume on low to start.STEP 4:Proceed to experiment by applying GND/0V to inputs with pullups or +5V to inputs with pulldowns to change their state.Try the following tests:(a)To verify the DAC output, connect a voltmeter to GND and U414 pin 6 (VDAC). Connecting a TB402 input pin to GND flips that bit to 1 on the DAC so a grounded pin 14 (MSB) means the DAC input is 10000000000000 binary (2000 hex or 8192 decimal) which should produce a mid-point voltage (+2.5V?) on VDAC. Whereas no TB402 input pins connected to GND should produce the lowest voltage (0V?) and all TB402 input pins grounded should produce the highest voltage (+5V?) on VDAC. Q:How do I know VDAC voltage is between 0V and +5V? A:because all MUX supplies have Vss=Vee=GND and Vdd=+5V.Measuring DAC pin 21 should always yield 0V because it is the"virtual ground"of the U414 opamp (ie. should always match pin 3, which is on GND). The DAC doesn't output a voltage but a current like some of the 3340 & 3372 pins (be wary of this, look at the datasheet).(b)Once you've confirmed the DAC (at VDAC) can produce a voltage that corresponds to the input bit pattern, try to direct that voltage to a MUX pin output. Ground the ABC inputs (TB403 pins 1,2,3) and only one of the enables (TB403 pins 4,5,6,7). This will direct the VDAC voltage to the first output (pin 13) of the enabled MUX. You should measure the same VDAC voltage on pin 13 and the output buffer pin 7 or 1. Repeat for all MUX ouputs to verify that both MUXs and buffers are working.If you now remove the grounded TB403 inputs, letting all MUX outputs be disabled, then the last VDAC voltage should still remain on the buffer input (pin 5 or 3) and output (pin 7 or 1) due to the voltage still present on the input cap. Although, this may slowly discharge over time (I don't know how long) but if you measure on the output pin (pin 7 or 1) the voltage should last longer since your multimeter will drain the cap faster if the cap is measured directly.(c)Because the buffer input caps slowly discharge over time, if not constantly topped-up you will find it difficult to manually select a DAC voltage via TB402 and direct it to a MUX output via TB403. However, we can bypass this usual procedure by keeping all MUX outputs off (not connecting any TB403 inputs to GND; letting the pullups do their job) then injecting a 0V to 5V signal (through a 330ohm current limiting resistor) directly at a disabled MUX output (pins 13,14,15,12,1,5,2,4).So to turn on the first voice, attach temporary jumper wires to the following pins: U415 pin 13 (OSC 1A), U416 pin 1 (FIL 1), U417 pin 15 (AMP 1), U418 pin 14 (VOL A CV), U418 pin 15 (VOL B CV), U418 pin 12 (M VOL CV), U418 pin 1 (PW A CV), U418 pin 2 (RES CV), and U418 pin 4 (PW B CV). You can terminate the wires on a breadboard then using a single +2.5V (through a 330ohm current limiting resistor) touch all wires in succession, or even have a 10K pot wiper controlling some wires directly (pot fixed pins on 0V and +5V). Be sure to connect TB404 pin 1 (Asaw) and pin 4 (Bsaw) to +5V to enable sawtooth wave.(d)Once you've successfully produced a single tone on one voice, you can verify that the TUNE COMPARATOR is working by checking its output TB403 pin 9. Be sure to add a 10k pullup resistor to +5V on TB403 pin 9 then confirm with an oscilloscope that you see a square wave with same frequency as the one at U467 pin 7.(e)To test the ADC COMPARATOR add a 10k pullup resistor to +5V on P403 pin 10, ground TB402 pin 14 (MSB) to dial-in a half-way voltage on the DAC, apply a variable voltage (0V to +5V) on P401 pin 2, then confirm with an oscilloscope that the comparator is emitting +5V when the variable voltage is above 2.5V or emits 0V when the variable voltage is below 2.5V.PIN SUMMARY:TB401 pins 1,2: GND/0V power supply inputTB401 pins 3,4: +15V power supply inputTB401 pins 5,6: -5V power supply inputTB401 pin 7: -15V power supply inputTB402 pins 1-14: DAC digital inputs (pin 1=LSB, pin 14=MSB), value is inverted before DACTB403 pins 1,2,3: MUXs ABC address digital inputsTB403 pin 4: MUX0 enable digital inputTB403 pin 5: MUX1 enable digital inputTB403 pin 6: MUX2 enable digital inputTB403 pin 7: MUX3 enable digital inputTB403 pin 8: -15V power supply inputTB403 pin 9: TUNE CPR open-collector digital outputTB403 pin 10: ADC CPR open-collector digital outputTB404 pin 1: Asaw enable digital inputTB404 pin 2: Atri enable digital inputTB404 pin 3: SYNC enable digital inputTB404 pin 4: Bsaw enable digital inputTB404 pin 5: Btri enable digital inputTB404 pin 6: PMOD FA enable digital inputTB404 pin 7: PMOD FIL enable digital inputTB404 pin 8: +5V power supply inputP401 pin 1: GND/0V power supply output (to BOARD 1)P401 pin 2: Vmux analog input (range 0V to +5V from front-panel pots)P401 pin 3: no connectionP401 pin 4: -15V power supply output (to BOARD 1)..where all "digital inputs" are CMOS-compatible (0V or +5V) logic levels..where all "open-collector digital output" are 0V or left floating (BOARD 3 has pullup resistor to +5V)If someone wants to have a crack at ROM disassemblyhere is the ROM image. I've SHA1 verified that ROM image againstthis MAME pagebut wasn't able to boot it in MAME.I've attached my disassembled output. See the memory and io map in thecomments here.I know that @Midphase isn't probably up to it but my preference would be to temporarily replace the ROM with a monitor program that would allow me to upload code (via serial console) to run diagnostics on the voice board (all the steps above).

author: fenugrec
author_rank: Frequent Contributor
timestamp: September 22, 2025, 08:00:37 pm
content: Nice, looks like you are in good hands here. Too bad you don't have a logic analyzer to see exactly where/what the z80 is waiting for.Out of temporary interest, I loaded your ROM in ghidra. Finding e.g. the writes to DAC mmio writes is trivial - navigate to address 0x4000-4001, follow the cross-refs. One could probably figure out what triggers the "tuning mode" mentioned earlier. And/or follow the reset code and try to find how far it makes it.Attached is a ghidra project file with basic mem maps and disasm (change extension to .gar), should be a good start for anyone with even basic z80 knowledge.Some samples :Code:Reset vector:{byte *puVar1;setInterruptMode(0x1);puVar1 = &BYTE_ram_2000;do {do {*puVar1 = 0x0;puVar1 = puVar1 + 0x1;} while ((char)puVar1 != -0xc);} while ((char)((ushort)puVar1 >> 0x8) != '!');pit8253_3 = 0x30;pit8253_3 = 0x70;pit8253_3 = 0xb2;Code:Some random code writing to the DAC regs:DAT_ram_4000 = 0x3e;bVar3 = 0x20;bVar2 = 0x20;do {bVar2 = bVar3 | bVar2;DAT_ram_4001 = bVar2;bVar1 = DAT_io_0009;if ((bVar1 & 0x8) == 0x0) {bVar2 = bVar2 ^ bVar3;}bVar1 = bVar3 & 0x1;bVar3 = bVar3 >> 0x1 | bVar1 << 0x7;} while (bVar1 == 0x0);DAT_ram_4000 = 0xbf;bVar2 = DAT_io_0009;