Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!sdd.hp.com!caen!kuhub.cc.ukans.edu!markv From: markv@kuhub.cc.ukans.edu Newsgroups: comp.sys.amiga.programmer Subject: Re: Virtual Memory Program? Message-ID: <29018.27db6cde@kuhub.cc.ukans.edu> Date: 11 Mar 91 17:41:18 GMT References: <1991Feb14.193510.13772@bradley.bradley.edu> <%1+-SC%@irie.ais.org> <1991Feb20.175103.24611@jato.jpl.nasa.gov> <1986@public.BTR.COM> Organization: University of Kansas Academic Computing Services Lines: 25 In article , efeustel@prime.com (Ed Feustel) writes: > In order to DMA into virtual memory, the dma must use virtual addresses or > the OS must supply a properly translated virtual address for each page. > In Prime Computer's proprietary system, the I/O has access to the translation > table and DMA goes to virtual memory. On the Amiga (and any micro with the MMU onboard the CPU) it would be impossible for the DMA to use virtual addresses. So the OS would have to supply translated physical addresses, and would have to lock the page in RAM. The only catch is that the max single DMA transfer would be the page size, which on most systems is 4K or 8K, so you would lose a lot of the potential performance of DMA. Unless of course the OS or program somehow maintained special buffer areas that were physically contiguous. All these problems makes controllers like the GVP that use a shared RAM buffer a bit more attactive. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mark Gooderum Only... \ Good Cheer !!! Academic Computing Services /// \___________________________ University of Kansas /// /| __ _ Bix: mgooderum \\\ /// /__| |\/| | | _ /_\ makes it Bitnet: MARKV@UKANVAX \/\/ / | | | | |__| / \ possible... Internet: markv@kuhub.cc.ukans.edu ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~