Path: utzoo!utgpu!watmath!att!pacbell!ames!mailrus!cornell!batcomputer!eacj
From: eacj@batcomputer.tn.cornell.edu (Julian Vrieslander)
Newsgroups: comp.sys.mac.programmer
Subject: Re: If Apple implements user mode, how will we do uninterrupted I/O?
Keywords: user mode interrupt
Message-ID: <8573@batcomputer.tn.cornell.edu>
Date: 8 Aug 89 01:54:00 GMT
References: <8538@batcomputer.tn.cornell.edu> <4111@ogccse.ogc.edu>
Reply-To: eacj@tcgould.tn.cornell.edu (Julian Vrieslander)
Organization: Cornell Theory Center, Cornell University, Ithaca NY
Lines: 57

In article <4111@ogccse.ogc.edu> afoster@ogccse.UUCP (Allan Foster) writes:
>In article <8538@batcomputer.tn.cornell.edu> eacj@tcgould.tn.cornell.edu
>(Julian Vrieslander) writes:
>>Tech Note #85 says that we should not disable interrupts from within an
>>application.
>> ...
>>What does Apple really mean when they say that the interrupt mask may
>>become inaccessible in some future System version, or on some future Mac?
>>My reading of the Motorola manuals indicates that applications running in
>>user mode will not be able to directly modify the interrupt mask in the
>>status register of a 680xx CPU.  If applications must run in user mode,
>>will Apple provide a trap (or another mechanism) that will allow an
>>application to disable interrupts?
>> ...
>>If not, what is the recommended way of doing uninterrupted I/O?
>
>It seems to me that the driver that you are writing really should
>be an OS level task.  I am sure there would be a way under the new systems
>to install a driver that would run in supervisor mode.

I just received a note from someone else suggesting the same.  I hope that this
is true, since I was planning to rewrite my code as a driver anyway.
 
>It seems the real solution to the problem is to do it in hardware...
>Get a board that can do DMA or has some sort of buffering on board
>so that it does not require the attention of the host CPU as much.

We looked, to no avail, for a card flexible enough to handle our data
acquisition tasks autonomously in hardware.  We even thought about building a
custom card, but that would require too much time.  We can, however, do what we
need with a simple GWI MacADIOS II card, and some custom interface code.  But
this code needs to run without being interrupted (and therefore, in supervisor
mode).   

>If Mac is ever going to run as a protected memory virtual machine,
>then running in USER mode is a MUST.  You do not own any hardware
>as a user process, only access to a virtual machine!

The bottom line is that, after "opening up" the Macintosh hardware with the Mac
II, Apple seems to be moving again in the direction of concealed, inaccessible
hardware.  I (sort of) understand the motives for this.  But there are some
folks who need to access low level hardware in order to implement unusual i/o
tasks.  Many of these applications, like mine, cannot be done with commercially
available plug-and-run products.  Apple execs may now see these applications as
an inconsequential market compared to networked business and dtp systems.  I
really like working with Macs, but in the future, people like me may have to
shop elsewhere for micros to run those "non-standard" data acquisition
applications.   

>Allan Foster
>MicroPhone II Development Team

-- 
Julian Vrieslander 
Neurobiology & Behavior, W250 Mudd Hall, Cornell University, Ithaca NY 14853    
UUCP: {cmcl2,decvax,rochester,uw-beaver}!cornell!batcomputer!eacj
INTERNET: eacj@tcgould.tn.cornell.edu     BITNET: eacj@CRNLTHRY