I bought SB LIVE 5.1 recently. Its dos emulation driver needs emm386 driver or similar.

also i tried hiram memory trick to put himem.sys to upper memory.This is my config.sys:

device=c:\dos\umbpci\umbpci.sys
DEVICE=C:\dos\hiram\HIRAM.EXE
DEVICEHIGH=C:\OS\himem.sys /numhandles=128 /hmain=64 /TESTMEM:OFF /Q
DEVICEHIGH=C:\DOS\EMM386.EXE NOTR

this order allows to load himem sys to upper memory and also allows SBlive, but emm386 gives info that it cannot adress some memory range or like that and requires hit to any key...

With this configuratiom emm386 has only 4kb in conventional memory and it does not affect upper memory. Also it seems that no special 32bit dost extenders are needed.

Memory managing works as i imagined but how can i remove that annoying pause?

Can you do all the above and still have a stable system with 1.5 GB of RAM?
You are the first person I ever heard of that managed to use > 512 MB of RAM *and* EMM386.EXE...
I'm impressed!

Yes it works. Maybe it is caused with chipset. i have Via Apollo Pro 133T. These chipsets are excellent with memory handling. The system is performing better as common P4 with DDR.

I will put it here all as it is written

Config.sys:

SWITCHES=/F /E
DOS=HIGH,UMB,NOAUTO
FILEShigh=255
FILES=255
BUFFERShigh=99,8
BUFFERS=99,8
LASTDRIVE=K
FCBShigh=1,0
FCBS=1,0
STACKShigh=0,0
STACKS=0,0
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=C:\DOS\EMM386.EXE NOTR
SET PATH=C:\OS;C:\OS\COMMAND;c:\vc;C:\DOS
SET BLASTER=A220 I5 D1
SET CTSYN=C:\OS
DEVICEhigh=C:\DOS\QCDROM.SYS /D:AADVARK
SHELL=C:\COMMAND.COM C:\ /E:1280 /L:160 /U:160 /P /F
ACCDATE=C- D- E- F-
DEVICEhigh=C:\OS\SETVER.EXE
DEVICEhigh=C:\OS\IFSHLP.SYS
device=C:\OS\COMMAND\DISPLAY.SYS con=(ega,,1)
Country=421,852,C:\OS\COMMAND\country.sys

Autoexec.bat

@echo off
rem @CTTY NUL
LFNFOR ON
c:\dos\xmsdsk\xmsdsk.exe 524288 K: /c1 /t /y
rem C:\OS\COMMAND\label k: scorpion
lh C:\dos\blaster\sbeinit.com
c:\dos\shsucdx.com /d:AADVARK /Q /l:f
c:\dos\cmouse\ctmouse.exe
mode con codepage prepare=((852) C:\OS\COMMAND\ega.cpi)
mode con codepage select=852
keyb sl,,C:\OS\COMMAND\keybrd2.sys
c:\dos\umbpci\umbfill.com
rem CTTY CON
SET PATH=%PATH%;C:\PROGRA~1\ATITEC~1\ATICON~1

this allows me to put most device drivers from dos mode to upper memory. There is also XMSDSK present which change 512mb to Ramdisk and there is windows swapfile to improve overall system performance. If EMM386 or UMPCI is not present XMSDSK will freeze system. i really dont know why when it works with XMS and not EMS.

Umbfill allows me to use 1gb of standard memory. without it i have to enlarge ramdisk to 700mb. UMBfilled memory is 3kb so i have some space for one or two smaller drivers.

also buffers and files shall be confusing for some people. I was trying to set it up as MDGx recomends, but it had one setback. Oblivion is probably working with extremely large number of Files. 150 was not enought so i entered the highest possible number and it works. I want this system to work with all apps - dos and win32 based.

this also could be little bit confusing.
FILESHIGH=100
FILES=150

if these two commands are entered this way it means that 100 files shall be located in upper memory and total amount of Files is 150 - which means that rest of 50 files will be located in conventional memory. I put these lines together because there is possible that system use default value if "FILES" command is missing.

Also "NOAUTO" setting allowed me to enter some files of system manually to config.sys and there set their position to upper memory, else these files shall be called automatically by system (to conventional memory)


Fatness of EMM368 is supressed, himem is in upper memory and dos games are working without any trouble, swapfile is on ramdisk and i have 1gb ram for windows. Only what i have to do is hit a key during startup or wait a couple of seconds longer...

problem solved. EMM parameter line must be entered like this:

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

This configuration allowed SBlive emulation driver to run and also all games based on dos4gw were running correctly, even when no EMS is present. Only few very old games had problem with it - The Elder Scrolls: Arena, Dynablaster, Aladdin and some other.

the only mystery that remains it why 10mb of memory is missing when this device is used. Without EMM386 i have 1024mb of RAM present in my windows, with it i have only 1014mb of ram...

