Hi.

Newbie to pinside!

I recently purchased a very nice Paragon but the sound is a bit off. It generates the music but seems to add extra sequences of notes.

All the boards seem correct. The soundboard prom has no code or sticker on it, but it sounds good... just some wrong notes. Sustain doesn't affect it.

I've searched various forums and can't seem to find any postings with something similar for Paragon, (or Harlem Globe-trotters or Dolly Parton). I've ordered a new prom for the sound board but think it likely may not fix it from stuff I've read so far.

From what I've read it doesn't sound like the prom holds the tunes...simple notes or short tunes sound ok. Longer ones seem to have extra notes. Startup and end of game has extra stuff. The score drain sequence doesn't have the increasing pitch that's typical... jumps to lots of different notes.

If I'm getting more notes than I should I think that's pointing to other stuff... thinking:

Stuck or shorted address bits?
Clocking through too many, or wrong locations in memory?

Anyone seen (or rather heard) that before?

Thanks!

Stephen

Thanks Peter,

Do you know if those chips (quad latches) are locking in a single byte from the mpu and U3 has stored what that tune is and spits out the series of notes... or the mpu sends each of the notes one at a time and U2 latches each one in.

If it's just one byte I can probably check signals without a scope to see what gets latched in. If it's a whole series of notes that come through it'll be harder to check. I want to avoid soldering until I'm sure which chip is bad...might not have the luxury though.

Thanks for your input, it seems like that would fit the symptoms.

Stephen

I don't have a scope... just multimeter. Miniscope now on my Christmas list!

No nothing on the chip... assume it was originally a sticker that dried up and fell off, or as suggested someone changed it in the past with the wrong chip.

Expecting the correct prom in the mail next week. Hoping that's it. If not I'll start checking address lines etc... there's a nice table in the Bally repair guide that has the expected u3 outputs for each set of inputs.

Will also do a visual check on the paths to see if any traces or soldering looks broken or shorted.

Thanks for the additional information... more facts lead to solutions!

Stephen

If there a table "out there" that has the correct U3 outputs for the Paragon, globe-trotters, Dolly Parton prom?

Stephen

Ok... new u3 prom received and tried out... no change. Bummer.

Used a logic probe to trace some signals. Found that u1 pin 15 (inverter output into u3) seems to be stuck low, not toggling... but not shorted to ground either.

Cut the leads to u1 14 and 15 and ran the signal through one of the spare inverters on u8 instead... same chip type but not all the inverters are used. Cheap fix without removing u1.

But u8 inverter output also doesn't toggle.

The node isn't shorted to ground.

I pulled U3 and the node still doesn't toggle... but does the same thing with two different proms anyway so not likely a u3 input.

Thoughts:
That one signal just happens to go through jumper B stuff with Jumper A potentially shorting it to ground... but everything looks connected ok. Coincidence?

The node may be stuck with another bit or signal? But others are toggling... not stuck.

U3 socket is shorting it? Or not connecting it? Will a node not be driven if it is floating... or has no input to another device?

The node has too much capacitance and can't be driven?

U2 output appears to be toggling with logic probe but signal is actually too low to trigger the inverter?

Any other ideas?

I hate doing it but I may bend the u3 pin out of the socket and try driving it directly instead of through pcb path and socket.

Open to suggestions.

Stephen

sidebar question... these circuit boards are old enough that they are only dual layer correct? There are no inter-layer ground planes that would make it possible for a via to potentially short to a ground plane? Just asking to get that off the table. Thx.

yup... already confirm most of those with logic probe (good investment!):
1) all header pins toggle
2) all inputs to U2's toggle
3) all outputs from U2 / inputs to U1's toggle
4) Outputs from U1 all toggle, except for pin 15

(What I cannot tell for 1-4 above with just a logic probe is if there is any cross talk between signals, or they're stuck together. The "ditty" that the logic probe chimes does sound a bit different for each signal so I'm assuming they are not at this point.. would need a real scope to see that level of detail).

Thinking that inverter (U2/Q3) was toasted, and not having another 4042, I ran it through an unused inverter on the U8 chip (same 4042) ... but again it's output doesn't toggle either.

I'm good for the schematic drawings. I'll check the Dolly Parton manual to see if it's any better than what I have. I have what you copy/pasted in your subsequent post.

Thanks!

How is U8 being used differently that I cannot use the Inverter's not already in use? It doesn't look like the unused inverters are tied off anywhere... You referred to them as 4042 and 4049... on my board they are exactly the same chip (I'll need to check at home what the specific number is... both motorola, same chip number and suffix). None of this stuff are tri-state devices are they?

never mind.... found it (Note 3). No power or ground.

pasted_image (resized).png

... you beat me by a minute . Looks like the smoking gun. Also the fact that in running it through U8 I get what appears to be the same behaviour as through U1, sort of implies that Q3 on U1 ain't got no power. Off to Radio Shack! Hopefully someone in Ottawa (only two real electronics shops) has that chip so I don't gotta get it online.

Thanks!

....afterthought.. If U2 pin 1 is the non-inverted output, can I connect it directly to U3 to see if it works, or as a permanent solution?... does the extra inverter just give more power to the signal? Would it be worth testing, instead of a permanent solution, or is U2 just not strong enough to drive U3 without the inverter?

U2 is OK... it's the inverter/buffer that's toasted (U1 pin 15). I'll use a test clip to U2 pin one, and connect it to the input to U3 pin 13... see if that fixes my sound.... if it does, then it confirms my only problem is U1. (I don't like reworking chips until it's my very last choice... soldering skills ain't like they used to be).

