Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!stanford.edu!agate!e260-1e.berkeley.edu!c60b-1eq From: c60b-1eq@e260-1e.berkeley.edu (Noam Mendelson) Newsgroups: comp.sys.ibm.pc.misc Subject: Re: Command.com in ramdisk Message-ID: <1991Apr24.194745.13507@agate.berkeley.edu> Date: 24 Apr 91 19:47:45 GMT References: <34067@ccicpg.UUCP> Sender: root@agate.berkeley.edu (Charlie Root) Organization: University of California, Berkeley Lines: 35 In article <34067@ccicpg.UUCP> mhr@ccicpg.UUCP (MHR {who?}) writes: >Whoa, hold on a moment there. >The upper 384k of the first megabyte of memory on a PC _is_ EMS memory. It is NOT EMS memory. EMS memory is a specification which allows 8086's to access data above 1M by simulating a 64K page in high memory and changing pages when different areas of the EMS memory are required. >Why would anyone want to go out and get an EMS emulator whic requires >XMS (extended memory spec) memory when they already have the EMS they >need? Because EMS memory is a standard. Many programs can't make use of extended memory, and by emulating EMS you're giving them access to it. >Now if Adam's 384k had been the first 384k on the far side of the first >megabyte, your advice would have been more appropriate, but I think you >may have misunderstood what he was saying (or I did, in which case >ignore this post). You've got it reversed. >Besides, I side with the previous responder to Adam's post who suggested >that he use it for a disk cache. I find that use to be eminently >suitable for my extra k. Agreed. A disk cache is a good choice if you want a general improvement in disk speed, since there are areas of the disk that are accessed frequently (such as the FAT and directory area). -- +==========================================================================+ | Noam Mendelson ..!ucbvax!web!c60b-1eq | "I haven't lost my mind, | | c60b-1eq@web.Berkeley.EDU | it's backed up on tape | | University of California at Berkeley | somewhere." |