mateusz.viste wrote on 2025-08-19, 14:33:

Pickle wrote on 2025-08-19, 14:23:

Your tool does sound appealing to use some of the EMS for 32kb/64kb UMB. Is the remaining EMS memory still available in that use case?

An interesting question could be: do you use any software that supports EMS but not XMS? If not, then loosing EMS in favor of XMS + 32/64K of UMBs is probably worth it.

What other memory schemes does you mainboard propose instead of the 512 conv +512 XMS setup? Can you, for example, assigne the entire 1M to conventional RAM? That would make you able to use plenty of conventional RAM + UMBs, take out the six pak board and still get EMS+XMS from the lotech clone.

ive been trying to run wing commander 1, but it appears to hang. Ive run the memory test in checkit on the EMS section. Ive also run commander keen and wolf3d. Ive had windows 286 on it at one time but i dont think i had the EMS used by it.
the other useful memory setup is 640 kb + 0 XMS, so as far i know that 384 kb is basically lost.
but i am going to try your tool and see how much i can maximize of that 640 kb. And if i need the EMS i will setup boot menu.

mateusz.viste wrote on 2025-08-18, 12:01:

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.

Tried SvarDOS but had multiple problems. Himemx.sys is for 386+ processors. Loading 4DOS caused a hang. Simple things like "dir/s" are not supported. WordPerfect 6.0 did work though (without himem). 😀

Also tried Novell DOS 7.0 but it's it takes more memory than PC DOS 7.0 (not related to Exms86). WordPerfect 6.0 did also work here.

Now trying DR DOS 6.0. But having trouble to get UMB's. USE!UMB loads without errors but no UMB's with mem or with CheckIt Pro. Loaded hidos.sys with the /noxms switch else it won't start successful. Will maybe try MS DOS 5.0 tomorrow.

I am using the default himem/hidos etc provided with each OS on purpose btw as in the ideal world these tools should work with them as well.

Yoghoo wrote on 2025-08-21, 21:03:

Himemx.sys is for 386+ processors.

True, but on a 286 you can install a 286 alternative from the SvarDOS repository - either FDXMS286 or DRHIMEM. Assuming the 286 has an internet connectivity:

1PKGNET PULL FDXMS286
2PKG INSTALL FDXMS286
3
4PKGNET PULL DRHIMEM
5PKG INSTALL DRHIMEM

If no network connectivity available, then the packages have to be downloaded manually from the SvarDOS website.

Yoghoo wrote on 2025-08-21, 21:03:

Loading 4DOS caused a hang.

Seems strange, since I know SvarDOS users that use 4DOS daily. Was it the 4DOS 8.00 from the SvarDOS repo, or some other version?

Yoghoo wrote on 2025-08-21, 21:03:

Simple things like "dir/s" are not supported.

DIR/S works, I've implemented it in October last year. I guess you probably used the old SvarDOS installation floppy from september 2024 and did not update the system after installation ("PKGNET CHECKUP").
That said, I've updated the link on the SvarDOS website this morning so the "stable release" points to a newer version now.

mateusz.viste wrote on 2025-08-21, 21:46:

True, but on a 286 you can install a 286 alternative from the SvarDOS repository - either FDXMS286 or DRHIMEM. Assuming the 286 […]
Show full quote

Yoghoo wrote on 2025-08-21, 21:03:

Himemx.sys is for 386+ processors.

True, but on a 286 you can install a 286 alternative from the SvarDOS repository - either FDXMS286 or DRHIMEM. Assuming the 286 has an internet connectivity:

Copy code to clipboard

1PKGNET PULL FDXMS286
2PKG INSTALL FDXMS286
3
4PKGNET PULL DRHIMEM
5PKG INSTALL DRHIMEM

If no network connectivity available, then the packages have to be downloaded manually from the SvarDOS website.

Yoghoo wrote on 2025-08-21, 21:03:

Loading 4DOS caused a hang.

