mkarcher wrote on Yesterday, 18:37:

Yoghoo wrote on Yesterday, 18:02:

Other tools like Astra and NSSI report only 384Kb XMS and 4Mb EMS. The 384Kb is probably the real memory from this PC (which has 1Mb memory and 4Mb EMS).

The sounds like you might have HIMEM loaded, an XMS driver for your "real XMS". I recommend you to try without HIMEM first. It's quite possible that EXMS86 is incompatible with another XMS driver at the same time. Not loading HIMEM also means you can not put DOS into the HMA ("DOS=HIGH"), so this will cause less conventional memory being free.

No himem.sys is loaded. If loaded (I tried 😀) it will not load and gives a warning.

I will be testing the beta soon, but overnight with some playlist of midi files playing on DOSMID, I got a "Error: Memory Access Fault". I replayed the midi that was playing separately, and no crash. Interesting. Perhaps it is related to the issue in the post before mine?

mkarcher wrote on Yesterday, 18:37:

The sounds like you might have HIMEM loaded, an XMS driver for your "real XMS". I recommend you to try without HIMEM first. It's quite possible that EXMS86 is incompatible with another XMS driver at the same time. Not loading HIMEM also means you can not put DOS into the HMA ("DOS=HIGH"), so this will cause less conventional memory being free.

EXMS86 refuses to load if it sees another provider of XMS memory.

Yoghoo wrote on Yesterday, 18:42:

This beta works a lot better. Mem is working. CheckIt Pro and Norton System Information 8.0 don't hang or crash anymore. They both show 4MB EMS and 4MB XMS. NSSI shows 320KB XMS 2.0 and 4MB EMS. Astra shows no extra memory above 1MB.

Wolfenstein 3D still hangs after a short time.

That's good news, I'm glad to hear. Astra is probably using the XMS3 API, which is unsupported by EXMS86. The NSSI case is much stranger. What version of NSSI are you using? I will try to reproduce the issue on my side with the same version.

Same question about Wolfenstein - is it one of the "normal" versions, or some fork?

mateusz.viste wrote on Yesterday, 18:50:

That's good news, I'm glad to hear. Astra is probably using the XMS3 API, which is unsupported by EXMS86. The NSSI case is much stranger. What version of NSSI are you using? I will try to reproduce the issue on my side with the same version.

Same question about Wolfenstein - is it one of the "normal" versions, or some fork?

NSSI version 0.60.45. Wolfenstein 3D is the normal full version. The exact version I don't know but it's not the GOG version (which includes Spear of Destiny).

I confirm the strange NSSI report. What happens is that NSSI does not rely on the XMS API to get the *total* of XMS memory, because the XMS API simply does not have such function. The XMS API can only provide the amount of currently available memory.

NSSI itself allocates XMS buffers for its own use. Then it calls the XMS API to get the available memory, and then it surely calls several int 15h functions to get the total. Afterwards it must do some math to compute the total, used and free and it certainly gets confused along the way since int 15h knows nothing about EXMS86, and vice-versa, so the math has no chance to add up.

I don't see any reasonable solution here. I mean, the only solution I think of is to intercept int 15 and answer to queries AH=88h, AH=C7h, AX=DA88h and AX=E820h instead of letting the BIOS answer, but this becomes quite a contraption. I'm afraid that might lead to some side effects, plus of course it would considerably increase EXMS86 resident size. I don't think it's worth it since the issue will likely appear only with some specialized diagnostic programs, not "normal" applications.

Intercepting int15h in a compact way to change reported size already has an example implementation in the syslinux project, in the memdisk component.

It (memdisk) hooks int13 and int15, to present a ram backed block device over int13, and adjusts output of int15 so the guest OS does not walk on the ramdisk's allocation.

It's not a dropin, of course, but their code weighs in at around 5k, iirc.

wierd_w wrote on Yesterday, 20:22:

It (memdisk) hooks int13 and int15, to present a ram backed block device over int13, and adjusts output of int15 so the guest OS does not walk on the ramdisk's allocation.

It's not a dropin, of course, but their code weighs in at around 5k, iirc.

EXMS86 has a resident footprint of 800 bytes, for comparison.

Yoghoo wrote on Yesterday, 19:05:

Wolfenstein 3D is the normal full version. The exact version I don't know but it's not the GOG version (which includes Spear of Destiny).

I tested with the shareware version 1.4, no issues. It uses XMS quite intensively, but everything seems stable. You mentioned that it has "both lines maxed out for XMS and EMS." - it's strange because in my test Wolf3D allocates all the EMS at start, and then when it asks for XMS there is none left. The difference on your side is perhaps due to the larger EMS card.. I can only emulate a 2MB card with 86box. I wonder if Wolf3D tries to use both EMS and XMS at the same time when it sees both available. In theory it should not be a problem, but who knows.

As a test, could you try loading EXMS86 with the "!" argument and see if it improves Wolf3D stability? With "!" there will be no EMS advertised, so the game will be forced to use exclusively XMS.

also tested the shareware 1.1 version - works flawlessly on XMS (with "EXMS86 !"). With just "EXMS86" (no "!") it also works perfectly, but then again on my VM Wolf3D does not detect any XMS available and hence uses only EMS. I'm afraid I'm getting to the limits of what I can do with my virtual testbed.

Would it be best if we had a tinytest program for this? Not asking for the world, but something that copies some memory around, and see if things stay sane.

