Please reassure me that you got rid of the Atari gold-plated CPU and ROM sockets if the ICs weren't also gold plated. Had more than one of these have problems because of different metal combinations, almost all were Atari games. The Atari pinball that had this mix would flake out, but if the CPU was removed and reinserted it would run fine for 1-2 weeks then crap out again. The last time it died it turned on ALL the solenoids first (Atari can do this, unlike Bally). The solenoids shorted which overloaded the drivers, which then shorted. The high current blew the emitters open in the drivers, but the collector/base shorts then put the full solenoid power into the driver ICs. They blew and sent the power back into all the addressable latches, which passed it back into everything on the address and data busses. A full set of very expensive solenoids (some were rotary), about 22 ICs, and a full set of driver transistors later it was back running. The sockets got replaced and never caused another problem. Oddly enough the only things on the buss that DIDN'T blow were the ROMs and 6800. So PLEASE tell me you replaced the sockets so I don't start having nightmares again. John Robertson wrote:
I don't know if anyone else has had this happen, but I was fixing an Atari pinball MPU and my 6800 pod would give timeout errors and reboot the pod to the default display of "Fluke 9000 Ready".
Found a number of interesting causes - first the 6800 uses both phase 1 & 2 clocks, and phase 2 was noisy. Fixed that...
So far so good...still got the pod rebooting itself...strange. Unplugged the interconnect cable between the MPU and the Lamp/Audio AUX board and the pod worked perfectly (found additional faults on MPU RAM). Plugged the AUX cable back in - down went the pod. Even gave messages of self test etc flickeringly fast as the base would then reset. None of the lines connect directly to the address or data bus to the AUX board, but there is a filtered A1 and A2 that feed back to the CPU - weird, check the schematic! However if I put the AUX cable on sideways so not all contacts engage the board will work until I get near the A/1 end (the A1/2 are at the K end of the plug - long since connected) at which point the pod craps out again. Pull out scope. Check Audio output lines - they are noisy...find bad latch IC for one Address line for the Audio PROM. Now the board works fine with the AUX cable plugged in.
I believe the noisy Audio lines were cross-talking with the two address lines and this was enough to load down the CPU and shut it down.
Moral of the story? Don't assume that just because something isn't connected to the Address/DATA bus that it can't take the UUT down!
(UUT = Unit Under Test)
John :-#)#