Using LOADHI without QEMM.SYS

You can use LOADHI with another 386 expanded
memory manager if you have Quarterdeck's QRAM.
This is is not as efficient on an 80386, 80386SX or i486 as
QEMM's RAM parameter. LOADHI does require that
you either have QEMM.SYS or QRAM.SYS.

Using QEMM-386 on 8088, 8086, or 80286 PCs

QEMM-386 only operates on an 80386, 80386SX or i486
PC. If your PC does not have an 80386, Quarterdeck's
QRAM programsupplies QEMM-386's LOADHI features,
if you have EMS4 or EEMS expanded memory. On PS/2
Model 50 and 60s, QEMM-50/60 also provides many of
the same features of QEMM-386, provided you have the
proper extra memory hardware.

PC does not function after booting with QEMM.

This may occur when QEMM and another device (or fea-
ture) of your PC are unable to cooperate. This section-
covers problems when just having DEVICE=QEMM.SYS
in the CONFIG.SYS file causes the computer to "lock up".
The next section covers problems with LOADHI--al-
though the information here may prove to be useful as
well. You may need a Boot Floppy to proceed, so be sure
to have one ready (see Appendix B).

You must first figure out what the conflict is:

:~ If you have the RAM parameter on the QEMM.SYS
line in the CONFIG.SYS file, remove the RAM
parameter and reboot.

If the PC now functions correctly, then some area be-
tween 640K and 1024K is being used by a device but the
RAM parameter does not see the device. It thinks that it
can put some high RAM into the same spot.

Check to see if any areas which are in the high RAM
area are currently in use by another device--using
QEMM.COM or Manifest First Meg Overview and
QEMM Types displays,

The most common devices are video or network adap-
ters. Usually QEMM can see these cards, but if areas that
are "Mappable" or "Rammable" are in locations where an
adapter already exists, then you should use the EX-
CLUDE parameter on the QEMM.SYS line to force
QEMM not to use these areas. If a network adapter has
some RAM between 640K and 1024K that QEMM does
not recogni~e, then that area should be excluded.

If removing the RAM option does NOT work, then add
"X=OOOO-FFFF FRAME=NONE" to the QEMM.SYS line
and reboot. If this works, type, QEMM ON, to see if
QEMM can enter Virtual 8086 mode at all.

If you are NOT using the RAM parameter and the com-
puter does not boot correctly, then there is another con-
flict. Try adding parameters which disable automatic fea-
tures of QEMM-386 such as NOCOMPAQFEATURES,
NOTOPMEMORY, NOROMHOLES, NOFILL,
NOVIDEOFILL, NOXBDA, NOSHADOWRAM, IG-
NOREA20, NOROM, and NOSORT.

Normally you would not add all of these at once. In fact,
adding one at a time and removing those that have no ef-
fect would be the most efficient way to isolate a problem.
You should remove any INCLUDE parameters, and
specifically EXCLUDE areas you know may be in use by
other devices. See Chapter 3, QEMM.SYS Programfor
parameters and examine them to determine if there may
be a conflict. Be sure to remove any extra parameters
you try which don't seem to make any difference. A
good starting point is "NOFILL NOSORT OFF". You
may find that "IGNOREA20 DMA=64 NOROM" makes a
difference. If it does, see the descriptions of these items
to determine why these parameters are necessary. Some
parameters may or may not make sense on your PC.

If you have a PC with Microchallnel Architecture, then
the MCA.ADL file may INCLUDE areas for you which
may not be correct. Manifest uses the same MCA.ADI.
file, and the System Adapters display can show you the
areas used by the adapters.

If you still haven't determined the conflict, then you
should follow the instructions in Appendix C, to create a
"pure environment" in order to isolate the exact problem
which is causing the trouble.

PC does not function when using LOADHI

If your PC locks up" after using DESQview's XDV.COM,
DV.COM, LOADHI.COM or LOADHI.SYS, (and having
the RAM option does not cause trouble), then there is
probably a memory conflict between 640K and 1024K
(see above), but only when the conflicting memory is
used. It's not always easy to tell which program using
LOADHI is causing the problem, but a patient, sys-
tematic approach (using LOADHI with one program at a
time) is the fastest and most reliable method.

While the most common problem when loading items
into high RAM is that the RAM area being loaded into is