Seems strange, since I know SvarDOS users that use 4DOS daily. Was it the 4DOS 8.00 from the SvarDOS repo, or some other version?

Yoghoo wrote on 2025-08-21, 21:03:

Simple things like "dir/s" are not supported.

DIR/S works, I've implemented it in October last year. I guess you probably used the old SvarDOS installation floppy from september 2024 and did not update the system after installation ("PKGNET CHECKUP").
That said, I've updated the link on the SvarDOS website this morning so the "stable release" points to a newer version now.

I'm using 4DOS 7.50. And yes there are newer versions but I'm not running DOS to run the latest and greatest versions. 😉

Indeed picked up the then stable version from the site. Good it's working in the new stable version.

My problem with Freedos and SvarDOS is that there are too many options for packages. And each program has it's own parameters which you have to relearn. Some like it but I like to play as much as possible with original programs for nostalgic reasons. I do like to play with alternative packages on Linux though. But that's enough for me. 😀 It's a great project though and I'm happy that people still invent and expand stuff for DOS.

Yoghoo wrote on 2025-08-21, 22:05:

And each program has it's own parameters which you have to relearn. Some like it but I like to play as much as possible with original programs for nostalgic reasons.

I can totally relate - myself I only like to watch movies I've already seen, and I listen mostly to music from the '90s because it's the music I know. But with legacy DOS versions I was always annoyed sooner or later, so ultimately I prefer using my own DOS that I can tailor exactly how I like. To each their own I guess. :)

Great to know WordPerfect + EXMS86 works for you (when not using PC-DOS, that is). Thanks for your feedback.

published today: EXMS86 version 0.9.7

• no longer a hacky TSR, EXMS86 has been reworked into a SYS driver
• the XMS_available function resets BL on success

where can use!umbs be obtained?

Pickle wrote on 2025-08-22, 00:15:

where can use!umbs be obtained?

Few places. One of them is here on vogons.

Hey, mateusz.viste, this is really awesome software project, if the things really work! I'm glad, that this topic survived after yet another attempt at censorship with the typical refgular suspect's interference 😀 I don't know how it is possible to address more than 1 MB memory on 8086/88 CPUs as their meximum RAM address limit is 1 MB and I also don't know if there are memory RAM-extension cards suitable for XT machines, which can be set above 1 MB RAM limit addressing. I suppose there is some kind of combined software-hardware trick behind the hardware CPU limitations. If for the software part (8086 XMS manager or driver) there's accessible physical memory beyond the 1 MB CPU address limit, then it uses it like in the EMS scheme - through "window" for XMS "pages" in "upper memory", which is directly accessible by the 8086/88 CPUs, right?

Also, I want to congratulate you as you are the creator of SvarDOS project. I hope it will be a much better DOS alternative, than the stalled FreeDOS, even if I don't like the "Svar" name's part,. which is a direct reference to the false "slavonic" mythology (it is not a coincidence that the word "slavs" was invented to sound very similar to "slaves", but this is another topic on false "history").

analog_programmer wrote on 2025-08-30, 19:52:

I don't know how it is possible to address more than 1 MB memory on 8086/88 CPUs

It is not possible, but it is also not necessary for XMS.

analog_programmer wrote on 2025-08-30, 19:52:

If for the software part (8086 XMS manager or driver) there's accessible physical memory beyond the 1 MB CPU address limit, then it uses it like in the EMS scheme - through "window" for XMS "pages" in "upper memory", which is directly accessible by the 8086/88 CPUs, right?

The XMS API does not deal with physical addresses, it only exposes the data through copy operations - so it does not matter where the data is actually stored, as long as the xms driver manages to get it and feed it to the buffer provided by the client program.

analog_programmer wrote on 2025-08-30, 19:52:

Also, I want to congratulate you as you are the creator of SvarDOS project. I hope it will be a much better DOS alternative, than the stalled FreeDOS

Thank you, I'm glad you appreciate the effort - but while I did build the general framework, the installer, package manager and some other tools, I also benefited from a huge boost from Bernd Böckmann and E.C. Masloch due to their excellent work on the EDR kernel. Their contributions were quite a game changer for SvarDOS.

