giving EMM386 no parameters other than RAM is pretty safe

I tried that:

DEVICE=C:\WINDOWS\EMM386.EXE RAM /V (apparently /MIN=0 is an invalid parameter)

And it works! ...but, I'd still like to know where in memory the VFAT stays. Internet searching hasn't gotten me very far.
Although, if I understand correctly, the I=B000-B7FF just frees up some conventional memory by moving reserved memory space to the upper memory area...

So I realized my problem wasn't with that line at all it was the NOAUTO at the end of my DOS= line:

DOS=HIGH,UMB,NOAUTO

"NOAUTO makes it possible to load drivers and TSR programs in conventional memory"

Looks like that's what was taking VFAT resources.

My working file now looks like this:

NUMLOCK=ON
BREAK=ON
DOS=HIGH,UMB
FILESHIGH=40
FCBSHIGH=1,0
STACKSHIGH=9,256
DEVICE=C:\WINDOWS\HIMEM.SYS /V
DEVICE=C:\WINDOWS\EMM386.EXE RAM I=B000-B7FF /V
DEVICEHIGH /L:2 =C:\WINDOWS\SETVER.EXE
SHELL=C:\WINDOWS\COMMAND.COM C:\WINDOWS\ /E:1024 /P

Now to get my ASPI working again...

B000-B7FF is used for MDA or the first HGC page. If you don't use that you should theoretically be able to use it for EMS or UMB.
I have also used a VGA card which could enable an LFB in A000-BFFF.
VGA cards are usually able to switch into a HGC compatible mode so keep that in mind if you want to experiment with games using HGC mode.

Regarding NOAUTO: I didn't know that parameter so I looked it up.
https://support.microsoft.com/en-us/kb/116253
Basically the parameter tells Windows (or probably the DOS kernel) not to load some stuff automatically. That will save some conventional memory. In that case you would have to include those drivers manually in CONFIG.SYS if you need them.
One example would be IFSHLP.SYS which your CONFIG.SYS doesn't include.

A missing IFSHLP.SYS can definitely be the cause for a VFAT blue screen as shown here:
https://support.microsoft.com/en-us/kb/139063

Try removing the I=B000-B7FF line.

NOAUTO also prevents DOS/Windows to automatically move BUFFERS, FILES, STACKS, SHELL and other stuff to UMBs automatically, so theoretically it can even reduce the available conventional memory unless you use BUFFERSHIGH, FILESHIGH, etc. It is not very useful for a Windows installation, because the stuff that it loads automatically is stuff Windows NEEDS (IFSHLP, the installable file system helper, being one of them and whose lack is DEFINATELY capable of giving you VFAT issues).

I don't see why manbearpig needs EMS if he wants to run Win98.
Basically he can leave config.sys empty as HIMEM.SYS and IFSHLP.SYS are loaded automatically as well as the default FILES, FCBS etc. settings are just fine.
This simplifies to a working config greatly.

elianda wrote:

I don't see why manbearpig needs EMS if he wants to run Win98.
Basically he can leave config.sys empty as HIMEM.SYS and IFSHLP.SYS are loaded automatically as well as the default FILES, FCBS etc. settings are just fine.
This simplifies to a working config greatly.

I'm assuming he wants to be able to use the same config for both Windows and "Command prompt only" at startup. I personally prefer using the "BOOTCONFIG" directive in MSDOS.SYS and making a boot menu.
EDIT: Also, if you have a slow HDD, using SmartDRV (which does benefit from UMBs) can speed up the first portion of the boot process (before Windows loads its own cache). Something like SMARTDRV 2048 256 should give a good boost while only taking 256KB of ram after Windows is loaded. On newer PCs with faster controllers I'd rather use UIDE without a cache for this.

Thanks for the tips, guys. Basically I want to create a good working DOS environment for when I don't start Windows. I have my system set to not load the GUI automatically, and have a config menu with options CD-ROM support, no CD-ROM, and start Windows. I want to be able to start Windows without restarting the computer if I am working in DOS, which is why I was trying to get a config that would allow this.

Thanks for the SmartDRV tip, the computer is a 430VX Pentium but it does have an Ultra ATA133 PCI controller and Barracuda 80 GB HDD.