EXMS86 v0.9.6 released today. Changelog:

• new arg '3': pretends XMS 3.0, fools apps that check for but do not need it
• fixed XMS-to-XMS transfers that cross 16K boundaries
• non-implemented functions return a proper error code
• optimized odd-length transfers (kindly suggested by mkarcher on vogons)
• lots of minor size and speed optimizations

Sneakernets wrote on Yesterday, 21:38:

Would it be best if we had a tinytest program for this? Not asking for the world, but something that copies some memory around, and see if things stay sane.

Here is the test program I wrote to stress EXMS86.

mateusz.viste wrote on Yesterday, 20:53:

As a test, could you try loading EXMS86 with the "!" argument and see if it improves Wolf3D stability? With "!" there will be no EMS advertised, so the game will be forced to use exclusively XMS.

Will try tomorrow. Nice to see you're so actively busy with this project btw. 😀

mateusz.viste wrote on Yesterday, 21:42:

Sneakernets wrote on Yesterday, 21:38:

Would it be best if we had a tinytest program for this? Not asking for the world, but something that copies some memory around, and see if things stay sane.

Here is the test program I wrote to stress EXMS86.

hooray! looks like my XT passed all the tests. This is good!

mateusz.viste wrote on Yesterday, 20:53:

As a test, could you try loading EXMS86 with the "!" argument and see if it improves Wolf3D stability? With "!" there will be no EMS advertised, so the game will be forced to use exclusively XMS.

Seems with the "!" argument it's stable. At least I can complete a level without hanging. No 32K UMB is added though. But maybe that's a motherboard thing as I never seen UMB on this motherboard?

Also now looking closer on the mem output I think I see what the problem is with the XMS reports from newer tools like NSSI, Astra and HWINFO. They all report 384K XMS (320K free). While older tools report 4M XMS available.

If I do a mem/c I see: Total Extended (XMS) 384K (as reported by newer tools). But Free Extended (XMS) is 4M. So it seems total extended is not being updated after running EXMS86.

Test.com ran successfully btw. Also without the "!" argument.

Yoghoo wrote on Today, 05:52:

Also now looking closer on the mem output I think I see what the problem is with the XMS reports from newer tools like NSSI, Astra and HWINFO. They all report 384K XMS (320K free). While older tools report 4M XMS available.

If I do a mem/c I see: Total Extended (XMS) 384K (as reported by newer tools). But Free Extended (XMS) is 4M. So it seems total extended is not being updated after running EXMS86.

As explained:

mateusz.viste wrote on Yesterday, 20:02:

I confirm the strange NSSI report. What happens is that NSSI does not rely on the XMS API to get the *total* of XMS memory, because the XMS API simply does not have such function. The XMS API can only provide the amount of currently available memory.

There is by definition no way to find the "total amount of XMS", so am XMS driver like EXMS86 is unable to provide that amount. Instead, tools that want to display the total amount of XMS have to find it in a non-XMS way, like for example checking the CMOS setting for "extended memory size", and guess the amount of memory managed by an XMS manager. This is bound to fail if the memory managed by an XMS manager is not provided from actual extended memory. And that's why EXMS86 is unable to "update total XMS".

If you are interested in understanding the output of memory diagnostic tools, you also need to undertstand that some tools can show both "extended memory provided by the BIOS (INT 15)" and "XMS provided by a driver like EXMS86". The extended memory as provided by the BIOS is called "linear extended memory" by some applications. The point of HIMEM is to take over the extended memory provided by the BIOS (and then hook the BIOS to report a total extended memory size of 0), and instead provide the more versatile XMS API on the extended memory. EXMS86 basically does the same, but it does not "take over" the extended memory. Instead it dynamically gets the memory to be presented as XMS from the EMS driver when an application ask to allocate an XMS block.

Yoghoo wrote on Today, 05:52:

Seems with the "!" argument it's stable. At least I can complete a level without hanging.

Excellent. This confirms the issue is related to Wolf3d trying to use EMS and XMS at the same time. I will try to look into that, but no promises since I cannot reproduce it myself, so I can only guess.

Yoghoo wrote on Today, 05:52:

No 32K UMB is added though. But maybe that's a motherboard thing as I never seen UMB on this motherboard?

The motherboard doesn't matter. EXMS "unlocks" UMB, but then you have to expose it to DOS using a driver like USE!UMB. The EXMS documentation provides config.sys examples to this effect.

mateusz.viste wrote on Today, 06:45:

Excellent. This confirms the issue is related to Wolf3d trying to use EMS and XMS at the same time. I will try to look into that […]
Show full quote

Yoghoo wrote on Today, 05:52:

Seems with the "!" argument it's stable. At least I can complete a level without hanging.

Excellent. This confirms the issue is related to Wolf3d trying to use EMS and XMS at the same time. I will try to look into that, but no promises since I cannot reproduce it myself, so I can only guess.

Yoghoo wrote on Today, 05:52:

No 32K UMB is added though. But maybe that's a motherboard thing as I never seen UMB on this motherboard?

The motherboard doesn't matter. EXMS "unlocks" UMB, but then you have to expose it to DOS using a driver like USE!UMB. The EXMS documentation provides config.sys examples to this effect.

Didn't read the documentation yet. 😜 Will try later today. Thanks.

Will also try the shareware version of Wolfenstein 3D. You're using version 1.4?