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!"