I tried taking the U2 non-inverted signal and applying it directly to the U3 input, but that didn't work. Assuming it's not strong enough to drive it. With no connection the u3 input floats... chime is mostly high pitched tones. With the non-inverted signal applied it sounds the same as I had it before... it adds some low pitched frequency to the tone but is still incorrect... essentially it acts the same as a stuck low input so I'm assuming the non-inverted signal is not strong enough to drive high (which is why the U1 buffers are there in the first place).

With signals cut now I can tie the u3 input to 5v... mostly high pitched tones, or tied it to ground... adds some low pitched tones.

Essentially from your table I'm really only getting half of the tones available to use since I can only have one of the input bits (pin 13 or "D") either high or low all the time. So the card will play a tune for an event (like drain sequence) with only 16 of the 32 possible notes... it sounds sort of correct because it's still using Paragon notes... but mixing up or playing the wrong notes for a specific event because it doesn't have all of the 32 notes to work with. Sounds ok to everyone else because they don't know what it's supposed to sound like... but I remember!!!

Contacting a local pinball fixit guy to see if he has the chip... he had components for me before to fix a display transistor.

Hoping I'm near the end of this cause I just want to hear the correct paragon ditties!

Getting old... thinking of ways to test what's bad, and do workarounds, and put barnacles for quick fixes... but never thought to just swap the two chips.

Soldering skills and tools ain't great... working with squishy bulb solder sucker and solder wicking mesh. If my local guy has the chip I'll get it from him. If not, and local electronics shops don't have an equivalent, I may give it a try.

Thanks for the idea!

U1 4049 replaced (now socketed) but still the same. Argh! Did a bit more forensics including directly connecting u1pin15 to u3 with flying leads outside the sockets in case there was anything with the tracks... no go. So running out of options ... if U1 is good even though the output doesn't toggle then it goes back to U2 4042... which was toggling... or so I thought.

Logic probed it again, but noticed this time that although the hi indicator was flashing, making me think it was toggling, the lo indicator wasn't actually flashing when the hi was off. Checked other signals and the hi/lo indicators always complement each other... as they should. Debugging skills and observation getting old, and I haven't worked with logic probes before anyway. A single flashing hi does NOT mean the signal is toggling.

So u2 pin 15 can drive hi but not lo, and then u1 inverter just stays low all the time. Waiting for some 4042's now. Maybe fixed next weekend!

Moral of the story... measure twice and cut once. Know your logic probe... I should have noticed the difference between how the signals were "toggling" differently last week.

Btw... soldering skills not too bad... desoldering skills suck... gave up and cut off the ic and worked out the legs one at a time. No way I could have swapped U1 with U8 without wrecking them both... and it would have been for nothing anyway. Learning the hard way

OK...getting the end of my patience (and options). 4042 parts received. Replaced and socketted U2. It's working great... all signals toggling. But dang it... the sound is still wonky. Most of the playfield sounds seem correct from what I remember... Paragon Saucer, Waterfall, Valley of Demons dropdowns... but what I distinctly remember about Paragon was the increasing pitch of the drain cycle when you had a high score.... with a really high score, you'd think the pin was going to blow through the roof... am I remembering incorrectly, or is that the way it's supposed to sound? So far I've replaced U3, U2, and U1, reflowed the header pins... I've just gone through checking all of the signals to and from the downcounters (U4,U5), and everything seems to be connected correctly, no shorts between lines, no stuck bits... everything toggles. Gah!

I've uploaded a video of the drain sequence for a high score on my machine.