Many newer DOS era drivers (like your SB emulation drivers) will use XMS for part of their memory for processing either to stay out of conventional memory, or because they would use too much memory if it were in conventional/upper memory.

Using NOEMS on EMM386 is what stops it from using EMS memory. With that parm, it only becomes a UMB provider. From looking at your complete CONFIG.SYS, I see you are already running one in UMBPCI.SYS. You might consider dropping EMM386 to test if you only use UMBPCI.SYS. If you want EMS memory, consider running EMM386.EXE alone without UMBPCI.SYS. And if that doesn't work, use the NOUMB option in running it alone. EMS works by swapping memory into and out of a 64KB block of upper memory, which makes it require most of upper memory to function. UMBPCI.SYS will allocate all upper memory blocks when it loads, so the EMS driver will not function.

To dencorso: Usually most drivers are okay with an excess of resources as long as they are written to handle it. If you notice, Offler mentions that it shows 1024MB (1GB) capacity when he has 1.5GB, which means the driver is likely using 1GB as an artificial ceiling. But running EMM386 is irrelevant in his case (likely), because HIMEM.SYS is what will control memory access.

umbpci and hiram is used in this case only to trick himem.sys to store it into upper memory. that config is little bit weird (xms provider already loaded in umb) but it can spare me some kilobytes in conventional memory.

Usually users do not need emm386 in windows 9x if they dont want to use dos programs. Emm386 provides EMS, UMB and Protected mode. UMBPCI provides only UMB which is mostly better choice just because it is not so fat as EMM386 Managing...

I need Protected mode. Not because i want to use it, but just because some dos applications are programmed for it - therefore i can use dos4gw without trouble and no other dos stubs are needed.

I need EMS for older games.

these two functions of EMM386 are crucial for wide spreaded compatbility. UMB managing which EMM386 provides is really a disaster for upper and conventional memory. i try some other configurations... and i hope i find another better solution.

Edit:
i tried some different configurations but none of them worked. If i want to have full compatibility it will by at cost of half of upper memory and part of conventional memory - with full usage of emm386 and without UMBPCI and HIRAM.

One positive thing is that i found a way how to remove umbfill to run windows 98 correctly even without umbfill. it seems that "LocalLoadHigh=0" works this time.

Last thing i can do is to find an EMS manager which will work with all other memory managers together - something that can transform part of XMS to EMS without negative side effects as emm386 did.

Edit2:
i made free some kilobytes again and put more programs to upper memory. now i have 615000 bytes of conventional memory available and conventional memory is almost full (720bytes needs to be umbfilled). the thick with localloadhigh does not work anymore, and i really dont know why.

Thanks a lot, Offler and Glenn9999, for all the enlightening info and comments. You both rock!

Now, here're my 2 ¢... To have Protected Mode without using EMM386.EXE, you can use CWSDPMI.EXE, which comes with lots of software, the Ranish Partition Manager (RPM) among them. Unless you really need you PM interface to be VCPI, not DPMI. Many dos extended programs can use either. Some, cannot. YMMV. But EMM386 NOTR NOEMS as Offler uses it is working just as a VCPI provider IMHO. Maybe there is some standalone VCPI provider, just like CWSDPMI, although I don't know of any.

As far as I'm aware in all the documentation I've seen in the past, EMM386 was never a protected-mode providing driver, so to speak. Usually, in anything to do with protected-mode, there's always an accompanying driver that the software is designed to work with. CWSDPMI is an example that was given, DOS4GW is another one. I've seen generic Dos Protected Mode Interface (DPMI) providing drivers (and I could probably look in my DOS stuff and see if I could find you one). EMM386 is not one (at least according to PKZIP/PKUNZIP 2.04g when I ran it).

I think the confusion lies in this: EMM386 is a VCPI client . Basically put, VCPI is what enables programs to see all the memory as either EMS or XMS memory (unlike DOS 5.0 or so when the EMS driver tied up memory, etc). VCPI has nothing to do with protected-mode programs. If you don't use EMS memory, then you don't need VCPI, which means if you don't need EMS memory, then you don't load EMM386.

To summarize: VCPI is not protected mode!



All DOS4GW requires is a XMS memory provider. I've run many games which use that without EMM386.



As was said, EMS works by swapping 64KB chunks of memory into the UMB. So #1: Your UMB handling needs to be through EMM386, and #2: You'll get maybe 30KB at the most aftewards - you either get the gobs of upper memory to load drivers, or EMS, not both. There's no way around both of these facts.

(And I don't think you'll find anything different/better for an EMM386 driver. When I looked at OpenDOS last, it was using virtually the same EMS driver as MS-DOS)

As was said, you'll want to use either UMBPCI.SYS or EMM386.EXE, not both. If both will load, one of them will be a waste in memory. Besides, you should be able to load the SB emulation driver without using much conventional memory, anyway. If you wish, I can look at my old configs and see what I did with my emulation driver load back in the 98 days - I didn't have a problem getting enough memory to run anything in DOS back in those days.

