🚀 go-pugleaf

[In the message entitled "Hardware Problems" on Jun  4, 12:51, ian@sibyl.eleceng.ua.oz.au writes:]
> My board occasionally gets into a stuck state, where "reset" fails to
> restart things.
> 
> When it is in this state, the LED's are out and the CPU is stopped
> with /rdy high. It appears to stop in a write to the AIC6250 or at
> least with /scsi selected. I've measured the signals around the WAIT
> PAL a DVM which is not the most appropriate instrument, but its the
> best I have at home.
> 
> 		U38
> 	Pin		Logic Level
>       -----------------------------
> 	1 (ck)		Pulsing (*)
> 	2 (/eprom)	1
> 	3 (/scsi)	0
> 	4 (/bmt)	1
> 	5 (/ddin)	1
> 	6 (/slow)	1
> 	7 (drq)		0
> 	8 (scsii)	0
> 	9 (a22)		1
> 	11 (/oe)	0
> 	12 (/dack)	1
> 	13 (/nrdy)	0 ]
> 	14		1 ]
> 	15		1 ] This indicates the IDLEW state in the wait pal.
> 	16		1 ]
> 	17 (/rd)	1
> 	18 (/wr)	1
> 	19 (/eop)	1
> 
> This fault is difficult to reproduce. This state is *after* I have pressed
> reset, however, reset normally does the write thing. Is there some flip
> flop somewhere which should be reset and isn't? I have no idea if this is
> a design fault or a fault on my particular board.

All ff's that should be reset are. The only things that are not are some of
the state machines in the pals. These rely on getting into the 'reset' state,
i.e. the idle state by clocking there. I have not seen the problem you are
having - in fact the IDLEW state that the wait pal is in can only be reached
by performing a read/write to the pseudo-dma port. If you look at the wait
pal source you will see that once in the IDLEW state the only way to exit
is via reset (ie !(!slow & scsi)) or if drq or scsii are asserted (which will
never happen if you get into IDLEW by accident). The only way to get
there is if a bus cycle when bmt & !slow & scsi & !drq & !scsii is true.
This should never happen except for pseudo-dma scsi accesses. i.e. something
is wrong! But if we look at the voltages that you have indicated are present:

	 1      1      0      0       0
	bmt & !slow & scsi & !drq & !scsii

Note: bmt is only asserted (low) in the 1st T-state of a bus cycle, so it
would have been low initially (to get to the IDLEW state). The equation is
true - which explains why you are in the IDLEW state. i.e. the wait pal is
doing the right thing, but for some reason the EPROM boot code is doing
the wrong thing. My bet is that the EPROM is flakey - if it is an AMD part
then toss it and re-program it into a different part. We have had lots of
trouble with AMD EPROMS - we had to return a whole bunch we bought for the
PC532 kits. You may have got one of the few that 'appeared' to work.

anyhow, keep us informed of your progress, - at last some hardware problem
I can think about...

p.s. measuring the signals on the wait pal was exactly the right thing to do.


-- 
George Scolaro (gs@vw25.chips.com)	Chips & Technologies
+1 408/434-0600 X4556 work		3050 Zanker Road
					San Jose, CA  95134