liberato@dri.com (Jimmy Liberato) (04/03/91)
wagner@chepil.weru.ksu.edu (Larry Wagner) writes: >valley@uchicago (Doug Dougherty) writes: >>jerry@gumby.Altos.COM (Jerry Gardner) writes: >>>In article <Z158y3w164w@ersys.uucp> ersys!davem@nro.cs.athabascau.ca (Dave McCrady) writes: >>>> Having said all that .. I guess the short answer to your question is >>>>yes ... IF your machine has expanded memory. Extended memory can't be >>>>mapped to high ram. >>>This is an incorrect statement. On a 386 machine, QEMM does map extended >>>memory to high RAM. Most 386 machines don't have true expanded memory, >>>this feature is provided by QEMM by remapping extended memory. A 386 running >>>in protected mode can remap RAM in any location to any other location. >>This is nitpicking. Actually, what happens is that the 386 memory >>manager emulates expanded memory in software, using the memory mapping >>capabilities of the processor. Then the expanded memory is used as >>"high ram". But the point is, it is true expanded memory. >>It is definitely the case that extended memory (qua extended memory) >>can't be mapped to high ram. >I pulled out my QEMM386 manual and what you say is correct with regards >to QEMM386 mapping expanded memory into high memory. However, the question >I have, is if Quarterdeck had wanted to, couldn't they have just done the >mapping of extended memory to high memory rather than extended to expanded to >high memory?... I, too, dug out the QEMM manual in addition to the XMS 2.0 and LIM EMS 4.0 specifications. It turns out that, in the case of QEMM at least, no expanded memory (EMS) is involved at all in the remapping to the upper addresses (A000- FFFF). It is also true that extended memory (qua extended) by definition cannot exist in that realm. So, what on earth is happening here? The confusion stems from not recognizing that QEMM is BOTH an EMS driver AND an XMS (Extended Memory Specification) driver. Part of the XMS specification defines what are called Upper Memory Blocks (UMBs) in the A000-FFFF range. An XMS 2.0 driver has the ability to redefine extended memory (by definition above FFFF) by remapping into the UMBs. Of course, some hardware assistance is required in the form of an 80386/486 class CPU or specialized memory management chips such as the Chips & Technologies NEAT chipset. Further confusion stems from the fact that the LIM EMS 4.0 specification also allows mapping of EMS pages into the upper memory addresses other than the 64K EMS page frame. (Actually, it allows remapping to any address in the 1 Meg real mode address space.) It is this ability that is capitalized upon by QEMMs sister product, QRAM. The QEMM manual (though superb and very thorough) is deficient when it implies that expanded memory is somehow involved in QEMM's upper memory remapping. This is simply not the case. Any who remain naysayers and disputants can try this simple test: Turn off QEMM's EMS driver services by using the NOEMS parameter. Turn on upper memory remapping with the RAM parameter. Use manifest to investigate memory usage, particularly in the extended memory category (notice the UMB services are on). Turn EMS back on by removing NOEMS parameter. Notice that the UMBs are still doing the remapping. Executive Summary: :-) QEMM does not use expanded memory for upper memory mapping. Expanded memory CAN be used for upper memory mapping but QEMM does not use it. -- Jimmy Liberato liberato@dri.com ...uunet!drivax!liberato