analog_programmer wrote on 2025-08-30, 19:52:

I don't like the "Svar" name's part,. which is a direct reference to the false "slavonic" mythology

You are correct that it is uncertain wheter or not Сварог was ever an actual pagan deity, it might have been invented in early christian days as a slavonic parallel to hellenic mythology.

Yet "Svar" is not about religion. It relates to heat, fire, forging and welding - all generally associated with blacksmith. The word has been around for at least over a thousand years and it is a good symbolic reflection I think of what SvarDOS is about.

Thanks for your more exact explanation on how the exms86.sys actually works, mateusz.viste! Actually I thought the same, just wrote it with non-proper words/terminology.

So, basically in DOS we can also have (for example) 63 MB accessible extended memory in addition to first 1 MB ("base" + "upper") memory on 386SX CPU, instead of its hardware limit of 16 MB (15 MB extended), if someone writes a new XMS manager/driver like yours for 8086/88 based systems. And this is really great! And one more time your work confirms the theory that corporate software development intentionally never f*cks-up the hardware selling schemes like:
"- Hey, user, we have a brand new 286 CPU with more features compared to your obsolete 8086 sh*t. Now 286 CPU supports up to 16 MB RAM! Go buy it!
- But I just upgraded my 8086 XT system with V30 and started a project for software extended mem...
- STFU, m*ron! You'll need our new 286 hardware for this! Go buy it now!
- Ok, Ok, I'll buy it..."
Nowadays the planned obsolescence is well known fact, not just a "conspiracy theory" 😉

So, SvarDOS is a real and pretty well made thing and not some imaginary/false "history" and this is the reason why I don't like the "Svar(og)" part in the name. But it is as it is and it was your personal decision from years ago, so it's already established as a known name 😀 And I hope the only thing I'll continue to dislike in SvarDOS (at least it's not "SlavsDOS" which will be like "DOS for slaves") in the future to remain that part of the name, 'cause currently I already don't like the entire FreeDOS project development direction.

P.S. I'm wondering why there's no popular SvarDOS topic in this forum? Or maybe there is, but I'm missing it.

You may not believe this, but SmartDrive in MS-DOS 6.22 works! That was an unexpected surprise.

Doom8088 has some issues - it uses 64KB of EMS memory for data structures and 1507 kB of XMS memory for IWAD data. Things run fine until Map3, where the walls become garbled and performance tanks. This might be a Doom8088 issue, but I thought I would let you know. funnily enough, disabling the use of xms in doom8088 and running SmartDrive seems to be a workaround - but obviously not a good one. I need to do more testing on this.

What about disabling EMS in Doom8088 with -noems?

Frenkel wrote on 2025-09-05, 16:07:

What about disabling EMS in Doom8088 with -noems?

That seems to work! Thanks!

Hi!! is possible to load windows 3.1? complains about himem.sys not taking care of XMS

All DOS stuff work fine, love to have EMS and XMS at same time in my 286 !!

thanks

theelf wrote on Today, 02:11:

Hi!! is possible to load windows 3.1? complains about himem.sys not taking care of XMS

All DOS stuff work fine, love to have EMS and XMS at same time in my 286 !!

Maybe you are trying the wrong tool for the job? Windows 3.1 in standard mode requires extended memory which can be directly accessed by the 80286 processor. This kind of memory is typically managed by HIMEM.SYS and HIMEM also allows DOS applications to transfer data from/to that memory. EXMS86 allows DOS applications to transfer data from/to EMS as if it were extended memory. The abstraction layer works: Applications that just use XMS to stash away data and retrieve that stashed data later work perfectly even if the stash location is not actually extended memory. On the other hand, Windows 3.1 does not just use HIMEM to stash and retrieve data, but it asks HIMEM for the location of the extended memory so the Windows 3.1 kernel can access the memory directly without help of HIMEM. Windows Application can run in extended memory equally well as they can run in conventional memory, as the difference between these types of memory disappear as soon as the 286 processor is operating in protected mode. EXMS86 is obviously unable to make EMS memory accessible as extended memory if EXMS86 is not involved in accessing that memory at all.

