Question about emm386.exe Why do I have to use X= exclusion range?
Posted 12 January 2011 - 08:22 PM
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?
Posted 12 January 2011 - 09:01 PM
Posted 12 January 2011 - 09:49 PM
The video card is an EVGA 6200 (256 mb AGP).
This post has been edited by wsxedcrfv: 12 January 2011 - 09:50 PM
Posted 13 January 2011 - 08:33 AM
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?
Posted 13 January 2011 - 12:17 PM
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.
Posted 13 January 2011 - 07:18 PM
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.
Number of downloads: 15
Number of downloads: 14
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 - ?
Posted 13 January 2011 - 08:45 PM
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.
Posted 13 January 2011 - 10:15 PM
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.
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.
Posted 13 January 2011 - 10:36 PM
Posted 14 January 2011 - 03:18 AM
Guides for EMM386.EXE usage = download W95-11D.EXE or W95-11D.ZIP (freeware):
Install (exe) or extract (zip) the files, and then read these plain text files:
[especially sections about expanded memory]
Few more tips here:
9x OSes SETUP switches:
Posted 17 January 2011 - 03:53 PM
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):
More details in REGIONS.TXT, part of my tips files archive (freeware):
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.
Run this command from a DOS box to see all emm386.exe available switches:
and see also the undocumented ones, if you wish:
EMM386.EXE switches are also detailed in your MSDOSDRV.TXT file, found in %windir% (installed by Win9x), or online:
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]:
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:
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:
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.
Posted 17 January 2011 - 08:33 PM
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.
Posted 17 January 2011 - 09:39 PM
So, in a nutshell, if you exclude both regions I mentioned above (or remove emm386.exe altogether, but I don't think that's really necessary to come to that), *and* install windows using "setup /p i" to instal without ACPI, I bet all will go smoothly. Then, after everything is up and running OK, you may remove the exclusion of the E000 segment, to see whether it really is needed. The whole C000 segment must remain excluded, that much you already know.
Then again, that's just my bet. You can't really know if you don't actually try it. But my previous experience with ASUS boards based on the 8237 southbridge leads me to believe that the procedure I outlined should be enough for you to have a stable machine with 9x. BTW, your board actually uses the 8237A chip, but, as you may see from this excerpt from an old press release about them, they are alsmost the same chip.