Category : Alternate Operating Systems - Quarterdeck DesqView, CP/M, etc
Archive   : QTEC9306.ZIP
Filename : LOADHI5.TEC

ID:L5 Loadhi: Recent Versions
Quarterdeck Technical Note #183
by Joe Wilder

This technote discusses QEMM's Loadhi programs, concentrating on
material which is not already in the Quarterdeck manuals and on
versions of QEMM 5.0 or later. Chapter 5 and Appendix A of the
Quarterdeck Expanded Memory manager manual contain
the basic Loadhi information.

Q: What does Optimize do?

OPTIMIZE will load TSRs and device drivers high in the most
"optimal" way, often testing millions of possible combinations.
The LOADHI programs available in QEMM version 5 and later can
determine the size of particular TSRs or device drivers and will
place them in specific memory address ranges. It would be
improbable that one could use the Loadhi utilities manually and
improve on the way Optimize arranges programs in high memory.

Q: What's Loadhi all about?

There is a popular misconception that PCs using DOS have an
absolute limit of 640K of space to run programs in. Untrue --there
is actually 1024K of addressable code space. The LOADHI programs
are used to run resident programs and device drivers in the
address space between 640K and 1024K. This area is normally
reserved for hardware devices such as video cards, system ROM and
network adapters. Any space in that range that isn't occupied by
devices, Roms, or Ram is just that, empty space. There is usually
more that one available space. Each of these areas is called a
region. Qemm puts memory in these empty spaces with a process
called memory mapping. Memory assigned to these regions is called
"High Ram." The more devices you have that use the address range
640-1024K, the less high memory will be available to load programs
into. Expanded Memory managers also utilize 64K of this upper
address space for what is called a "Page Frame." The Expanded
Memory Page Frame is a space through which programs familiar with
the Expanded Memory standard can get access to the pool of Expanded
Memory.

Q: Can I get rid of the Expanded Memory Page Frame?

The Page Frame may turned off, and doing so would allow space for
64K more High Ram. The disadvantage to doing this is that programs
that want to use the Expanded Memory pool could no longer do so.
Therefore, turning off the Expanded Memory Page Frame is only a
viable option for users whose programs don't use Expanded Memory.
The parameter to turn off the Expanded Memory Page Frame is
"FRAME=NONE".

Q: Will QEMM and LOADHI load TSRs directly into Extended and/or
Expanded Memory?

Many new QEMM users assume that LOADHI can run TSRs and device
drivers directly in Extended or Expanded Memory. This is not the
case. The only address space where these items can be run is in
what were empty addresses (previous to the installation of Qemm and
the RAM parameter) in the address range from 640K to 1024K. This
is where "High Ram" gets installed when the RAM parameter is used
with QEMM.

Q: Why am I getting an error message, "No High Memory Available"?

The RAM parameter to QEMM.SYS must be invoked in order to use
LOADHI programs. This attaches some Expanded Memory to the unused
addresses in the reserved memory area. Once the RAM is available,
programs can be loaded there with LOADHI. If loading high is
attempted without the RAM parameter being specified, the above
error message will appear. Using the RAM parameter to QEMM.SYS
prevents QEMM from being turned off at the prompt.

Q: I seem to have enough High Ram, but my program still won't load
high.

Each program must be loaded into a single contiguous memory region.
Because of this, very large TSRs and device drivers often won't
load high. For instance, if QEMM establishes two high memory
regions, one of 80K, and the other of 32K, a program that requires
90K to load wouldn't be able to be loaded high. It would have to
fit in one Region or the other. The size and number of regions
varies from computer to computer depending on the size of the BIOS,
the number of devices and where in the 640-1024K address space
these are situated.

Q: Is there any way of finding just a little more High Ram?

There are some small things you can do that may improve your
available conventional memory. Rearranging your config.sys and
autoexec.bat so that the items that take the most memory come first
often will improve available conventional memory when Optimize is
run. Setting up you hardware devices so that the available High
Ram is large contiguous regions instead of small fragmented regions
will allow Optimize more options in putting things up high. For
example, three 7K regions often aren't as usable as one 21K area.
Changing the address ranges hardware is accomplished by
reconfiguring the hardware itself. Some devices have jumpers or
switches on the card, others are software configurable. Using the
Analyze feature of Qemm will almost surely find some more places to
put High Ram. If this procedure is used, the instructions must be
followed explicitly.

Q: Is there anything special to consider about Loading High for
DESQview users?

DESQview has the capability of running most of its own code in high
memory. You don't have to use the RAM parameter with QEMM to get
this feature. DV.COM (XDV.COM renamed) will map Expanded Memory
into the available addresses on its own. It will then run DESQview
in that memory. DESQview can use as much as 95K of reserved
memory space. Loading high too many resident programs and drivers
before going into DESQview may cause DESQview to load more of
itself in the lower 640K, resulting in little or no gain for the
largest available window size in DESQview. Frequently, because of
the different sizes of memory regions available, you may actually
get a slightly larger window size in DESQview by loading something
low instead of high. If you are running DESQview, it is a good
idea to avoid loading "Pop-up" type TSRs before DESQview at all
(using LOADHI or not,) but instead run them in DESQview windows,
where their overhead in lower memory can be completely eliminated.

Copyright (C) 1991 by Quarterdeck Office Systems
* * * E N D O F F I L E * * *