You said your goal is having EMS and XMS at the same time in your 286 processor. For optimal results, this would need to be hardware backed. Windows 3.1 only works if the XMS memory is backed by physical extended memory. EMS delivers mediocre performance unless page mapping (a kind of bank switching) is performed by hardware. Most 286 systems already have extended memory provided by the mainboard (assuming there is more than 640KB on the board), so EXMS86 is not required to provide fake extended memory. On the other hand, if you want to add EMS to a system that already has XMS, you don't need EXMS86 at all, but you need something like EMM286, which emulates EMS by copying memory from/to XMS.

The amount of sensible use cases for EMM286 is limited. The EMS provided by it is slow, and it takes up more than 64KB of conventional memory to provide a "window" into some parts of the XMS without any hardware providing a direct window. This means for any application that just uses 64KB of EMS (essentially using EMS as their private UMB), you are better off not using EMM286 at all, because this will free up more than 64KB of conventional memory which is working at least as well as EMS in nearly any application. If applications use more than 64KB of EMS, they might be impaired by the slow bank switching. So EMM286 is useful only if you have an application that uses more than 64KB and doesn't bank switch too often. The slow bank switching of EMM286 is still way faster than to reload data from disk, so any application that starts heavy swapping or errors out if there is not enough conventional memory + EMS present will profit from EMM286. One real-world example is Microsoft Works for DOS which requires complete database files to be loaded into conventional + EMS, so having virtual EMS provided by EMM286 allows using bigger databases than not having EMS at all - even with the big hit on conventional memory that comes with EMM286.

mkarcher wrote on Today, 07:13:

Maybe you are trying the wrong tool for the job? Windows 3.1 in standard mode requires extended memory which can be directly acc […]
Show full quote

theelf wrote on Today, 02:11:

Hi!! is possible to load windows 3.1? complains about himem.sys not taking care of XMS

All DOS stuff work fine, love to have EMS and XMS at same time in my 286 !!

Maybe you are trying the wrong tool for the job? Windows 3.1 in standard mode requires extended memory which can be directly accessed by the 80286 processor. This kind of memory is typically managed by HIMEM.SYS and HIMEM also allows DOS applications to transfer data from/to that memory. EXMS86 allows DOS applications to transfer data from/to EMS as if it were extended memory. The abstraction layer works: Applications that just use XMS to stash away data and retrieve that stashed data later work perfectly even if the stash location is not actually extended memory. On the other hand, Windows 3.1 does not just use HIMEM to stash and retrieve data, but it asks HIMEM for the location of the extended memory so the Windows 3.1 kernel can access the memory directly without help of HIMEM. Windows Application can run in extended memory equally well as they can run in conventional memory, as the difference between these types of memory disappear as soon as the 286 processor is operating in protected mode. EXMS86 is obviously unable to make EMS memory accessible as extended memory if EXMS86 is not involved in accessing that memory at all.

You said your goal is having EMS and XMS at the same time in your 286 processor. For optimal results, this would need to be hardware backed. Windows 3.1 only works if the XMS memory is backed by physical extended memory. EMS delivers mediocre performance unless page mapping (a kind of bank switching) is performed by hardware. Most 286 systems already have extended memory provided by the mainboard (assuming there is more than 640KB on the board), so EXMS86 is not required to provide fake extended memory. On the other hand, if you want to add EMS to a system that already has XMS, you don't need EXMS86 at all, but you need something like EMM286, which emulates EMS by copying memory from/to XMS.

