Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!cs.utexas.edu!usc!apple!mips!daver!bungi.com!news From: george@wombat.bungi.COM (George Scolaro) Newsgroups: comp.sys.nsc.32k Subject: Re: Hardware Problems Message-ID: <9006101101.AA05461@wombat.bungi.COM> Date: 10 Jun 90 18:01:08 GMT Sender: news@daver.bungi.com Lines: 85 Approved: news@daver.bungi.com [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. There are 4 pins (near each corner of the chip) which have small rings that should seat all the way flush with the socket. The 32532 should be pushed all the way it until this occurs - it does take a lot of pressure - i.e. place the board flat on something a bit soft (several sheets of newspaper) and then stand over the board and with the palm of the hand PUSH until the chip is fully seated (if you ever have to extract the 32532 you will discover the wonders of splintering ceramic - unless you have a PGA chip extractor!). > thing that ever gets selected is the DRAM. Eventually (10minutes) the > thing gets totally stuck with scsi selected and the cpu waiting for > rdy. If I reset before the "stuck" state then the cycle is repeatable. > If I wait until it is "stuck" then reset won't work and the only way out > is to power off. You definitely have some major problem - a dead chip or bad contact. > The "stuck so it won't reset problem" seemed the easiest to attack so > I investigated it further. It seems that reseting the wait pal from > the "idlew" state is supposed to happen when the cpu starts its first > bus cycle to the eprom. Well, /slow and /scsi can both be observed to > momentarilly change state (to 0 and 1 respectively) when the reset is /SLOW is asserted for all slow devices - i.e. checking the DEC32 equations: SLOW = EPROM (in both swapped and non-swapped positions) # duart (all 4) # scsi (software polled only - Not pseudo-dma) # icu. > removed. I can't for the moment say whether that happens > simultaneously. I've borrowed a logic probe but not a logic analyser > yet! The eprom also gets momentarilly selected when reset is raised Obviously the thing to check is that /SCSI should be asserted along with /SLOW when the monitor is programming the AIC chip to turn the LEDs on. If /SLOW isn't asserted then the WAIT pal is not at fault - it's doing what it should be - and the fault is the code being executed by the 32532 - data path or control problem to/from the EPROM-32532. > but that is about all that happens before it is stuck in the same > "idlew" state as before! The swap signal is also high. Again, the only way this can happen is if /SCSI is asserted and the /SLOW is not. This is only for pseudo-dma accesses which are not present in the monitor (at least not at the boot/signon phase). This means that the cpu is executing incorrect code. Maybe the WAIT pal is broken - or something that controls the EPROM-CPU data path access. Since this is a rock hard reproduceable problem you should attack it from there. > My current hypothesis is that the select pal is dodgy. I will attempt > to run the test vectors on all the pals tomorrow (don't actually know > if our programmer will do that). I can't think of many hypotheses which > let "reset" work when the system is in any state except "idlew". The SELECT pal shouldn't be able to cause the problem you are seeing, unless it is selecting the AIC or 8490 device (via their chip selects) continuously and therefore causing data bus contention etc. The monitor code will still fire up if you pull the AIC, 8490 and SELECT pal out - maybe you should also try that. > I have three eproms. The original monitor that came with the system, > the most recent binary that Bruce posted and also a locally compiled > version. They all exhibit this behaviour, so I am disinclined to think > it is a eprom problem. Agreed, the EPROMs themselves are not at fault. > I am for now assuming that the "can't talk to the duart" and "stuck so > it won't reset" problems are symtoms of the same fault. Definitely - whatever is causing the pseudo-dma access instead of a normal programmed access to the AIC chip is at fault. best regards, -- George Scolaro george@wombat.bungi.com [37 20 51 N / 122 03 07 W]