Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.sys.apple
Subject: Re: interrupts (was: Switcher/MultiFinder theory,etc)
Message-ID: <8169@brl-smoke.ARPA>
Date: 27 Jun 88 03:43:12 GMT
References: <8806262035.aa21500@SMOKE.BRL.ARPA>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) )
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 17

In article <8806262035.aa21500@SMOKE.BRL.ARPA> AWCTTYPA@UIAMVS.BITNET ("David A. Lyons") writes:
>For example, ProDOS calls could be intercepted, and before any disk
>access happened, a Ctrl-S could be sent through the serial ports;
>after the disk access was done, a Ctrl-Q could be sent.  (There may
>be some other problems here...I don't claim that this is a complete
>solution.)

There isn't any fully satisfactory solution (other than not requiring the CPU
to be used for disk I/O timing).  Sending a DC3 does not guarantee that more
characters won't subsequently arrive; typically two might, and it is worse on
some systems.  (You could allow time to handle input that trickles in before
starting the disk I/O.)  Hardware handshaking suffers from similar problems.
Packet protocols, e.g. AT&T's layers (xt) protocol, can solve the problem,
but of course not every host will know the protocol.

Real computers use DMA disk I/O and I/O completion interrupts.  This isn't
inherently expensive, but unfortunately the Apple II wasn't done that way.