X-Authentication-Warning:	delorie.com: mailnull set sender to opendos-bounces using -f
Message-ID:	<000601c19f8f$55a06800$c03dfea9@atlantis>
From:	"Matthias Paul" <Matthias DOT Paul AT post DOT rwth-aachen DOT de>
To:	<opendos AT delorie DOT com>
References:	<000001c19e43$6c5b3a40$c03dfea9 AT atlantis>
Subject:	Re: More than 32 Mb of EMS memory
Date:	Thu, 17 Jan 2002 20:16:56 +0100
Organization:	University of Technology, RWTH Aachen, Germany
MIME-Version:	1.0
X-Priority:	3
X-MSMail-Priority:	Normal
X-Mailer:	Microsoft Outlook Express 5.50.4522.1200
X-MIMEOLE:	Produced By Microsoft MimeOLE V5.50.4522.1200
X-MIME-Autoconverted:	from quoted-printable to 8bit by delorie.com id g0HJhOT00590
Reply-To:	opendos AT delorie DOT com

On 2002-01-16, I wrote:

> However, if you load a 3rd party XMS-provider which detects more
> than 64 Mb of memory, the DR-DOS EMM386.EXE will also be able to
> handle more memory and provide this as EMS from a shared pool
> with XMS memory.
> For example, if you load the MS-DOS 7.10 HIMEM.SYS before the
> DR-DOS 7.03 EMM386.EXE, HIMEM.SYS will detect more than 64 Mb of
> memory (256 Mb on my system) and provide this as XMS memory.
> DR-DOS EMM386.EXE will then happily take over this memory and
> provide means to allocate up to this much memory as VCPI or EMS
> memory in chunks with up to 64 Mb each. Using the QEMM EMS.COM
> utility I just tried this up to ca. 250 Mb EMS memory on my system,
> but I guess even more would be possible on a system equipped with
> more physical memory.

The last two sentences were not correct...

I thought the allocation limit would be 64 Mb per handle, but this
was only my first impression due to the faulty display of the EMS.COM
tool (from QEMM 7.50) which I was using to test this.

