Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!mailrus!tut.cis.ohio-state.edu!bloom-beacon!think!ephraim
From: ephraim@think.COM (Ephraim Vishniac)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Apple HD SC 80 does not support Asynch i/o.
Keywords: Just what is the problem here?
Message-ID: <35104@think.UUCP>
Date: 4 Jan 89 14:44:03 GMT
References: <11605@dartvax.Dartmouth.EDU> <271@berlin.acss.umn.edu> <11614@dartvax.Dartmouth.EDU>
Sender: news@think.UUCP
Reply-To: ephraim@think.com (Ephraim Vishniac)
Organization: Thinking Machines Corporation, Cambridge MA, USA
Lines: 36

In article <11614@dartvax.Dartmouth.EDU> earleh@eleazar.dartmouth.edu (Earle R. Horton) writes:

>The Mac OS supports asynchronous I/O for all drivers installed in the
>system.  Inside Macintosh gives quite precise instructions for an
>application developer to use it.  There can only be one of two
>reasons why this feature is not implemented for SCSI hard disks, even
>the Apple HD SC 80:

>	a)  Disk driver writers were too lazy to put it in, and
>	    figured most people wouldn't miss it.

>	b)  The present SCSI interface is not capable of it.  I don't
>	    know how this could be true, but I am extremely unwilling
>	    to believe that the Apple drive cannot do asynch I/O because
>	    of the first reason.

>Anybody have any idea which of the above is true?

I won't stick my neck out by essaying a definitive answer, but I
believe that (b) is so very nearly true that (a) can be taken for
granted.  That is, it's so difficult and of so little benefit in most
cases that you'd have to be real masochist to go for it.

The main problem is that the Mac provides no interrupts from the SCSI
interface.  (They do for the floppy, so async floppy I/O is much
easier.)  So, you have no choice but to poll the SCSI interface.  You
can either sit in a loop and do this, as everybody does, or you can
try to figure out some scheme with VBL's to get coarse polling with
lower performance.  BTW, Developer Technical Support (and, I think,
one of the Tech Notes) strongly advise against SCSI operations from a
VBL.

Ephraim Vishniac					  ephraim@think.com
Thinking Machines Corporation / 245 First Street / Cambridge, MA 02142-1214

	"He shook his head to clear a momentary system error."