49   APPENDIX A: TROUBLESHOOTING
actually used by something else, there are programs
which are not capable of being loaded high. These
programs may require addresses below 640K to work for
example. As long as there is enough room to load the
program (you can use the /GETSIZE option of LOADHI
to be sure) most programs can be loaded into high
memory. Watch the program's initialization display to
see if it loads successfully.

If the problem is with DESQview's XDV.COM or
DV.COM when running DESQview, then you can use the
"/L" (no quotes) option of XDV.COM to determine the
areas of high RAM which XDV is using to load the
DV.EXE file into. You can then use the "/X=xxxx-yyyy"
option to XDV.COM to specifically exclude areas which
may be a problem. If you find an area, then use the EX-
CLUDE parameter on the QEMM.SYS line to keep the
area excluded. The /L and /X options to XDV.COM can
both be used at the same time, and the /X option may be
used more than once if needed.

Network drivers "lock up" or act unpredictably

This problemis probably a memory conflict with a
memory area between 640K and 1024K. Token Ring,
ARCnet, Proteon, Ethemet, and some others may not be
"seen" by QEMM at boot time, so QEMM may have
placed high RAM into the memory area used by the net-
work card. Use the methods described previously to iso-
late the conflicting area and EXCLUDE it on the
QEMM.SYS line in the CONFIG.SYS file. You may even
find the memory address listed when the network driver
initializes, and most network cards list the addresses
they use in their documentation.

Graphics programs have corrupted displays

The most likely cause of a graphics program having its
display appear corrupted or "fuzzy" is that some high
RAM has been placed into an area that the graphics
adapter was not using until a particular program started
using it. Removing any INCLUDE parameters and using
the QEMM Analyze or Manifest QEMM Analyze display
after running the graphics program should identify the
area of conflict. You should then either EXCLUDE the
video area being used (somewhere in the AOOO to CFFF
area, but probably not all of it), and/or not use IN-
CLUDE to put high RAM into as large an area.

Floppy drive does not work or reports "Drive not
ready" when QEMM-386 is loaded

There are two reasons why the floppy drive may have
trouble when QEMM-386 is loaded. The first, and most
likely, is that you have used the ROM parameter with
QEMM-386. The ROM parameter copies your ROM
RAM and then maps the RAM into the same location
where the ROM is. The result is that the ROM area is
able to work much faster since it is now using RAM.
However, some ROMs use "timing loops" to determine if
the floppy drive is ready. Now that the ROM area is
faster, the timing loop takes less time so the computer
thinks that the drive is malfunctioning. You can either
remove the ROM parameter or attempt to find the exact
location of the floppy drive code (not easy to do) and use
ROM=xxxx-yyyy to map the areas NOT involved with
timing.

The second reason a floppy drive may not work correctly
is that is uses DMA. Specifying DMA=64 on the
QEMM.SYS line should correct this problem.

Attempting to LOADHI a program reports "Not
enough room to load high"

When using LOADHI, a program needs its "normal"
amount of memory in high RAM in order to get started.
Many TSRs and device drivers take much more room to
initially load into memory and then reduce their memory
size to only the amount needed to stay resident. The
/GETSIZE (/GS) parameter can be used with LOADHI to
determine if this is happening. Using the Optimize pro-
gram automatically keeps track of the amount of "run
time" memory as well as its "resident" size for all
programs in the CONFIG.SYS and AUTOEXEC.BAT files,
and will try to find a way to place as many programs in
high RAM as possible.

LOADHI fails with an SCSI disk drive controller

When using SCSI (or other "bus master") devices, the
memory mapping feature of QEMM-386 is not seen by
the disk controller; the "bus master" controller will "talk"
to the memory directly. Since the controller doesn't
know that the high RAM is being provided through
memory mapping, and LOADHI is asking to place a pro-
gram into memory the drive controller can't "see", LOAD-
Hl doesn't work correctly. This is easily corrected by ad-
ding DISKBUF=2 to the QEMM.SYS line. This parameter
tells QEMM-386 to provide a disk buffer in "non-
mapped" memory for the disk drive to use when it needs
to. Higher numbers result in better disk performance,
but increase the resident size of QEMM-386 below 640K.

QEMM-386 reports "not enough room to load"

If you have only lMB of memory on your 80386 and use
the RAM parameter, it is possible that QEMM-386 will

