Jump to content

Some trouble with memory management


Recommended Posts

Posted
i want to use single config sys configuration. in some cases win98 gui can benefit from more space in conventional memory.

But with separate configurations you wouldn't have to worry about Windows not seeing the XMS memory used by other utilities (which were initialized prior starting windows). Besides, in a Windows-only config you wouldn't need most of your drivers/TSR's, like QCDROM, shsucdx, ctmouse, SBEINIT and others, and would avoid any conficts that might arrise if you decide to add any DOS-based drivers in the future, or if you decide to use other 3rd-part memory managers while still mantaining a nice amout of free conventional memory.

i am sure that i need files 255... Oblivion was causing trouble while using less (sound problems directly connected to this setting).

OK

this configuration is set for one goal. completely fulfill UMB in dos mode and keep conventional memory so free as possible, with XMS and EMS alltogether :) My system (gui) cannot boot if any UMBs are free - there i must use umbfill so i rather use umbs for excess of buffers and files like just fill them up with no effect.

right now i am missing only one thing it this and it is page frame for EMS in any place where possible. i am reading mdgx's page for more info and i shall play with some bios and system settings and i hope there shall be some additional place.

Actually, you need to use less UMB in DOS mode so you can afford to lose 64KB of contiguous upper memory to the EMS page frame. According to MS-DOS 6.22's help, each buffer uses 532 bytes, so your buffers would use at about 51K (I only took in accout your primary buffers, ignoring the 8 secondary ones, so you probably use more), and freeing that (BUFFERS=10 should fit in HMA, so it souldn't use UMBs) would be a great step towards making room for the page frame.

Just out of curiosity, could you post the output of "mem /c" and "mem /f" (in bare DOS)?


Posted

I tried another setting:

DEVICE=C:\DOS\UMBPCI\UMBPCI.SYS

DEVICE=C:\DOS\HIRAM\HIRAM.EXE

DEVICEhigh=C:\OS\HIMEM.SYS /numhandles=128 /hmain=64 /TESTMEM:OFF /Q

Device=xms2ems.sys 768

DEVICE=C:\DOS\EMM386.EXE noems NOTR

xms2ems was not working with rest of system (sblive or dos4gw) but when entered in this order xms2ems creates EMS and then emm386 picks up its management. This works for most apps except one - the SBlive driver.

Amount of EMS must be smaller than 1mb or the driver shall not load. But applications are expecting larger ems like that. page frame is stored in conventional memory and there is 540kb of conventional memory free.

i try to use bare emm386 with ram parameter and compare it... when using "noems" there was aprox 610kb of conventional ram free even when files and buffers were on their topmost limit, but UMB was completely used.

also i was able to run UMBPCI to locate only 32kb of memory but the effect was same as using emm386 with ram parameter.

Right now i try to lower the buffers to 20-30

Posted

@Offler: did you try DEVICEHIGH=<path>\XMS2EMS.SYS ? What happened?

If you can load it high, the page frame will be located in the UMB arena, not in the convetional memory arena...

Posted (edited)

i didnt tried it because emm386 is able to store its page frame to UMB automatically. the configuration as described was almost same as emm386 can do. i wanted to place page frame elsewhere.

for example i placed page frame at d800 where UMBPCI begins with its umb mapping. it worked for DOS perfectly but i was unable to run windows...

Edited by Offler
  • 16 years later...
Posted
On 12/28/2007 at 7:34 AM, dencorso said:

did you try DEVICEHIGH=<path>\XMS2EMS.SYS ? What happened?

If you can load it high, the page frame will be located in the UMB arena, not in the convetional memory arena...

Given "XMS2EMS.SYS", at least, works correctly on my hardware (Unlike 386MAX, which causes a hang when booting). However, this is at the DOS stage. But when you start WINDOWS, at the very final stage, right before the desktop appears, the following message appears on a black background:

Quote

While initializing device V86MMGR:
ERROR: Unsupported expanded-memory driver already installed. Remove the driver from CONFIG.SYS

and then the computer shuts itself down. After a bit of searching on the Internet, I was able to find out that this problem may be caused by the lack of "XMS2EMS.SYS" support for the Global EMM Import Specification (GEMMIS), which is required for transferring control to WINDOWS. Here, for example, something similar is discussed (About the need to add this function to a similar product):

https://github.com/Baron-von-Riedesel/Jemm/issues/5

it also provides links to GEMMIS source code sources and examples of open source products where it has already been successfully implemented (for example, DOSBOX).

As part of the package " xms2ems.zip "contains its source code in the file "xms2ems.asm". You can download it, for example, here:

https://www.minuszerodegrees.net/5170/ram/5170_extended_memory_use.htm

or here:

http://files.mpoli.fi/unpacked/software/programm/asm/dosutil.zip/

Do you think it will be possible to add support for GEMMIS to XMS2EMS so that you can boot with it on WINDOWS?

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...