Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!mips!daver!bungi.com!news From: gs@vw25.chips.com (George Scolaro) Newsgroups: comp.sys.nsc.32k Subject: Re: Hardware Problems Message-ID: Date: 13 Jun 90 00:21:32 GMT Sender: news@daver.bungi.com Lines: 82 Approved: news@daver.bungi.com [In the message entitled "Re: Hardware Problems" on Jun 13, 3:16, ian@sibyl.eleceng.ua.oz.au writes:] > > 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! Sounds like it is definitely seated properly - since you can't see the rings. > 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? With the correct chip extractor (which looks like a medieval thumb screw) it is quite an easy task. The reason the socket is so tight is that I neglected to get very low insertion force pins! Oh well. > 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! Hmm, an intermittent of some sort - that's for sure. Maybe you should check (if you haven't done so) that no chip legs are bent under in their sockets. Also 'wiggle' the board while resetting to see if it comes to life. Also, check the resistor packs (the SIPs primarily), I have seen them with hairline cracks that cause all sorts of nasty intermittent problems. > 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. I have seen this sort of thing. Even though the pal should come out of the IDLEW state, I think that the 532 gets 'confused' on the first new access. Anyhow - I'm not sure why it takes 2 resets, but that is normal behaviour when it crashes in this way. > resoldered that socket. Now it doesn't work again in exactly the same > way as before and with either PAL. The fault must be at some other place - that causes the IDLEW state lockup. > 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 No, the I/O access is inhibited if /IOINH is low. i.e. it should be high for a valid I/O access to proceed. > /ioinh pin is still high. The only explanation for that is that the > 532 is driving it that way! Yes it is - i.e. it is correct for /IOINH to be normally high. > 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 No. /IOINH means I/O inhibit. The only time the 32532 does this is if there is a pending write (i.e. in it's on-chip write fifo) and you are trying to do a read access. /IOINH is asserted to tell the hardware that if the current access is to an I/O device then it should be ignored. At the same time the hardware should generate /IODEC (set it low) to inform the 32532 that the current access really was to an I/O device. The 32532 will then flush out the write fifo and re-execute the aborted read access (this time not asserting /IOINH). These events are essential to ensure that a write to a I/O control port followed by a read from the I/O device (e.g. while setting up a UART) executes in the correct order. I'm pretty sure that NS has a patent on this protocol. The 486 etc can get away with not having this stuff since it has dedicated I/O instructions - the 32532 has no special purpose instructions for handling I/O so it needs this extra hardware - of course you get a more powerful instruction set to do I/O with. > As Alice said "curiouser and curiouser". But at least everything still makes sense.... best regards, -- George Scolaro (gs@vw25.chips.com) Chips & Technologies +1 408/434-0600 X4556 work 3050 Zanker Road San Jose, CA 95134