Question about emm386.exe

[Guest wsxedcrfv]

I generally start a win-98 installation process by formatting a hard-drive and "installing" DOS on it first, and then copying the win-98 CD image to the drive and installing 98 from the image.

I never have a problem with DOS as far as the himem, emm386, smartdrv goes, but I now have an issue with emm386 and an Asrock 4-core Dual VSTA motherboard (the "4-core" is part of the name of the motherboard - I do not have a 4-core CPU installed on this board in case you're wondering).

I never have had to specify an EMM386 memory exclusion range for any PC I've worked with in the past, but in this case I have to specify X = C800 - CFFF. If I don't do that, then DOS hangs during booting - I think during loading of EMM386. That range is (I believe) part of the standard CGA or VGA video memory area. Why is EMM386 not properly detecting and excluding that area automatically?

[dencorso]

No. C800 - CFFF is the (old) HDD BIOS arena. The EGA/VGA low memory arena is C000-C7FFF. But many newer XVGA boards may go as far as C9FF, and emm386.exe may not detect that correctly. If you have Jeff Prosise's UMASCAN.COM, run it without emm386.exe loaded and you may get a good idea of what emm386.exe is actually detecting (or failing to). Or change the video card for the older one you have at hand, just for testing sake, and see if the issue goes away. If so, then I'm right: it's the video card, all right.

[Guest wsxedcrfv]

Would the video memory aperture size in the bios have anything to do with this? Is there an optimum setting for this when running win-98 ?

The video card is an EVGA 6200 (256 mb AGP).

Edited January 13, 2011 by wsxedcrfv

[dencorso]

No. Run UMASCAN in dos and post a pic of it.

[Guest wsxedcrfv]

Run UMASCAN in dos and post a pic of it.

I'm going to have to run it straight from DOS, because I don't yet have win-98 installed on this motherboard (I'm having some trouble getting through the full install without getting a blue-screen error or the system hanging - not sure why).

Is emm386 supposed to be loaded first when running UMAScan?

[dencorso]

I'm going to have to run it straight from DOS, because I don't yet have win-98 installed on this motherboard.

Is emm386 supposed to be loaded first when running UMAScan?

Yeah. Run it from plain DOS, with just HIMEM, but *without* emm386. This is the way to find out where there's ROM or other memory in the upper memory area, in the 1st MB of ram (the real memory arena). A common boot floppy, having no autoexec and a one-line config.sys with "DEVICE=HIMEM.SYS" is the ideal way of doing it.

[Guest wsxedcrfv]

I find that UMAscan crashes or locks up about 80% of the time I try to run it. When it locks up, it displays no memory map. I have to reset the computer and boot back into DOS and try again.

I captured 2 screens - one with emm386 loaded and one not loaded. They are basically the same, except that you'll see on one of them that the segment at D000 is blank - there's no indication as to what is using that segment. That was captured when UMAscan was running without emm386.

Memtest 86 runs just fine - no memory errors.

So to repeat - I must use the exclusion switch X=C800-CFFF when using emm386. If I don't use that switch then the machine hangs during boot. I don't know if I should make that range larger - ?

[dencorso]

You should exclude the whole C000 segment: X=C000-CFFF.

But how comes you already have RAM at E000, before loading emm386? That's not common at all. Why is it there?

I think emm386 is invading that RAM and letting some BIOS routine, probably SATA or USB without its communication area. So I suggest you exclude it too (X=E000-EFFF) and see whether your problems go away. I bet that's the origin of your BSODs. Were I you, I'd try to avoid using emm386 altogether. The RAM you can recover, in case I'm right, is just 64k, the D000 segment. I bet you can make do without it in DOS, and Win 9x/ME don't really need emm386, and, in fact, works better without it. My own board is a case in point. Removing emm386 left my system much more stable. And my board uses the same southbridge as yours do... so my example may very well apply specifically to your case.

For the record, here's your motherboard's manual...

It may help us.

[submix8c]

Hmmm... D000 used to be generally used for an add-in NIC (ISA, specifically ) or other add-in card.

Edited January 14, 2011 by submix8c

[dencorso]

Yes, but since there's nothing on D000, according to UMAscan, I think that segment is safe to let emm386 take over... UMAscan is very thorough, and usually reliable.

[Guest wsxedcrfv]

But how comes you already have RAM at E000, before loading emm386? That's not common at all. Why is it there?

I have no idea. I have no control over that, as far as I know. The motherboard manual does not include a memory-map of the first 1-mb.

Were I you, I'd try to avoid using emm386 altogether. The RAM you can recover, in case I'm right, is just 64k, the D000 segment. I bet you can make do without it in DOS, and Win 9x/ME don't really need emm386, and, in fact, works better without it. My own board is a case in point. Removing emm386 left my system much more stable.

I always have emm386 in my config.sys just for when I start the machine in DOS mode or when I open a DOS shell.

I thought that when win-98 gets installed that it doesn't need or rely on anything in config.sys or autoexec.bat because once win.com is started, the CPU is switched over to protected mode and DOS is effectively wiped from memory as the 32-bit kernel is started.

[dencorso]

It's more complicated than that. The 32-bit core interacts with the 16-bit core, and that takes over DOS by patching in-memory and hooking. DOS is not wiped out, it remains there and is taken over by Windows, not removed. Emm386 is also taken over, if present, so that makes the protected mode switches more involved. You probably will be able to install Win 9x by excluding both the C000 and the E000 segments. If you do, run it for some time with emm386, test it well, then comment out emm386 and test it again. Windows uptime, in my experience, is much longer when emm386 is not loaded. If, however, you keep running into trouble on installation, do it without emm386.exe, and if that's not enough, do also disable ACPI from install time (i. e.: use "setup /p i"). Read also this, for further info. I bet you'll succeed in your installation.

[MDGx]

FYI...

Guides for EMM386.EXE usage = download W95-11D.EXE or W95-11D.ZIP (freeware):

http://www.mdgx.com/95.htm

Install (exe) or extract (zip) the files, and then read these plain text files:

MEMORY.TXT

REGIONS.TXT

EMM386.TXT

[especially sections about expanded memory]

Few more tips here:

http://www.mdgx.com/newtip20.htm#9SMM

9x OSes SETUP switches:

http://www.mdgx.com/last2.htm#SETUPSW

HTH

[MDGx]

X=yyyy-zzzz memory address ranges (can be more than 1 X= switches on the same EMM386.EXE line) exclusion is necessary to make sure the operating system (DOS, Windows 9x) doesn't use by accident the same range(s) used by certain hardware devices/peripherals/cards.

Such devices use preset (built-in, hard-coded) memory ranges when your PC boots, and in most cases nothing can change that.

You just need to make sure DOS (and implicitly Windows 9x) and software applications/drivers/TSRs/processes/etc do not use the same ranges, to avoid lockups/errors/data loss.

All these memory addresses are in the upper memory area (UMA):

http://en.wikipedia.org/wiki/Upper_memory_area

More details in REGIONS.TXT, part of my tips files archive (freeware):

http://mdgx.com/95.htm

To see a generic map of what uses which ranges, please see REGIONS.TXT, the "2. Conventional Memory: below the 1st MegaByte" section, and also the "III. MDGx ADDENDUM = UPPER MEMORY REGIONS MANAGEMENT" section (bottom of file).

Please look also at at MEMORY.TXT (part of my tips files archive) under the "I. My CONFIG.SYS Lines Explained" section for more details.

MSKB article:

http://support.microsoft.com/?id=112816

Run this command from a DOS box to see all emm386.exe available switches:

HELP EMM386.EXE

and see also the undocumented ones, if you wish:

http://www.mdgx.com/secrets.htm#EMM

EMM386.EXE switches are also detailed in your MSDOSDRV.TXT file, found in %windir% (installed by Win9x), or online:

http://support.microsoft.com/?id=234868

You can use the MSD command in either native DOS (recommended) or from a DOS box (not recommended, adds memory ranges used by Win9x OS memory manager) to view the UMA layout. The areas used by hardware devices are coded with the letter R (reserved) or U (used).

MSD editions [free]:

http://www.mdgx.com/speed.htm#MSD

Just make sure an expanded memory manager (EMS) like EMM386.EXE is not loaded from your config.sys when you run MSD, otherwise most UMA areas will be in use by either EMM386 manager itself or its EMS page frame (marked with the letter P on the MSD screen) = page frame range can be changed to make sure it doesn't conflict (overlap) with memory areas used by some hardware device(s) => see the FRAME=xxxx-yyyy switch.

MSD9X.TXT (from my tips files archive) has more details.

To be safe, add this line to your SYSTEM.INI [found in %windir% = usually C:\WINDOWS] under the [386enh] section:

EMMExclude=A000-FFFF

To prevent Windows from searching the Upper Memory

Area (UMA) for unused memory (RAM) upon startup. Safer

if using any 3rd party memory managers (QEMM, NetRoom,

386MAX etc), or any real MS-DOS mode

devices/drivers/TSRs in CONFIG.SYS/AUTOEXEC.BAT. This

is equivalent with starting Windows by running:

WIN /D:X

This is found here:

http://www.mdgx.com/lastweek.htm#SYSINI

A000 (hex) is the bottom (lowest) address (where UMA starts), and FFFF (hex) is the top (highest) address (where UMA ends).

This way, you can make sure the OS/software/etc will never use memory ranges which might otherwise in use by hardware devices.

HTH

[Guest wsxedcrfv]

HTH

Well, ok, let me put it this way.

I don't really have a direct need for emm386 on my systems. I just have a habit of putting it in my startup files, right after himem.sys. I don't know why I do it - I just always have done it. I figure why not. Whether or not having himem.sys and emm386 in my config.sys is necessary or does Windows 98 any good - I don't know.

BUT, with that said, I must say that it bummed me out that I had to come up with an emm386 exclusion range for this Asrock motherboard just to get DOS to boot. Normally emm386 just works and I don't have to putz with it - on any of the 2-dozen different motherboards I've worked with for the past 20 years.

So in this case, if emm386 didn't properly recognize upper memory usage all by itself, then I'm thinking that maybe Win-98 will also screw itself up during the install process for the same reason. Or maybe I'm completely off-base about that.

I really don't want to learn all these nitty-gritty details about emm386. I just want to know if the installation of win-98 will be problematic for the same reasons that emm386 needed my help to get itself working on this motherboard.