QEMM386 and EMS (XMS)
Karl Springer
Siming Zhan said to All:
SZ> Physically, I have 8 mb ram installed in my i386dx25.
> After using QEMM386 (7.04), I have only 1 mb EMS (XMS)
> available (djgpp complains not enough EMS to run).
Try using QEMM's Manifest to assist you in finding where
your EMS/XMS memory pool went.
Siming Zhan
After using QEMM386 (7.04), I have only 1 mb EMS (XMS) available
4,294,284 upper memory with 4,294,200 used. Where does the upper memory
go? Can someone give me an explanation?
(see attached configuration files: autoexec.bat and config.sys.)
Modules using memory below 1 MB:
Name Total = Conventional + Upper Memory
-------- ---------------- ---------------- ----------------
SYSTEM 4,429 (4K) 867,373 (847K) 4,294,10 (4,193,
RSTRCFG 128 (0K) 128 (0K) 0 (0K)
QEMM386 784 (1K) 784 (1K) 0 (0K)
DPMS 1,728 (2K) 1,728 (2K) 0 (0K)
COMMAND 5,568 (5K) 272 (0K) 5,296 (5K)
DOS-UP 224 (0K) 0 (0K) 224 (0K)
DOSDATA 5,424 (5K) 0 (0K) 5,424 (5K)
QDPMI 2,112 (2K) 0 (0K) 2,112 (2K)
ANSI 4,208 (4K) 0 (0K) 4,208 (4K)
STACHIGH 17,024 (17K) 0 (0K) 17,024 (17K)
FILES 3,504 (3K) 0 (0K) 3,504 (3K)
FCBS 272 (0K) 0 (0K) 272 (0K)
WKBUFFER 528 (1K) 0 (0K) 528 (1K)
LASTDRIV 544 (1K) 0 (0K) 544 (1K)
STACKS 3,024 (3K) 0 (0K) 3,024 (3K)
INSTALL 160 (0K) 0 (0K) 160 (0K)
NCACHE2 17,088 (17K) 0 (0K) 17,088 (17K)
NCACHE2 16,400 (16K) 0 (0K) 16,400 (16K)
NCACHE2 12,832 (13K) 0 (0K) 12,832 (13K)
MOUSE6 8,432 (8K) 0 (0K) 8,432 (8K)
KSTACK 1,072 (1K) 0 (0K) 1,072 (1K)
SHARE 17,904 (17K) 0 (0K) 17,904 (17K)
Free 710,608 (694K) 646,608 (631K) 64,000 (63K)
Memory Summary:
Type of Memory Total = Used + Free
---------------- ---------- ---------- ----------
Conventional 655,360 8,752 646,608
Upper 4,294,284, 4,294,220, 64,000
Reserved 393,216 393,216 0
Extended (XMS) 8,022,928 6,974,352 1,048,576
---------------- ---------- ---------- ----------
Total memory 8,388,608 6,629,424 1,759,184
Total under 1 MB 4,294,939, 4,294,229, 710,608
Total Expanded (EMS) 7,585,792 (7,408K)
Free Expanded (EMS) 1,048,576 (1,024K)
Largest executable program size 646,592 (631K)
Largest free upper memory block 61,072 (60K)
MS-DOS is resident in the high memory area.
SET SYMANTEC=%S
D:\NDW\IMAGE.EXE
rem C:\SMARTDRV.EXE
SET CPAV=C:\PCTOOLS\DATA\CPAV.INI
SET PCTOOLS=C:\PCTOOLS\DATA
C:\STACKER\CHECK /WP
c:\qemm\loadhi /r:1 /lo c:\nu\ncache2 /install
c:\qemm\loadhi /r:1 c:\mouse\mouse6.com
@ECHO OFF
PROMPT $e[32;44;1m$p$g
PATH D:\BC4\BIN;D:\NDW;C:\DOS;C:\4DOS;C:\NU;C:\PCTOOLS;C:\TSR;C:\BT;C:\WINDOWS;
PATH %PATH%C:\QEMM;C:\STACKER;C:\PCPLUS;C:\SPELL;C:\G4;C:\ED;
PATH %PATH%C:\BIN\IM;C:\DJGPP\BIN;C:\ZW;
SET cdpath=c:\tex;c:\tex\94;
SET GMK4=C:\G4\
SET list=F:\tmp
SET tfm=c:\emtex\tfm
SET texinput=c:\emtex\texinput!;c:\emtex\2e;
SET texfmt=c:\emtex\texfmts;c:\emtex\2e;
SET btexfmt=c:\emtex\btexfmts;c:\emtex\2e;
SET textfm=c:\emtex\tfm
SET bibinput=c:\emtex\bibinput
SET mfinput=c:\emtex\mfinput
SET mfbas=c:\emtex\mfbases
SET bmfbas=c:\emtex\bmfbases
SET mfjob=c:\emtex\mfjob
SET dvidrvinput=c:\emtex;c:\emtex\doc
SET dvidrvfonts=c:\texfonts
SET dvidrvgraph=c:\emtex\doc;c:\emtex\doc\gr$r;c:\emtex\doc\gr300
SET emtexed=elvis +%%1 %%2
call c:\djgpp\bin\setdjgpp c:\djgpp c:/djgpp
SET GO32=ansi driver c:/djgpp/drivers/tridnt89.grd gw 1024 gh 768
emu c:/djgpp/emu387/emu387
SET EXINIT=source c:\ed\elvis.rc
set DPMI32=SWAPFILE D:\CCC\EDPMI.SWP
SET COMSPEC=C:\COMMAND.COM
rem SET COMSPEC=G:\COMMAND.COM
rem SET SYMANTEC=C:\SYMANTEC
SET NU=C:\NU
rem MKDIR G:\TMP
SET TEMP=d:\TMP
SET TMP=d:\TMP
SET TERM=ansi
c:\qemm\loadhi /r:1 C:\4dos\kstack.com
rem C:\NU\IMAGE C:
rem C:\NU\NDD C:/Q
VERIFY OFF
rem c:\qemm\loadhi /r:1 fmark c:\tsr\zw.fmk
rem c:\qemm\loadhi /r:1 zwvga.com /U
rem c:\qemm\loadhi /r:1 c:\bin\clockon
rem copy command.com G:\
alias /r 4.a
C:\QEMM\LOADHI /R:1 C:\DOS\SHARE.EXE /L:500 /F:5100
[common]
FILES=64
BUFFERS=20
rem files=30
rem files=64
break=on
rem STACKS=9,128
DEVICE=C:\QEMM\DOSDATA.SYS
DEVICE=C:\QEMM\QEMM386.SYS RAM ST:M R:1 x=A000-BFFF
DEVICE=C:\QEMM\DOS-UP.SYS @C:\QEMM\DOS-UP.DAT
DEVICE=C:\QEMM\LOADHI.SYS /R:1 /SIZE=8592 C:\QEMM\QDPMI.SYS SWAPFILE=DPMI.SWP
SWAPSIZE=1024
DEVICE=c:\qemm\loadhi.sys /r:1 /size=9360 C:\DOS\ansi.sys
SHELL=C:\QEMM\LOADHI.COM /R:1 /LO C:\4dos\command.COM C:\4dos\ /e:2048 /p
DEVICE=C:\STACKER\DPMS.EXE
DEVICE=C:\QEMM\LOADHI.SYS /R:1 /SIZE=28160 C:\STACKER\STACHIGH.SYS
rem DEVICE=c:\qemm\loadhi.sys /r:1 /size=6176 c:\dos\ramdrive.sys 1024 512 /e
rem device=c:\stacker\screate.sys G:
DOS=high,UMB
STACKS=9,256
[common]
rem DEVICE=D:\NDW\NAVTSR.EXE
Wong Kim Ling Kenneth
>Physically, I have 8 mb ram installed in my i386dx25.
>After using QEMM386 (7.04), I have only 1 mb EMS (XMS) available
>(djgpp complains not enough EMS to run). What's wrong? QEMM claims
>4,294,284 upper memory with 4,294,200 used. Where does the upper memory
>go? Can someone give me an explanation?
>(see attached configuration files: autoexec.bat and config.sys.)
> Type of Memory Total = Used + Free
> ---------------- ---------- ---------- ----------
> Conventional 655,360 8,752 646,608
> Upper 4,294,284, 4,294,220, 64,000
> Reserved 393,216 393,216 0
> Extended (XMS) 8,022,928 6,974,352 1,048,576
> ---------------- ---------- ---------- ----------
> Total memory 8,388,608 6,629,424 1,759,184
> Total under 1 MB 4,294,939, 4,294,229, 710,608
> Total Expanded (EMS) 7,585,792 (7,408K)
> Free Expanded (EMS) 1,048,576 (1,024K)
> Largest executable program size 646,592 (631K)
> Largest free upper memory block 61,072 (60K)
> MS-DOS is resident in the high memory area.
[stuffs deleted]
>c:\qemm\loadhi /r:1 /lo c:\nu\ncache2 /install
NCache is the most suspicious program. I use SpeedCache+. If I load it
without specifying cache size, it will claim as much as 5M. Not sure
about ncache though.
>rem DEVICE=c:\qemm\loadhi.sys /r:1 /size=6176 c:\dos\ramdrive.sys 1024 512 /e
Here goes another 1M. If my previous guess is correct, it explains why
you have only 1M EMS.
>DOS=high,UMB
I suggest you to use "DOS=high" so that QEMM can see your UMB properly.
"DOS=UMB" asks DOS to manage your UMB. I still don't understand why QEMM
reports so much UMB but hope this helps anyway.
Wong Kim Ling Kenneth
Wichen, V. van
|->Physically, I have 8 mb ram installed in my i386dx25.
|->After using QEMM386 (7.04), I have only 1 mb EMS (XMS) available
|->(djgpp complains not enough EMS to run). What's wrong? QEMM claims
|->4,294,284 upper memory with 4,294,200 used. Where does the upper memory
|->go? Can someone give me an explanation?
|->(see attached configuration files: autoexec.bat and config.sys.)
|->
|->Modules using memory below 1 MB:
|->
|-> Name Total = Conventional + Upper Memory
|-> -------- ---------------- ---------------- ----------------
|-> SYSTEM 4,429 (4K) 867,373 (847K) 4,294,10 (4,193,
|-> RSTRCFG 128 (0K) 128 (0K) 0 (0K)
|-> QEMM386 784 (1K) 784 (1K) 0 (0K)
|-> DPMS 1,728 (2K) 1,728 (2K) 0 (0K)
|-> COMMAND 5,568 (5K) 272 (0K) 5,296 (5K)
|-> DOS-UP 224 (0K) 0 (0K) 224 (0K)
|-> DOSDATA 5,424 (5K) 0 (0K) 5,424 (5K)
|-> QDPMI 2,112 (2K) 0 (0K) 2,112 (2K)
|-> ANSI 4,208 (4K) 0 (0K) 4,208 (4K)
|-> STACHIGH 17,024 (17K) 0 (0K) 17,024 (17K)
|-> FILES 3,504 (3K) 0 (0K) 3,504 (3K)
|-> FCBS 272 (0K) 0 (0K) 272 (0K)
|-> WKBUFFER 528 (1K) 0 (0K) 528 (1K)
|-> LASTDRIV 544 (1K) 0 (0K) 544 (1K)
|-> STACKS 3,024 (3K) 0 (0K) 3,024 (3K)
|-> INSTALL 160 (0K) 0 (0K) 160 (0K)
|-> NCACHE2 17,088 (17K) 0 (0K) 17,088 (17K)
|-> NCACHE2 16,400 (16K) 0 (0K) 16,400 (16K)
|-> NCACHE2 12,832 (13K) 0 (0K) 12,832 (13K)
|-> MOUSE6 8,432 (8K) 0 (0K) 8,432 (8K)
|-> KSTACK 1,072 (1K) 0 (0K) 1,072 (1K)
|-> SHARE 17,904 (17K) 0 (0K) 17,904 (17K)
|-> Free 710,608 (694K) 646,608 (631K) 64,000 (63K)
|->
|->Memory Summary:
|->
|-> Type of Memory Total = Used + Free
|-> ---------------- ---------- ---------- ----------
|-> Conventional 655,360 8,752 646,608
|-> Upper 4,294,284, 4,294,220, 64,000
|-> Reserved 393,216 393,216 0
|-> Extended (XMS) 8,022,928 6,974,352 1,048,576
|-> ---------------- ---------- ---------- ----------
|-> Total memory 8,388,608 6,629,424 1,759,184
|->
|-> Total under 1 MB 4,294,939, 4,294,229, 710,608
|->
|-> Total Expanded (EMS) 7,585,792 (7,408K)
|-> Free Expanded (EMS) 1,048,576 (1,024K)
|-> Largest executable program size 646,592 (631K)
|-> Largest free upper memory block 61,072 (60K)
|-> MS-DOS is resident in the high memory area.
|->
The rest I have deleted! You are the victim of a little bug of qemm...
You are using DOS-DATA and the other one, due to the fact dos-up is
screwing some systemarea, which has no effect for operating the system,
dos-command mem shows a incorrect number of UMB's. You can solve
this by using qemm 7.04... Or use another reporting programming!
Hope this will help!
Vincent.
Henrik Storner
> In article <Cpu9M0.Dww@eng_ser1.ie.cuhk.hk>,
> klw...@ie.cuhk.hk (Wong Kim Ling Kenneth) writes:
>
>>sz...@watdragon.uwaterloo.ca (Siming Zhan) writes:
>>
>>>DOS=high,UMB
>>
>>I suggest you to use "DOS=high" so that QEMM can see your UMB properly.
>>"DOS=UMB" asks DOS to manage your UMB. I still don't understand why QEMM
>>reports so much UMB but hope this helps anyway.
>>
> QEMM and EMM386 REQUIRE that the DOS switch is set to UMB in order to
> access the Upper Memory Blocks. If you do not specify this option,
> everything will be loaded into conventional memory.
For QEMM, this is _wrong_ ! QEMM provides upper memory blocks by default,
with or without the 'dos=umb' line. In fact, Quarterdeck advise is not to
use this switch. (Not sure if this advice is still given with QEMM 7.x,
but it certainly does provice UMB's - whether you have the dos=umb or
not).
--
Henrik Storner | "First get your facts; then you can distort
(sto...@osiris.ping.dk) | them at your leisure."
| Mark Twain
Robb Topolski KJ6YT
> QEMM and EMM386 REQUIRE that the DOS switch is set to UMB in order to
> access the Upper Memory Blocks. If you do not specify this option,
> everything will be loaded into conventional memory.
QEMM ignores DOS=UMB (or not) and just does it anyway as long as QEMM's
RAM parameter is present. The poster is fine using DOS=HIGH (unless he's
using DESQVIEW, in which case he shouldn't even use that.
> Seeing all of the 'extra' stuff you have in your CONFIG and AUTOEXEC
> would suggest to me that you have too many things loaded right now.
> For debugging purposes, you might want to rename/backup your files and
> build new ones from scratch to see what device drivers are taking up
> some much excess memory.
The earlier poster was correct about MEM not reporting QEMM statistics
correctly. I'm not sure the blame falls on Quarterdeck (and not sure it
doesn't either), but it doesn't matter. For better information than MEM
can even hope to give, use the MFT program that comes with QEMM.
--
____[ Robb Topolski ]___[ San Clemente, CA ]___[ topo...@kaiwan.com ]____
Michael D. Ketchen
Robb Topolski KJ6YT <topo...@kaiwan.com> wrote:
>Christopher Hayashida (EZB...@MVS.OAC.UCLA.EDU) wrote:
>> QEMM and EMM386 REQUIRE that the DOS switch is set to UMB in order to
>> access the Upper Memory Blocks. If you do not specify this option,
>> everything will be loaded into conventional memory.
>
>QEMM ignores DOS=UMB (or not) and just does it anyway as long as QEMM's
>RAM parameter is present. The poster is fine using DOS=HIGH (unless he's
>using DESQVIEW, in which case he shouldn't even use that.
Not exactly. If you use DOS=UMB, DOS links the upper memory blocks into
its memory list, allowing the internal LOADHIGH/LH and DEVICEHIGH commands
to work. QEMM's high-loader utilities may or may not work with DOS=UMB on.
Without DOS=UMB, the DOS LOADHIGH/DEVICEHIGH commands will not work. There
usually is no advantage to using DOS=UMB with QEMM, since QEMM's high-loader
utilities are more powerful and efficient than their DOS counterparts. Also,
I'm not sure that QEMM's Optimize will work correctly with DOS=UMB.
>The earlier poster was correct about MEM not reporting QEMM statistics
>correctly. I'm not sure the blame falls on Quarterdeck (and not sure it
>doesn't either), but it doesn't matter. For better information than MEM
>can even hope to give, use the MFT program that comes with QEMM.
MEM will only show the upper memory block info if DOS=UMB is used. For a
quick display of the upper memory areas when not using DOS=UMB, just type
LOADHI. This lists all the programs in the upper memory areas (basically
the same display as in MFT, but without the time of loading and hunting
through menus).
- Mike
Robb Topolski KJ6YT
> In article <2rha5q$g...@kaiwan.kaiwan.com>,
> Robb Topolski KJ6YT <topo...@kaiwan.com> wrote:
> >Christopher Hayashida (EZB...@MVS.OAC.UCLA.EDU) wrote:
> >> QEMM and EMM386 REQUIRE that the DOS switch is set to UMB in order to
> >> access the Upper Memory Blocks. If you do not specify this option,
> >> everything will be loaded into conventional memory.
> >
> >QEMM ignores DOS=UMB (or not) and just does it anyway as long as QEMM's
> >RAM parameter is present. The poster is fine using DOS=HIGH (unless he's
> >using DESQVIEW, in which case he shouldn't even use that.
> Not exactly. If you use DOS=UMB, DOS links the upper memory blocks into
> its memory list, allowing the internal LOADHIGH/LH and DEVICEHIGH commands
> to work.
Okay, you're right. DOS's UMB programs probably need DOS=UMB. Since
Quarterdeck provides its own UMB loader programs (which look for QEMM,
not DOS=UMB), I assumed you wouldn't use DOS's loaders anymore.
> QEMM's high-loader utilities may or may not work with DOS=UMB on.
They don't care if it's there. As long as QEMM is making High Ram,
they'll work.
> Without DOS=UMB, the DOS LOADHIGH/DEVICEHIGH commands will not work. There
> usually is no advantage to using DOS=UMB with QEMM, since QEMM's high-loader
> utilities are more powerful and efficient than their DOS counterparts. Also,
> I'm not sure that QEMM's Optimize will work correctly with DOS=UMB.
It doesn't care either.
> >The earlier poster was correct about MEM not reporting QEMM statistics
> >correctly. I'm not sure the blame falls on Quarterdeck (and not sure it
> >doesn't either), but it doesn't matter. For better information than MEM
> >can even hope to give, use the MFT program that comes with QEMM.
> MEM will only show the upper memory block info if DOS=UMB is used.
Interesting. I didn't know this.
> For a
> quick display of the upper memory areas when not using DOS=UMB, just type
> LOADHI. This lists all the programs in the upper memory areas (basically
> the same display as in MFT, but without the time of loading and hunting
> through menus).
Or just type 'mft f o' and/or 'mft f r' :-)
Thanks for the info. I learned a few things! :-)
Wong Kim Ling Kenneth
>>>DOS=high,UMB
>>
>>I suggest you to use "DOS=high" so that QEMM can see your UMB properly.
>>"DOS=UMB" asks DOS to manage your UMB. I still don't understand why QEMM
>>reports so much UMB but hope this helps anyway.
>>
>QEMM and EMM386 REQUIRE that the DOS switch is set to UMB in order to
>access the Upper Memory Blocks. If you do not specify this option,
>everything will be loaded into conventional memory.
Really? Let's see.
=======================================================
c:\> grep DOS= config.sys
DOS=HIGH
c:\> mem
Memory Type Total = Used + Free
---------------- ------- ------- -------
Conventional 638K 7K 631K
Upper 0K 0K 0K <--- dos sees nothing
Reserved 130K 130K 0K
Extended (XMS) 7,424K 2,752K 4,672K
---------------- ------- ------- -------
Total memory 8,192K 2,889K 5,303K
Total under 1 MB 638K 7K 631K
Total Expanded (EMS) 7,728K (7,913,472 bytes)
Free Expanded (EMS) 4,672K (4,784,128 bytes)
Largest executable program size 631K (645,792 bytes)
Largest free upper memory block 0K (0 bytes)
MS-DOS is resident in the high memory area.
c:\> \qemm\loadhi
IMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM;
: Region Area Size Status :
: 1 B000 - B0AB 2.6K Used (QEMM386) :
: 1 B0AC - B0B9 0.2K Used (DOS-UP) :
: 1 B0BA - B204 5.1K Used (DOSDATA) :
: 1 B205 - B4EE 11K Used (MVSOUND) :
: 1 B4EF - B568 1.8K Used (SCPCDEXT) :
: 1 B569 - B56E 0.1K Used (FCBS) :
: 1 B56F - B58B 0.4K Used (LASTDRIV) :
: 1 B58C - B648 2.9K Used (STACKS) :
: 1 B649 - B652 0.1K Used (INSTALL) :
: 1 B653 - B71C 3.1K Used (4DOS) :
: 1 B71D - B75D 1K Used (4DOS) :
: 1 B75E - B7FE 2.5K Available :
: 2 CA01 - CDF0 15K Used (STACHIGH) :
: 2 CDF1 - CEDD 3.6K Used (NNANSI) :
: 2 CEDE - D214 12K Used (TSLCDR) :
: 2 D215 - D2E1 3.1K Used (FILES) :
: 2 D2E2 - D302 0.5K Used (WKBUFFER) :
: 2 D303 - D30A 0.1K Used (MSCMOUSE) :
: 2 D30B - DBE4 35K Used (MSCDEX) :
: 2 DBE5 - DF48 13K Used (MSCMOUSE) :
: 2 DF49 - DF4E 0.1K Available :
: 2 DF4F - DF91 1K Used (KSTACK) :
: 2 DF92 - E492 20K Used (SCPLUS) :
: 2 E493 - E7F7 13K Used (SCPLUS) :
: 2 E7F8 - E7FF 0.1K Available :
HMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM<
================================================================
Actually QEMM likes DOS=HIGH more than DOS=HIGH,UMB because
the former gives higher control of UMB's to QEMM. I suspect
whether QEMM's loadhi still works under DOS=UMB.
Just my $.02.
Wong Kim Ling Kenneth
Christopher Hayashida
>sz...@watdragon.uwaterloo.ca (Siming Zhan) writes:
>
>>Physically, I have 8 mb ram installed in my i386dx25.
>>After using QEMM386 (7.04), I have only 1 mb EMS (XMS) available
>>(djgpp complains not enough EMS to run). What's wrong? QEMM claims
>>4,294,284 upper memory with 4,294,200 used. Where does the upper memory
>>go? Can someone give me an explanation?
>>(see attached configuration files: autoexec.bat and config.sys.)
>
[stuff deleted ]
>
>NCache is the most suspicious program. I use SpeedCache+. If I load it
>without specifying cache size, it will claim as much as 5M. Not sure
>about ncache though.
>
>>rem DEVICE=c:\qemm\loadhi.sys /r:1 /size=6176 c:\dos\ramdrive.sys 1024 512 /e
>
>Here goes another 1M. If my previous guess is correct, it explains why
>you have only 1M EMS.
>
>>DOS=high,UMB
>
>I suggest you to use "DOS=high" so that QEMM can see your UMB properly.
>"DOS=UMB" asks DOS to manage your UMB. I still don't understand why QEMM
>reports so much UMB but hope this helps anyway.
>
QEMM and EMM386 REQUIRE that the DOS switch is set to UMB in order to
access the Upper Memory Blocks. If you do not specify this option,
everything will be loaded into conventional memory.
Seeing all of the 'extra' stuff you have in your CONFIG and AUTOEXEC
would suggest to me that you have too many things loaded right now.
For debugging purposes, you might want to rename/backup your files and
build new ones from scratch to see what device drivers are taking up
some much excess memory.
Hope this helps,
Christopher Hayashida