Path: utzoo!mnetor!tmsoft!dptcdc!torsqnt!jarvis.csri.toronto.edu!rutgers!sun-barr!oliveb!tymix!tardis!jms
From: jms@tardis.Tymnet.COM (Joe Smith)
Newsgroups: comp.sys.amiga
Subject: Re: GVP controller
Message-ID: <501@tardis.Tymnet.COM>
Date: 10 Aug 89 23:23:57 GMT
References: <8908072207.AA14796@jade.berkeley.edu> <12254@grebyn.com>
Reply-To: jms@tardis.Tymnet.COM (Joe Smith)
Organization: McDonnell Douglas Field Service Co, San Jose CA
Lines: 46

In article <12254@grebyn.com> ckp@grebyn.UUCP (Checkpoint Technologies) writes:
>In article <8908072207.AA14796@jade.berkeley.edu> (Valentin Pepelea) writes:
>>So if you multitask a lot, you'll want the GVP controller, otherwise the other
>>controllers are for you.
>
> Facts are sound - but the conclusion is backwards! On such as a
>HardFrame or A2090, the controller moves data *directly* into the data's
>final resting place, using one bus cycle per 16 bit word. With the GVP,
>the data moves into the controllers on-board RAM using no bus cycles,
>but then the CPU must move the data to it's final location, using *6*
>bus cycles (four for the 68K instructions moving the data, and two for
>the data, one coming from the controller RAM and one going to the task
>buffer) for each word.

What about DMA overhead?  It takes some bus cycles to start DMA (the device
has to get a Bus Grant signal), and non-zero time to stop DMA (release the
bus).  If you have an extremely fast disk, the controller could grab the
bus, squirt all the data into RAM, and beat the pants off any controller that
uses the CPU to copy data.  But, unfortunately, most disks don't have data
transfer rates that match the Amiga's raw bus speed.

So, what do you do with DMA and a slower disk?
  A) Transfer the data as a single DMA request, locking the CPU out until
     the last byte is transfered.  (slows down or stops CPU intensive tasks)
  B) Transfer one word at a time, allowing the CPU to run between consecutive
     pairs of bytes from the disk.  (CPU eaten up by DMA requests and grants)
  C) Transfer data to cache on controller, let CPU copy to RAM via a program
     loop (read data into CPU, write from CPU, fetch opcodes, branch)
  D) Transfer data to cache on controller, let DMA hardware copy complete
     buffer of data to RAM at full bus speed using a single DMA request.

Option D produces is the least taxing on the CPU, and is the most expensive.
As for option C (which is what I interpret Valentin's remarks as advocating),
you will get more usable CPU time if the transfer rate from the disk is
slower than the speed of the program loop.

Again, this is true if the elapsed time for CPU to transfer data from RAM to
RAM is less that the elapsed time DMA grant + DMA transfer + DMA release.

Summary: If the disk speed does not match the memory bus speed, CPU assisted
transfers may be better than simple DMA transfers.
-- 
Joe Smith (408)922-6220 | SMTP: JMS@F74.TYMNET.COM or jms@tymix.tymnet.com
McDonnell Douglas FSCO  | UUCP: ...!{ames,pyramid}!oliveb!tymix!tardis!jms
PO Box 49019, MS-D21    | PDP-10 support: My car's license plate is "POPJ P,"
San Jose, CA 95161-9019 | narrator.device: "I didn't say that, my Amiga did!"