Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site ektools.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!whuxl!whuxlm!akgua!gatech!seismo!rochester!kodak!ektools!john
From: john@ektools.UUCP (John H. Hall)
Newsgroups: net.micro,net.arch
Subject: Re: Apple's IWM; Floppy Disk Controllers
Message-ID: <364@ektools.UUCP>
Date: Fri, 10-Jan-86 07:59:28 EST
Article-I.D.: ektools.364
Posted: Fri Jan 10 07:59:28 1986
Date-Received: Wed, 15-Jan-86 03:09:41 EST
References: <382@ncr-sd.UUCP> <1894@peora.UUCP>
Reply-To: {allegra,seismo}!rochester!kodak!ektools!john (John H. Hall)
Organization: Eastman Kodak, Dept. 47
Lines: 32
Xref: watmath net.micro:13484 net.arch:2402

In article <1894@peora.UUCP> jer@peora.UUCP (J. Eric Roskos) writes:
> (discussion of Apple's IWM 'disk controller' that uses the CPU for
> timing and control vs dedicated controllers such as in the IBM PC )
>
>some of the parallelism in the machine.  Thus you get the reduction in
>chip count at a (sometimes considerable) cost in terms of performance of
>the machine, because now your CPU has to sit spinning around in timing
>loops whenever you do disk I/O, whereas before you had a dedicated
>processor to do that. 

In a single-user, single-task environment, (such as the Apple II and the
Mac) the ability to compute and do disk I/O concurrently is not nearly
the big win it is in a multi-user, multi-tasking system.  For a low-end
system such as the Apple ][ it is entirely appropriate.

>Furthermore, it may be that a fully general CPU
>can't execute as fast as the one in the disk controller, so you lose even
>more performance that way.  

I agree.  I doubt IWM could handle the data rates from anything faster 
than a floppy.

-- 
-------------------------------------------------------------------------
John Hall
Supervisor, Software Tools Laboratory
Product Software Engineering

USPS:   EASTMAN KODAK COMPANY, 901 Elmgrove Rd., Rochester, NY 14650
VOICE:  716 726-9345
UUCP:   {allegra, seismo}!rochester!kodak!ektools!john
ARPA:   kodak!ektools!john@rochester.ARPA