[Jimmyjam]

HimemX with /Max=524288, by itself, *should* be ample to overcome the initial boot issues

It should, but I've got the case open and a 512MB module in a drawer anyway. Physically limiting the ram during install just eliminates another variable. As for the ramdisk, that was initially set up largely just to put the extra memory to use since it's there.

^Jimmyjam
Man, this two lines ->

Must be removed when you use my patcher

That was just a test in a virtual machine. The patcher didn't seem to mind at all, though. The patch works in the VM regardless of whether or not those lines are there.

The lines were not added for the test on actual hardware. System.ini was untouched, but the VFAT lockup still happened during reboot.

I do not think so. I think Q288430 causing troubles.

You can do one experiment?

Couldn't hurt.
I followed your instructions, but did not get far.

On step 2, when trying to run 4G_Enabler:

untitled.png (21.08 KiB) Viewed 4612 times

Also- I just found out that the commercial VMM patcher has an option to load the VXDs in VMM32 outside the lower memory area, freeing up more of the first 16MB for memory tables and other drivers. I'll try experimenting with the demo of that to test my hypothesis.

[Steven W]

Jimmyjam, I wasn't intending that comment for you, more for some total newb. I don't want anyone thinking that there's some impossible amount of work to be done to accomplish this.

[Jimmyjam]

Okay, those tests were pretty conclusive.

If I allow the commercial patcher to perform its default patch to the VMM files, I get exactly the same issue I had with the 4G_Enabler patcher: "VFAT Device Initialization Failed."

However when I use the /M switch (relocate VXDs in memory) on the commercial patcher, it patches the VMM files to load outside the first 16MB of memory and the system boots properly. It recognizes the full 3GB of memory.

I think 4G_Enabler is working just fine. Some hardware (like apparently my Gigabyte board) just requires additional steps to be taken over and above enabling the use of 4GB, because of limitations in how much lower memory the hardware leaves available to the OS.

I also don't think 4G_Enabler is that sensitive to system.ini changes. Virtualbox doesn't have the 16MB issue, so I did testing with various settings.ini changes in the VM, and the patcher doesn't seem to care at all about vcache settings, or even maxphyspage. I even tried setting maxphyspage to 80000 just to see what would happen and the patcher doesn't mind at all. Win98 just limits itself to 2GB of memory out of the 3GB in that case and still boots properly thanks to the patch.

Jimmyjam, I wasn't intending that comment for you, more for some total newb. I don't want anyone thinking that there's some impossible amount of work to be done to accomplish this.

Not to worry. I just like being thorough.

[Steven W]

When you're saying "commercial VMM patcher", you're meaning rloew's patch?

[Jimmyjam]

Yes, that's the one.

I also noticed in the documentation for it that Gigabyte is specifically mentioned as having network hardware that can produce issues loading VMM drivers into the first 16MB of memory.

So I completely disabled the network interface in the BIOS and tried RFMaster's patch again. The system boots!

Re-enable the network interface, and it starts hanging on VFAT initialization again.

So this is exactly the problem. You can't load VMM drivers into the first 16MB on this hardware. They must be relocated to higher memory or the networking hardware disabled.

[Steven W]

Is there a driver that works with Windows 98 for the networking card? If so, what happens if you load it before installing the patch? Or, have you done that already?

[Jimmyjam]

There is a working driver and I was using it before, but I've tried with and without. The mere presence of the network controller causes the problem because it steals a chunk of the first 16MB of address space at the BIOS level when enabled and Win98 does not know how to work around this while managing large amounts of memory.

It looks like relocating the drivers in memory is the only way to run over 1GB of memory while using the network interface.

[Steven W]

Got it, that's a pain in the ass!

[Steven W]

I suppose too, there's no forcing it to use a different memory range under resource tab -- from device manager...you know what I mean.

[Steven W]

http://support.microsoft.com/kb/133240/EN-US