home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Black Box 4
/
BlackBox.cdr
/
desqview
/
qwhite.arj
/
XBDA.TEC
< prev
next >
Wrap
Text File
|
1992-03-09
|
5KB
|
110 lines
ID:XB The XBDA and Quarterdeck Memory Managers/Enhancer
DESQview Technical Note #222
by Quarterdeck Testing & Compatibility Department
December 26, 1991
XBDA.TEC
The purpose of this document is to explain what the Extended BIOS Data
Area is and how it affects the operation of QEMM-386, QEMM 50/60, and QRAM.
WHAT IS THE EXTENDED BIOS DATA AREA (XBDA)?
There is a piece of memory called the "BIOS Data Area" which begins at
1K (address 40:0H). The contents of the BIOS Data Area can be seen in the
"First Meg/Overview" screen of MANIFEST. Information about the configuration
of the system is stored here. IBM decided that more such information needed
to be stored so it invented the Extended BIOS Data Area because the original
BIOS Data Area is not expandable. Some computers have one, some computers do
not. All IBM PS/2 computers have an XBDA.
HOW DO I KNOW THAT I HAVE ONE?
The third line of the First Meg/BIOS Data screen of Manifest will read
"0E: Extended Bios Segment 0AF8" (or whatever address at which the XBDA is
being put) if you have an Extended BIOS Data Area.
HOW LARGE IS THE XBDA?
The XBDA is usually one kilobyte large. Some machines have a larger
XBDA. The size of the XBDA (in kilobytes) is stored in the first byte of the
XBDA itself.
WHAT DO QEMM-386, QEMM 50/60, AND QRAM DO WITH THE XBDA?
QEMM-386, QEMM 50/60, and QRAM move the XBDA. They do this because the
XBDA is put at 639K (9FC0H) by default and this prevents the extension of
conventional memory beyond 640K. If you have Hercules or CGA video then QEMM-
386 and QRAM (if your expanded memory card maps the video region) will extend
DOS memory above 640K automatically. If you wish to use the Quarterdeck
program VIDRAM then the XBDA must be moved.
HOW DO I STOP THIS FROM HAPPENING?
If you wish to stop QEMM-386 (QEMM 50/60, QRAM) from moving the XBDA
then you must put the switch NOXBDA (NX) on the QEMM386.SYS, (QEMM.SYS,
QRAM.SYS) line of the CONFIG.SYS.
DEVICE=C:\QEMM\QEMM386.SYS RAM NX
for example.
WHY WOULD I WANT TO STOP QEMM-386 (QEMM 50/60, QRAM) FROM MOVING THE
XBDA?
Some programs (and some BIOSes) look for the information stored in the
XBDA at 9FC0, rather than reading the BIOS Data Area at 40:E to find out where
the XBDA really is. When the XBDA has been moved they read whatever has been
written here and misbehave because what they find is completely inappropriate.
If you have a program that malfunctions when QEMM-386 (QEMM 50/60, QRAM) is
loaded and you have an XBDA this switch may remedy the problem. There is a
protocol for moving the XBDA and Quarterdeck obeys it. Not all programs (or,
perhaps, BIOSes) are aware that the XBDA may be moved though.
When the XBDA is not being moved by QEMM-386 (QEMM 50/60, QRAM) then you
will see this line in the First Meg/Overview screen of MANIFEST:
===Conventional memory ends at 639K====
9FC0-9FFF 1K Extended BIOS Data Area
TROUBLESHOOTING
There is no way to know that a program is failing because the XBDA has
been moved except by adding the parameter NOXBDA (NX) to the QEMM386.SYS,
QEMM.SYS, or QRAM.SYS line of the CONFIG.SYS and trying again.
There is hardware that creates an XBDA improperly, without causing the
existence of an XBDA to be properly reported. In some cases a device driver
written by Quarterdeck, MAKEXBDA.SYS, loaded before QEMM-386, QEMM 50/60, or
QRAM, will fix this problem by causing the XBDA to be properly reported. This
driver, zipped together with an explanatory document, is available on the
Quarterdeck BBS.
VIDRAM is reporting: "VIDRAM: Top of memory NOT at 640K" and refusing
to load: What do I do?
If conventional memory is ending at 639K or thereabouts and you have an
XBDA (as discussed above) and the XBDA is just beneath 640K then the XBDA must
be moved for VIDRAM to work. You can use QEMM-386, QEMM 50/60, or QRAM to
perform this task alone. Of course the NOXBDA (NX) parameter cannot be on the
QEMM386.SYS (QEMM.SYS, QRAM.SYS) line of the CONFIG.SYS for them to relocate
the XBDA.
The existence of an XBDA is not the only reason for the top of
conventional memory not being at 640K. Having the page frame at 9000 causes
conventional memory to end at 576K. Other hardware (perhaps a hard disk
controller) can cause it to end at less than 640K. Some viruses can cause
this to happen.
************************************************************************
*This technical note may be copied and distributed freely as long as it*
*is distributed in its entirety and it is not distributed for profit. *
* Copyright (C) 1991-2 by Quarterdeck Office Systems *
************************ E N D O F F I L E *************************