Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utcs!mnetor!seismo!husc6!harvard!panda!genrad!decvax!decwrl!pyramid!hplabs!tektronix!uw-beaver!ssc-vax!uvicctr!collinge
From: collinge@uvicctr.UUCP
Newsgroups: net.micro.apple
Subject: Re: Apple //e Interrupts
Message-ID: <175@uvicctr.UUCP>
Date: Thu, 10-Jul-86 16:07:59 EDT
Article-I.D.: uvicctr.175
Posted: Thu Jul 10 16:07:59 1986
Date-Received: Mon, 14-Jul-86 01:41:29 EDT
References: <283@ski.UUCP>
Reply-To: collinge@uvicctr.UUCP (Doug Collinge)
Organization: University of Victoria, Victoria B.C. Canada
Lines: 27

>>	I just got in an Apple 2E/enhanced computer that is
>>replacing an older vanilla Apple 2E in an lab application that we
>>are running.  The application uses an ADC driven by interrupts to
>>look at a process every 100 cpu clocks.
>>
>	"Once the built-in interrupt handler is called, it takes at
>	least 150-200 microseconds for it to call your interrupt
>	handling routine.  After your routine returns, it takes 40 to
>	140 microseconds fto restore memory and return to the
>	interrupted program."
>

Yes! 350 us to take an interrupt! Honestly - why bother having them at all?
I know people doing MIDI who have been bitten by this.  You have to read the
code to believe it - it is absolutely unbearable.

Of course, there is nothing stopping you from using the language ram and
subverting the e2e IRQ handler by jamming in your own hardware vector.

-- 
		Doug Collinge
		School of Music, University of Victoria,
		PO Box 1700, Victoria, B.C.,
		Canada,  V8W 2Y2  
		decvax!nrl-css!uvicctr!collinge
		decvax!uw-beaver!uvicctr!collinge
		ubc-vision!uvicctr!collinge