50   APPENDIX A: TROUBLESHOOTING
not have enough memory to both load itself and fill in all
of the unused high RAM areas. This is especially true on
systems which use some of the extra memory to map
ROM for themselves (Shadow RAM) without using
QEMM's ROM parameter. Since the Shadow RAM is
being used to map high RAM and possibly ROM, there
isn't enough extended memory left over for QEMM-386
to load its own program code! QEMM-386 does not run
in Conventional or high RAM; it actually uses extended
memory for the program code. The solution is to get
more memory. In the meantime, you can use RAM=xxxx-
yyyy to place high RAM into a smaller area in order to
leave some memory free for QEMM to use, or you may
not be able to use RAM at all.

Another reason this could happen is that QEMM-386 is
not able to access the "extra" memory beyond 640K on
your PC. QEMM-386 can find memory, but some PC
manufacturers hide their extra memory or don't allow it
to be extended memory. Once again, there won't be
enough extended memory for QEMM-386 to load itself
into. The ROM parameter uses memory too, and since
the PC may already be performing a similar function,
you should remove it until you get more memory.

PC boots but the keyboard does not work

If the keyboard does not respond to the familiar DOS
prompt, then your PC may use the "A20" line in a non-
standard way. The "A20" line is used to gain access to
memory above 1024K and is thus very important to
QEMM-386. Use of the UNUSUAL8042 parameter
should correct this problem.

Using QEMM with Microsoft Windows

QEMM-386 will work with both Windows/286 2.xx and
Windows/386 2.xx. There are several considerations for
each.

For Windows/286 2.xx, QEMM-386 can provide ex-
panded memory for all programs using Windows. The
Windows/286 SETUP program will NOT complete if
there is a valid DEVICE=QEMM.SYS line in the CON-
FIG.SYS file. You may simply modify the CONFIG.SYS
file temporarily by placing "REM" (without quotes) in
front of the DEVICE=QEMM.SYS line. There is no need
to reboot after having changed the CONFIG.SYS line,
since the Windows 2.xx SETUP program only check to
see if a valid line is there, and a line with REM in front
of it is not valid. The Windows 2.xx SETUP program
will then complete and Windows will be installed. You
should NOT have Windows 2.xx install its "HIMEM.SYS"
driver, since QEMM-386 provides an XMS interface al-
ready. Be sure to remove the "REM" after the installation.

Windows/386 2.xx can NOT run with QEMM-386 active.
However, the "Windows" portion of Windows/386 2.xx
CAN be used. This is a program which comes with Win-
dows/386 2.xx called WIN86.COM. This program will
NOT run "off-the- shelf" programs in Windows, but will
run any Windows-based programs. The WIN86.COM
program may even be run inside DESQview.

I If you are running several Windows 2.xx programs, it
may be advantageous to run theminside DESQview.
This way, each Windows 2.xx program gets its own
memory area to use and does not have to share the
memory with other Windows 2.xx programs.

Using LOAI)HI FILES with Microsoft Windows
(strange beeping when starting Windows)

Microsoft Windows 2.xx seems to not like having the
DOS resource FILES loaded into high RAM. If there are
fewer than 10 FILES resources below 640K, then Win-
dows will usually act very strangely when started, and
will never actually start working. You must have at least
FILES=10 in your CONFIG.SYS file, and if you run other
programs in DESQview before using Windows, you may
need more before Windows will start. If the problem per-
sists, try adding 5 more FILES at a time until it goes
away. Once you've determined the minimum needed for
Windows additional room for FILES can use LOADHI.

Lotus 1-2-3 Release 2.01 reports "Memory Full"
even when there is lots of expanded memory still
, available

When using very large spreadsheets in Lotus 1-2-3
Release 2.01 or 2.2 (not Release 3), you may encounter a
"Memory Full" message even though the Worksheet
Status command (and DESQview's Memory Status win-
dow) show plenty of expanded memory available. This
is due to the way that 1-2-3 Release 2.01 stores data in ex-
panded memory. The program only uses expanded
memory to store floating point numbers and labels
(strings of characters). In addition, it keeps track of these
items by using the conventional memory area. So every
item in expanded memory uses some conventional
memory as well. Therefore it is possible to fill up all of
conventional memory with integers and pointers to ex-
panded memory and yet still have expanded memory
left over. Lotus Development has published several ar-
ticles on how to conserve conventional memory, and you
may find that using LOADHI to increase your conven-

