Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!bbn!rochester!udel!new
From: new@udel.EDU (Darren New)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Virtual Memory / doable 1.4 request
Message-ID: <15706@louie.udel.EDU>
Date: 18 May 89 02:39:34 GMT
References: <8905170500.AA25917@jade.berkeley.edu>
Sender: usenet@udel.EDU
Reply-To: new@udel.EDU (Darren New)
Organization: University of Delaware
Lines: 16

In article <8905170500.AA25917@jade.berkeley.edu> 451061@UOTTAWA.BITNET (Valentin Pepelea) writes:
>For swapping page 316, it is much simpler to transfer directly sector 316
>through the trackdisk.device, than having to determine the location of the
>sector through a filing system.

Alternately, the VM handler could, upon startup, in some way scan through the file
to determine where all the sectors are, then bypass the file system and go to the
driver. If the file is fixed size, this is real easy. If the file can grow, then it
would have to be done on later allocations as well. This would give the best of
both worlds, and certainly could not be harder to code than DiskSalv or DiskDoctor.
		  -- Darren
P.S., I always assumed MEMF_PUBLIC meant memory that would be shared between
tasks, thus providing an upgrade for when memory mapping/protection is
implemented (much like the MEMF_CHIP that most 1.1 programs failed to use).
Are you saying that MEMF_PHYSICAL/MEMF_VIRTUAL is needed to lock pages in 
RAM or needed to allow sharing? -- Darren