🚀 go-pugleaf

[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