Sorry for late response... topics page wasn't really clear that new posts were added.

Thanks for all the input Quench. I'll leverage the information if I can.

I'm trying to avoid shotgun approach for several reasons... it still works very good... only sux for me because I know how it's supposed to sound like...don't want to bust it worse. Soldering skills getting better but still not great... old boards ... some pads lifting when desoldering. Chips not readily available so I'm ordering stuff and waiting for it in the mail... make the fix but doesn't get it.

So far it's getting personal and i just want to nail it instead of bailing on the fix. But I'm almost ready to buy a brand new aftermarket one instead of mucking around with it more but I'm not convinced it's the soundcard. I don't want to drop another $100 bucks for a card just to find out the card is ok and something is wrong with the mpu. Would really like to try the card in another system to be sure its the soundboard.

Is there anyone in the Ottawa area with either a Paragon, Harlem Globetrotters, or Dolly Parton who would be willing to plug it into their system... I really don't see any risk to damaging the mpu with it. There could be a beer in it for you

... also could be in the analog circuits... not sure how it could affect tone, but my digital knowledge is better than my analog. Given that it's making sounds I don't think it's analog stuff, but I could be wrong. Looks like mostly op amp stuff to control sustain and drive the speaker levels. Could stuff in the analog circuit affect sequence or tone played? Does sustain just control how long the tone lasts or could it be on "too long" and pick up data/tones off the bus that it shouldn't, or affect the frequency that's fed into the analog circuit?

OK... at a computer instead of iphone, so can type a bit more... here are some other anomalies that I've found in debugging. I'll put in separate posts.

Following the Ball Repair Procedures ... Third Revision F.O 560-2. For debugging the sound card. On page 65.
1) 5V and 12V power levels good at test points
2) 0.8 VDC at R3/R5 is correct.
and from the Schematic, I'm seeing 2VDC at the outputs of U11 pin 11 and pin 9. This makes me think U11 is probably working OK.
3) Audio Amplifier Check. Says that I should see 2VDC at U9 pin 2 but I'm getting 6 volts. I'm going to measure a few more things around the op amps to see if the resistors are still correct value and the sustain rheostat is the correct resistance.

Sweeping the sustain does seem to have a minor effect on the duration of the tones, like I would expect it to, but nothing extraordinary like changing the tone itself.

If the Op Amp or surrounding circuitry is out of whack can that affect the tone frequency itself? I expect all that circuitry is just amplification and DC levels, and wouldn't affect tone frequency; and if it does, why some tones and not others?

Any ideas on why U9 pin 2 would be 6V instead of 2V, and would it be OK if it was?

Separate post follows...

...Following the Ball Repair Procedures ... Third Revision F.O 560-2. For debugging the sound card. On page 67... on clocking in data to drive U3.

Repair guide indicates "momentarily connect 5V to U2 pin 5 (clock) which should clock in a null on the address line". Page 70 item 3) also indicates the same thing... clock in data with 5V on U2 pin 5. This seems to imply that the signal should be sitting at low, and pulses high to lock in a data for tone.

