Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!caen!uflorida!reef.cis.ufl.edu!jdb From: jdb@reef.cis.ufl.edu (Brian K. W. Hook) Newsgroups: comp.os.msdos.apps Subject: Re: Epanded, Extended & Reserved Message-ID: <27844@uflorida.cis.ufl.EDU> Date: 5 Apr 91 17:15:47 GMT References: <1991Apr4.182459.12299@ingres.Ingres.COM> Sender: news@uflorida.cis.ufl.EDU Organization: UF CIS Dept. Lines: 57 Okay, maybe some clarification is needed here for you who are slightly confused about the functionality of QEMM. First of all, getting QEMM to work right on a given system is pure hell. Period. But ONCE you get it running (expect to devote a couple of hours to doing this), it is a pure God send. My system has 8MB of RAM, however, this extended memory is rather moot according to QEMM. It uses only the UMB and HMA. Things that QEMM can do include: 1. Shadow video and ROM BIOS into upper memory. 2. Load buffers/files/lastdrive/etc. into high/upper memory (640-1024) 3. Replace himem.sys OUTRIGHT. 4. Give you expanded memory 5. Give you extended memory 6. Load TSRs and what not and some device drivers high. However, QEMM will NOT do the following: 1. Load device drivers and TSRs into extended memory or expanded memory. 2. Be the miracle software everyone wants. 3. Load command.com high. Some typical problems that people will run into are: 1. If your hardware has automatic ROM shadowing, you must either disable the hardware shadowing and let QEMM do it, or, disable QEMM's ROM shadowing using the NOSH parameter. 2. You sometimes get a lot of conflicts with different devices, etc. present in your system when QEMM tries to shadow these areas. you will have to do a lot of talking with Quarterdeck and your peripheral manufacturers on this one. Most prevalent are things that memory on the cards, such as SCSI controllers and caching controllers, and things that have their own processor/ROMs, such as SCSI, ESDI, graphics coprocessor boards, bus mastering LAN adapters, etc. You will have to do a LOT of fiddling with the FRAME= and the EXCLUDE options. 3. You don't get all the memory you need out of the upper 384K. You have to make sure that you don't have small drivers being dispersed over all of your upper memory area. If you have 160K free of UMBs, but it is in 10 16K blocks, you won't be able to load a mouse driver, small tsr, etc. at all, even with all of that memory. Use the /R:n parameter to get past this and try and put all of your loaded high stuff in a contiguous memory region. 4. You get conflicts with some protected mode programs that aren't VCPI compliant. For example, I cannot run Turbo Debugger 386 since it tries to force the processor into 386 mode, and QEMM has put the processor in protected mode already. 5. QEMM, as far as I know, is VCPI compliant ONLY when it is acting as a EMS manager. I use it at time with the NOEMS switch so that I can recover an extra 64K out of high memory or when I just want XMS. However, TD286 won't run in since it believes I have a non-VCPI complain memory manager loaded. When I keep the EMS switch on, I don't have a problem. I hope this helps, Brian