Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!zephyr.ens.tek.com!tekig5!phils
From: phils@tekig5.PEN.TEK.COM (Philip E Staub)
Newsgroups: comp.sys.amiga.tech
Subject: Re: 2091 problems (was JrComm 1.0)
Message-ID: <6621@tekig5.PEN.TEK.COM>
Date: 24 Jul 90 22:51:50 GMT
References: <1500@faatcrl.UUCP> <25990@usc.edu> <1509@faatcrl.UUCP> <26053@usc.edu> <1518@faatcrl.UUCP> <13242@mcdphx.phx.mcd.mot.com> <6611@tekig5.PEN.TEK.COM> <2243@sauron.Columbia.NCR.COM>
Reply-To: phils@tekig5.PEN.TEK.COM (Philip E Staub)
Distribution: na
Organization: Tektronix, Inc., Beaverton,  OR.
Lines: 31

In article <2243@sauron.Columbia.NCR.COM> stevem@sauron.UUCP (Steve McClure) writes:
>I would think that following the SCSI spec of watching the bus for the 
>Bus Free Delay time of 800 nanoseconds would assure you that you can now
>assert the BSY signal and go to arbitration.  But I have seen "SCSI" device
>drivers that didn't even handshake REQ/ACK properly, so you never know.
> 
This is true for multiple initiators on the bus. 

I'd say things are different when your two bus requests are channeled
through two processes using the same initiator hardware.
Merely waiting for the bus to be free for some length of time is no guarantee 
that another process doesn't come along and steal the controller chip out 
from under you between the time the chip says the bus is free (notice it's 
said the same thing for the other processes on the box, too) and the time
you go to selection phase, unless you're protected by a semaphore or via 
forbid().

Besides, I don't know of many Amigae which can do an accurately timed 800ns 
wait loop 8-).

>-- 
>----------------------------------------------------------------------
>Steve		email: Steve.McClure@Columbia.NCR.COM	803-791-7054
>The above are my opinions, which NCR doesn't really care about anyway!
>CAUSER's Amiga BBS! | 803-796-3127 | 8pm-8am 8n1 | 300/1200/2400


-- 
------------------------------------------------------------------------------
Phil Staub, phils@tekig5.PEN.TEK.COM
Definition: BUG: A feature (present or absent) which is (at best) inconvenient.