The amount of sensible use cases for EMM286 is limited. The EMS provided by it is slow, and it takes up more than 64KB of conventional memory to provide a "window" into some parts of the XMS without any hardware providing a direct window. This means for any application that just uses 64KB of EMS (essentially using EMS as their private UMB), you are better off not using EMM286 at all, because this will free up more than 64KB of conventional memory which is working at least as well as EMS in nearly any application. If applications use more than 64KB of EMS, they might be impaired by the slow bank switching. So EMM286 is useful only if you have an application that uses more than 64KB and doesn't bank switch too often. The slow bank switching of EMM286 is still way faster than to reload data from disk, so any application that starts heavy swapping or errors out if there is not enough conventional memory + EMS present will profit from EMM286. One real-world example is Microsoft Works for DOS which requires complete database files to be loaded into conventional + EMS, so having virtual EMS provided by EMM286 allows using bigger databases than not having EMS at all - even with the big hit on conventional memory that comes with EMM286.

Hi, thanks for response

right now this is my config.sys in the 286, hope to do better, but this is best i could do

1DEVICE=C:\DOS\G2MMC.SYS /M=3000 /Z
2DEVICE=C:\DOS\HIMEM.SYS
3DEVICE=C:\DOS\QRAM\QRAM.SYS R:1
4DEVICE=C:\DOS\EXMS86\EXMS86.SYS Q$
5DOS=UMB,HIGH
6BUFFERS=42
7FILES=30
8LASTDRIVE=G
9DEVICEHIGH=C:\DOS\CDMKE.SYS /P:260 /Q

DEVICE=C:\DOS\G2MMC.SYS /M=3000 /Z <--- this give me EMS for me Headland HT18
DEVICE=C:\DOS\QRAM\QRAM.SYS R:1234 <-- this give me 32k of UMB from EMS
DEVICE=C:\DOS\EXMS86\EXMS86.SYS Q$ <--- and this give me back XMS

For me this setup work fine en all dos app, games etc i tried yet, exept windows

I will love to have UMB without EMS but i cant find a umb driver for HT18, and i need XMS for dos app too not only ems. The first try was add 16mb to my 286, and add for example 4mb ems and 12mb XMS, but the HT18 driver is limited to 4mb, whatever you have, 5mb ram, 8mb or 16mb, once driver is loaded limited you to 4mb !!! no idea, but of course nobody complains in 1989 for 4mb limit... jaja

^Win-OS/2 is a DPMI client and can work without the need for Himem.sys/XMS.
That being said, I don't know if 16-Bit DPMI is supported by it or if Win-OS/2 relies on 386+ system files here.
Also, no 80286-based DPMI hosts come to my mind right now. 🙁

Edit: A 4 MB RAM limit wasn't that uncommon to 80286 chipsets.
To them, a full memory expansion was 4x 1 MB SIMMs.

By using ISA-based RAM boards, the full 16 MB address range was available, though.
IBM had provided such expansion boards for IBM Model 5170, originally.

But that was in the pre-chipset days, then ISA bus still was the 80286 front-side bus (FSB).

Edited.

theelf wrote on Today, 08:41:

DEVICE=C:\DOS\G2MMC.SYS /M=3000 /Z <--- this give me EMS for me Headland HT18
DEVICE=C:\DOS\QRAM\QRAM.SYS R:1234 <-- this give me 32k of UMB from EMS
DEVICE=C:\DOS\EXMS86\EXMS86.SYS Q$ <--- and this give me back XMS

I don't know the HT18 drivers and your BIOS well enough, but the way chipsets like this are designed to be use is that you configure a static split between extended and expanded memory in the BIOS setup (or possibly at the command line of the EMS driver). Then you load the EMS driver to handle the EMS part of your memory, and HIMEM.SYS to handle the extended memory part of your memory.

It is not supposed to work the way that loading the EMS driver makes the extended memory unavailable. Do you have documentation for the G2MMC command line parameters?

theelf wrote on Today, 08:41:

but the HT18 driver is limited to 4mb, whatever you have, 5mb ram, 8mb or 16mb, once driver is loaded limited you to 4mb !!! no idea, but of course nobody complains in 1989 for 4mb limit... jaja

