Gott Sys80B MPU IRQ stuck high

Ok this is a long description of what I have done to isolate the problem of a Stuck high IRQ.

This Gottlieb System 80B MPU has become more than a problem. The IRQ is stuck high.

1. The 6502, and the three RIOTs, 6532 have been socketed and replaced. I added two sockets for two of the RIOTs. 6502 and one RIOT had existing sockets.

2. The IRQ remains stuck high. Continuity and shorts between pins were checked on the 6502 and three RIOTs with no problems found.

3. I then got out the logic probe and checked all selection circuit logic chips. I found one problem with Z4 an output pin 10 going to the 5101 RAM pin 17 CE2 and replaced Z4. The IRQ remained stuck high.

4. The 5101 was removed, and IRQ remained stuck high. The 5101 was replaced with new and tesedt chip, and the IRQ remained stuck high.

5. Since logic probe results can not always detect proper logic chip operation, I got out the Bugtrap (see below) and checked all of the logic chips and found no problems.

6. In desperation I changed Z7 and Z8 with no change in the IRQ –remained stuck high

7. Since Z36 was socketed by previous worked, I also replaced Z36. IRQ – remain stuck high

8. I repeated the Bugtrap testing with no faults found. Z10,Z12,Z5,Z8,Z9 et al.

9. I repeated the continuity tests on all of the replaced chips and checked for shorts and found no problems.

10. On a RIOT by RIOT basis I lifted pins 8,9,10,11,12,13,14,15,16,17,18,19,21,22,23,and 24. The IRQ remains stuck high with all RIOTs and pins lifted as previously noted.

11. I examined the clock circuit and all appears operating correctly. I measured the clock frequencys and all appears OK. The Bugtrap on Z3 shows not problem, but does interfere with the circuit operations. I haven't put a scope on the clock circuit.

12. All testing is done with GPE QUICKSCAN test unit operational with the board.

13. The Bugtrap 2974A is a logic chip comparator that matches the operation of the chip under test with a like chip mounted in the Bugtrap ziff socket.

14. Voltages at the chips are at 4.9VDC on the bench. Reset is not a problem.

15. I again checked continuity and chip operation with a logic probe and found no anomalies.

This is a nice clean board with no battery corrosion.

I am at a loss as to what to do next.

#3 6 years ago

MAR

MarAlb

Pinside member

Zeist

9y 53,650 814 19

When the IRQ line remains high it is usualy an indication the program isn't starting. I would check the selection signals for PROM1 (at the piggyback), address + databus signals from the 6502 CPU to the PROM1 socket.

I wrote a system80 testprogram which may give you some new insights. PM me if you would like to have it.

Marco

#4 6 years ago

GPE

G-P-E

Correct - a 6532 doesn't hold an IRQ high, it relies on a pull up resistor located at R1 to pull it high (which is obviously working). The 6532 only pulls the signal low and then releases it when the IRQ is cleared by the CPU. When bad - a RIOT often fails pulling IRQ low and holding it low.

"12. All testing is done with GPE QUICKSCAN test unit operational with the board."
Is the test fixture going all the way through testing and you get the complete "4", "5", "6", "1" sequence? Do you see the IRQ LED go green during each cycle of test? If not, it might not be activating the timers so they will appear to stay high.
What are you seeing on the LEDs and 7-segment display?

#5 6 years ago

UUG

minnesota13

Pinside+ Frequent

With power on the Quickscan is going all green, then holding red on the IRQ and a Zero in the display. Pressing the reset button has the same result. Then I would check the logic with the logic probe sometimes together with a logic pulser to verify correct gate operation. When using the Bugtrap I would power up and then hit reset on the Quickscan, then hit reset on the Bugtrap and repeat a few times.

#6 6 years ago

TOX

ChrisHibler

As mentioned above, the program must be running to enable interrupts.

Have you tested all 5 of the switch matrix ICs?
2x7400, 2x7404, 1x7432.
If one or more of those are toast, they can prevent the MPU from booting. I don't know how or why, but I've seen it many times. Just had a board with a failed 7400 (Z13 IIRC) that would make the QS80 do odd things. Marco's basic tests didn't indicate a problem.
--
Chris Hibler - CARGPB #31
http://ChrisHiblerPinball.com/contact/
http://www.PinWiki.com - The new place for pinball repair info

#7 6 years ago

GPE

G-P-E

OP
Quoted from minnesota13:
With power on the Quickscan is going all green, then holding red on the IRQ and a Zero in the display. Pressing the reset button has the same result. Then I would check the logic with the logic probe sometimes together with a logic pulser to verify correct gate operation. When using the Bugtrap I would power up and then hit reset on the Quickscan, then hit reset on the Bugtrap and repeat a few times.

The 7-segment display -- it isnt cycling through the very distinct "4", "5", "6", "1" sequence?
If not - as Chris said, the CPU isn't booting. A "zero" on the display would also indicate the CPU isn't running. If the CPU isn't booting then the RIOT IRQ signals are never turned on and you will see a logical high signal on these.

Chris -
Funking bizarre that a bad IC in the switch matrix will keep the CPU from booting - these are all on the "far side" of the 6532. Switch matrix is never touched in software until after other tests are completed. Unless one of the bad ICs are doing something weird to U4 which is then doing something weird to the 6502. That would be a very interesting thing to diagnose why this happens ... especially since I am working on new 6502 code this week.

#8 6 years ago

TOX

ChrisHibler

Quoted from G-P-E:
Funking bizarre that a bad IC in the switch matrix will keep the CPU from booting - these are all on the "far side" of the 6532. Switch matrix is never touched in software until after other tests are completed. Unless one of the bad ICs are doing something weird to U4 which is then doing something weird to the 6502. That would be a very interesting thing to diagnose why this happens ... especially since I am working on new 6502 code this week.