well there are different things.

umbpci is good for memory managing in windows. the best i have seen. it does not turn on protected mode as i know.

Emm386 and similar are turning on protected mode and creating EMS. I dont know much about technical details but i think this description fits.

In my case UMBPCI is not loaded in memory with emm386. it try to load before himem.sys, but because himem.sys is not present it only maps UMBs. Then HiRAM do something similar so upper memory is fully available before himem is loaded, but no manager is present at this time - memory is empty. then i can load himem.sys with Devicehigh parameter

also i tried different expanded memory managers. applications had several trouble with them. Without EMM386 i was unable to load SBLive emulation, and some dos4gw apps. Aplications which use EMS (TES: ARENA) are automatically not working.

i tried cwsdpmi and similar but it was not the right choice. sbemulation was still not working and some dos4gw were not working anyway. i tried dos32stub and it worked but i need to recompile some *.exe files and it was waste of effort.

i like emm386 like is used now. without EMS support, only with its basical service which allows sbemulation and other apps to work correctly. Good for compatibility, but its ems support is just terrible.

what i need now is EMS emulation driver. i have heard about Rdosems.com, but the file is unavailable on internet...

i need something which can create ems and nothing else. In my system UMBs are provided by hiram and umbpci, compatibility with all apps is granted by himem.sys and emm386 but i want to use different way how to enable EMS.

EMM386.EXE runs in V-86 mode, which is a kind of protected mode. For some more on DPMI/VCPI look here.

@Offler: try XMS2EMS, by Jeff Prosise. It might prove to be just what you're looking for.

If I recall correcty, the latest QEMM version also works well with Windows 9x (well, I think it was before Windows 98 came out, but it is worth a shot). If it works, it can replace your complicated HIMEM.SYS, EMM386.EXE, UMBPCI.SYS and HIRAM.EXE setup altogether. The only drawback would be your SBLive drivers, that are way too picky about memory managers, and they might not be very happy with QEMM.

Another detail: for someone trying to squeeze every byte of conventional memory, it is amazing that you're not using a 3rd part shell like 4DOS. If I recall correctly, 4DOS has a much smaller memory footprint than COMMAND.COM, can handle LFNs in Windows and is way more powerful. Also, if you get some DOS-based cache drivers like SmartDrv, though you should search FreeDOS's utilities page for other/better ones, you can ditch those horriby large BUFFERS to something like 10,0 (that should fit in HMA) and get a performance boost at the same time. Just remember to add you cache driver to the [SafeList] section in your %windir%\ios.ini or else you'll loose 32-bit disk-access.

EDIT: (double-post, sorry)

to alexanrs:
If possible i try to use original memorÿ tools. i dont want to use non standard command.com because of compatibility. i tried the qemm.sys already. it created 256mb of ems, but it has not possibility to set the frame position.

to dencorso:
xms2ems did the memory trick. it opened ems 64kb page frame in conventional memory and created 8mb of ems. worked good for TES:Arena, but sblive nor dos4gw extenders were not functional... but very good beginning.

i tried this configuration:
DEVICE=C:\DOS\EMM386.EXE FRAME=NONE NOTR

this setting created 32mb of EMS without creating page frame. EMS is present but it didnt worked for TES:Arena.

i need 64kb of memory where can be page frame...i try to remove some bios shadowings and maybe there shall be enough place for placing it...

From QEMM help file:





You'll get more free UMBs if you change a few things in your config.sys:

1. FILES=255? Are you sure you need that much? You should try to reduce that to something more reasonable (and less conventional memory consuming) like 60. I myself use 40 and never had troubles.
2. You used NOAUTO, so if you really do not want to go 4DOS (I never had compatibility issues with it), you should check if your COMMAND.COM is being loaded high (if you want it to, of course). I think you can replace SHELL with SHELLHIGH to ensure that.
3. I will insist on this one: I just noticed you use QCDROM.SYS, so you might replace it with UIDE.SYS (in the freedos page I told you about in the last post), which provides cache (from 5mb up to 1GB), CD-ROM support and UDMA. And it uses about 5kb of conventional memory and would allow you to remove your insanely large (and upper-memory consuming) BUFFERS and also QCDROM.SYS, freeing up some more memory. The only problem here would be your SBLive drivers, that require the first 4 MB of extended memory to be free, so you'll probably need to load SBEINIT before UIDE.SYS (there are utilities that allow you to load TSRs from CONFIG.SYS in a DEVICE(HIGH) line, or .SYS drivers from the AUTOEXEC.BAT)

One last question: Have you considered having multiple configurations, one for Windows and one for DOS-only programs via a boot menu? If you search through MDGX's site you'll find all the information you need to achieve that.

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

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

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.

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.


OK


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)?

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

@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...

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...