Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!mips!daver!bungi.com!news From: ian@sibyl.eleceng.ua.oz.au Newsgroups: comp.sys.nsc.32k Subject: Re: Hardware Problems Message-ID: <9006121804.29038@munnari.oz.au> Date: 12 Jun 90 17:16:23 GMT References: <<9006101101.AA05461@wombat.bungi.COM>> Sender: news@daver.bungi.com Lines: 65 Approved: news@daver.bungi.com George Scolaro writes: > [In the message entitled "Re: Hardware Problems" on Jun 11, 1:20, ian@sibyl.eleceng.ua.oz.au writes:] > > > > Things have deteriorated! I can no longer talk to the serial port at > > all and the "stuck" state is now quite reproducable. What happens is > > As John Connin mentioned, have you ensured that the 32532 is fully seated > in it's socket. I think so. > There are 4 pins (near each corner of the chip) which have > small rings that should seat all the way flush with the socket. I can't see any rings on *my* 32532. However, I used the method you suggested and applied a *lot* of force -- my full weight which is 95kg. I am unwilling to use any more force than that! To quantify, there is a .6 - .7 mm gap between the ceramic of the pc532 and the top of the socket (I measured with feeler gauges)! This is the same or slightly less than the gap for the 32381. > (if you ever have to extract the 32532 > you will discover the wonders of splintering ceramic - unless you have a > PGA chip extractor!). I shudder to think. The thought crossed my mind as I pushed it in that I hope I never have to extract it! It does beg the question, what use is a socket that you can only plug in once to? I attempted to verify the PALS. Well it turns out that I can verify PALs but not GALs (which most of them in fact are). So I blew a new decoder PAL and plugged it in. Lo and behold it worked! Being the suspicious sort, I plugged the original back in and it still worked! Strange. While it was working I deliberatly got it into the "idlew" state by accessing location 3800 0000 with the rom monitors dump and set commands. Sure enough it ground to a halt. It then takes *two* resets to get the prompt back. Can you please check this? It was quite repeatable. Clearly I hadn't actually fixed anything but maybe there was an intermittent dry joint near the socket, so I pulled the board out, and resoldered that socket. Now it doesn't work again in exactly the same way as before and with either PAL. Poking around the decoder PAL reveals a strange anomaly. /ioinh is permanantly high and yet I get pulses out of /icu. This, according to the PAL equations, is impossible! The only explanation I can think of is that there *are* pulses on /ioinh which are two short for the logic probe and which get stretched going through the PAL. This still doesn't seem very likely, the probe detects pulses on bclk and /bclk perfectly well. I also thought that maybe there was a bad connection to the 532 on that pin. However, removing the DEC32 PAL shows that the /ioinh pin is still high. The only explanation for that is that the 532 is driving it that way! When should the 32532 assert /ioinh? My reading of the manual implies that it should get asserted for every bus read. Is there anything which can prevent /ioinh being asserted? Note that the CPU is active with address lines waggling up and down and /conf waggling up and down. As Alice said "curiouser and curiouser". Ian Dall.