51   APPENDIX A: TROUBLESHOOTING
tional memory area will help as well. When using
1-2-3 inside DESQview, you should alter the "Maximum
Program Memory Size (in K)" item for 1-2-3 to a large
number to increase the amount of conventional memory
available. Breaking the spreadsheet into several smaller
pieces and using Release 2.2 or 3 are other alternatives.

Paradox 386 requires QEMM-386 to be ON

The current versions of Paradox 386 require that QEMM-
386 be in the ON state. If you are not using expanded
memory or the RAM parameter, then you will need to ex-
plicitly include the ON parameter on the QEMM.SYS
line. Later versions of Paradox 386 may correct this
anomaly.

Program reports a "Packed file corrupt" message

Some software packages are delivered in a "packed file"
format. This allows more files to fit on the disk and also
helps the program load faster. Due to a "bug" in some
versions of DOS, the "unpacking" algorithm does not
work if the program is loaded below 64K (not 640K, 64K)
and the "A20" line is enabled. Since use of the LOADHI
programs and other features of QEMM-386 can save a lot
of memory, it is possible that the the area where
programs are loaded may begin below 64K. If this hap-
pens and the "A20" line is enabled (as it is on some com-
puters and when DESQview is running) the "Packed file
corrupt" message may appear. Usually you can add
some DOS resources (BUFFERS is a good start) to use up
some memory to get the starting address above 64K.
Running the program in a slightly smaller DESQview
window will also usually make the message go away
when it appears in DESQview.

Programs report "Exception 13"

Exceptions are unusual or invalid conditions associated
with the execution of a particular instruction of the 80386
processor. The 80386 recognizes several different classes
of exceptions, and assigns a different number to each
class. QEMM-386 has been designed to capture these
80386 exception vectors and display them. Exception 13
is the "General Protection Fault" error. Any privileged in-
struction or any instruction that references memory incor-
rectly can cause an Exception 13.

In the first case, privileged instructions, the Exception 13
could indicate that a program has executed a privileged
instruction or I/O reference. This could be a special in-
struction which is only allowed in protected mode while
the PC is not in protected mode. If this is the case the
"Continue" option of the "Terminate, Reboot or Con-

52   APPENDIX A: Tl~.

tinue?" prompt will tell the 80386 to reorder the ranking
of privileged instructions and the program can continue
to execute.

It is the second case, instructions that reference memory
incorrectly, that are far more common to QEMM-386
(and DESQview 386) users. Here the exception may indi-
cate that the current program has a "bug" or has gone
astray in some way. QEMM-386 has not necessarily
caused the "bug" nor has it necessarily caused the pro-
gram to act differently. QEMM-386 is just able to report
the problem. The program may have overwritten some
of its own memory and may in fact be running wild,
writing data all over memory and executing instructions
that don't belong to the program. At this point when
"Terminate, Reboot or Continue" is displayed, the user
can only "Terminate", and in fact it may not even be able
to do that.

The technical description of what happens is that a
WORD or DOUBLE WORD value has been written to or
read from the last address of a segment. The "bug" in
the program is that the value is not written to the first
byte of the next segment, but rather wraps to the begin-
ning of the current segment. This is probably not what
was intended and, in fact, is not allowed on an 80386.

This problem may have existed in the program all along
and not been noticed, or it may be due to the higher ad-
dresses now being used when loading programs into
high RAM. The programmer may have assumed that
the program would never address such high numbers.

DESQview 386 users have two different things they may
try to fix the problem. First, use Change a Program and
try to allocate more memory to the application. Second,
increase the Protection Level to 3. This will not alleviate
the source of the Exception 13, but may allow you to find
out sooner what is causing the exception.

When Exception 13 is seen outside of DESQview, it is
usually not recoverable and often difficult to fix. If the
program you are running is using 80386 protected mode,
then perhaps it does not support VCPI (Virtual Control
Program Interface). Since QEMM-386 is uses Virtual
8086 mode, such applications cannot be run under
QEMM without VCPI. There is no choice but to reboot
without QEMM, and contact the developer of the applica-
tion to see if they intend on providing VCPI support.

If the program was not written for protected mode, then
the problem is harder to fix. Write down the information
displayed along with the Exception 13 message. The
data displayed is the address of the rc when the excep-