Agreed. Very bizarre. I used the same logic that you did and thought that unless that particular IC is gating memory/device addressing, then it shouldn't matter if they were there or no. I'll post a video of what I saw with the failed 7400. I can send you the 7400 too. I thought about that.
--
Chris Hibler - CARGPB #31
http://ChrisHiblerPinball.com/contact
http://www.PinWiki.com - The Place to go for Pinball Repair Info

#9 6 years ago

TOX

ChrisHibler

Here is a vid I shot just now.

After reviewing the QS80 documentation again it looks like the failed 7400, which is in the switch matrix return circuit, causes the QS80 to think that the enter button is being pressed and the sequence I'm observing are the subsequent QS80 tests.

Make sense?

--
Chris Hibler - CARGPB #31
http://ChrisHiblerPinball.com/contact/
http://www.PinWiki.com - The new place for pinball repair info

#10 6 years ago

GPE

G-P-E

OK -- figured it out, it's doing what it's told to do but not as expected. As you said - it it going through the subsequent tests. Bad Z14 was pulling one or more of U4's switch matrix inputs high so it sees the start switch as being pushed (Start = Proceed to next test).

First test:
"4", "5", "6", "1" -- main ICs check out fine.

Test fixture then checks the switch matrix. If Row 4, Column 7 shorted (Start switch pushed) -- it proceeds to test 2.
Test 2 displays "-2-" (dash then 2 then dash) and then steps through lamp control (LD) values ("1", "2", "4", "8"). Normally this would go 1,2,4,8 twelve times before restarting test 2 -- once per lamp strobe (DS) value. But after first set of lamp control values, it checks the start button to see if it should proceed to next test. If you had this board connected to VFDs then you would have seen the displays show test 2 and count off control and strobe values for displays.

At end of first LD set -- QS80 thinks start button is pushed so it goes to test 3 ("-3-") where it counts off test 3 steps.
Same to test 4, 5, 6, etc.

Tester was just getting into to the switch matrix test "-5-" when you shut it off. It showed "C77" which said Row 7. column 7 are shorted. Looked like it was getting to Row 6, 7 ... but that is when it got shut off. I'll bet if you put the bad 7400 back in there -- all column 7 switches would show up as closed. Maybe columns 4, 5 and 6 as well but wasn't enough of the video to show that.

I don't remember where the machine's 'test' button is on the matrix but I think he's also column 7. This controls how fast it steps through the tests. I'll bet it kept reading that button as closed and was going up and down with the speed of the testing as well.

Not having the VFD's hooked up makes that board a bit difficult to decypher but info is there. Next gen board adds 2nd display - bit easier but still easier if you have VFDs hooked up. I would love to put a simple USB port on this board to spit out real information but the amount of memory space available is way too small. Not enough space to fit the tests plus any text.

#11 6 years ago

UUG

minnesota13

Pinside+ Frequent

I have check all of the switch matrix TTL chips. I used the Bugtrap tester and found no problems.

I can't find any chip problems either by logic probe of Bugtrap. The 6502 has been replaced with a variety of replacements with no change. The RIOTs also have been replaced with a number of new and old chips. I ordered some new ones from Arcade chips and those are the currently installed chips.

I have checked multiple times for breaks in any of the circuit paths between the CPU and all of other chips and find no problems. I also checked for shorts and find none.

Now here's a weird thing I did find:
1. The 5101 had a bad socket leaving pin 1 as a no connect. Further I poorly inserted the 5101 into the bad socket leaving some pins, 1 or 2 outside of the bad socket on the left side.

2. Power on the board with quickscan attached, the results are reset low then high. IRQ red/green/red. Clock green.
Quickscan display zero.

3. If the logic probe is on pin 1 of Z8, then the CPU boots, display runs through the numbers and announces F1. A metallic touch by a very small screw driver didn't do the same thing, but only when the logic probe touched pin 1 would the cpu boot.
I tried Z8 pin4 and pin10 and couldn't get the same results.

4. I then noticed the bad job of inserting the 5101 and thought I found my problem. But nope it wasn't the problem. I checked and then found the socket wasn't gripping the 5101 pin 1 and I again though I found the problem. But it it didn't solve the problem.

I believe this board is cursed.

#12 6 years ago

GPE

G-P-E

The "F1" was pointing to 5101 problems. Your #3 is problematic. U5 enable seems to be held by pin 1 of Z8 and the probe is putting a small load on it. Bad Z8?

#13 6 years ago

UUG

minnesota13

Pinside+ Frequent

I have replaced Z8 . With the 5101 properly seating I can't reproduce the Z8 pin 1 logic probe thing. The 5101 is new and tested good in ram tester. I think I should give up on this board.

#14 6 years ago

---

ForceFlow

Pinside Moderator

9y 238K 31,381 268 15

OP
Quoted from minnesota13:
I have replaced Z8

Are you sure that it is a known good chip? I usually put it in a chip tester first to verify to make sure I'm not replacing one bad part with another.

#15 6 years ago

UUG

minnesota13

Pinside+ Frequent

I don't have a chip tester. The chip is new in this particular case. It is a 7402. It was tested with the Bugtrap comparator a couple of times with different 7402s as well as a 74ls02 with no anomalies showing. It was also tested with a logic probe in combination with a logic pulser to confirm proper function.

This board is enough to make a person crazy.

5 years later

#16 1 year ago

???

RobAquinas

Pinside member

Atlanta, GA

3y 20,900 53

minnesota13 did you ever find a solution? I am in a similar situation where I cannot figure out why IRQ is stuck high.

#17 1 year ago

TOX

ChrisHibler