0fbbc0070c
* Import unmodified USE!UMBS source. From https://forum.vcfed.org/index.php?threads/loading-dos-high-on-a-xt.32320/ * Customize the UMB Driver prompts. * Refactor memory management. Allow activation of EMS/UMB on demand. * Update the XTEMM and XTUMBS drivers to map their ranges. * Add instructions for all the drivers.
693 lines
30 KiB
Plaintext
693 lines
30 KiB
Plaintext
|
||
|
||
|
||
USE!UMBS Documentation Page 1
|
||
==============================================================
|
||
|
||
DOCUMENTATION FOR USE!UMBS.SYS Ver 2.0 Utrecht, 21 Nov 91
|
||
|
||
--------------------------------------------------------------
|
||
|
||
PROGRAM USE!UMBS.SYS
|
||
Upper Memory Block Manager for PC/XT/ATs
|
||
|
||
PURPOSE This program is a device driver that will handle
|
||
calls for Upper Memory Blocks. In doing so, it gives
|
||
you the possibility to save conventional memory by
|
||
storing device drivers and resident programs in the
|
||
UMBs and hence save conventional memory. It takes up
|
||
only 256 bytes of your (conventional) memory and is
|
||
fully compatible with MS-DOS 5.0.
|
||
|
||
REQUIRES It will work on any PC/XT/AT or higher, either with
|
||
or without extended memory. What you obviously
|
||
*must* have are UMBs, and MS-DOS Version 5.0. It
|
||
will not be useful on 386sx or higher.
|
||
|
||
EXTRA'S Since Video-RAM is RAM in Upper Memory too, you can
|
||
use it just as well as other UMBs. You only have to
|
||
take care that you use an UNused part of Video memo-
|
||
ry.
|
||
|
||
PROBLEMS Since ExPANded Memory is remapped to the range of
|
||
addresses where UMBs would normally be, I think this
|
||
program will not cooperate with your expanded memory
|
||
manager. Since I could not test the program on many
|
||
different configurations, I kindly ask you to report
|
||
any problems to me. I don't expect many problems
|
||
though, since USE!UMBS is a `friendly' programme: it
|
||
complies completely with the rules of MS-DOS 5.0.
|
||
|
||
AUTHOR Marco van Zwetselaar Phone: 030-313128
|
||
Oorsprongpark 5 Email: zwets@rivm.nl
|
||
3581 ES Utrecht
|
||
The Netherlands
|
||
|
||
==============================================================
|
||
|
||
|
||
USE!UMBS Documentation Page 2
|
||
==============================================================
|
||
|
||
I wrote this program for my own entertainment, not in order to
|
||
make money. Therefore I dedicate it to the Public Domain. Feel
|
||
free to copy it and pass it on to friends - just make sure
|
||
this documentation file is included.
|
||
|
||
If you find this program useful enough to reward me for writ-
|
||
ing it, you may send me a donation anuwhere from 50 cents upto
|
||
25 guilders. My giro number is 5636618, my snailmail address
|
||
is displayed above.
|
||
|
||
If you have any questions, just contact me via one of the
|
||
above-mentioned addresses. I will be pleased to help you out -
|
||
whether you are a donator or not. Also, if you find any incon-
|
||
sistencies or mistakes in this documentation, please notify me
|
||
of them, so that I can correct them in a possible next versi-
|
||
on. Finally, if you think you can improve the driver, please
|
||
do so. For this purpose I have included the asm-code code in
|
||
the archive. But if you do so: keep it well documented.
|
||
|
||
Marco van Zwetselaar.
|
||
|
||
==============================================================
|
||
|
||
CONTENTS
|
||
|
||
1. General Introduction & Definitions 3
|
||
|
||
2. Preparations 6
|
||
|
||
3. Using VideoRAM 7
|
||
|
||
4. Patching in the Addresses 9
|
||
|
||
5. Installation 12
|
||
|
||
Appendix 1. Functional description of driver (freaks) 13
|
||
|
||
Appendix 2. Detailed description of driver (utter freaks) 14
|
||
|
||
==============================================================
|
||
|
||
|
||
USE!UMBS Documentation Page 3
|
||
==============================================================
|
||
|
||
1. General Introduction & Definition of Terms:
|
||
|
||
In this first section I will explain how the memory on IBM-
|
||
compatibles is organized, and what UMBs actually are. If you
|
||
are not interested in `backgrounds', you may skip this section
|
||
and move on to section 2 (page 6) rightaway. (I advise you to
|
||
at least have a glance at this section though.)
|
||
|
||
Conventional Memory
|
||
Conventional memory is the memory that is present on any
|
||
IBM or compatible. Its maximum size is 640K, and nearly
|
||
all IBM-compatible computers have exactly that amount.
|
||
Conventional memory is used in a conventional way, i.e.
|
||
any user program may make use of it, as may the operating
|
||
system. Actually, most user programs won't even use
|
||
anything except conventional memory (unless specifically
|
||
told to do so). Conventional memory resides in the first
|
||
640K of the adressable memory. That is, at the addresses
|
||
00000-9FFFF.
|
||
|
||
Addressable Memory
|
||
The computer can address more than just 640K of conven-
|
||
tional memory. The maximum amount a specific computer can
|
||
address depends on the type of CPU it has (8086, 80286,
|
||
and so on). But whatever CPU it may have, it can *always*
|
||
address the first 1M of memory. (That's why it is called
|
||
Adressable Memory, I suppose.)
|
||
Addressable Memory consists of two parts: the first 640K
|
||
are Conventional Memory (adresses 00000-9FFFF), the
|
||
remaining 384K are Upper Memory (adresses A0000-FFFFF).
|
||
|
||
Upper Memory
|
||
Upper Memory is the upper 384K of Adressable Memory,
|
||
which begins just beyond the 640K conventional memory
|
||
border. This implies that it is located at the addresses
|
||
A0000-FFFFF.
|
||
|
||
Since Upper Memory is normally addressable on any PC, you
|
||
might wonder why programs don't make use of it. The
|
||
reasons are the following:
|
||
(1) The operating system and the hardware make use of
|
||
parts of it already. For example, anything you see
|
||
on the screen is stored in an area in UM - you can
|
||
probably imagine what will happen if you mess around
|
||
in that area. Also the computer itself will store
|
||
some of its vital data in UM - and we don't want to
|
||
embarrass MS-DOS, who's having hard times already.
|
||
|
||
==============================================================
|
||
|
||
|
||
USE!UMBS Documentation Page 4
|
||
==============================================================
|
||
|
||
(2) Even if there are parts of Upper Memory that are not
|
||
in use already, these parts may not be RAM. What
|
||
this means is that one may *read* data from those
|
||
locations, but not *write* anything into them. (In
|
||
fact, you can try and write something into them, but
|
||
it will vanish mysteriously into thin air.)
|
||
Most computers don't have RAM in these areas, first-
|
||
ly because that would make the computer more expen-
|
||
sive, and secondly because MS-DOS was not designed
|
||
to use anything above the 640K border anyway.
|
||
(3) Even if there are unused parts of UM that do consist
|
||
of RAM (readable & writeable memory), dos will not
|
||
normally make them available as conventional memory.
|
||
This is precisely why I wrote this device driver:
|
||
since Version 5.0, Dos can use the UMBs to store
|
||
prog- rams, namely device drivers and TSRs. Device
|
||
drivers are the files that you install via the DEVI-
|
||
CE=... lines in your config.sys; they take care of
|
||
interfacing dos with your hardware. Dos usually
|
||
loads these devices in conventional memory. If you
|
||
have UMBs (or a 386) you can load the devices into
|
||
them using the DEVICEHIGH=... statement, instead of
|
||
the DEVICE=... statement. TSRs (Terminate and Stay
|
||
Resident) programs are programs that stay in memory
|
||
after they are executed. Some of these programs stay
|
||
resident so that you can invoke them during other
|
||
programs using a HotKey (sidekick for example),
|
||
others stay resident because they perform tasks in
|
||
the background (like screenblankers, autopark, dos-
|
||
key, fastopen, etc). Normally, TSRs will be loaded
|
||
into conventional memory. Dos 5.0 provides the com-
|
||
mand LOADHIGH (may be abbreviated to LH) to put them
|
||
into the UMBs. You do this by preceding the TSR's
|
||
invocation line in the autoexec.bat by LH (or LOAD-
|
||
HIGH). So, if you 'd normally use "FASTOPEN C:=200",
|
||
you now put "LH FASTOPEN C:=200" in the autoexec.
|
||
|
||
Extended Memory
|
||
Extended Memory is, by definition, all memory that is
|
||
located beyond the 1MB border. So, its addresses start at
|
||
100000. Since a computer needs to have more than 20
|
||
address lines in order to address such large addresses,
|
||
PCs and XTs can't have extended memory (they have preci-
|
||
sely 20 lines). On an AT or higher one can access exten-
|
||
ded memory by enabling address lines A20 (and higher - if
|
||
you start counting at 0, that is the 21st line and hig-
|
||
her).
|
||
|
||
==============================================================
|
||
|
||
|
||
USE!UMBS Documentation Page 5
|
||
==============================================================
|
||
|
||
So in order to make use of extended memory, a program
|
||
must have a special design - more and more programs are
|
||
offering eXtended memory support. But since many programs
|
||
use eXtended memory in many different ways, conflicts may
|
||
arise. In order to resolve these, a standard way of
|
||
accessing extended memory was developed.
|
||
This is specified in the XMS (eXtended Memory Specifica-
|
||
tion). MS-Dos 5.0 provides you with a manager for XM -
|
||
this manager will 'hand out' extended memory to programs
|
||
that make a request according to XMS specs. The problem
|
||
with dos's XMS-manager (HIMEM.SYS) is that it doesn't
|
||
handle requests for UMBs (they simply haven't implemented
|
||
that function, probably because most XTs and ATs don't
|
||
have UMBs anyway). What MicroSoft does provide is
|
||
EMM386.EXE, which is an exPANded memory manager that
|
||
handles UMB-requests as a side-effect. The problem is
|
||
that this manager can only be installed on 386s or hig-
|
||
her. The reason for this is that only a 386 has the
|
||
ability to 'remap' expanded memory to UMB locations, thus
|
||
providing RAM in Upper Memory locations.
|
||
|
||
So, what can you do if you have UMBs on an XT or AT?
|
||
Suppose you have extended memory - so you can install
|
||
HIMEM.SYS - then you still can't use the UMBs because
|
||
EMM386.EXE won't work on your machine... Now say you
|
||
have no extended memory *at all* (which will always be
|
||
the case on an XT), then you can't load himem in the
|
||
first place! In both cases, USE!UMBS will be the right
|
||
thing to use.
|
||
|
||
HMA - High Memory Area
|
||
The HMA is the first block of 64K of extended memory (so
|
||
with addresses 100000-10FFFF). Since Dos 5.0, it is
|
||
possible to load the system files into this area. (System
|
||
files are *not* the devices that you install: dos in-
|
||
stalls them at boot-time!)
|
||
In order to highload these systemfiles, you must have
|
||
extended memory, and insert the lines DEVICE=HIMEM.SYS
|
||
and DOS=HIGH at the front of your config.sys file. If you
|
||
don't have an HMA, then you can not use dos=high. You can
|
||
use dos=umb though.
|
||
|
||
Expanded Memory
|
||
Expanded memory can't be defined in terms of 'adresses',
|
||
since it is organized altogether differently. It resides
|
||
on a separate 'card' that you plug into a free slot in
|
||
your computer, and it cannot be accessed all at once but
|
||
in 'pages'.
|
||
|
||
==============================================================
|
||
|
||
|
||
USE!UMBS Documentation Page 6
|
||
==============================================================
|
||
|
||
What happens is that pages of say 16K are 'remapped' from the
|
||
expanded memory board to addresses in Upper Memory. If the
|
||
computers wants to find something in an area elsewhere on the
|
||
card, an expanded memory manager must take care of storing the
|
||
present page and making the new page active. As was the case
|
||
with XMS, people have also devised a standard for access to
|
||
expanded memory. This standard is the LIM/EMS specification
|
||
(now at revision 4.0). Dos 5.0 provides a manager for it:
|
||
EMM386.EXE. As said before, this manager will only work on a
|
||
386, and since it takes care of the UMBs too, you are advised
|
||
to rather use EMM386 when you have a 386 or higher. (USE!UMBS
|
||
will, in fact, not install if it finds out that a UMB manager
|
||
was installed already.)
|
||
|
||
==============================================================
|
||
|
||
2. Preparations
|
||
|
||
This program will install a UMB manager on any PC, XT, AT or
|
||
higher, whether it has extended or expanded memory or not. In
|
||
order to be able use it, it must have UMBs, i.e. holes in the
|
||
memory-area between 640k and 1M that are filled with RAM.
|
||
|
||
How do you find out whether you have UMBs? Firstly, let me say
|
||
that there are not many PC/XT/ATs that do have them (refer to
|
||
section 1 if you want to find out why). One XT that I know of
|
||
certainly has them, namely the Philips 31xx series XTs. I ori-
|
||
ginally wrote the program for precisely that machine. Later on
|
||
I found out it might be useful for other machines as well.
|
||
|
||
If you want to find out whether you have UMBs, run the program
|
||
TEST!UMB.EXE. This program will run through the upper memory
|
||
and try if it can write information there. (By the way: don't
|
||
worry. It won't destroy anything while doing that!)
|
||
|
||
The locations where TEST!UMB can succesfully change values are
|
||
RAM locations. It will display a table with its findings, sta-
|
||
ting:
|
||
"None at paragraphs xxxx until xxxx" or
|
||
"Found RAM at paragraphs xxxx until xxxx"
|
||
|
||
Don't be too optimistic if it displays a range of adresses
|
||
where it finds RAM: it will always find at least one such
|
||
range! That range is occupied with Video-RAM, and you can't
|
||
simply use all of that as a UMB (refer to section 1 for de-
|
||
tails).
|
||
|
||
==============================================================
|
||
|
||
|
||
USE!UMBS Documentation Page 7
|
||
==============================================================
|
||
|
||
So now comes the tricky bit: which ranges can you use?
|
||
First of all, if TEST!UMB shows that there is RAM in the range
|
||
D000 until EFFF, then you have "true" UMBs. And you can use my
|
||
device driver rightaway. These two blocks (the D and the E
|
||
block) provide you with 128K of Upper Memory - probably by far
|
||
enough to store all of your device drivers and TSRs.
|
||
So, if you are in that lucky situation and don't want to
|
||
complicate matters, you can move on to section 5 (Installa-
|
||
tion, page 12) rightway.
|
||
|
||
If you were less fortunate and TEST!UMB showed that there is
|
||
no RAM in that range, or in only a part of that range, or if
|
||
you don't want to use all of that range, or if you want to use
|
||
more than one range, then you should read section 3 and/or
|
||
section 4.
|
||
|
||
==============================================================
|
||
|
||
3. Using VideoRAM or other ranges as a UMB
|
||
|
||
If you don't have RAM in the D000-EFFF range, or if you want
|
||
to use a different range of memory, then you must make a small
|
||
modification to the driver: you must `patch in' the addresses
|
||
that it should manage.
|
||
This may sound difficult, and yes, it is not simple... The
|
||
point is that I had wanted to use command line parameters to
|
||
specify the range(s) the driver should manage... but I don't
|
||
know how to program that option. [So, If YOU are a proficient
|
||
Assembly programmer, please change the source code and include
|
||
that option!]
|
||
|
||
Anyway, let's go for it:
|
||
If TEST!UMB showed that you have RAM outside the D000-EFFF
|
||
range, that RAM may be of three kinds:
|
||
(1) Completely free RAM - not used by the videocard or by any
|
||
other program. This is good news: you can use it as a UMB
|
||
without any problems - you only have to patch the addres-
|
||
ses into USE!UMBS.SYS.
|
||
(2) Graphics VideoRAM - this is only used by the video system
|
||
when you are working in graphics mode. If you don't use
|
||
graphics, you may use this RAM as a UMB. Beware to boot
|
||
your computer without USE!UMBS.SYS if you intend to use
|
||
graphics programs! (It won't damage anything, though,
|
||
your computer will simply hang once it switches to grap-
|
||
hics mode.)
|
||
(3) Text VideoRAM - sorry, but you really can't use this. If
|
||
you would, then how could you get anything on the screen?
|
||
|
||
==============================================================
|
||
|
||
|
||
USE!UMBS Documentation Page 8
|
||
==============================================================
|
||
|
||
Finding out to which of the three categories your RAM belongs
|
||
is complicated: it depends on your videocard. I will try and
|
||
describe as well as I can what ranges each videocard uses. As
|
||
said above: you can use any range as long as it doesn't inclu-
|
||
de the Text Range; and you may use the Graphics Range, but
|
||
only if you don't switch to graphics mode. Read the Advice
|
||
carefully - but note that this doesn't guarantee anything!
|
||
(Thanks to Eef Hartman for the information about addresses.)
|
||
|
||
Monochrome Display Adapter (MDA)
|
||
TEXT : B000-B0FF (4K)
|
||
GRAPHICS : None (0K)
|
||
ADVICE This is a very old-fashioned one. It was in the
|
||
original IBMs. It can't do any graphics, only text.
|
||
So if you appear to have *any* RAM outside the text
|
||
range specified above: use it.
|
||
|
||
Color Graphics Adapter (CGA)
|
||
TEXT : B800-B8FF (4K)
|
||
GRAPHICS : B800-BBFF (16K)
|
||
ADVICE If there is any RAM outside the graphics range
|
||
(B800-BBFF) then that RAM is not used by the CGA
|
||
adaptor, and you may problemlessly use it.
|
||
If you want to use the graphics range, take care:
|
||
this may give problems since the CGA adapter often
|
||
uses it as 4 pages of text.
|
||
|
||
Hercules Adapter
|
||
TEXT : B000-B0FF (4K)
|
||
GRAPHICS : B000-BFFF (64K) full
|
||
or : B000-B7FF (32K) half
|
||
ADVICE If there is any RAM outside the graphics range
|
||
(B000-BFFF) then that RAM is not used by the Hercu-
|
||
les adaptor, and you may problemlessly use it.
|
||
If you want to use the graphics range, take care:
|
||
the hercules adapter may use the first half of its
|
||
RAM (B000-B7FF) to store several text pages. So if
|
||
you want to use the graphics range, use B800-BFFF.
|
||
If you have a half (1 page) hercules, then you don't
|
||
have that range.
|
||
|
||
==============================================================
|
||
|
||
|
||
USE!UMBS Documentation Page 9
|
||
==============================================================
|
||
|
||
Enhanced Graphics Adapter (EGA)
|
||
TEXT : B000-B0FF (4K) mono mode
|
||
: B800-B8FF (4K) color mode
|
||
GRAPHICS : A000-AFFF (64K)
|
||
ADVICE As you see, you can use the A segment as a UMB if
|
||
you don't use graphics applications.
|
||
You may also use parts of the B segment, but notice
|
||
that the EGA card will use one of the two text are-
|
||
as: the lower one when it is in mode MONO, the upper
|
||
one when it is in mode CO80.
|
||
|
||
V? Graphics Adapter (VGA)
|
||
TEXT : same as EGA
|
||
GRAPHICS : same as EGA, but sometimes also the range
|
||
B000-BFFF (64K)
|
||
ADVICE There is a large variety of VGA cards. I can't tell
|
||
you precisely what ranges you may use. What is sure
|
||
is that you can follow the advice of the EGA card:
|
||
as long as you don't use graphics, the A000-AFFF
|
||
range is at your disposal.
|
||
|
||
==============================================================
|
||
|
||
4. Patching in the addresses
|
||
|
||
This is the hardest bit. As I mentioned before, I wrote this
|
||
driver for the Philips 35xx series, so it will by default only
|
||
manage the block from D000 until EFFF. If you don't have that
|
||
entire block at your disposal, you will have to change some
|
||
code in the file. I will describe below how you can patch in
|
||
the adresses using the DEBUG program, which you will have,
|
||
since it came with the MS-DOS package.
|
||
|
||
First of all, you need to know the addresses of the block(s)
|
||
you want to patch in. The maximum number of separate blocks
|
||
you can patch in is three. I don't think you will need more
|
||
than that; if you think you do, contact me, and I can fix it
|
||
for you. (As long as the RAM is contiguous, you can specify it
|
||
in one block, however long the contiguous block is.)
|
||
|
||
Once you know the starting and the ending address of a block,
|
||
you should calculate its length (in paragraphs). How do you do
|
||
that? You simply subtract the beginning address from the end
|
||
adress, USING HEXADECIMAL CALCULATION. [Hex calculation goes
|
||
just like decimal calculation, only that the numbers 10
|
||
through 15 are changed to A through F]
|
||
|
||
==============================================================
|
||
|
||
|
||
USE!UMBS Documentation Page 10
|
||
==============================================================
|
||
|
||
Some examples:
|
||
|
||
End address : AFFF BFFF BBFF E7FF EFFF EFFF
|
||
Begin address : A000 B800 B0FF E000 D7FF D000
|
||
------------- - ---- ---- ---- ---- ---- ----
|
||
Length : 0FFF 07FF 0B00 07FF 1800 1FFF
|
||
|
||
So, what you do is (just as with decimal calculation): go from
|
||
right to left and each time subtract two digits. If you have
|
||
to `borrow' you can do so. Keep in mind that e.g. F-7=8 (bec-
|
||
ause 15-7=8) and that 10-8=8, because 16-8=8.
|
||
|
||
Ok, now you must patch the starting address and the length of
|
||
each block into USE!UMBS.SYS. Only ... there is a twist now:
|
||
both values have to be reversed bytewise before being patched
|
||
in. It's best to explain this using an example: suppose you
|
||
have a block, which starts at B800 and has length 07FF, then
|
||
you reverse the bytes as follows:
|
||
|
||
Address Length
|
||
B8 00 07 FF
|
||
\ / \ /
|
||
/ \ / \
|
||
00 B8 FF 07
|
||
|
||
So, the sequence B800 07FF becomes 00 B8 FF 07. And this is
|
||
the sequence we will patch in. If you have more blocks, trans-
|
||
pose them in the same way, and append them to this sequence.
|
||
(But *never* more than three blocks in total!!!)
|
||
|
||
Then startup the debug program with the following command:
|
||
|
||
DEBUG USE!UMBS.SYS
|
||
|
||
and debug will report with its prompt:
|
||
-
|
||
(if this doesn't happen: make sure debug is in the search path
|
||
and use!umbs.sys is in the current directory. You can type Q
|
||
to exit from debug).
|
||
|
||
Now type:
|
||
|
||
-E153
|
||
|
||
(don't type the hyphen, and finish with carriage return)
|
||
and debug will say this
|
||
|
||
xxxx:0153 00._
|
||
|
||
==============================================================
|
||
|
||
|
||
USE!UMBS Documentation Page 11
|
||
==============================================================
|
||
|
||
Now, type the first byte of your sequence, and finish with a
|
||
SPACE, NOT A CARRIAGE RETURN!!!. So, if your first byte was
|
||
(for example) AB, you will now see something like this:
|
||
|
||
xxxx:0153 00.AB D0._
|
||
|
||
Now, type the next byte, AGAIN FOLLOWED BY A SPACE, NOT A
|
||
CARRIAGE RETURN! And keep on doing this until you have entered
|
||
the whole sequence (which amounts to 4 bytes for one block, 8
|
||
bytes for two blocks, 12 for three blocks). After having
|
||
completed this, STILL DON'T PRESS CARRIAGE RETURN, but enter
|
||
another four bytes, all with value 00, every time using the
|
||
spacebar to move to the next. (These 00-bytes signal the end
|
||
of the list.)
|
||
|
||
If you have done that, you may now finally press RETURN to get
|
||
back to the debug-prompt. If you made any mistakes, you can
|
||
now press Q to quit without changes, but if everything went
|
||
alright, press W to write away the changes. (And afterwards Q
|
||
to exit the programme.)
|
||
|
||
Well, that was it... Now you can continue to the next section
|
||
and finally install USE!UMBS.SYS.
|
||
|
||
==============================================================
|
||
|
||
|
||
USE!UMBS Documentation Page 12
|
||
==============================================================
|
||
|
||
5. Installation
|
||
|
||
In order to install USE!UMBS.SYS, follow the following three
|
||
steps carefully.
|
||
|
||
STEP I: Tell DOS to install the device driver.
|
||
You do this by adding this line to your config.sys:
|
||
DEVICE=USE!UMBS.SYS
|
||
(Provided USE!UMBS.SYS is in the root directory.)
|
||
The position at which this line is placed is important! If you
|
||
have an extended or expanded memorymanager (like HIMEM.SYS),
|
||
then the line DEVICE=USE!UMBS.SYS must come *after* the line
|
||
specifying the other manager. On the other hand, it must come
|
||
*before* any other line that starts with DEVICE=.
|
||
On the whole: put it as much as possible toward the beginning
|
||
of your config.sys, but never before the installation line of
|
||
an XMS or EMS driver.
|
||
|
||
STEP II: Tell DOS to actually use the UMBs
|
||
You do this as follows: If there is a line saying DOS=HIGH in
|
||
your config.sys, then change it to DOS=HIGH,UMB. If there is
|
||
no such line, then add the line DOS=UMB to the config.sys.
|
||
Also here, position is important: make sure the line is on the
|
||
*very first* line of your config.sys. (And therefore comes
|
||
somewhere before DEVICE=USE!UMBS.SYS)
|
||
|
||
STEP III: Tell DOS which things to put in the UMBs
|
||
There are two kinds of things that can be put in the UMBs:
|
||
device drivers and TSRs. Device drivers are `highloaded' by
|
||
changing their lines in the config.sys from DEVICE=... to
|
||
DEVICEHIGH=.... The TSRs are highloaded by preceding their
|
||
invocation line in the autoexec.bat with LOADHIGH (or LH). So:
|
||
if there formerly was a line saying AUTOPARK in your auto-
|
||
exec.bat, now it should become LH AUTOPARK.EXE or LOADHIGH
|
||
AUTPARK.EXE.
|
||
[NOTE: Some people load TSRs via the config.sys instead of the
|
||
autoexec.bat by using the line INSTALL=.... If this is the
|
||
case, you better remove them from the config.sys and LOADHIGH
|
||
them via the autoexec.bat.]
|
||
|
||
Well, that's all there is to it.
|
||
Once you have made all the changes, try MEM to see how much
|
||
memory you have left. Then reboot (and see USE!UMBS sign on),
|
||
wait for the DOS-prompt and then run MEM again. Calculate the
|
||
difference USE!UMBS makes. Now divide this difference by 2000.
|
||
The result is - in my humble opinion - a reasonable donation
|
||
for the author. (But, of course, it's up to you...)
|
||
|
||
==============================================================
|
||
|
||
|
||
USE!UMBS Documentation Page 13
|
||
==============================================================
|
||
|
||
Appendix 1. Functional description of the driver
|
||
(for the freaks).
|
||
|
||
This program is a device driver that will install a routine
|
||
that handles requests for UMBs. These requests are made by
|
||
MS-Dos if it has read the statement DOS=[high,]UMB in the
|
||
config.sys file and encounters a DEVICEHIGH or a LOADHIGH
|
||
statement. (For more information about devicehigh and loadhigh
|
||
see the MS-Dos 5.0 manual.)
|
||
|
||
The UMB-requests are normally sent to the extended memory
|
||
manager, which, in the case of Dos 5.0, is HIMEM.SYS. There
|
||
are two problems here. Firstly, if you don't have extended
|
||
memory, you cannot have Himem.sys installed. And since PCs and
|
||
XTs can't even have extended memory, they can never install
|
||
himem.sys. Secondly, even if you DO have extended memory AND
|
||
install Himem.sys, you still have no access to the UMBs becau-
|
||
se Himem doesn't implement a UMB manager, only an XMS handler.
|
||
The UMB-handler is provided by a separate device driver,
|
||
namely EMM386.SYS. And yes, as the name suggests, you can't
|
||
install this on an AT (286).
|
||
|
||
So, what this USE!UMBS does is the following: it will install
|
||
a routine that will intercept any requests to the extended
|
||
memory manager. It then checks this request in order to see if
|
||
it is a request for UMBs. If it is, then it will handle the
|
||
request, otherwise it will pass them on to the XMS handler. If
|
||
you don't have an XMS driver installed (which is quite fair if
|
||
you don't have eXtended memory), USE!UMBS will not forward the
|
||
request but answer it with a polite "no", so that nothing will
|
||
hang or mess up. (So, in a way, USE!UMBS will install a HIMEM
|
||
manager too - but since there is no high memory to manage, it
|
||
won't have much to do anyway.)
|
||
|
||
==============================================================
|
||
|
||
|
||
USE!UMBS Documentation Page 14
|
||
==============================================================
|
||
|
||
Appendix 2. Technical description of the driver
|
||
(details for the real freaks)
|
||
|
||
A request to the XMS manager goes in two steps. First, the
|
||
caller will want to find out whether there is a manager and,
|
||
if so, where it is. Second, it will call the manager with a
|
||
specification of what it should do.
|
||
|
||
The first step is done via interrupt 2Fh (the multiplexer).
|
||
This interrupt handles a lot of very different requests, which
|
||
it classifies by looking in the AH register. If this contains
|
||
43h, the request is for the XMS manager. So what we do is
|
||
chain a little bit of code to the front of the interrupt 2Fh
|
||
handler - this added code will determine if AH=43h. If it is
|
||
not, it gives control back to the old INT 2F handler, if it
|
||
is, it will take over.
|
||
|
||
Once it has taken over, it will check the AL register. This
|
||
register specifies the precise nature of the question. It can
|
||
contain only two possible values: 00h and 10h. If it contains
|
||
00h, this means that the question is "Hullo! Is there any
|
||
XMS-manager installed?", and our response should be "Yo!"
|
||
(because that's exactly what we are installing). We signal a
|
||
yes by returning 80h in the AL register. If AL contains 10h
|
||
upon entry, then the question is "Well then, where can I find
|
||
that XMS manager?". So in this case we return its address in
|
||
the registers ES:BX. The address we pass is, yes, the address
|
||
of the XMS manager that we are installing.
|
||
|
||
The second step. After the caller has used the interrupt
|
||
described above to find out about the existence (4300) and the
|
||
whereabouts (4310) of the XMS manager, it will at some point
|
||
call it. It calls it by simply making a FAR JMP to the address
|
||
that was previously specified in ES:BX.
|
||
|
||
Upon entering the XMS manager, we first have to check its AH
|
||
register in order to find out whether the request is for UMBs
|
||
or for extended memory. If it is anything else than 10h (= "I
|
||
want a UMB"), our UMB-manager will do the following: (a) IF
|
||
another XMS-manager (like MS-Dos's HIMEM.SYS) was loaded
|
||
before, it will pass the request on to that manager, (b) IF
|
||
NOT, it will return an errorcode saying that there is no XMS
|
||
memory. If the request actually is for UMBs (AH=10h), then it
|
||
will provide them as long as there are any.
|
||
|
||
[END OF DOCS]
|
||
==============================================================
|