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

[dencorso]

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

[dencorso]

wsxedcrfv, on 13 January 2011 - 08:33 AM, said:

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.

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

This post has been edited by submix8c: 13 January 2011 - 08:50 PM

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

[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....per_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.micro....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.micro....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:

Quote

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

[dencorso]

VMM.VxD is way more sophisticated than emm386.exe.
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.

Quote

The main difference between the 8237A adn the 8237 is the introduction of HD audio capabilities, like Intel's ICH7, the chipset will support output of up to 8 channels and 192k/32bit. Otherwise, VIA VT8237 and 8237A is exactly the same, pin for pin.