mateusz.viste wrote on Yesterday, 22:09:

EXMS86 became a SYS driver. version 0.9.7 beta attached. Works for me, but no guarantee, I just finished the SYS work and did not test it extensively yet.

Just tried it and now see 32K or 64K UMB. So this issue is solved. Thanks!

Got a hang in Wolfenstein 3D the first time immediately after starting a new game. But after a reboot I could complete a whole level. So maybe just a hick up. Also it now only shows XMS when starting the game and not EMS as well. Tools like CheckIt Pro etc report everything as expected.

This is with USE!UMBS btw as UMM didn't want to start: Error installing UMM: Memory test failed.

The only issue I am now having is that I can't use DOS=HIGH (HMA not available: Loading DOS low). So DOS takes 69K low memory and that is quitte a big hit. Should I be able to use DOS=HIGH,UMB or is it only DOS=UMB?

The 0.9.7 beta version seems to be good so far. My 86box setup is stable, UMB works fine and applications detect and use XMS wih no apparent issues.

The SYS adaptation costs a footprint of 32 bytes (ie. SYS takes 832 bytes of RAM while the equivalent TSR had a footprint of 800 bytes). It's a bit counter-intuitive as I was expecting the SYS version to be more efficient due to the lack of PSP, but I guess there is some other overhead in the kernel. Still worth it, of course.

mateusz.viste wrote on Today, 09:19:

The SYS adaptation costs a footprint of 32 bytes (ie. SYS takes 832 bytes of RAM while the equivalent TSR had a footprint of 800 bytes). It's a bit counter-intuitive as I was expecting the SYS version to be more efficient due to the lack of PSP, but I guess there is some other overhead in the kernel. Still worth it, of course.

For me it was from 800 bytes to 816 bytes.

Yoghoo wrote on Today, 08:29:

The only issue I am now having is that I can't use DOS=HIGH (HMA not available: Loading DOS low). So DOS takes 69K low memory and that is quitte a big hit. Should I be able to use DOS=HIGH,UMB or is it only DOS=UMB?