Anyone got any more ideas based on the drain sequence?
- harness rewired in the past, and data bits from MPU swapped? (checked that and seems correct)
- crosstalk between data bits in harness? (not sure how I'd test that)
- signals stuck together somewhere on the circuit board? (really sure I checked all those)
- U4/U5 downcounters not working correctly?
- something in the analog path... but that doesn't seem to address the symptoms... really just seems to be playing the wrong notes.
- MPU proms wonky?
- please don't tell me the two sound control bits affect this ?

In the end, it still sounds pretty good, and no one really knows the difference except me... am I being too picky?

Thanks everyone!

'Zactly! Now what? I'm assuming the tones played are incorrect ... like possibly the data bits are mixed up or cross talk.

If it makes a difference, the machine was retrofit with a Twobits Dash35 MPU... are there any known issues with bus bits being swapped or needing to be configured? I haven't really looked at the mpu.

Checked the fifth data bit... good all the way through to u3. Rats.

Any recommendations on how to check the down counters? U4 and u5? I don't want to just replace ic's just to see if it helps.

I usually put it in sound test mode...haven't tried it with the actual draining, but I can. I checked toggling on u4 and u5, and but not u11 yet. Will check them all again including the dc levels shown on the diagram. Not really expecting any surprises though... assuming they're all toggling since it's making sounds... just not the correct ones. U4 or u5 may not be downcounting correctly and still be toggling on a logic probe... I can check intermediate bits too that have n/c to see if any of them appear funny.

After reviewing diagrams again I was thinking now that I have u1 u2 and u3 socketed I can probably pull any one out and rig some wires up to drive data bits as I want and see how they flow... eg pull u3 out and put what I want as data to the down counters to get a single tone. Anyone test like that before? Not sure what keeps the tone going though. I'm assuming that in sound test mode that a4j4_10 is providing a signal to the analog circuit that will keep repeating whatever tone i select. My diagram isn't clear but it looks like there is a B jumper that brings that signal to c14 to generate a pulse into the analog stuff? or do I need to ping another signal to execute each time... I have the Bally testing manual so I'll review how they say to walk through but by bit testing.

Still struggling with the soundcard... I'll post a larger update with some questions later.

Thought I'd post this jpg though, of some calculations I did... wanted to figure out what frequencies were being generated for each of the 31 input data combinations. For each data input, U3 generates a number that U4 and U5 count down, and they put out a clock signal to U11 each time they count that many cycles. U11 then multiplies that "clock" by 2 and 8 (lowers the frequency). The two digital frequencies are modulated together through Resistor/Capacitor pairs to give an analog signal that goes to the analog circuit to pump the speaker (per the diagrams on the schematics). The MPU sends "notes" to the soundcard to play one at a time... each of the 31 data input combos is one note.

Based on the U1 clock signal feeding U4p6 being about 2 microseconds, I came up with the two frequencies that are modulated together for each input data. Frequencies generated range from 300hz to 5Khz... which is a nice range of stuff we can hear (and makes me think the math is correct). The "null" value (15) calculates to a frequency of 76Khz which we can't hear (or more likely since it's only counting "1" each time, the input to U11 may not actually be toggling... whatever). I think the math is correct... please let me know if you think something's incorrect or I'm totally out to lunch.

All good... except my Paragon is still playing the wrong notes . More later. Happy Friday.

soundcard (resized).JPG

350khz maps to 2.85microsecond timing... so looks good (schematic says 1.1microsec to 3.1microsec)... I generated my numbers based on 1.1 and 3.1 and then averaged to come up with my table.

What are you calling the "sound select signals"... the data input signals? J1,2,3,4,12... or the clock signal that latches them in? or something else? I've buzzed out the data signals and they look correct. Wondering if there's cross talk in the wiring harness though where insulation may have been rubbed away (some other wires have been taped up to insulate again). I think they're good though and don't seem to be stuck together (checked with multimeter).

I'll send more of an update later with some of my other findings, but I'm wondering if I'm getting sounds from the MPU talking to the Solenoid board over the same buss, and the soundcard is picking them up when it's not supposed to be.

yes... and on the MPU card the signals are in the opposite order on the connector J4: A=4, B=3, C=2, D=1 (and E is on J1_7)

Solenoids firing out of order would be a clue too.

Solenoids seem to fire OK while playing... only one is goofy (I'll put in a separate post later). When ball goes into Golden Cliffs the CoinLockout relay gets temporarily activated (or de-activated... I hear it switching... will check again). Was saving that for another post, but could be related. I haven't run the solenoid test check to see if they are hitting the correct order... will try that... good tip. thx!

Weird... but works for me... one less thing to investigate.

kewl... you mentioned emulator... is this from the PROM code? Are there text files with the prom code? It's been a very very long time, but it may be fun someday to look at the code and figure out all that it's doing. Machine code! ooo yeah!

Given the Hexidecimal I'll need to convert that to the 5 bit binary for each... which bits become the A,B,C,D,E signals? LSB and MSB?

12 becomes 16+2=18 = 10100... are A and C high, or C and E?

Based on my table, it looks like they're increasing in frequency like I remember... although I thought the frequency only got higher if you had a high score...Is this sequence only if you drain all the way from 49K and there's a different sequence at lower amounts... ie... if you only had 09K.... would it also drain with the sequence starting with OA... or would it use one of the other sequences? or the higher the score you get, it actually starts at a lower frequency but always finishes at the same high frequencies?

The counting is slow enough that I should probably be able to pick out where in the sequence it's not increasing in pitch in the correct order... see if there's a pattern.

Unfortunately, no oscilloscope to look at signals... just multimeter and logic probe (but you can do lots with them)... I may have a neighbour who's even more of a techno-geek than me... i'll see if he has a scope.

Do you also have the sequence for the Test chime that repeats in test mode? Probably too fast for me to follow anyway.

How do the bonus multipliers affect it... it sounds like for 5X it's doing something like this:

49k: 00, 00, 00, 00, 00, 02, 02,02,02,02, 04, 04, 04, 04, 04, 05, 05, 05, 05, 05, 07, ... is that correct?

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 .