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.