Path: utzoo!utgpu!watmath!clyde!ima!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.
Message-ID: <35334@think.UUCP>
Date: 11 Jan 89 15:13:38 GMT
References: <11605@dartvax.Dartmouth.EDU> <271@berlin.acss.umn.edu> <27318@ucbvax.BERKELEY.EDU> <13271@cup.portal.com> <5958@polya.Stanford.EDU> <13369@cup.portal.com>
Sender: news@think.UUCP
Reply-To: ephraim@think.com (Ephraim Vishniac)
Organization: Thinking Machines Corporation, Cambridge MA, USA
Lines: 27

In article <13369@cup.portal.com> ts@cup.portal.com (Tim W Smith) writes:
>Also, removable media devices have to poll at interrupt time if they
>are waiting for a disk to be inserted.  This is because you don't get
>accRun events when the system is displaying the "Please Insert Disk
>So-and-so" dialog.  At least these don't really have to worry about
>wiping out someone else's use of SCSI, since the system is hung
>waiting for the disk anyway.

This is semi-true.  You don't get accRun events, but you don't have to
use a VBL task.  In the driver for the Jasmine MegaDrive, I used a
patch to _GetNextEvent (maybe _GetNextOSEvent?) because that's the
only trap repeatedly called by the disk swap routine.  In my patch, I
peek at the TickCount to see whether a couple of seconds have passed
since my last poll.  If not, I've only cost the user about a dozen
instructions of execution time.  If so, I simulate an accRun call to
my driver.

Mactech did suggest using a VBL task, but it looked like bad advice to
me.  BTW, looking at the clock is much better than counting calls to
GetNextEvent because the frequency of GNE calls in the disk swap
dialog varies enormously between different Mac models.

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

	"Arlo Guthrie, it seems, has found what he was looking for:
		God, and the Macintosh." (Boston Globe)