From: daveh@cbmvax.commodore.com (Dave Haynie)
Newsgroups: comp.sys.amiga.hardware
Subject: Re: Concern (Not flames) over IDE for A4000
Date: 1 Oct 92 22:46:06 GMT
Reply-To: daveh@cbmvax.commodore.com (Dave Haynie)
Organization: Commodore, West Chester, PA

In article <1992Sep28.234235.4643@unlv.edu> maniac@lil-ed.cs.unlv.edu (Eric J. Schwertfeger) writes:

>1) Does the IDE interface support multiple drives?  The normal
>IBM IDE interface supports two drives only, 

It supports two drives, as that is the limit of the IDE interface.

>and then only if the drives are standard enough.  

In that this is somewhat dependent on the drives, as you mention, I don't
think any IDE system can guarantee than any two drives will work together.
We've also that problem with SCSI, though to a much lesser extent (older
Conner's didn't want to coexist with Quantums).

>2) Are there any plans for IDE tape drives?  I know that there is
>one such beast in the IBM world, but I don't know if it would work
>on the Amiga.

I don't know if C= has any product plans.  Assuming such an IDE tape drive 
coexists properly with the hard disk, most backup software should already
support it, far as I know.  At the low level, tape backups work via the 
SCSI direct protocol, which is emulated in the A4000's IDE device driver.
Perhaps some of the software folks have tried this, I have not.

>3) Is the A4000 IDE interface really polled?  That's a bad design
>choice, IMHO.  

It's not polled, it's programmed I/O.  Polling implies some kind of CPU
spin wait on a bit somewhere.  In the A4000, the IDE device driver sets up
a transfer, then waits for an interrupt (eg, consumes no CPU time) which
indicates the drive has data to transfer.  The transfer is managed via a
CPU loop between the IDE port and memory (eg, programmed I/O).

>even the AdIDE on my A500 seems to be a DMA design

It's not.

>but CPU contention doesn't slow it down, CHIP bus contention does.

CPU contention is not going to slow down the average device driver, as they
run a higher task priority than your normal user program.  In fact, the driver's
activity slows down the user tasks.  The degree to which this happens depends
on the work the driver has to do.  DMA is ideal because it requires no CPU
intervention for the actual transfer.  It will take some time away from the
CPU (since it shares the main processor bus), but if done right, it does its
transfers as fast as the bus will permit, no matter how fast the actual device
will run.  Interrupt-driven programmed I/O is the next most efficient protocol.
The C= Ethernet card, for example, has always worked this way.  The CPU is
required for transfers between I/O device (or buffer) and main memory.  The CPU
never idles, but the access to device memory isn't necessarily full CPU bus 
speed (in fact, it never is).  Polled I/O is programmed I/O, but instead of 
letting the I/O run to completion and signalling the CPU, this form has the CPU
busy wait, polling some I/O bit to see if the transfer has completed.  This is
what I call parasitic programmed I/O, since it's stealing CPU cycles from your
other tasks for no good reason.
-- 
Dave Haynie Commodore-Amiga (Cool Advanced High-End Systems You Can't See Yet)
 "The Crew That Never Rests"  {uunet|pyramid|rutgers}!cbmvax!daveh   BIX: hazy
             "You lie so much you believe yourself" -Metallica
Newsgroups: comp.sys.amiga.hardware