However, the datasheet for U2 indicates that if P input (pin6) is HI (and it's tied to 5V in the schematic), then you need a negative pulse to latch in the data. The guide sort if implies the opposite; that the Clock signal should be sitting at low, and you pulse it with a HI 5V signal to latch in data. I've checked signals and U2P6 ("P") is tied high as per the schematic, and CLK pin 5 idles at 5volts and does toggle when a tone is played (so I'm assuming it's toggling low, then high again).... Also, the same signal goes to U7 to generate the pulse into the analog circuit, which also appears to be set up to expect a Low pulse to generate a sound pulse.

Based on the circuitry then, it looks like the Clock or data latching line is supposed to be high and pulse low to both lock in a tone data, and trigger the pulse to the analog circuit. This seems contrary to the repair guide which is saying I should pulse it high to latch in stuff.

Any thoughts or prior experience? Is that version of the guide incorrect? Was it for a different version of the Sound Card? Does anyone have a different version of the repair guide that gives different instructions to latch in data?

That's what seems wrong to me... the idle state of the select line seems to be high instead of low. Makes me think MPU has issues or inverted signal. Using a two bits dash 32 mpu. Wondering if they have that signal inverted compared to original. Solenoids seem to work correctly though. I'll check again. Already replaced U2 and U1 and swapped U3 prom... and all lines are not stuck or tied to each other. not much digital left to work through.

Q3 seems to be OK, inverting Address E signal before sending to U3.

So far I've replaced

U3 Prom (no change - part was not bad)
U2 latch (no change - part was not bad, was actually U1 signal to it)
U1 Inverting buffer (confirmed there was a bad inverter... stabilized tones but still incorrect)

Right now I'm debugging the draining tone sequence. Set up for 49K with a 5X bonus.
Recorded with an iPhone, and then can slow it down and follow the sequence to see when tones are increasing or decreasing in frequency.
Data you provided is very helpful.
Tones increase in a sequence of 8, then drop down and start again for another 8 tones but starting at a slightly higher frequency.
Confirmed that for the big drops after an 8 tone sequence, the frequency drops correctly.
However intermediate tones in an 8 tone sequence don't all increase.
Working out which ones decrease instead of increase, and will work backwards to see which tones / hex / bits are suspect.

In the drain sequence, the first three tones are
__________D 12345678
00 downcount 11100010 (226 clock cycles)
02 downcount 11010110 (214 clock cycles)
04 downcount 10111110 (190 clock cycles)

and are supposed to be increasing in frequency (less clock cycles for downcounters U4/U5 to count)

I find that 02 and 04 are actually lower frequencies than the first tone 00
This means that they need more than 226 clock cycles
The only way they could have more than 226 clock cycles is if bits D2 and D3 are 1 instead of zero

D1-D4 go to U5

I did some more logic probing around U4 and U5.
On both U4 and U5 pin 12 "0" are toggling - looks good
On U4 pin 1 is toggling (Q3 latch in the IC) which is the clock to U5 - looks good
On U4 pins 7, 9, and 15 are also toggling (not used, but are the outputs of the intermediate latches in the downcounter) - looks good
On U5 pins 1,7,9, and 15 are NOT consistently toggling as expected if the chip were downcounting correctly.
Depending on the tone/data any of those bits may toggle, or be either stuck high or stuck low.

Suspect that U5 is not downcounting correctly, but just resetting itself on each PE pulse to start the countdown again. Each latch captures the Data Input again, but then some don't count down. Some of the 4 latches may be working, but others blown. Unless I'm missing some facts, I think all of the intermediate latches should be toggling as the chip counts down.

Will order some MC 14526's and see what happens.

Can anyone confirm with a logic probe (or emulator?) that for both U4 and U5 pins 1,7,9 and 15 should all be toggling on both chips, and none of them stuck either high or low.

Thanks!

MC14526B (resized).JPG

... yes possible that 00 is too high, but
02 is lower than 00 (implying D3 is wrong)
04 is even lower than 02 instead of increasing again. (implying D2 is wrong, which would give it a higher number than 02)
05 10101010 and
07 10001111 both increase in frequency OK, but then
09 01111111 decreases in frequency again... again implying D1 is wrong... also U5
I went through the whole sequence, just flagging when tones that were supposed to increase in pitch, actually decreased.

02 is only used once
04 is incorrect both times it's used in the middle of a sequence
09 is incorrect each time it's used
0A 01111010 is incorrect each time it's used
0E 01011111 is incorrect both times it's used
10 01011010 is incorrect each time it's used
a couple others in the last sequence as well but it's hard to tell.

... I guess key outstanding question is:

Do U5 pins 1,7,9,15 consistently pulse for any tone data on the bus (the same way U4 pins 1,7,9,15 do).
If they do, then that's my next culprit.

Sorry... clarification. Not necessarily in test mode. At the end of any tone played the data stays on the bus and U4/U5 just keep looping their count, and U11 keeps providing its signal into the analog circuit. The note is not heard because u7 generates a pulse that decays to play the note.. clock signal both latches the data and generates the pulse to play the sound at the same time. The sound decays away but the counters keep on counting.

So my query was whether u5 pin 1,7,9,15 are pulsing after a single note is played and then ended. It's still counting the data over and over which should create a consistent pulse for a logic probe to pick up. Should be present on each of the 4 internal latches outputs (3 of which are not used)

... my logic probe has hi and lo indicators to show signals toggling but also has another light that will just flash if the signal toggles with a constant frequency ... for indicating clock like signals. With paragon in sound test mode the hi/lo lights toggle as the data changes, but the "pulsing" indicator will only come on for clock signals. After a note is played and silent again, the looping counters will create a constant pulse on several other signals (just because they're looping)...the counters and u11 output signals.

I took a look at the schematics again, and believe the following is happening.

U1 C and D inverters are connected up to provide a constant free running on board clock into U4. Per the notes there, that clock is somewhere between 1-3us or 1MHz-333Khz, depending on the tolerances of the resistors, capacitors, and IC.

U4 and U5 are connected as "cascaded" downcounters... U4 has the lower 4 bits, and U5 has the higher 4 bits. When U4 has counted down from whatever it started with, it's Q4 signal will clock one pulse into U5 to make it count down 1 more, U4 rolls over to 1111 again and starts counting again. So essentially the onboard clocks from U1 are clocking both U4 and U5 to count down the number provided from U3. (think of U4/U5 as one long IC).

U3 is actually much simpler than I originally thought. For each of the 32 possible input combinations on the Data bus, it simply puts out an 8 bit number on to the downcounters. The downcounters will then provide a single pulse to U11 each time the U4/U5 count down that number to zero. When that happens, the "0" signal is also fed back to the PE signals of U4/U5 which has them load the 8 bit data from U3 again, and it counts down the same number again. Depending on how big (low frequency) or small (high frequency) that number is, you get a different note.

I expect this is what is happening that results in U5 bits "not pulsing" during attract mode and after startup sequence. There is only one combination of data to U3 that provides all zeros to the upper 4 bits (ie. U5). That is for when the data input 15 or 0F hex. In that case, it's only providing a "1" to the counters: "0001" to U4 and "0000" to U5. In that case, U5 outputs will never toggle. The cascaded counters only need to count 1 pulse, then they reset themselves. This is what I expect is the "null" value whenever the game starts up, or the game over sequence (see in post 52 that the sequence ends with 0F). For any other data input / note played, there is an initial value going into at least one of the bits to U5, so you will see pulsing on it's outputs.

Because the U1 onboard clock is free running and not controlled by the MPU at all, there will always be something counting down on U4/U5 and feeding into U11 and then the analog circuit. The only reason you don't hear it, is because you also need a pulse into U7 that feeds a 12V signal through the analog circuit and picks up the frequency from the U11 on the way. I accidentally blew Q2 which controls the pulse generated by U7, so that U7 was providing a constant signal to the analog circuit. What happened is that depending on the note played (ending on 0F or something else), it would keep on playing that note until you hit something else. PITA... but helped me understand why I wasn't constantly hearing sound when U4/U5/U11 are always "on" and counting.

So... data is always clocking on U4/U5/U11... unless the input from the MPU is 0F which will provide no sound (or it's too high for us to hear), and for 0F you will also only see data clocking on U4 (Q4 pin 1 and "0" pin 12), since U5 is being fed 0000 and has nothing to count. What I have been doing is after the startup sequence, slide down the glass a bit, and push a few of the rollovers and bumpers at the top of the board to generate a note... whatever that note is, the data lingers on U4/U5/U11 to aid in testing them.

... sidebar...

It was also confusing to me that the U2 4042 datasheet indicates that whatever is on the ABCDE bus will constantly pass through to U3 and the down counters U4/U5/U11 and only latches it in when it gets a negative pulse edge on the clock. I would have expected that data is only latched in whenever the MPU wants to send a note to play. However again, this is simpler than I thought it to be... the sol/sound bus is only ever talking to one or the other (either the solenoids or the sound card), and by default it's talking to the sound card. The MPU doesn't "latch" the note it wants to play, it's actually latching that last note it was told to play, because it wants to talk to the solenoids (negative on Select line).... the select line toggling is not saying "play this note", it's saying "the next data is not a note, so don't play it, keep playing the prior note).

So by default, the ABCDE bus is always sending a note to the sound card until it wants to tell the solenoids to do something. We just don't hear it because either a) the "sound" played is the null value 0F or b) it still needs to wait for the toggle on the select line which also sends the 12v pulse from U7 through the analog portion of the circuit to actually play the note.

...I love the smell of napalm in the morning. It's the smell of...

VICTORY!

Nailed it. U5 was my final piece of the puzzle. All sounding the way it's supposed to.

For those of you who, in the future, skip to the end of the RESOLVED topics.

Big thanks to Quench, Barakandl, and Inkochnito for being constant readers and providing direction; as well as others who contributed.

This is applicable to Paragon, Dolly Parton, and Harlem Globetrotters that use the same soundcard and U3 prom, but also to other Bally pins that use the same soundcard with different proms.

Two IC's were defective:

U2 Latch
U5 DownCounter

Symptoms:
Sound card is working, but tone sequences sound partially incorrect depending on which notes get triggered.
Drain tone sequence in particular did not exhibit a progressively increasing series of notes (for Paragon)
Also tones were a little unstable and not repeatable, and affected by the logic probe when checking signals around U1/U2/U3

Debugging:

Check U2 latch outputs on the data path between the connector, and U1 and U3 with a logic probe, while playing the test tone sequence. U2 outputs should toggle solidly Hi/Lo with bright alternating colors. On the bad pin, the hi was a solid color, but the lows only flickered the lo indicator, and didn't reflect a solid bright low like other good signals on the chip. Also, adding the probe in the path sometimes affected the tone sequence played (either helped or hindered the low signals becoming more or less "lo"). The failed output (Q3bar pin 15) didn't toggle solidly, while it's non-inverted output (Q3 pin 1) did, as did the other outputs. Replacing the chip stabilized the tones played while in test mode, but didn't correct the actual notes played.

Check U4/U5 outputs with a logic probe that has an additional "pulsing" indicator to indicate that a repeatable signal (like a clock) is being seen. In play mode (not test sequence) triggering a sound (bumper or rollover) will leave the "note" playing on U4/U5/U11 even though you cannot hear it. U4 and U5 pins 1,7,9 and 15 should ALL be pulsing. (Quench actually told me this in an early post but I missed it and didn't check until much later). The note cannot be heard anymore because U7 provides a decaying pulse into the analog circuit that drives the note into the speaker. However after the note has been played, the downcounters keep repeating, so their outputs will look like periodic pulses to the logic probe. U4 pin 6 is the ClockIn which will be a fast pulse. U4 pin 12 sends pulses (slower than clock) into U11 when the downcounters complete a cycle, but will sound the same for any note played, even if it's incorrect. U4 and U5 pins 1,7,9 and 15 (Q1-Q4) are not connected, but are intermediate latches in the downcounters and should also be pulsing like a clock if the counters are working correctly. In my case, all of those pins on U4 were pulsing, but they were not pulsing on U5, some being either stuck hi or lo. This causes U4 to count either too fast or too slow. The final output still pulses and resets the counting sequence, however it has counted incorrectly so the overall note played is incorrect.

Other lessons learned:

Incorrectly replaced U3. Initial shot in the dark since it provides the tones to the rest of the circuit, and the sticker on it was missing so I didn't know which prom it was. However in hindsight the board itself had factory stickers indicating it was the correct version of the board, and all of the B/C jumpers and specific missing resistors and caps for that board variant were correct and didn't looked manually reworked; so no real reason to think the prom was incorrect.

Incorrectly changed U1, thinking that the input (from U2) was toggling correctly, but the U1 output was stuck low. Actually, the input was not toggling sufficiently low to trigger the inverter and the real problem was U2.

As noted above, in most cases the digital circuitry (U1,U2,U3,U4,U5,U11) are still actively playing the last note, even though you don't hear it, which helps debugging. (except if the prior tone sequence ended with the null note)

Data inputs A-D are applied to U3 as provided at the connector because they are inverted twice (ie. Hi on the connector is hi at U3)
Data input E is applied to U3 inverted from the signal at the connector, as it only goes through one inverter (Q3) (ie. Hi on the connector is Lo at U3)

U3 only stores "notes", not whole sequences of sounds. The MPU sends a series of notes that the soundcard plays one at a time. U3 is simply providing a number to count... the higher the number, the lower the frequency of the note played. One "note" is a null signal with a count of only 1 that is sometimes used to generated no tone at the end of a sequence. The counters will keep repeating just the last note played in the sequence, so triggering different sounds (rollover, bumper, etc...) will leave different data on U3 inputs/outputs to help debug... not as good as providing your own specific data, but still aids in debugging the flow of data signals (U1,U2,U3) and the outputs from the prom, and through the downcounters (U4/U5) and divider (U11)

U2 outputs on their own don't have sufficient drive for inputs to U3. The U1 inverting buffers are required to sufficiently drive U3 inputs, and they cannot be "bi-passed" by using the equivalent non-inverted output of U2.

Although U1 and U8 are the same chip, U8 is being used differently in the analog circuit and has no power to it. You cannot re-route signals through spare U8 inverters, in place of a blown U1 inverter.

The MPU shares the data bits A-D between the SoundCard and the Solenoid drivers. By default it is always talking to the SoundCard so U2 is configured to pass through all data to U3, and will only "latch" the last note played whenever the MPU wants to talk to the solenoids (when J4P10 "clock" toggles low).

It was a pita and a few months to fix but very satisfying to get it playing right again. Still working fine. Hope you’re able to find it. Very interesting to go through and figure out how it all worked... nothing at all like I thought, much simpler in fact.

Let us know if you get it or need some more help resolving .