Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!jarthur!spectre.ccsf.caltech.edu!tybalt.caltech.edu!toddpw
From: toddpw@tybalt.caltech.edu (Todd P. Whitesel)
Newsgroups: comp.sys.apple2
Subject: Re: pipes (implementation thereof)
Message-ID: <1990Mar23.200426.28446@spectre.ccsf.caltech.edu>
Date: 23 Mar 90 20:04:26 GMT
References: <2284@tellab5.tellabs.com>
Sender: news@spectre.ccsf.caltech.edu
Organization: California Institute of Technology
Lines: 56

toth@tellab5.tellabs.com (Joseph G. Toth Jr.) writes:

>First of all - in order to provide multi-tasking (which is refered to in
>   the articles), the OS/Shell would have to work using interrupts.  Most
>   owners of Apples (][, ][+ //e - The //c includes a mouse interface which
>   can generate timing interrupts) don't have clocks or mouse controllers
>   to provide the timing interrupts required to provide multi-tasking.

1. Only true pre-emptive multitasking requires interrupts. Cooperative
	multitasking (a la Multifinder on the Mac) does not use interrupts to
	decide when to change contexts. It would not be that hard to write a
	cooperative multitasking system on ANY machine provided the O/S is
	smart enough to provide the necessary intercommunication (pipes) and
	to be able to load more than one program at once.

2. Cards which many people have that could be pressed into interrupt service:
	Mockingboard (two 6522's) and compatibles (AE Phasor, etc.)
	Apple Cat II modem (30 hz interrupt, also see Serial Cards below)
	Serial Cards or any card which allows transmit interrupts

Note that the serial card needs to be dedicated to interrupt generation. If
you have one but aren't using it then you can just leave the serial port
connected to nothing and it will transmit characters at 300 baud out into the
void while your interrupt driver transmits another character and goes on about
its business.

(I know, it's a kludge. But it would work if it were really that important. On
6502's it's much easier to use something that does _not_ do a full CPU context
switch because the stack and ZP are fixed. With a 65802/65816 your entire CPU
state is in the registers, and life is much easier. Except nobody's bothered
to write one yet that I know of.)

>Second - in order to make any gains provided by task switching, all I/O to
>   disk, etc. would require new hardware to allow interrupting I/O control
>   and/or DMA.  Since there has been no uniformity to restrictions regarding
>   the use of interrupts in the past (DMA requires use of interrupt lines)
>   almost all current I/O device drivers (hardware and software) would have
>   to be scrapped.

To clarify here: what you're trying to get across is that all currently
existing drivers were designed without the possibility of multitasking in
mind. So what? When a process makes an I/O request it is satisfied even if
it effectively halts the system for a second or two. Nobody said anything
about full real-time performance here. (Granted it'd be nice.)

DMA does not require interrupts -- the driver could and probably does just
poll a bit until DMA is finished -- but interrupts do simplify things.
They prevent your driver from having to wait for the DMA to finish which is
what I believe you were referring to. This could and should be exploited by
a multitasking system but as you said the drivers would have to be rewritten --
which I would do anyway. Queuing of I/O requests and all that. (Which might
gobble some memory but come on! how many people who'd want these features still
have only 128K?)

Todd Whitesel
toddpw @ tybalt.caltech.edu