The early revisions of the HT18 chipset only supported 1MB SIMMs. So if a board with the early revisions only has 4 slots, that is a hard limit of 4MB. The latest revision does support 4MB SIMMs. For extended memory support on the latest revision, it is sufficient if the BIOS correctly initializes the memory controller. Application software, including Windows 3.1, will not notice how the memory is split to the different SIMMs and how big they are. This is different for EMS, though. The EMS driver needs to support 4MB SIMMs to correctly handle them. Possibly your G2MMC.SYS driver is at the core of the issue if that driver does not support 4MB SIMMs.

There is no way to re-establish "real XMS" backed by extended memory once the memory has been claimed by the EMS driver. The only way Windows 3.1 will be happy if your XMS driver handles native extended memory. This is the job of HIMEM.SYS, and HIMEM.SYS does it that well that there is no need for 3rd party tools doing the same thing. So unless you use HIMEM.SYS as your XMS driver, you will not be able to run Windows 3.1.

mkarcher wrote on Today, 19:30:

I don't know the HT18 drivers and your BIOS well enough, but the way chipsets like this are designed to be use is that you confi […]
Show full quote

theelf wrote on Today, 08:41:

DEVICE=C:\DOS\G2MMC.SYS /M=3000 /Z <--- this give me EMS for me Headland HT18
DEVICE=C:\DOS\QRAM\QRAM.SYS R:1234 <-- this give me 32k of UMB from EMS
DEVICE=C:\DOS\EXMS86\EXMS86.SYS Q$ <--- and this give me back XMS

I don't know the HT18 drivers and your BIOS well enough, but the way chipsets like this are designed to be use is that you configure a static split between extended and expanded memory in the BIOS setup (or possibly at the command line of the EMS driver). Then you load the EMS driver to handle the EMS part of your memory, and HIMEM.SYS to handle the extended memory part of your memory.

It is not supposed to work the way that loading the EMS driver makes the extended memory unavailable. Do you have documentation for the G2MMC command line parameters?

theelf wrote on Today, 08:41:

but the HT18 driver is limited to 4mb, whatever you have, 5mb ram, 8mb or 16mb, once driver is loaded limited you to 4mb !!! no idea, but of course nobody complains in 1989 for 4mb limit... jaja

The early revisions of the HT18 chipset only supported 1MB SIMMs. So if a board with the early revisions only has 4 slots, that is a hard limit of 4MB. The latest revision does support 4MB SIMMs. For extended memory support on the latest revision, it is sufficient if the BIOS correctly initializes the memory controller. Application software, including Windows 3.1, will not notice how the memory is split to the different SIMMs and how big they are. This is different for EMS, though. The EMS driver needs to support 4MB SIMMs to correctly handle them. Possibly your G2MMC.SYS driver is at the core of the issue if that driver does not support 4MB SIMMs.

There is no way to re-establish "real XMS" backed by extended memory once the memory has been claimed by the EMS driver. The only way Windows 3.1 will be happy if your XMS driver handles native extended memory. This is the job of HIMEM.SYS, and HIMEM.SYS does it that well that there is no need for 3rd party tools doing the same thing. So unless you use HIMEM.SYS as your XMS driver, you will not be able to run Windows 3.1.

Hi, there’s no EMS setting in the BIOS, but the HT18 driver does let you use part EMS and part XMS, which isn’t very practical with only 4 MB of RAM! My original idea was to use 16 MB of RAM: 4 MB for EMS and 12 MB for XMS, since my board is a revision C chipset and it handles 4 MB modules fine. 16 MB works perfectly in XMS mode, but the 4 MB EMS limit seems to come from the software side, it’s just an old driver, nothing else. Even the HT21 driver, which is supposed to be a newer chipset, has the same limit. Back then nobody really tried more than 4 MB, I guess…

About “there’s no way,” I know, but with computers I learned something: never say never, and asking doesn’t hurt anyone, jejea. It’s no big deal, I just use a multiboot menu and that’s it. But i like a clean boot with all in one

Cheers.