I use both "DOS=UMB" and "DOSDATA=UMB" on my 86box setup, works wonderfully: only 12K of conventional RAM is used (but that's on SvarDOS, your mileage with IBM-DOS may vary).

Also note that you still should be able to use HMA with EXMS86, but you need to have a HMA driver loaded *before* EXMS86. In such setup EXMS86 detects it and cooperates with the pre-existing driver by relaying any HMA/A20 queries to it. Also, said driver must NOT provide any XMS, otherwise EXMS86 will refuse to load.

Now, I do not know what HMA-only driver could fit there, perhaps HIMEM can be told not to provide XMS but I have no clue, really.

mateusz.viste wrote on Today, 09:24:

I use both "DOS=UMB" and "DOSDATA=UMB" on my 86box setup, works wonderfully: only 12K of conventional RAM is used (but that's on […]
Show full quote

Yoghoo wrote on Today, 08:29:

The only issue I am now having is that I can't use DOS=HIGH (HMA not available: Loading DOS low). So DOS takes 69K low memory and that is quitte a big hit. Should I be able to use DOS=HIGH,UMB or is it only DOS=UMB?

I use both "DOS=UMB" and "DOSDATA=UMB" on my 86box setup, works wonderfully: only 12K of conventional RAM is used (but that's on SvarDOS, your mileage with IBM-DOS may vary).

Also note that you still should be able to use HMA with EXMS86, but you need to have a HMA driver loaded *before* EXMS86. In such setup EXMS86 detects it and cooperates with the pre-existing driver by relaying any HMA/A20 queries to it. Also, said driver must NOT provide any XMS, otherwise EXMS86 will refuse to load.

Now, I do not know what HMA-only driver could fit there, perhaps HIMEM can be told not to provide XMS but I have no clue, really.

Tried "DOSDATA=UMB" and it loads part of it to UMB. Problem is that CheckIt Pro now hangs during startup with DOSDATA=UMB. So it isn't stable.

Will try something like DOSMAX in the future as I can't find options for HIMEM.SYS to not enable XMS.

mateusz.viste wrote on Today, 09:24:

I use both "DOS=UMB" and "DOSDATA=UMB" on my 86box setup, works wonderfully: only 12K of conventional RAM is used (but that's on SvarDOS, your mileage with IBM-DOS may vary).

DR-DOS/Novell DOS used to be better in moving code and data to UMBs or the HMA than MS-DOS (and its cousin IBM PC-DOS). Quarterdeck provided a tool DOS-UP, which was bundled with QEMM, their EMM386 replacement. That tool moved stuff from MS-DOS into UMBs that MS-DOS on its own would not move high. The official statement by Quarterdeck about DOS-UP and DR-DOS/Novell DOS was that DOS-UP made no sense with these DOS implementations, because they are good enough on its own. Maybe there's a bit of corporate: "we don't want to spend effort on implementing DOS-UP for DR-DOS, as there are way less DR-DOS users than MS-DOS users" included in their statement, but I believe the claim that a tool like DOS-UP was more effective than a similar tool for DR-DOS would have been.

DOS-UP itself does (if I remember correctly) not depend on QEMM, and if I remember correctly, there was also a UMB driver by Quarterdeck called QRAM that was shipped with DOS-UP as well. Quarterdeck was big into memory management solutions back in the day, because their DOS multi-tasker DesqView profited from every extra free byte of DOS memory, especially low conventional memory.

Alas, I also don't know of any XMS driver that only manages the HMA but does not manage extended abover the HMA memory as well. Maybe HIMEM will do that if you manage to make INT 15/88 return an extended memory size of 64K.

mkarcher wrote on Today, 10:36:

DR-DOS/Novell DOS used to be better in moving code and data to UMBs or the HMA than MS-DOS (and its cousin IBM PC-DOS). Quarterd […]
Show full quote

mateusz.viste wrote on Today, 09:24:

I use both "DOS=UMB" and "DOSDATA=UMB" on my 86box setup, works wonderfully: only 12K of conventional RAM is used (but that's on SvarDOS, your mileage with IBM-DOS may vary).

DR-DOS/Novell DOS used to be better in moving code and data to UMBs or the HMA than MS-DOS (and its cousin IBM PC-DOS). Quarterdeck provided a tool DOS-UP, which was bundled with QEMM, their EMM386 replacement. That tool moved stuff from MS-DOS into UMBs that MS-DOS on its own would not move high. The official statement by Quarterdeck about DOS-UP and DR-DOS/Novell DOS was that DOS-UP made no sense with these DOS implementations, because they are good enough on its own. Maybe there's a bit of corporate: "we don't want to spend effort on implementing DOS-UP for DR-DOS, as there are way less DR-DOS users than MS-DOS users" included in their statement, but I believe the claim that a tool like DOS-UP was more effective than a similar tool for DR-DOS would have been.

DOS-UP itself does (if I remember correctly) not depend on QEMM, and if I remember correctly, there was also a UMB driver by Quarterdeck called QRAM that was shipped with DOS-UP as well. Quarterdeck was big into memory management solutions back in the day, because their DOS multi-tasker DesqView profited from every extra free byte of DOS memory, especially low conventional memory.

Alas, I also don't know of any XMS driver that only manages the HMA but does not manage extended abover the HMA memory as well. Maybe HIMEM will do that if you manage to make INT 15/88 return an extended memory size of 64K.

I tried QRAM in the past but didn't get it to work if I remember correctly. But will maybe try again.

PC DOS 7.0 gave this 286 machine the most conventional memory (with EMS) that's why I choose it. I tested MSDOS 5.0, 6.22 and DR DOS 6.0. Maybe also Novell DOS 7.0 but I forgot.

Anyway, testing all those combinations again and test which one gives enough conventional memory in combination with EXMS86 will take some time. As it's now EXMS86 seems to work fine but I don't have enough conventional memory left to really enjoy it. 😀

Yoghoo wrote on Today, 10:57:

As it's now EXMS86 seems to work fine but I don't have enough conventional memory left to really enjoy it. :)

But do you have /less/ conventional RAM than before? My understanding is that with EXMS86 you basically traded EMS for XMS and HMA for UMB. All other things being equal, you should end up with roughly the same amount of available conventional RAM. Have I missed something?

mateusz.viste wrote on Today, 11:18:

Yoghoo wrote on Today, 10:57:

As it's now EXMS86 seems to work fine but I don't have enough conventional memory left to really enjoy it. 😀

But do you have /less/ conventional RAM than before? My understanding is that with EXMS86 you basically traded EMS for XMS and HMA for UMB. All other things being equal, you should end up with roughly the same amount of available conventional RAM. Have I missed something?

Yes, a lot less. Because before I could use DOS=HIGH and that saves almost 70K conventional memory.

I can use DOS=UMB with EXMS86. But that combination loads 20K in UMB and uses 50K of conventional memory. So 50K less conventional memory.

Yoghoo wrote on Today, 11:23:

Yes, a lot less.

Attached version 0.9.7 beta 2. You can load HIMEM, then EXMS86 with "!!$", and then USE!UMBS. As a result you should get:

- 64K of UMB
- 64K of HMA
- XMS instead of EMS

On my setup I used this:

1DEVICE=LTEMM.EXE
2DEVICE=HIMEMX.EXE
3DEVICE=EXMS86.SYS !!$
4DEVICE=USE!UMBS.SYS E000-EFFFF
5DOS=HIGH,UMB
6DOSDATA=UMB

The result is awesomely crazy :-)

Yoghoo wrote on Today, 11:23:

Anyway, testing all those combinations again and test which one gives enough conventional memory in combination with EXMS86 will take some time.

If you are willing to test DR-DOS again, then may I suggest SvarDOS? We have put a lot of effort into it so it is small, fast and efficient. It uses the EDR-DOS kernel and an in-house COMMAND.COM, but every piece can be replaced, it's a very open system.

mateusz.viste wrote on Today, 12:01:

Attached version 0.9.7 beta 2. You can load HIMEM, then EXMS86 with "!!$", and then USE!UMBS. As a result you should get: […]
Show full quote

Yoghoo wrote on Today, 11:23:

Yes, a lot less.

Attached version 0.9.7 beta 2. You can load HIMEM, then EXMS86 with "!!$", and then USE!UMBS. As a result you should get:

- 64K of UMB
- 64K of HMA
- XMS instead of EMS

On my setup I used this:

Copy code to clipboard

1DEVICE=LTEMM.EXE
2DEVICE=HIMEMX.EXE
3DEVICE=EXMS86.SYS !!$
4DEVICE=USE!UMBS.SYS E000-EFFFF
5DOS=HIGH,UMB
6DOSDATA=UMB

The result is awesomely crazy 😀

Yoghoo wrote on Today, 11:23:

Anyway, testing all those combinations again and test which one gives enough conventional memory in combination with EXMS86 will take some time.

If you are willing to test DR-DOS again, then may I suggest SvarDOS? We have put a lot of effort into it so it is small, fast and efficient. It uses the EDR-DOS kernel and an in-house COMMAND.COM, but every piece can be replaced, it's a very open system.

I have good and bad news. 😀 Good news is that DOS=HIGH,UMB is working perfectly. Now I'm having the same amount of conventional memory as with EMS. Also tools like CheckIt Pro etc work without problem.

Bad news is that any program that actually uses XMS is hanging the PC (needs a hard reset). Word Perfect 6.0 and also Wolfenstein 3D are some examples.

Yoghoo wrote on Today, 12:51:

Bad news is that any program that actually uses XMS is hanging the PC (needs a hard reset). Word Perfect 6.0 and also Wolfenstein 3D are some examples.

I understand that this happens only when HIMEM is loaded before EXMS86 (and EXMS86 is run with '$'), is that correct?

Does it also happen when you have HIMEM loaded but do not use "DOS=HIGH" ?

mateusz.viste wrote on Today, 13:05:

Yoghoo wrote on Today, 12:51:

Bad news is that any program that actually uses XMS is hanging the PC (needs a hard reset). Word Perfect 6.0 and also Wolfenstein 3D are some examples.

I understand that this happens only when HIMEM is loaded before EXMS86 (and EXMS86 is run with '$'), is that correct?

Does it also happen when you have HIMEM loaded but do not use "DOS=HIGH" ?

I am using the same lines as your example (but modified for my configuration).

If I remove the DOS=HIGH option Wolfenstein 3D worked correctly. Word Perfect 6.0 still hangs but I just added this test in the last beta. It works with EMS though.

Okay, I now see that even without the HMA business Wolf3D became very broken, I think since the SYS migration - but only Wolf3D 1.1, not the 1.4 version, which is why I did not notice it earlier. I will look into this.

mateusz.viste wrote on Today, 13:36:

Okay, I now see that even without the HMA business Wolf3D became very broken, I think since the SYS migration - but only Wolf3D 1.1, not the 1.4 version, which is why I did not notice it earlier. I will look into this.

Turns out the Wolf3D 1.1 issue I was observing was not related to the SYS migration at all. Wolf3D 1.1 goes crazy if I do not reset BL when it asks for the amount of available XMS memory. The spec does not mandate this explicitly, but reading between the lines it becomes obvious that it should have been done.

This might be an issue that impacts other software as well (like maybe WordPerfect?), I feel it's important enough that it warrants a new beta build - attached.

It is very unlikely, however, that it will fix the "Wolf3D hangs with HIMEM=EXMS86 and DOS=HIGH" problem. This is an issue I have yet to reproduce.

EDIT: Sadly I can't reproduce this. Wolf3D works fine for me, both with DOS=HIGH and DOS=HIGH,UMB. Tested both Wolf3D 1.1 and Wolf3D 1.4. Perhaps this is something specific to IBM DOS, I will have to look for some PC-DOS bootdisk later.

mateusz.viste wrote on Today, 14:43:

Turns out the Wolf3D 1.1 issue I was observing was not related to the SYS migration at all. Wolf3D 1.1 goes crazy if I do not re […]
Show full quote

mateusz.viste wrote on Today, 13:36:

Okay, I now see that even without the HMA business Wolf3D became very broken, I think since the SYS migration - but only Wolf3D 1.1, not the 1.4 version, which is why I did not notice it earlier. I will look into this.

Turns out the Wolf3D 1.1 issue I was observing was not related to the SYS migration at all. Wolf3D 1.1 goes crazy if I do not reset BL when it asks for the amount of available XMS memory. The spec does not mandate this explicitly, but reading between the lines it becomes obvious that it should have been done.

This might be an issue that impacts other software as well (like maybe WordPerfect?), I feel it's important enough that it warrants a new beta build - attached.

It is very unlikely, however, that it will fix the "Wolf3D hangs with HIMEM=EXMS86 and DOS=HIGH" problem. This is an issue I have yet to reproduce.

EDIT: Sadly I can't reproduce this. Wolf3D works fine for me, both with DOS=HIGH and DOS=HIGH,UMB. Tested both Wolf3D 1.1 and Wolf3D 1.4. Perhaps this is something specific to IBM DOS, I will have to look for some PC-DOS bootdisk later.

Tested the new beta with Wolfenstein 3D and DOS=HIGH. Tried it 2 times with a reboot between them and both times it ran successful. WordPerfect 6.0 still locks up the pc when starting though.

This beta allows FractInt to run on an IBM XT! Heck yes!

Edit: with an EMS card installed, that is. previously, FractInt would crash with a stack error.

Yoghoo wrote on Today, 17:28:

Tested the new beta with Wolfenstein 3D and DOS=HIGH. Tried it 2 times with a reboot between them and both times it ran successful. WordPerfect 6.0 still locks up the pc when starting though.

I fail to see the link between DOS=HIGH and Wolf3D's XMS misdetection when BL is not being reset, but surely there must be some non-obvious relation. It's good it works now, thanks for your tests!

BTW I have installed WordPerfect 6.0 in 86box - unfortunately it works very well for me. I tested with different VM configurations (486, 386SX, 286),.with and without "DOS=HIGH" - works every time. So it might possibly be some PC-DOS thing.

Sneakernets wrote on Today, 18:53:

This beta allows FractInt to run on an IBM XT! Heck yes!

Awesome - yet another cool use case for EXMS86! :-)