emm386, 512MB ram, asus p4pe
SummyTheNewbie
Whenever i load emm386 (either dos 6.22 or 7), i get the following error:
"unable to set frame base, EMS unavailable"
I have 512MB ram with m/b asus p4pe. I searched in the net and the only idea
about the cause of this error is that there is a problem with the memory
chip which makes no sense to me. This is because I use the same pc with
windows 98 & windows XP and have no problems even in greatly memory
consuming tasks and games.
Note that there are no "strange" programs/drivers that run before emm386. I
also use the same autoexec/config combination to another machine (same boot
disk) and the problem disappears so i think the scripts are ok. I thought
there might be a BIOS option which i should swap but all my attempts have
failed so i abandoned that idea...
Could it be a bug? Could it be because of the 512mb ram? Any ideas of what i
should try next? :[
Thanks for ur time. hoping to find a solution...
nick
asdfg
Did you load Himem.sys before loading emm386?
AAH
http://www.computerhope.com/emm386hl.htm
It may help you about EMM386.EXE
"SummyTheNewbie" <num...@freemail.gr> wrote in message
news:b8f5aa$rki$1...@usenet.otenet.gr...
AAH
http://home7.inet.tele.dk/batfiles/msdos7/
"SummyTheNewbie" <num...@freemail.gr> wrote in message
news:b8f5aa$rki$1...@usenet.otenet.gr...
SummyTheNewbie
"asdfg" <nos...@nospam.com> wrote in message
news:3EAB508D...@nospam.com...
SummyTheNewbie
I summarize below my answers in order to give more info to you. Perhaps
someone could think of something...
First of all the error is this: ( I typed it wrongly and i apologize!!:(
)
*** Unable to set page frame base ***
and **not**:
*** unable to set frame base, EMS unavailable ***
So...
a) I use exactly the same starting scripts (config&autoexec) in different
pcs, the error appears only one of them. I use the same config.sys in dos 7
and in dos 6.22 boot disks. Again the error appears only in one of the two
machines. Honestly i don't believe that there is an error in scripts..
b) emm386 is loaded, but EMS is not supported.
c) The config.sys is as simple as possible:
----------------------------------------------
device=c:\windows\himem.sys <-- the
folder is different ofcourse in the win32 boot and in the dos 6.22 boot disk
device=c:\windows\emm386.exe
dos = high, umb
device=C:\WINDOWS\COMMAND\display.sys con=(ega,,1) <-- this is
only in win32 boot
Country=030,737,C:\WINDOWS\COMMAND\country.sys <-- this is
only in win32 boot
----------------------------------------------
d) The error appears when emm386 is loaded, so autoexec.bat content must be
irrelevant to the problem.
Even the simplest of all wont work:
------------------------------------
device=c:\windows\himem.sys
device=c:\windows\emm386.exe ram
-----------------------------------
AHH, i read the links you gave me. I found no useful info here:( I guess my
problem is related to the onboard motherboard devices and in the first 640k
ram. If anyone can help, please read the following links:
http://www.computing.net/dos/wwwboard/forum/12558.html <- very important. It
will take only 2 mins to read it..
and:
http://www.touslesdrivers.com/index.php?v_page=23&v_code=804 <- just as a
reference. DONT read this whole page. Just search for "Unable to set page
frame base address--EMS unavailable.".
Since epox motherboard had an internal raid controller as p4pe has, i
conclude that problem should be related to the onboard raid controller. I
tried to disable all m/b onboard devices (raid, lan, firewire, the soundcard
is always disabled) in order to free more space in the low memory area but
the problem was not solved so i am afraid it is a bios related bug as it was
with epox m/bs.
Any ideas?
AAH
and Win98
DEVICE=C:\DOS\HIMEM.SYS /V
DEVICE=C:\DOS\EMM386.EXE RAM I=B000-B7FF /V X=C000-C7FF
DOS=HIGH,UMB
BUFFERS=10,0
FILES=8
LASTDRIVE=D
FCBS=1,0
DEVICEHIGH=/L:1,9072 C:\DOS\ANSI.SYS
STACKS=0,0
SHELL=C:\DOS\COMMAND.COM C:\DOS\ /E:208 /p
"SummyTheNewbie" <num...@freemail.gr> wrote in message
news:b8ghor$r53$1...@usenet.otenet.gr...
Klaus Meinhard
> a) I use exactly the same starting scripts (config&autoexec) in
> different pcs, the error appears only one of them. I use the same
> config.sys in dos 7 and in dos 6.22 boot disks. Again the error
> appears only in one of the two machines. Honestly i don't believe
> that there is an error in scripts..
So the difference must be between the 2 machines, right?
> b) emm386 is loaded, but EMS is not supported.
No wonder after the error message. What does mem /d report for XMS and
UMBs?
You probably have hardware in that machine (your raid controller?) that
sets up it´s driver software in a way that doesn´t leave enough
_continous_ free space (64K?) in upper memory.
Solution 1: do you really need EMS? Under Windows you can do pretty well
without it. Only very old software _may_ need ems, and that can
sometimes be persuaded to use XMS. There's the handy /NOEMS switch of
EMM386.EXE that will take care of that and leave you much more memory to
load useful things high.
Solution 2: IIRC you cannot persuade EMM386 to use a smaller pageframe
(32 K, 16K) or to shift it's basic adress. But there are more flexibel
proggies out there. QEMM was a commercial EMS/XMS manager that can be
found on the net nowadays (see my DOS Tools page) which might help.
Solution 3: study the handbook of your raid controller. Sometimes you
can shift the place these drivers use for themselves to somewhere it
doesn´t interfere.
--
Viele Grüße, best regards,
*Klaus Meinhard*
07°36´57" East 53°07´52" North
Author of the 4XBTM batch collection at
http://home.t-online.de/home/K_meinhard/
AAH
I tried Norton Commander. The download link leads to a Games site.
Also XtreeGold link cannot be
acccessed.
Any help?
Thanks.
"Klaus Meinhard" <K_Mei...@t-online.de> wrote in message
news:b8gspm$ldt$04$1...@news.t-online.com...
Klaus Meinhard
> I tried Norton Commander. The download link leads to a Games site.
> Also XtreeGold link cannot be
> acccessed.
> Any help?
That site hasn't been updated for several month. In that time, a good
percentage of links is bound to change. Try any good ftp search engine
(see my Search page) or Google to look for the file names.
But that wasn´t your original concern, was it?
SummyTheNewbie
> Solution 1: do you really need EMS? Under Windows you can do pretty well
> without it. Only very old software _may_ need ems, and that can
> sometimes be persuaded to use XMS. There's the handy /NOEMS switch of
> EMM386.EXE that will take care of that and leave you much more memory to
> load useful things high.
Well, to be honest i don't need EMS for my usual boots in win98 or XP
environents. In my normal boot i don't use emm386 at all. But still, the
question is eating me. Shouldn't all new motherboards have a 100% backward
compatibility with old OSes? In any case, simply "ignoring" the problem is
certainly not a solution, right? :o)
> Solution 2: IIRC you cannot persuade EMM386 to use a smaller pageframe
> (32 K, 16K) or to shift it's basic adress. But there are more flexibel
> proggies out there. QEMM was a commercial EMS/XMS manager that can be
> found on the net nowadays (see my DOS Tools page) which might help.
I will think about that. Indeed if i find no solution, i ll change the ems
manager.
>
> No wonder after the error message. What does mem /d report for XMS and
> UMBs?
>
Now.. here starts the real troubleshooting stuff :o( please help me out if
you come up with an idea.
Here is the results of mem /d :
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
Conventional Memory Detail:
Segment Total Name Type
------- ---------------- ----------- --------
00000 1,039 (1K) Interrupt Vector
00040 271 (0K) ROM Communication Area
00050 527 (1K) DOS Communication Area
00070 2,656 (3K) IO System Data
CON System Device Driver
AUX System Device Driver
PRN System Device Driver
CLOCK$ System Device Driver
A: - C: System Device Driver
COM1 System Device Driver
LPT1 System Device Driver
LPT2 System Device Driver
LPT3 System Device Driver
COM2 System Device Driver
COM3 System Device Driver
COM4 System Device Driver
00116 5,072 (5K) MSDOS System Data
00253 11,920 (12K) IO System Data
1,104 (1K) XMSXXXX0 Installed Device=HIMEM
3,104 (3K) EMMQXXX0 Installed Device=EMM386
2,672 (3K) FILES=50
256 (0K) FCBS=4
512 (1K) BUFFERS=10
2,288 (2K) LASTDRIVE=Z
1,856 (2K) STACKS=9,128
0053C 80 (0K) MSDOS System Program
00541 64 (0K) COMMAND Data
00545 2,656 (3K) COMMAND Program
005EB 80 (0K) MSDOS -- Free --
005F0 272 (0K) COMMAND Environment
00601 112 (0K) MEM Environment
00608 88,992 (87K) MEM Program
01BC2 528,336 (516K) MSDOS -- Free --
Upper Memory Detail:
Segment Region Total Name Type
------- ------ ---------------- ----------- --------
0B14A 1 27,456 (27K) MSDOS -- Free --
0CF01 2 4,048 (4K) MSDOS -- Free --
0E401 3 49,136 (48K) MSDOS -- Free --
Memory Summary:
Type of Memory Total = Used + Free
---------------- ---------- ---------- ----------
Conventional 642,048 24,640 617,408
Upper 80,640 0 80,640
Reserved 0 0 0
Extended (XMS) 66,962,688 316,672 66,646,016
---------------- ---------- ---------- ----------
Total memory 67,685,376 341,312 67,344,064
Total under 1 MB 722,688 24,640 698,048
Memory accessible using Int 15h 0 (0K)
Largest executable program size 617,312 (603K)
Largest free upper memory block 49,136 (48K)
MS-DOS is resident in the high memory area.
XMS version 3.00; driver version 3.16
Klaus Meinhard
> environents. In my normal boot i don't use emm386 at all. But still,
> the question is eating me. Shouldn't all new motherboards have a 100%
> backward compatibility with old OSes? In any case, simply "ignoring"
> the problem is certainly not a solution, right? :o)
This behaviour _is_ compatible. The upper memory area (640 k - 1024 K)
is reserved for the needs of drivers and stuff (your graphics card uses
it too). The people making your raid controller probably decided that
it´s improbable people still use EMS or simply didn´t give a damn. I
still made heavy use of many DOS programs (and still do under XP) under
Windows9n, but had no EMS because I needed that space for more useful
things. 2 old DOS proggies I used regularly could be configured to use
EMS or XMS.
> Now.. here starts the real troubleshooting stuff :o( please help me
> out if you come up with an idea.
> 0B14A 1 27,456 (27K) MSDOS -- Free --
> 0CF01 2 4,048 (4K) MSDOS -- Free --
> 0E401 3 49,136 (48K) MSDOS -- Free --
It seems you have 3 blocks of free memory, but none is big enough to
take the pageframe (64 K). The use of QEMM _might_ help (afair the
latest version could even remap drivers to some other adress and was
very clever at deciding what to load where). But even EMM386 might be
flexibel enough to solve this:
Take a look at the help system of MS-DOS 6.22 (if it´s not on your
system, many versions can be found in the NET, (take a look at my
DOS-Links page).
The first step should be to include a few usable areas into the memory
pool used by EMM386. Take a look at the /I switch. On many systems it
was safe to include the area B000-B7FF. The /HIGHSCAN switch enables
EMM386 to search for includable segments, but can be too agressive in
including segments. Perhaps this is enough to give you a free area of 64
K.
bud
'Lo Summy:
Group: comp.os.msdos.misc Date: Mon, Apr 28, 2003, 3:28am (CDT+8) From:
num...@freemail.gr (SummyTheNewbie)
script:
<snip>
>
>Here is the results of mem /d :
>
<snip>
Go into your BIOS Setup and see how much "ROM shadowing" you can
disable.
It's possible that with (reasonably modern) video cards you could
(maybe) even do without "video RAM".
HTH.
salaam,
dowcom
--
http://community.webtv.net/dowcom/DOWCOMSAMSTRADGUIDE
DOShead Credo:
a) Try it! It might work.
b) GOTO a).
SummyTheNewbie
> is reserved for the needs of drivers and stuff (your graphics card uses
> it too). The people making your raid controller probably decided that
> still made heavy use of many DOS programs (and still do under XP) under
> Windows9n, but had no EMS because I needed that space for more useful
> things. 2 old DOS proggies I used regularly could be configured to use
> EMS or XMS.
Well lets say "100% compatible with software written in old OSes" and not
"100% compatible with old OSes". A program that requires EMS will run under
windows 9x even if emm386 is not loaded? If not, then how can we talk about
"backward compatibility?" :o( ?
> The first step should be to include a few usable areas into the memory
> pool used by EMM386. Take a look at the /I switch. On many systems it
> was safe to include the area B000-B7FF. The /HIGHSCAN switch enables
> EMM386 to search for includable segments, but can be too agressive in
> including segments. Perhaps this is enough to give you a free area of 64
> K.
I studied emm386 documentation and links from your site. Btw, you have a
great page! :o) Now, here is what i tried:
First of all i tried AAH's handy solution which didn't work:
DEVICE=...EMM386.EXE RAM I=B000-B7FF /V X=C000-C7FF
And then i tried simply to add the parameter "highscan" which didn't work
either. Then i booted and run msd. From there i studied the memory map and
here is most probably the strange thing that causes this problem: According
to the map the space from D400 to EFFF(!) is empty but sporadically
contains dots leaving no contiguous 64k of totally empty space. According to
msd, dots mean "possibly empty". I can't understand if this is normal and
why this happens.
I tried to do the following:
DEVICE=...EMM386.exe M7
which m7 corresponds to starting address D400. Now, emm386 loads
successfully (it activates EMS) but with the following warning:
"Warning: Option ROM or RAM detected within page frame"
After that warning, emm386 loads normally, and everything seems to work
properly. I run the msd again and in the memory map and then verified that
indeed emm386 has been loaded and takes space from d400 to e3ff.
What do you think of that? Is there a logical explanation for the dots
spread within the space D400-EFFF?
Richard Bonner
> I have an awkward problem and need some help or ideas at least:(
> Whenever i load emm386 (either dos 6.22 or 7), i get the following error:
> "unable to set frame base, EMS unavailable"
>
> nick
*** I can think of four possibilities:
1/ As already mentioned, load HIMEM.sys before EMM386.
2/ Be sure the line loading EMM386 specifies "RAM".
3/ There is a memory conflict with the page frame address.
4/ Specify DOS=HIGH,UMB
Number 3 may be eliminated by specifying the memory address in the
line which loads EMM386. The last is important as this allows access to
upper memory blocks, which is where the EMS page frame resides.
A link was provided by a poster here for EMM386 help, but don't forget
to check your DOS on-screen help, as well. Look at both EMM386 and
specifically, EMM386.exe.
Richard Bonner
http://www.chebucto.ns.ca/~ak621/DOS
Richard Bonner
> ----------------------------------------------
> device=c:\windows\himem.sys <-- the
> folder is different ofcourse in the win32 boot and in the dos 6.22 boot disk
> device=c:\windows\emm386.exe
*** Hmm, might the problem be because you are loading Windows versions
of HIMEM.sys and EMM386 for DOS 6.22?
Richard Bonner
http://www.chebucto.ns.ca/~ak621/DOS
Richard Bonner
> Solution 1: do you really need EMS? Under Windows you can do pretty well
> without it. Only very old software _may_ need ems, and that can
> sometimes be persuaded to use XMS.
*** Actually, even some newer DOS software makes use of EMS.
> There's the handy /NOEMS switch of EMM386.EXE that will take care of
> that and leave you much more memory to load useful things high.
*** True, but he will have to be sure no other programs require EMS, if
he goes this route.
> Solution 2: IIRC you cannot persuade EMM386 to use a smaller pageframe
> (32 K, 16K) or to shift it's basic adress.
*** I believe that is correct regarding the page frame size, but one may
specify the memory address.
> But there are more flexibel
> proggies out there. QEMM was a commercial EMS/XMS manager
*** QEMM is still being produced. It is an *excellent* memory manager. I
use version 8.1.
> that can be
> found on the net nowadays (see my DOS Tools page) which might help.
>
> *Klaus Meinhard*
*** I would be surprised to find a legal free version of QEMM.
Quarterdeck seems very protective of its products - eveh old versions.
Richard Bonner
http://www.chebucto.ns.ca/~ak621/DOS
SummyTheNewbie
Well, although i have seen the shadow ram related options in other
motherboards, the P4PE BIOS has no such option so its either always enabled
or alwayed disabled..
>
> > After that warning, emm386 loads normally, and everything seems to work
> > properly. I run the msd again and in the memory map and then verified
that
> > indeed emm386 has been loaded and takes space from d400 to e3ff.
>
> > What do you think of that? Is there a logical explanation for the dots
> > spread within the space D400-EFFF?
>
> *** Perhaps a glitchy memory module? Try exchanging the memory modules
> with those of a machine where you are not having this problem.
>
> Richard Bonner
> http://www.chebucto.ns.ca/~ak621/DOS
>
>
SummyTheNewbie
...where was i ...
oh, i ll answer all the posts addressed to me in this message k?
> *** Perhaps a glitchy memory module? Try exchanging the memory modules
> with those of a machine where you are not having this problem.
I will try that soon and tell you the results. But as i have wrote before, i
have no problems in win98 or xp even when performing tasks which require
great amounts of memory. While looking in to the net, i have read an article
that states that an epox motherboard with the same onboard raid controller
had exactly the same problem with the problem i describe, so i m afraid it
must be a bug or something. Anyway, i ll swap the memory modules just in
case.
>> ----------------------------------------------
>> device=c:\windows\himem.sys <-- the
>> folder is different ofcourse in the win32 boot and in the dos 6.22 boot
disk
>> device=c:\windows\emm386.exe
>>*** Hmm, might the problem be because you are loading Windows versions
> of HIMEM.sys and EMM386 for DOS 6.22?
No, in windows i run window versions and in dos i run dos versions. That has
been double checked. In both boots, i get the same error message. Actually,
right now i am experimenting with a simple 1,44 floppy formatted w/ dos 6.22
so paths differ. But files versions match, thats for sure.
Now..
> 1/ As already mentioned, load HIMEM.sys before EMM386.
> 2/ Be sure the line loading EMM386 specifies "RAM".
> 3/ There is a memory conflict with the page frame address.
> 4/ Specify DOS=HIGH,UMB
>
I have doubled checked (1) (2) and (4). So its must be the 3rd one. I have
"solved" the problem with the m7 option of emm386, and it seems to work ok
until now, apart ofcourse from that strange warning message. So after
reading your answer, i looked in the BIOS of my motherboard and i found no
option related to shadow ram. Is this normal for a new motherboard as p4pe?
I have seen before such options in older motherboards, but nothing in this
one.
Klaus Meinhard
>
>> Solution 1: do you really need EMS? Under Windows you can do pretty
>> well without it. Only very old software _may_ need ems, and that can
>> sometimes be persuaded to use XMS.
>
> *** Actually, even some newer DOS software makes use of EMS.
That surprises me. EMS was essentially a very dumb technology (mirroring
4 16k code pages somewhere into the DOS memory space of 1024 K)
superseded by XMS which allowed a basically flat memory model above 1MB.
For a while many proggies supported both EMS and XMS, but XMS was
quickly adopted by most. But nothing is impossible :-))
>> There's the handy /NOEMS switch of EMM386.EXE that will take care of
>> that and leave you much more memory to load useful things high.
>
> *** True, but he will have to be sure no other programs require
> EMS, if he goes this route.
I still have many DOS application running, many use DOS extenders, but
none EMS. I live for several years with the /NOEMS switch, which makes
uploading of more drivers and DOS utils possible while keeping more than
600 KB DOS mem free.
>> Solution 2: IIRC you cannot persuade EMM386 to use a smaller
>> pageframe (32 K, 16K) or to shift it's basic adress.
>
> *** I believe that is correct regarding the page frame size, but
> one may specify the memory address.
Yes, I found that later when I looked at the Help info.
> *** QEMM is still being produced. It is an *excellent* memory
> manager. I use version 8.1.
That surprises me too. AFAIK Quarterdeck was bought by Symantec, QEMM
and Desqview discontinued. I found a link to a Version 9 and placed that
on my page, but I have no idea if it´s still current. I´ll have to check
that and your info about this.
Klaus Meinhard
> I will try that soon and tell you the results. But as i have wrote
> before, i have no problems in win98 or xp even when performing tasks
> which require great amounts of memory. While looking in to the net, i
> have read an article that states that an epox motherboard with the
> same onboard raid controller had exactly the same problem with the
> problem i describe, so i m afraid it must be a bug or something.
> Anyway, i ll swap the memory modules just in case.
I doubt that will bring any results. MSD isn´t very good at _reliably_
detecting used or empty memory areas. There was a Qemm utility that was
much better (MFT (?), iirc). Anyway, as long as EMM386 reports a
conflict you run the risk of a mulfunctioning raid controller, a much
bigger disaster that missing EMS.
Are you sure there is no way to shift the base adress your raid
controller uses for his driver?
Marco van de Voort
>> Klaus Meinhard wrote:
>>
>>> Solution 1: do you really need EMS? Under Windows you can do pretty
>>> well without it. Only very old software _may_ need ems, and that can
>>> sometimes be persuaded to use XMS.
>>
>> *** Actually, even some newer DOS software makes use of EMS.
>
> That surprises me. EMS was essentially a very dumb technology (mirroring
> 4 16k code pages somewhere into the DOS memory space of 1024 K)
> superseded by XMS which allowed a basically flat memory model above 1MB.
> For a while many proggies supported both EMS and XMS, but XMS was
> quickly adopted by most. But nothing is impossible :-))
I used it mainly with 16-bit compilers (TopSpeed). Simply because I could
map in parts of datablocks, and have ordinary pointers to them.
(iow a pointer is a page nr+ 16-bit pointer in the pageframe)
When you use extenders, extenders often prefer DPMI, XMS, or even "extended" (raw access)
> I still have many DOS application running, many use DOS extenders, but
> none EMS. I live for several years with the /NOEMS switch, which makes
> uploading of more drivers and DOS utils possible while keeping more than
> 600 KB DOS mem free.
Me also, since I converted nearly all apps to a 32-bit compiler.
>>> Solution 2: IIRC you cannot persuade EMM386 to use a smaller
>>> pageframe (32 K, 16K) or to shift it's basic adress.
>>
>> *** I believe that is correct regarding the page frame size, but
>> one may specify the memory address.
>
> Yes, I found that later when I looked at the Help info.
>
>> *** QEMM is still being produced. It is an *excellent* memory
>> manager. I use version 8.1.
>
> That surprises me too. AFAIK Quarterdeck was bought by Symantec, QEMM
> and Desqview discontinued. I found a link to a Version 9 and placed that
> on my page, but I have no idea if it愀 still current. I惻l have to check
> that and your info about this.
Is Qemm also free? I know DV was released into PD last year, but can't remember anything
about qemm.
SummyTheNewbie
> detecting used or empty memory areas. There was a Qemm utility that was
> much better (MFT (?), iirc). Anyway, as long as EMM386 reports a
> conflict you run the risk of a mulfunctioning raid controller, a much
> bigger disaster that missing EMS.
>
> Are you sure there is no way to shift the base adress your raid
> controller uses for his driver?
I am not sure about that. I suppose something like that would be possible
via options in the bios menu of the raid controller right? There is nothing
there (only options for the array). I also looked in the motherboard bios
and found nothing. But i will look there again.
Now, i will need some help because i want to be sure that i have understood
everything right.
In DOS boot i don't load any OS drivers for any of the onboard devices of
the motherboard (the raid controller, firewire, and nic). As far as i can
understand, the motherboard loads (copies?) the rom of each of the enabled
(from motherboard bios) devices in the upper memory during boot, right? So
if raid controller takes up memory from XXXX to YYYY in bos 6.22 boot from
floppy, the raid controller would take up the same region in win9x boot from
hdd right?
So two questions arrise:
Since i don't load any OS drivers for the devices (eg the raid controller),
the OS will not try to use the devices. Is then a malfuction possible
because of the memory overlap?
And, since the devices will take up the same upper memory region in either
boot, i can use win9x programs to see the map in that area (from d000 to
efff) and see which space each device takes up for sure?
Richard Bonner
> Thanks for your participation in this subject, Bonner.
*** You're welcome.
> Well, although i have seen the shadow ram related options in other
> motherboards, the P4PE BIOS has no such option so its either always enabled
> or alwayed disabled..
*** OK. I was just sort of thinking out loud as to what the cause of
your trouble might be. My sugestion sare onmes which I might try myself if
your system was here in from of me.
Richard Bonner
http://www.chebucto.ns.ca/~ak621/DOS
Richard Bonner
> > Klaus Meinhard wrote:
> >
> >> Solution 1: do you really need EMS? Under Windows you can do pretty
> >> well without it. Only very old software _may_ need ems, and that can
> >> sometimes be persuaded to use XMS.
> >
> > *** Actually, even some newer DOS software makes use of EMS.
> That surprises me. EMS was essentially a very dumb technology (mirroring
> 4 16k code pages somewhere into the DOS memory space of 1024 K)
*** It used upper or extended memory, as available, for a frame
page of four 16k memory blocks. These were placed into upper or expanded
memory and mapped to lower (conventional) memory as needed by a program.
I wouldn't say it was dumb technology given the context of its
development. This originally came out for the 8088/86 processors, which
had no extended memory capability. An expanded memory board could be added
to such systems for use of memory beyond 1 Mb. The technology was
designed to get around the limitation of the 8088/86 chip.
This changed with the 386 chip, and then again with emulators. These
would emulate expanded memory from extended memory. Since these became
available, expanded memory became very fast. In fact, in a modern system,
one can not tell expanded memory use from extended use when operating a
computer. It's seemless.
> superseded by XMS which allowed a basically flat memory model above 1MB.
> For a while many proggies supported both EMS and XMS, but XMS was
> quickly adopted by most. But nothing is impossible :-))
*** XMS was adopted, but some programmers still use EMS. I assume it has
to do with compatibility or perhaps it's simply easier to program using
EMS.
> I still have many DOS application running, many use DOS extenders, but
> none EMS. I live for several years with the /NOEMS switch, which makes
> uploading of more drivers and DOS utils possible while keeping more than
> 600 KB DOS mem free.
*** Correct.
I make use of a wide variety of DOS programs because I prefer to use
DOS-only systems. Some of these use EMS. However, with agressive memory
management. I am able to load a tonne of stuff into upper memory, and I
mean a *tonne of stuff* and still have 620 - 630 K available to programs,
depending on my selected boot-up.
> > *** QEMM is still being produced. It is an *excellent* memory
> > manager. I use version 8.1.
> That surprises me too. AFAIK Quarterdeck was bought by Symantec, QEMM
> and Desqview discontinued.
*** How recently did this happen? I'm sure I saw ads for Quarterdeck
stuff no longer than a couple of years ago. I also went on the Quarterdeck
website within the past year, I believe.
> I found a link to a Version 9 and placed that
> on my page, but I have no idea if it's still current. I'll have to check
> that and your info about this.
> --
> Viele Grüße,
*** I'll look, too.
Richard Bonner
http://www.chebucto.ns.ca/~ak621/DOS
Richard Bonner
> In article <b8qr24$p5n$03$2...@news.t-online.com>, Klaus Meinhard wrote:
> >> Klaus Meinhard wrote:
> >>
(Re: EMS Useage)
> I used it mainly with 16-bit compilers (TopSpeed). Simply because I could
> map in parts of datablocks, and have ordinary pointers to them.
> (iow a pointer is a page nr+ 16-bit pointer in the pageframe)
> When you use extenders, extenders often prefer DPMI, XMS, or even
> "extended" (raw access)
*** Correct. DPMI (DOS Protected Mode Interface) was developed to allow
DOS programs to run as do Windows ones. That is, they run in extended
memory. These types of programs also allow easier multi-tasking under DOS.
I also believe this or similar technology is what allows 32-bit DOS
programs to run, as well.
> >> *** QEMM is still being produced. It is an *excellent* memory
> >> manager. I use version 8.1.
> >
> > That surprises me too. AFAIK Quarterdeck was bought by Symantec, QEMM
> > and Desqview discontinued. I found a link to a Version 9 and placed that
> > on my page, but I have no idea if it愀 still current. I惻l have to check
> > that and your info about this.
> Is Qemm also free? I know DV was released into PD last year, but can't
> remember anything about qemm.
*** If it is, it's only recently this happened. One had to purchase it
for Windows and even DOS usage up until a year or so ago, as I remember.
Richard Bonner
http://www.chebucto.ns.ca/~ak621/DOS
Richard Bonner
> > *** Perhaps a glitchy memory module? Try exchanging the memory modules
> > with those of a machine where you are not having this problem.
> I will try that soon and tell you the results. But as i have wrote before, i
> have no problems in win98 or xp even when performing tasks which require
> great amounts of memory.
*** Oh, yes, you did say that. Sorry - I didn't clue in.
> While looking in to the net, i have read an article
> that states that an epox motherboard with the same onboard raid controller
> had exactly the same problem with the problem i describe, so i m afraid it
> must be a bug or something. Anyway, i ll swap the memory modules just in
> case.
*** OK. It would be something I would try if the system was here for me
to diagnose.
> >>*** Hmm, might the problem be because you are loading Windows versions
> > of HIMEM.sys and EMM386 for DOS 6.22?
> No, in windows i run window versions and in dos i run dos versions. That has
> been double checked. In both boots, i get the same error message.
*** OK. This is good.
> Actually, right now i am experimenting with a simple 1,44 floppy
> formatted w/ dos 6.22 so paths differ. But files versions match, thats
> for sure.
*** OK. It sounds like you have that together.
> > 1/ As already mentioned, load HIMEM.sys before EMM386.
> > 2/ Be sure the line loading EMM386 specifies "RAM".
> > 3/ There is a memory conflict with the page frame address.
> > 4/ Specify DOS=HIGH,UMB
> I have doubled checked (1) (2) and (4). So its must be the 3rd one. I have
> "solved" the problem with the m7 option of emm386, and it seems to work ok
> until now, apart of course from that strange warning message.
*** OK.
> So after
> reading your answer, i looked in the BIOS of my motherboard and i found no
> option related to shadow ram. Is this normal for a new motherboard as p4pe?
> I have seen before such options in older motherboards, but nothing in this
> one.
*** I can't say. Perhaps for new boards, it's automatic, or maybe they
have a different system to handle this without user input needed.
Richard Bonner
http://www.chebucto.ns.ca/~ak621/DOS
Klaus Meinhard
> Is Qemm also free? I know DV was released into PD last year, but
> can't remember anything about qemm.
Try to look for Quarterdeck with Google. You are directed to Symantec.
That must be at least 2 years, afair, but I'm far from sure and might be
corrected.
Qemm is at least "abandoned" :-( Wasn´t Qemm a necessary part of DV? I
know it was sold alone, but I seem to remember that DV needed it (???).
Klaus Meinhard
> As far as i can understand, the motherboard loads (copies?) the rom
> of each of the enabled (from motherboard bios) devices in the upper
> memory during boot, right? So if raid controller takes up memory from
> XXXX to YYYY in bos 6.22 boot from floppy, the raid controller would
> take up the same region in win9x boot from hdd right?
Yes, just as the memory area your VGA card uses.
> Since i don't load any OS drivers for the devices (eg the raid
> controller), the OS will not try to use the devices. Is then a
> malfuction possible because of the memory overlap?
The ROMs of these devices use this area for their purposes. And while a
mmeory conflict with your VGA card tends to let your screen dark, a
conflict with your raid controller would seriously endanger your data.
Care to risk it?
> And, since the devices will take up the same upper memory region in
> either boot, i can use win9x programs to see the map in that area
> (from d000 to efff) and see which space each device takes up for sure?
There are devices that need bigger amounts of memory when booting, after
that being content with a smaller amount. The diagnostics of qemm would
show you exactly if that is the case here. If you want to try, backup
your data (at least what´s valuable to you), and try teh scenario where
you had included some areas and only a warning was displayed by EMM386.
Then, if eberything goes well for a week or two, you can be reasonably
certain that there is no real conflict.
bud
I notice that you don't set the INT15h switch in EMM386 (or is it in
HIMEM?). As a result, MEM states that INT15h mem is not available.
I would try setting that switch to see if it makes a difference.
SummyTheNewbie
> that being content with a smaller amount. The diagnostics of qemm would
> show you exactly if that is the case here. If you want to try, backup
> your data (at least what´s valuable to you), and try teh scenario where
> you had included some areas and only a warning was displayed by EMM386.
> Then, if eberything goes well for a week or two, you can be reasonably
> certain that there is no real conflict.
>
So, I will try to run qemm as soon as i find a link to download it:)
Thank you for your answers, you have been very helpful.
c u
Richard Bonner
> Marco, Richard,
> > Is Qemm also free? I know DV was released into PD last year, but
> > can't remember anything about qemm.
> Try to look for Quarterdeck with Google. You are directed to Symantec.
> That must be at least 2 years, afair, but I'm far from sure and might be
> corrected.
*** No. you are correct. I think it said the takeover was in 1999. I
must have been on some other site last year because I saw QEMM
still offered for sale and there were no free downloads.
> Qemm is at least "abandoned" :-( Wasn´t Qemm a necessary part of DV? I
> know it was sold alone, but I seem to remember that DV needed it (???).
> --
> *Klaus Meinhard*
*** QEMM came with DSEQview. I know because I use both. If one wishes to
multitask well in DOS, DV and QEMM are an unbeatable combination.
Richard Bonner
http://www.chebucto.ns.ca/~ak621/DOS
Richard Bonner
> Summy,
> > I will try that soon and tell you the results. But as i have wrote
> > before, i have no problems in win98 or xp even when performing tasks
> > which require great amounts of memory.
(Snip)
> MSD isn't very good at _reliably_
> detecting used or empty memory areas. There was a Qemm utility that was
> much better (MFT (?), iirc).
*** That is Manifest. It's a powerful diagnostic tool.
Richard Bonner
http://www.chebucto.ns.ca/~ak621/DOS
SummyTheNewbie
> > MSD isn't very good at _reliably_
> > detecting used or empty memory areas. There was a Qemm utility that was
> > much better (MFT (?), iirc).
>
> *** That is Manifest. It's a powerful diagnostic tool.
>
> And then i tried simply to add the parameter "highscan" which didn't work
> either. Then i booted and run msd. From there i studied the memory map and
> here is most probably the strange thing that causes this problem:
According
> to the map the space from D400 to EFFF(!) is empty but sporadically
> contains dots leaving no contiguous 64k of totally empty space. According
to
> msd, dots mean "possibly empty". I can't understand if this is normal and
> why this happens.
So why all those dots in my ram ? ?? ://
btw, i swap the memory modules and nothing changed.
Marcus Houlden
wrote the following to comp.os.msdos.misc:
The dots don't really exist. They just appear in your program for display
purposes.
mh.
--
This space intentionally blank.
SummyTheNewbie
> The dots don't really exist. They just appear in your program for display
> purposes.
>
no i am not that stupid:Pp
The dots i mean are the symbol that msd uses in order to define: "possible
empty" memory space and not "empty space" in its memory map. Run msd and
check it out.
How can a "powerful diagnostic program" not know if a memory address is
empty or not? :o/ ?
Bruce Patis
<num...@freemail.gr> wrote:
>I have an awkward problem and need some help or ideas at least:(
>
>Whenever i load emm386 (either dos 6.22 or 7), i get the following error:
>
>"unable to set frame base, EMS unavailable"
>
>I have 512MB ram with m/b asus p4pe. I searched in the net and the only idea
>about the cause of this error is that there is a problem with the memory
>chip which makes no sense to me. This is because I use the same pc with
>windows 98 & windows XP and have no problems even in greatly memory
>consuming tasks and games.
I had a similar problem a few years ago. I transferred the two hard
drives (with lots of working DOS software on them) from my previous
computer to a new computer. The main difference was that the old
computer had 128MB of memory, but the new computer had 512MB. The new
computer was also much faster, but it turned out that the problem was
due to the quantity of memory.
Believe it or not, even the later versions of DOS have a memory limit.
No, it's not 640kB, as the Mac/Windoze people would have us believe
<grin>, but 256MB. I confirmed this by inserting various sizes of ram
modules, then running DOS programs which can utilize a large amount of
memory. Everything worked fine with 256MB or less, but 384MB and
512MB gave memory manager errors and either locked up or re-booted the
computer.
Very little info is available on using that much ram with DOS, but I
did confirm the 256MB limit with tech support at 386Max. BTW, the
limit is due to the way DOS handles expanded and extended memory, but
the details are handled by the memory manager, e.g. emm386. The ones
included with most newer versions of DOS (any brand) support 64MB,
several brands and versions of DOS and third-party memory managers
support 128MB, but very few support 256MB. 386Max version 8.03 is one
of the few that does.
If it is easy to remove actual RAM modules from your mobo, try using
64MB total, and 128MB total. Then you will know if you have this
problem.
Hope this helps,
Bruce