(For those who don´t know, EMS.COM is not any kind of memory manager,
I´m still using DR-DOS EMM386 to provide EMS memory, of course. EMS.COM
is just a small tool which can be used to list the currently allocated
handles ("EMS DIR"), or allocate new handles ("EMS CREATE handle_name
size"), etc. It also provides options to load and save the contents of
an EMS handle from/to a disk file.)

Using only the physically available memory on my machine (256 Mb),
I was able to allocate EMS memory in multiple chunks up to this
limit (240 Mb actually here), or even with a single call with up to
240 Mb in size. Mind again, that the original EMS 4.0 specification
maxes out at 32 Mb total and 32 Mb max per handle. I ran a few simple
"stress tests" like:

 EMS LOAD test1 d:\tmp\srcfile.img
 EMS SAVE test1 d:\tmp\dstfile.img
 FC /B srcfile.img dstfile.img

with srcfile.img being various files with up to 240 Mb in size.
Due to the 16 Kb granularity of EMS allocations, the resulting
file dstfile.img might become up to 16383 bytes larger than the
srcfile.img file, but it is easy to accomodate this for the test.

Of course, I tried various combinations of such tests and so far
it always returned the data unaltered, that is, DR-DOS EMM386
is actually able to correctly handle EMS allocations with more
than 32 Mb per call, and with much more than 32 Mb of total EMS
memory allocated.

Going further, I used Marko Kohtala´s XMSSIZE 1.00 utility (part of
the distribution of his resizeable RAM disk SRDISK 2.08) to make
MS-DOS 7.10 HIMEM.SYS - which I load before DR-DOS 7.03 EMM386.EXE
3.27 - believe, that I would have short to 2 Gb of physical memory
installed, although I have not. (BEWARE: Memory is still allocated
from the bottom up, so you will not normally see it crashing
immediately, but you should never forget that the memory is not
physically there, so this can be used to range check the implementation,
but not to check the data. Be extremely careful and never use any disk
cache while running these tests, and go back to a valid setup ASAP.)

Faking a 2 Gb system, I was able to allocate all this memory through
the DR-DOS EMM386 EMS API. As I predicted from the EMS 4.0 specification,
the maximum possible allocation per chunk was 1 Gb (FFFFh pages a 16 Kb =
1.073.725.440 bytes). Since I only had less than 1 Gb free space on disk,
I experimented with two 900 Mb chunks instead:

EMS CREATE handle_a 900M
EMS CREATE handle_b 900M
EMS SAVE handle_b d:\tmp\dstfile.img (volume must have enough free
                                     space or system will crash!)

Of course, the contents of the DSTFILE.IMG file is worthless, because
the corresponding memory does not physically exist, but this simple
tests leads to the strong assumption that EMM386.EXE is actually
able to handle such large chunks of EMS memory without problems.

I was not able to increase the size of the faked memory beyond
the 2 Gb limit. If I tried, EMM386 rebooted when loading.

This could indicate that some kind of signed arithmetic is
used by EMM386 internally, which overflows at 2 Gb instead
of the physical limit of 4 Gb, but it could also be a problem
elsewhere, for example in the chipset (Intel 430HX) or the
mainboard implementation (missing address wire?). The mainboard
(ASUS T2P4 Rev.3.10 from 1997) is designed to only handle up
to 512 Mb of physical memory, so I cannot be sure about it.

Maybe someone with a newer board and/or more physical memory
installed can try and push the limit up to the CPU´s limit of
4 Gb and test the DR-DOS EMM386 EMS implementation under these
conditions (it should allow to allocate up to 4 handles with
almost 1 Gb associated EMS memory for each of them :-)?

BTW. The per-task-limit under the multitasker remains at 64 Mb
total memory (EMS+XMS), but still beyond the original EMS 4.0
specification.

Finally a few more notes for those who want to experiment, just
because the DOSBOOK documentation is partically misleading in
regard to EMS support:

 EMM386 FRAME=NONE

will *not* disable EMS, it will only disable the 64 Kb page
frame. Most drivers and applications need the frame to map in
their EMS data, and will not be able to use EMS with FRAME=NONE.
However, since EMS 4.0+ it is possible to temporarily map in
a 16 Kb page (almost) anywhere else (for example at an 16 Kb
boundary inside the application itself). Only very few
applications make use of this, QEMM´s EMS.COM appears to be
one of them, because you can still allocate and load/save disk
data to/from allocated EMS handles while using FRAME=NONE.
A few environments like DESQview and Windows 3.x are known
to be able to make use of this as well and map in EMS memory
elsewhere, even below 640 Kb.

To completely disable EMS, you must specify the NOEMS option.
AFAIR this will also disable VCPI.

Experimenting with memory allocations under the multitasker
some may also want to change the default setting, which
makes all allocations before the multitasker global and
all allocations made inside each domain under the multi-
tasker local, so that they are automatically freed when
killing a task - even if the running applications forget
deallocating the memory themselves. There are two
undocumented DR-DOS EMM386.EXE options named

 /EMS=AUTO|LOCAL|GLOBAL

and

 /XMS=AUTO|LOCAL|GLOBAL

If you set them to GLOBAL, allocations made inside a task
will not be freed automatically and will remain allocated
even when exiting the multitasker.
One possible use for this is when you want to resize a RAM
disk under the multitasker (assuming the RAM disk driver
does not block this under a multitasker).

Greetings,

 Matthias

-- 

<mailto:Matthias DOT Paul AT post DOT rwth-aachen DOT de>; <mailto:mpaul AT drdos DOT org>
http://www.uni-bonn.de/~uzs180/mpdokeng.html; http://mpaul.drdos.org

- Raw text -