mockingbird wrote on 2025-06-04, 16:35:

Very simple:

Add RLOEW's limitmem to config.sys as the first line.

This only stops himem.sys from claiming and servicing the address space.

The system would still have ram connected to addresses above this limit, which is the suspected culprit.

386+ cpus have a feature called an MMU, or Memory Management Unit. On intel processors, it's a feature of protected mode.

https://en.m.wikipedia.org/wiki/Memory_management_unit

The utility I posit would use this functionality to literally tell the CPU to disconnect (ignore) physical address above the detected threshold, using this method.

This means nothing would be in the way of the OS using the MMU later to do virtual addressing.

--

Addendum:

Isolinux+memdisk assume control over physical addresses outside what the bios int15h reports, so that the memory used by the ramdisk is not in contest with the XMM or running OS. Accesses to those physical addresses still talk to physical RAM, which is HOW the ramdisk functions.

It is this 'Ram still connected, even though the OS is ignorant of this fact' that I would address.

That we might not want to clobber certain hardware address connections (device crossbar area, ramdisks of this type, et al) is why an exclusion argument is desirable.

See also

https://stackoverflow.com/questions/30190050/ … ter-bar-in-pcie

mockingbird wrote on 2025-06-04, 16:35:

Very simple:

Add RLOEW's limitmem to config.sys as the first line.

I tried that already, but it doesn't help - still getting degraded performance in games.

BUT the win98 I've installed already had RLOEW's patchmem slipstreamed. I'm trying to install a vanilla copy of win98 and see if limitmem would work with that. I'll also try LIMEM and BURNMEM, to see if anything works

wierd_w wrote on 2025-06-04, 16:42:

This only stops himem.sys from claiming and servicing the address space. […]
Show full quote

mockingbird wrote on 2025-06-04, 16:35:

Very simple:

Add RLOEW's limitmem to config.sys as the first line.

This only stops himem.sys from claiming and servicing the address space.

The system would still have ram connected to addresses above this limit, which is the suspected culprit.

386+ cpus have a feature called an MMU, or Memory Management Unit. On intel processors, it's a feature of protected mode.

https://en.m.wikipedia.org/wiki/Memory_management_unit

The utility I posit would use this functionality to literally tell the CPU to disconnect (ignore) physical address above the detected threshold, using this method.

This means nothing would be in the way of the OS using the MMU later to do virtual addressing.

--

Addendum:

Isolinux+memdisk assume control over physical addresses outside what the bios int15h reports, so that the memory used by the ramdisk is not in contest with the XMM or running OS. Accesses to those physical addresses still talk to physical RAM, which is HOW the ramdisk functions.

It is this 'Ram still connected, even though the OS is ignorant of this fact' that I would address.

That we might not want to clobber certain hardware address connections (device crossbar area, ramdisks of this type, et al) is why an exclusion argument is desirable.

I'm not familiar with much of the technical language above, but from what I vaguely understand I think you're right. I'm using a 64-bit CPU (Xeon W3680) - I wonder if that's contributing to the problems.

xtreger wrote on 2025-06-04, 16:52:

I tried that already, but it doesn't help - still getting degraded performance in games.

Yes, this is a known bug with Intel chipsets and Windows 98.

mockingbird wrote on 2025-06-04, 17:10:

xtreger wrote on 2025-06-04, 16:52:

I tried that already, but it doesn't help - still getting degraded performance in games.

Yes, this is a known bug with Intel chipsets and Windows 98.

Is there any known fix or workaround for this, to your knowledge? (of course getting a different chipset motherboard is an option, but that's hard for me and probably a last resort)

e.g. installing unofficial win98 intelinf drivers

xtreger wrote on 2025-06-04, 17:19:

Is there any known fix or workaround for this, to your knowledge? (of course getting a different chipset motherboard is an option, but that's hard for me and probably a last resort)

e.g. installing unofficial win98 intelinf drivers

What you're doing isn't attainable, and you should split this into two systems, Win98 slow and Win98 fast.

Even if you switched chipsets, you will lose DDMA functionality with AMD (read: sound compatibility in pure DOS).