🚀 go-pugleaf

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.