hitch@buhub.bradley.edu (Douglas Hanna) (02/15/91)
Has anyone out there in netland written/heardof/know where I can obtain a virtual memory program? If there is one on one of the fred fish disks that would be great. The reason I ask is because I don't have the funds at this time to purchase a ramcard, and I can spare a few megs off of my harddrive. Any assistance would be appreciated. TIA (Thanks In Advance) -- |><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><| |<>| Douglas Hanna Bradley University |<>| |><| HITCHhiker (042) hitch@buhub.bradley.edu |><| |<>| "All disclamers, standard and nonstandard apply" |<>| |><| "Another Brilliant mind destroyed by the rigors of |><| |<>| higher education" |<>| |><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><|
kelson@ais.org (David Lewis) (02/16/91)
In article <1991Feb14.193510.13772@bradley.bradley.edu> hitch@buhub.bradley.edu (Douglas Hanna) writes: >Has anyone out there in netland written/heardof/know where I can >obtain a virtual memory program? If there is one on one of the fred >fish disks that would be great. The reason I ask is because I don't >have the funds at this time to purchase a ramcard, and I can spare a >few megs off of my harddrive. Any assistance would be appreciated. >TIA (Thanks In Advance) > Yeah.. if I would be interested in hearing about it too... I was thinking about attempting to write one.. but it sounded like a LOT of work.. -- Internet: Kelson@ais.org
GHGAQZ4@cc1.kuleuven.ac.be (02/20/91)
I've written a routine to list the MMU tree (for my debugger).
The problem is that this routine works in AmigaDOS 2.0 (on my Amiga 3000)
but not in AmigaDOS 1.3. The routine simply thinks that the list is
infinite. The problem could be that my routine does not support all
MMU features. For example, I do not support page indirection, 8 BYTE
pages, FC code tables. I'm pretty sure that AmigaDOS 1.3 does NOT use
8 BYTE pages and FC code tables so I think the problem is with the
page indirection feature of the MMU. Has anyone in AmigaLand some source
to do things with the MMU that he/she wants to share with me ?
I'm especially interested in a complete MMU table lister.
If I get a lot of response I even might write a virtual memory system
for the Amiga :-)
Thanks In Advance,...
Jorrit Tybergheindaveh@cbmvax.commodore.com (Dave Haynie) (02/20/91)
In article <91050.163512GHGAQZ4@cc1.kuleuven.ac.be> GHGAQZ4@cc1.kuleuven.ac.be writes: >Has anyone in AmigaLand some source to do things with the MMU that he/she >wants to share with me ? You might want to track down the source code for SetCPU V1.6. It's on a Fish disk (400-something I think), and it's public domain. It doesn't have an MMU disassembler, but it certainly does "do things with the MMU". > Jorrit Tyberghein -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "What works for me might work for you" -Jimmy Buffett
jdickson@jato.jpl.nasa.gov (Jeff Dickson) (02/21/91)
> Yeah.. if I would be interested in hearing about it too... >I was thinking about attempting to write one.. but it sounded >like a LOT of work.. > >Internet: Kelson@ais.org To support a virtual memory application (more like a virtual disk), is it safe to assume that the application will only use AmigaDOS to access the file's contents? Without an MMU I don't see any other way. Comments? Jeff
valentin@public.BTR.COM (Valentin Pepelea) (03/02/91)
In article <91050.163512GHGAQZ4@cc1.kuleuven.ac.be> GHGAQZ4@cc1.kuleuven.ac.be writes: > >I've written a routine to list the MMU tree (for my debugger). >The problem is that this routine works in AmigaDOS 2.0 (on my Amiga 3000) >but not in AmigaDOS 1.3. The routine simply thinks that the list is >infinite. The problem could be that my routine does not support all >MMU features. For example, I do not support page indirection, 8 BYTE >pages, FC code tables. I'm pretty sure that AmigaDOS 1.3 does NOT use >8 BYTE pages and FC code tables so I think the problem is with the >page indirection feature of the MMU. The 2.0 and 1.3 translation trees used by the A3000's SuperKickstart are identical. In both cases the first level of the tree is limited to 16 entries by the limit field of the CRP. Well, that's how things used to be in the summer of 1990. I haven't bothered to check since. > Has anyone in AmigaLand some source > to do things with the MMU that he/she wants to share with me ? > I'm especially interested in a complete MMU table lister. I have written an utility which does exactly this in my spare time, but while at the employ of Commodore-Amiga. It was quite interesting to see the progression of the translation tree used by SuperKickstart from the early days to its final stages. If you beg hard enough, perhaps the people at C-A will start distributing the thing. Otherwise, the only freely distributable thingy would be Dave Haynie's SetCpu program. The latest version is 1.6, but if you want to understand the source code, go back to 1.4. > If I get a lot of response I even might write a virtual memory system > for the Amiga :-) Sorry, but you've been preempted. I implemented virtual memory for the Amiga as a fourth year university project, back in 1989. You are still welcome to try your own hand at it, but if you have my luck, you'll run into a multitude of compiler bugs, assembler bugs and operating system bugs. Unless you are motivated by the granting of a four year degree upon completion of your project, you are likely to loose motivation. Valentin -- "An operating system without virtual memory Name: Valentin Pepelea is an operating system without virtue." Phone: (408) 985-1700 Usenet: mips!btr!valentin - Ancient Inca Proverb Internet: valentin@btr.com
valentin@public.BTR.COM (Valentin Pepelea) (03/02/91)
In article <1991Feb20.175103.24611@jato.jpl.nasa.gov> jdickson@jato.Jpl.Nasa.Gov (Jeff Dickson) writes: > > To support a virtual memory application (more like a virtual disk), >is it safe to assume that the application will only use AmigaDOS to access >the file's contents? Without an MMU I don't see any other way. Comments? You are indeed right. The problem with accessing a disk directly through its device driver is that the device driver does not know when it is not allowed to DMA into a portion of memory. As for the AmigaDOS filing system, the MASK value in a mount list identified the region of memory into which DMAing is allowed. So files may be loaded into virtual memory only through the filing system. Obviously, DMAing into virtual memory is not possible without the full support and knowledge of the operating system. But then, I don't know of any operating system offering the possibility of DMAing into virtual memory. No wonder considering the futility of such an exercise. Valentin -- "An operating system without virtual memory Name: Valentin Pepelea is an operating system without virtue." Phone: (408) 985-1700 Usenet: mips!btr!valentin - Ancient Inca Proverb Internet: valentin@btr.com
peter@cutmcvax.cs.curtin.edu.au (Peter Wemm) (03/03/91)
valentin@public.BTR.COM (Valentin Pepelea) writes: >> If I get a lot of response I even might write a virtual memory system >> for the Amiga :-) >Sorry, but you've been preempted. I implemented virtual memory for the >Amiga as a fourth year university project, back in 1989. You are still >welcome to try your own hand at it, but if you have my luck, you'll >run into a multitude of compiler bugs, assembler bugs and operating system >bugs. Unless you are motivated by the granting of a four year degree upon >completion of your project, you are likely to loose motivation. Wow! Any chance that something might come of it? Are you able to distribute it? Or even sell it? (Or has somebody else got the rights to it??) You can't expect to dangle a carrot like that and not expect a bite!!! :-) >Valentin >-- >"An operating system without virtual memory Name: Valentin Pepelea > is an operating system without virtue." Phone: (408) 985-1700 > Usenet: mips!btr!valentin > - Ancient Inca Proverb Internet: valentin@btr.com -- Peter Wemm ------------------------------------------------------------------------------ peter@cutmcvax.cs.curtin.edu.au (if fails, try peter@cutmcvax.oz.au)
valentin@public.BTR.COM (Valentin Pepelea) (03/03/91)
In article peter@cutmcvax.cs.curtin.edu.au (Peter Wemm) writes: > > Wow! Any chance that something might come of it? Are you able to distribute > it? Or even sell it? (Or has somebody else got the rights to it??) Before you jump up and down with joy, let me first tell you that virtual memory can not be automatically used by applications out there. Virtual memory may be allocated only to programs which explicitly request it. Therefore the usefullnes of the VM handler is cut down by an order of magnitude. The problem is that current applications expect physical memory, and often access their memory whithin a Forbid(). That is a no-no for virtual memory, since multitasking has to be re-enabled upon a page fault. Since there is no way to find out why a Forbid() occurred, there is no way for the VM handler to safely re-enable multitasking. > You can't expect to dangle a carrot like that and not expect a bite!!! :-) In order to distribute virtual memory, I would first like to polish it up, by giving it a little window in which to plot the paging frequency and other goodies like that. But I have no inclination to give up my free time or one of my other projects to do that. On the other hand, if someone dangled a carrot in front of my nose... Valentin -- "An operating system without virtual memory Name: Valentin Pepelea is an operating system without virtue." Phone: (408) 985-1700 Usenet: mips!btr!valentin - Ancient Inca Proverb Internet: valentin@btr.com
efeustel@prime.com (Ed Feustel) (03/04/91)
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.
gilgalad@caen.engin.umich.edu (Ralph Seguin) (03/05/91)
Hi. Why not get the Mach micro-kernel, port it to the Amiga (not a trivial task :), and then pop BSD 4.4 on top of it? Voila, PD UNIX :) Then get X11R4, write iwm (Intuition Window Manager), and you have Amiga "Look and Feel". See ya, Ralph Ralph Seguin gilgalad@dip.eecs.umich.edu 536 South Forest Apt. #915 gilgalad@caen.engin.umich.edu Ann Arbor, MI 48104 (313) 662-4805
rhialto@cs.kun.nl (Olaf'Rhialto'Seibert) (03/06/91)
In article <1986@public.BTR.COM> valentin@public.BTR.COM (Valentin Pepelea) writes: >Obviously, DMAing into virtual memory is not possible without the full >support and knowledge of the operating system. But then, I don't know >of any operating system offering the possibility of DMAing into virtual >memory. No wonder considering the futility of such an exercise. IBM, in its infinite wisdom, does this (sort of) with VM/CP (Virtual Machine/ Control Program) for 370-style mainframes. Basically, VM emulates complete (totally complete) 370 machines on 370s (or anything compatible). That means: you can do all I/O a 370 can, which usually means DMA into virtual memory (since the whole machine is virtual). Therefore you have virtual disks, virtual printers, and (yeah) virtual card readers and punches for communication with the outside world. Sending a file means punching it, while spooling the virtual cards to a special machine (RSCS) which sends the file to another machine or across a network. And you can define new devices with a simple command. Interesting concept. Very complex. Hopelessly outdated, but very interesting. The source listing to a very old version of VM was about one meter high, all written in assembly. >Valentin -- Olaf 'Rhialto' Seibert rhialto@cs.kun.nl How can you be so stupid if you're identical to me? -Robert Silverberg
tell@oscar.cs.unc.edu (Stephen Tell) (03/08/91)
In article <1986@public.BTR.COM> valentin@public.BTR.COM (Valentin Pepelea) writes: >In article <1991Feb20.175103.24611@jato.jpl.nasa.gov> >jdickson@jato.Jpl.Nasa.Gov (Jeff Dickson) writes: >> >> To support a virtual memory application (more like a virtual disk), >>is it safe to assume that the application will only use AmigaDOS to access >>the file's contents? Without an MMU I don't see any other way. Comments? > >Obviously, DMAing into virtual memory is not possible without the full >support and knowledge of the operating system. But then, I don't know >of any operating system offering the possibility of DMAing into virtual >memory. No wonder considering the futility of such an exercise. > >Valentin Internet: valentin@btr.com >-- And also, in <efeustel.668096462@tiger1>, 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. The Sun-3 and Sun-4 machines also do this. All DMA accesses, whether originating from VMEbus or on-board devices, to memory on the CPU board goes through the MMU. A device uses an address way down at the bottom of VMEbus address space. Hardware on the cpu board maps this up to the top of virtual address space, called somthing like "dma virtual space". Just before an I/O transaction, the driver calls routines to allocate and map a dma virtual page to the appropriate physical page (which may also be accessed at another virtual address, say from within a process or the kernal) On the other hand, DMA accesses from VMEbus devices to ordinary VMEbus memory (or to another VMEbus device - we've done this!) do not. This is straying from the point, but it does show that just about any architecture you can think of, and some you can't, has been implemented somewhere. Of course, the hardware and software has to be designed from the ground up to deal with it. Just for the record, I'd also like to be able to say Foo *bar = AllocMem(sizeof(Foo), MEMF_VIRTUAL);. Steve -------------------------------------------------------------------- Steve Tell tell@cs.unc.edu H: +1 919 968 1792 #5L Estes Park apts CS Grad Student, UNC Chapel Hill. W: +1 919 962 1845 Carrboro NC 27510
markv@kuhub.cc.ukans.edu (03/12/91)
In article <efeustel.668096462@tiger1>, 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
daveh@cbmvax.commodore.com (Dave Haynie) (03/12/91)
In article <1986@public.BTR.COM> valentin@public.BTR.COM (Valentin Pepelea) writes: >In article <1991Feb20.175103.24611@jato.jpl.nasa.gov> >jdickson@jato.Jpl.Nasa.Gov (Jeff Dickson) writes: >> To support a virtual memory application (more like a virtual disk), >>is it safe to assume that the application will only use AmigaDOS to access >>the file's contents? Without an MMU I don't see any other way. Comments? >You are indeed right. The problem with accessing a disk directly through >its device driver is that the device driver does not know when it is not >allowed to DMA into a portion of memory. Of course, "the way it often is" is not the same thing as "the way it should be". Only a device driver knows the details of its underlying hardware. Because of this, a device driver is responsible for knowing, for example, which memory it has DMA access to and which memory it doesn't have DMA access to. This, of course, counts on the memory systems in the computer behaving according to a consistent set of rules. >As for the AmigaDOS filing system, the MASK value in a mount list identified >the region of memory into which DMAing is allowed. The MASK parameter, however, is an acknowledged kludge. It is a way to let the user often force a piece of hardware to work properly, despite hardware or firmware bugs. So MASK can be used to support a 24-bit DMA device that doesn't know it only has 24 bit access to memory. And it can support hacked-in memory devices that don't support DMA. It is useful, but it is not the correct way of handling these problems. It is just the one tweakable parameter available to the user. >"An operating system without virtual memory Name: Valentin Pepelea -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "What works for me might work for you" -Jimmy Buffett
mcr@Sandelman.OCUnix.On.Ca (Michael Richardson) (03/12/91)
In article <29018.27db6cde@kuhub.cc.ukans.edu> markv@kuhub.cc.ukans.edu writes: >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. Not really. It just makes programmable controllers that do DMA even better. Good DMA controllers can do scatter/gather operations and take a list of buffers to which they should move the data. -- :!mcr!: | The postmaster never | - Pay attention only Michael Richardson | resolves twice. | to _MY_ opinions. - HOME: mcr@sandelman.ocunix.on.ca + Small Ottawa nodes contact me Bell: (613) 237-5629 + about joining ocunix.on.ca!
dillon@overload.Berkeley.CA.US (Matthew Dillon) (03/15/91)
In article <1991Mar12.055922.27355@Sandelman.OCUnix.On.Ca> mcr@Sandelman.OCUnix.On.Ca (Michael Richardson) writes: >In article <29018.27db6cde@kuhub.cc.ukans.edu> markv@kuhub.cc.ukans.edu writes: > > Not really. It just makes programmable controllers that do DMA even >better. Good DMA controllers can do scatter/gather operations and take >a list of buffers to which they should move the data. >-- > :!mcr!: | The postmaster never | - Pay attention only > Michael Richardson | resolves twice. | to _MY_ opinions. - > HOME: mcr@sandelman.ocunix.on.ca + Small Ottawa nodes contact me > Bell: (613) 237-5629 + about joining ocunix.on.ca! Yes, DMA controllers with linked buffer capability are almost required to get good network throughput on ethernet and other networks, mainly because the host computer need not do any buffer copies of the network data as it constructs the packets. -Matt -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA