DPMI-Alloc with 192MB RAM - how ?
DrFoerst
I have the problem to allocate a large block of RAM (about 150MB in one piece,
the machine has 192MB built in). I use Watcom C++, the prog runs under MSDOS
6.22 or DOS7.0 with himem/emm386. Currently, using PMODE/W, I can only get
about 96MB of the RAM, the rest seems unavailable, but mem.exe tells me there
are 199.000 KB there.
What must I do to get ALL of the RAM in my program ???
Please mail me, since I don't read this group:
in...@drfoerst.de,
or m.b...@oberberg-online.de
Thanks !
Michael Barth
Eli Zaretskii
On Tue, 20 Jul 1999 varo...@colba.net wrote:
> DJGPP can only reconise the first 128MB of physical and virtual RAM. So you
> can only use the first 128MB of memory you have.
Not true. DJGPP has no internal limits on the memory size, except the
basic 2GB limit of 32-bit address space. CWSDPMI supports up to 256MB
of RAM, see the FAQ.
(There are some known bugs in CWSDPMI when you approach the 256MB
limit, though. These should be fixed with the next release of
CWSDPMI.)
Eli Zaretskii
On 20 Jul 1999, DrFoerst wrote:
> I have the problem to allocate a large block of RAM (about 150MB in one piece,
> the machine has 192MB built in). I use Watcom C++, the prog runs under MSDOS
> 6.22 or DOS7.0 with himem/emm386. Currently, using PMODE/W, I can only get
> about 96MB of the RAM, the rest seems unavailable, but mem.exe tells me there
> are 199.000 KB there.
>
> What must I do to get ALL of the RAM in my program ???
Are you asking this for a Watcom program or for a DJGPP program?
For Watcom, please refer to their tech support, this news group is for
DJGPP-related discussions.
For DJGPP, the FAQ is the place to look for answers for such
questions. Check out the recommendations in section 3.10 of the DJGPP
FAQ list. In particular, they specifically tell you to use CWSDPMI,
not PMODE, and not to install *any* memory manager.
mdru...@cs.vu.nl
> Not true. DJGPP has no internal limits on the memory size, except
> the basic 2GB limit of 32-bit address space. CWSDPMI supports up to
> 256MB of RAM, see the FAQ.
IIRC, CWSDPMI only supports up to 128MB of *virtual* memory. At least,
it doesn't give me more than that.
Groente, Michel.
Eli Zaretskii
On Thu, 22 Jul 1999 mdru...@cs.vu.nl wrote:
> IIRC, CWSDPMI only supports up to 128MB of *virtual* memory. At least,
> it doesn't give me more than that.
No, it supports up to 256MB of physical and additional 256MB of paged-out
memory, for a grand total of 512MB of vurtual memory. If this doesn't
work for you, either you have an old version of CWSDPMI (before r4), or
something is wrong in your setup, or some memory manager you install
prevents CWSDPMI from giving you more.
Martin Str|mberg
Hmm. My lastest box (the screaming 20MHz with 4MB of RAM) seems to
think differently:
Filesystem Type 1024-blocks Used Available Capacity Mounted on
\\KANT\TMP net 2402586 2028571 374015 84% t:/
go32/v2 version 2.0 built Mar 20 1999 14:47:50
Usage: go32 coff-image [args]
Rename this to go32.exe only if you need a go32 that can run v2 binaries as
well as v1 binaries (old makefiles). Put ahead of the old go32 in your PATH
but do not delete your old go32 - leave it in the PATH after this one.
Set GO32_V2_DEBUG=y in the environment to get verbose output.
DPMI memory available: 3414 Kb
DPMI swap space available: 129818 Kb
cwsdpmi -p -st:\cwsdpmi.swp
CWSDPMI V0.90+ (r4) Copyright (C) 1997 CW Sandmann ABSOLUTELY NO WARRANTY
And doing a simplistic "b = (char *)malloc(A_LOT); for(i=0; i < A_LOT;
i += 4096) { b[i] = 1; }" verifies that only ~128MB is available.
Can it be the low amount of RAM (4MB) that cause this?
Right,
MartinS
Charles Sandmann
> : memory, for a grand total of 512MB of vurtual memory. If this doesn't
> : work for you, either you have an old version of CWSDPMI (before r4), or
> : something is wrong in your setup, or some memory manager you install
> : prevents CWSDPMI from giving you more.
>
> Hmm. My lastest box (the screaming 20MHz with 4MB of RAM) seems to
> think differently:
> DPMI memory available: 3414 Kb
> DPMI swap space available: 129818 Kb
Okay, I just found out my news server has been eating all posts for the last
6 months or so -- let me summarize!
1) To provide more than 128Mb virtual memory you need to use CWSPARAM to
increase the max swap file size. This eats up DOS 640K memory - about
32 bytes for each 1 Mb maximum swap usage (for the bitmap). This would
be an extra 4K of DOS memory to go from 128Mb virtual to 256Mb virtual.
2) To provide more than 64Mb physical memory, you need HIMEM.SYS from a
Win 9x release or a commercial memory manager. The BIOS calls only
support 64Mb max (best case) and only 16Mb max (worse case) - so this
might be all you see with an empty config.sys. Adding EMM386 may
decrease the amount of memory available, so if you need a lot of memory
and use EMM386 (for UMBs?) use NOVCPI and/or NOEMS.
3) There is a BUG in r4 which prevents usage of more than 255Mb total virtual
memory. If you have 128Mb or more of physical memory you need to run
CWSPARAM to decrease your swap file size so the total available is less
than 255Mb. If you don't - then you can't even use all the physical
memory without page fault bugs! (Example: 120Mb max on a 128Mb machine).
4) There is a BUG in r4 which prevents usage of more than 128Mb physical
memory (even worse, any physical address above the 128Mb mark!)
5) I have fixed the bugs in 3 & 4 in a beta WIP r5. The new release will
support 2Gb total memory - I have personally tested 1.2Gb of total memory
(1Gb physical, 200Mb virtual) on the WIP version. I'm busy at work and
probably won't get it done for another month or two.
6) I'm considering low effort requests for r5.
mdru...@cs.vu.nl
> 1) To provide more than 128Mb virtual memory you need to use
> CWSPARAM to increase the max swap file size.
I didn't know that. Or maybe I forgot it. Thanks, I will try it right
away. Somehow compiling some C++ files requires more than 140Mb of
memory...
--
Groeten, *Michel* _http://www.cs.vu.nl/~mdruiter_
____________
\ /====\ / "You know, Beavis, you need things that suck,
\/ \/ to have things that are cool", Butt-Head.
Martin Stromberg
: 1) To provide more than 128Mb virtual memory you need to use CWSPARAM to
: 32 bytes for each 1 Mb maximum swap usage (for the bitmap). This would
: be an extra 4K of DOS memory to go from 128Mb virtual to 256Mb virtual.
: 2) To provide more than 64Mb physical memory, you need HIMEM.SYS from a
: Win 9x release or a commercial memory manager. The BIOS calls only
: support 64Mb max (best case) and only 16Mb max (worse case) - so this
: might be all you see with an empty config.sys. Adding EMM386 may
: decrease the amount of memory available, so if you need a lot of memory
: and use EMM386 (for UMBs?) use NOVCPI and/or NOEMS.
: 3) There is a BUG in r4 which prevents usage of more than 255Mb total virtual
: memory. If you have 128Mb or more of physical memory you need to run
: CWSPARAM to decrease your swap file size so the total available is less
: than 255Mb. If you don't - then you can't even use all the physical
: memory without page fault bugs! (Example: 120Mb max on a 128Mb machine).
: 4) There is a BUG in r4 which prevents usage of more than 128Mb physical
: memory (even worse, any physical address above the 128Mb mark!)
: 5) I have fixed the bugs in 3 & 4 in a beta WIP r5. The new release will
: support 2Gb total memory - I have personally tested 1.2Gb of total memory
: (1Gb physical, 200Mb virtual) on the WIP version. I'm busy at work and
: probably won't get it done for another month or two.
: 6) I'm considering low effort requests for r5.
Regarding 1):
4KB is a small price to pay (IMHO). Why not set the maximum as default?
Right,
MartinS
Charles Sandmann
> : increase the max swap file size. This eats up DOS 640K memory - about
> : 32 bytes for each 1 Mb maximum swap usage (for the bitmap). This would
> : be an extra 4K of DOS memory to go from 128Mb virtual to 256Mb virtual.
> 4KB is a small price to pay (IMHO). Why not set the maximum as default?
In r5 the maximum will be 2Gb which would consume an extra 64Kb. Dos memory is
a precious resource which is needed for DMA buffers, nested images, and
pagetables. The number of users which needed more than 128Mb of virtual
memory (in 1995 it would take about 2 minutes just to read that from disk
and another 2 minutes to write it...) is very, very small. I'm open to what
the default should be, but I figured 128Mb virtual was enough. If you need
to run something that big you probably ought to buy more real memory :-)
Martin Str|mberg
: In r5 the maximum will be 2Gb which would consume an extra 64Kb. Dos memory is
: a precious resource which is needed for DMA buffers, nested images, and
: pagetables. The number of users which needed more than 128Mb of virtual
Are you saying this extra 64KB (or 4KB) is needed for every nested
program?
: memory (in 1995 it would take about 2 minutes just to read that from disk
: and another 2 minutes to write it...) is very, very small. I'm open to what
: the default should be, but I figured 128Mb virtual was enough. If you need
: to run something that big you probably ought to buy more real memory :-)
Yeah, max. 2GB is cool! Will there be any limitations on how much of
those 2GB needs to be physically present?
Kokkonen, Sinfonia da camera,
MartinS
Charles Sandmann
> : In r5 the maximum will be 2Gb which would consume an extra 64Kb. Dos memory is
> : a precious resource which is needed for DMA buffers, nested images, and
> : pagetables. The number of users which needed more than 128Mb of virtual
>
> Are you saying this extra 64KB (or 4KB) is needed for every nested
> program?
No, only once for the DPMI provider. But page tables for large memory is
a big problem. It takes 4Kb for each 4Mb memory address space you have
touched. So, if you want to use 384Mb physical memory (no virtual) then
you need 384Kb of memory just for the page tables. With DOS needs, DJGPP
low memory needs, and other DPMI needs - you can't afford to just waste
any of it. Some very small memory machines (640K/1Mb total memory 386s)
are supported by CWSDPMI - and it must use DOS memory for all purposes.
The extra 64K would cut your memory usage without paging by 64Mb, and 64Kb
of DPMI on a 640K machine makes a huge performance difference.
> Yeah, max. 2GB is cool! Will there be any limitations on how much of
> those 2GB needs to be physically present?
No - you should be able to run a 2Gb program on a 640K machine if you have
enough disk and patience. This requires faulting the page tables themselves
which can really slow things down.
Dave Bird
<sand...@clio.rice.edu> writes
>> Charles Sandmann (sand...@clio.rice.edu) wrote:
>> : In r5 the maximum will be 2Gb which would consume an extra 64Kb. Dos memory
>is
>> : a precious resource which is needed for DMA buffers, nested images, and
>> : pagetables. The number of users which needed more than 128Mb of virtual
>> : is very small ...
>>
>> Are you saying this extra 64KB (or 4KB) is needed for every nested
>> program?
>
>No, only once for the DPMI provider. But page tables for large memory is
>a big problem. It takes 4Kb for each 4Mb memory address space you have
>touched. So, if you want to use 384Mb physical memory (no virtual) then
>you need 384Kb of memory just for the page tables. With DOS needs, DJGPP
>low memory needs, and other DPMI needs - you can't afford to just waste
>any of it. Some very small memory machines (640K/1Mb total memory 386s)
>are supported by CWSDPMI - and it must use DOS memory for all purposes.
Charles, couldn't the program either (1) suggest a default supported
size based on knowing how much DOS memory there is, or (2) simply be
recompilable with options for different large memory configurations?
Then everyone would be happy.
--
^-^-^-@@-^-;-^ http://www.xemu.demon.co.uk/
(..)__u news:alt.smoking.mooses
Martin Str|mberg
: Charles, couldn't the program either (1) suggest a default supported
: recompilable with options for different large memory configurations?
: Then everyone would be happy.
Ahum! Doesn't "CWSPARAM" do (2)? Or am I missing something?
Cocteau Twins, Heaven or Las Vegas,
MartinS
Charles Sandmann
> size based on knowing how much DOS memory there is, or (2) simply be
> recompilable with options for different large memory configurations?
CWSDPMI tries to do 1) right now - but it's hard to anticipate if the
first program you run is going to want to use a whole bunch of DPMI
memory or spawn off a tree 6 deep of children.
You can use CWSPARAM to set any of the options (2) - but I agree it
should be easier to use.