~OUBLESHOOTING
tion occurred, the contents of the CPU's registers, and
several bytes at the exception location. The data may be
intermixed with the screen display, but it is locatable.

If any of the registers or the instruction address is 0000,
or FFFE, or FFFF, then the problem is usually "segment
wrap". After rebooting the computer, use LOADHI with
no parameters to get a list of program addresses, or the
Manifest First Meg Programs display to try and see
which program was executing at the time of the excep-
tion. If this program has been loaded into high RAM,
then see if loading it below 640K or in a different loca-
tion eliminates the problem. Sometimes loading
programs in a different order helps, and sometimes ad-
ding or subtracting one from your BUFFERS will change
the location in memory enough to eliminate the problem.

Technical users can use the instruction bytes displayed to
determine the exact instruction which caused the excep-
tion. Using DEBUG and entering the values into
memory allows you to "unassemble" the code and, along
with the register values, understand the exact nature of
the exception. This usually doesn't solve the problem,
but it does show you that the exception 13 was caused
by a genuine fault. Knowing which program caused the
exception (it may be some resident program rather than
the one you thought was executing) is crucial in solving
an exception 13 problem. If you can't figure out which
program causes the exception, you may need to create a
"pure" environment. See Appendix C.

Maximum memory size programs in DESQview

When using DESQview, many people would like to have
the largest possible program area in which to run their
programs. Indeed, DESQview allows you to "re-use" the
memory are below 640K many times, so having a large
area is very important. You should be sure that the
parameters (using Change a Program) for "Memory Size
(in K)" is quite large (400K is a good number) and "Maxi-
mum Program Memory Size (in K)" is even larger (800K
will work). This makes sure that the window will be AT
LEAST 400K in size, and then DESQview will allocate
more up to the Maximum specified. (The 800K is far
more than is even possible, so you're sure you get all of
the rest without having to figure it out.) In order to gain
the maximum size of memory, you should be using the
XDV.COM program (or have copied XDV.COM to
DV.COM, since DOS will allways load a ".COM" file
before loading a ".EXE" file).

The XDV.COM program puts some of DV.EXE into High
RAM. You can find out how much by adding "/L" (no
quotes) to the XDV command line to get a display of the
free areas, their size, and how much of DV.EXE is placed
there. This points out an interesting dilemma: since
LOADHI puts items into high RAM, and XDV puts
pieces of DV.EXE there too, you may actually end up
leaving some of DV.EXE in Conventional memory be-
cause I OADHI has used up so much of it. You can check
your free memory before running DESQview (with
CHKDSK or Manifest) and then check the "Total Avail-
able Conventional Memory" using DESQview's Memory
Status command. You may want to evaluate what TSRs
you are running before DESQview, perhaps they would
be better run inside DESQview. This can free up memory.

Using memory in the most efficient way possible

One of QEMM's and QRAM's greatest features is that
you can control the memory you have better than you
ever could before. Many people want to make sure that
the area between OK and 640K is as large as possible.
Using high RAM and the LOADHI programs can go a
long way to make sure that the conventional memory
area is as big as possible. The OPTIMIZE program can
assist in maximizing conventional memory by analyzing
the possible methods of loading items into high RAM
and placing them into the best possible location. Using
Quarterdeck's Manifest program, you can observe how
much memory is still being used below 640K by looking
at the First Meg Programs display. The DOS Overview
display will show you if more of DOS is being left below
640K that could be loaded high. A word of caution: you
can spend a lot of time trying to get an extra few bytes of
memory and not really gain much. Try to determine
what the memory savings will be before attempting to
spend a lot of time rearranging things. Loading TSRs
and device drivers into high RAM is usually the quickest
way to gain useful amounts of memory. On DOS 2.xx
and 3.xx systems, loading BUFFERS into high RAM is
easy and provides a lot of memory savings.

If you need more high RAM, then try QEMM-386s
Analyze feature. There may be areas of memory be-
tween 640K and 1024K that you are not using. You may
also find that a particular adapter which is using a lot of
memory addresses above 640K can either be removed or
moved to a different location to get larger c(mtiguous
areas of high RAM. Having many small areas of High
RAM is not as useful as a few large contiguous areas.

If you are not using ANY programs which use graphics,
or if some large programs you use don't need graphics,
you can use the VIDRAM program to gain a significant
amount of memory from your EGA or VGA adapter.

53   APPENDIX A: TROUBLESHOOTING