MobyGamer wrote on 2025-07-18, 20:08:

I think you are making the mistake that software written 30+ years ago should somehow adhere to current homebrew/enthusiast standards.

I think you are making the mistake that I am concerned only about 30+ years software. :)

A perfect example of what I was referring to is FreeCOM: it works on a 8086, but hardly usable without its xms-swapping feature. When executed on a 8086 it still probes for XMS and is able to use it. A similar situation to DOSMid, in a sense. Surely there's a lot more such software out there.

The sad part is that FreeCOM does not work with EXMS86, at least not on my virtual setup. FreeCOM asks for XMS transfers that are 30-50K big, and these fail to be performed correctly by the bocaram EMS driver I use. The maximum I can do without data corruption seems to be around 9K. Weird, since the EMS spec promises transfers of up to 1MB... Perhaps it's a virtualization glitch, or maybe I am missing something. Oh well, I should really look around for a real ISA card.

mateusz.viste wrote on 2025-07-18, 20:44:

The sad part is that FreeCOM does not work with EXMS86, at least not on my virtual setup.

I realized that I could test EXMS86 without emulating an EMS card through 86box - disabling XMS (but keeping EMS enabled) in DOSBox works just as well, and is much faster.

With this streamlined setup, the FreeCOM issue no longer appears, everything runs flawlessly. It’s beginning to look like my previous problem may have stemmed from some stupid virtualization glitch.

I released EXMS86 v0.9.1 today.

http://mateusz.fr/exms86/

mateusz.viste wrote on 2025-07-18, 20:44:

The maximum I can do without data corruption seems to be around 9K. Weird, since the EMS spec promises transfers of up to 1MB... Perhaps it's a virtualization glitch, or maybe I am missing something. Oh well, I should really look around for a real ISA card.

The 1MB transfer limit comment applies only to conventional-to-conventional moves; the most that can be moved in ems-to-conventional is limited to a 16K page. That said, you shouldn't be seeing errors transferring more than 9K; what is the AH result code after a failed Function 24 copy?

I wouldn't be quick to blame "a virtualization glitch". dosbox does a lot behind the scenes to "fix" bugs in software to get that software to run.

MobyGamer wrote on 2025-07-19, 20:28:

The 1MB transfer limit comment applies only to conventional-to-conventional moves; the most that can be moved in ems-to-conventional is limited to a 16K page.

Could you please provide the source of your information? What I read in the EMS 4.0 spec is this:

"Using Function 24 (Move/Exchange Memory Region), you can easily move
and exchange data between conventional and expanded memory. Function
24 can manipulate up to one megabyte of data with one function call."

and then, later in the longer description of Fn 24:

"A region length which exceeds 16K bytes is not an error. In this case the function assumes that a group of logical pages is the target for the move. The logical page specified represents the first logical page in which the move will take place. If the region length exceeds 16K bytes, or if the region is less than 16K bytes but spans logical pages, there must be sufficient logical pages remaining after the first logical page for the entire region to fit."

MobyGamer wrote on 2025-07-19, 20:28:

That said, you shouldn't be seeing errors transferring more than 9K; what is the AH result code after a failed Function 24 copy?

Zero.

MobyGamer wrote on 2025-07-19, 20:28:

I wouldn't be quick to blame "a virtualization glitch". dosbox does a lot behind the scenes to "fix" bugs in software to get that software to run.

Of course, no virtualization is perfect. Sometimes it breaks things that should work, sometimes it fixes things that should break. But until I have real hardware to check or a bug report from a hardware owner, I'll go the easy route and assume I'm good.

I've tried this utility after the work on UMBs was implemented, and dosmid does attempt to load files, but eventually stops loading and hangs. not seeing any action from DOSMID after about an hour. I'm not sure if it's due to the midi file's size (500 KB I think?) but I haven't tried the new version with *only* the EMS driver and EXMS86 loaded, which did work last time I tried.

Sneakernets wrote on 2025-07-21, 21:57:

I've tried this utility after the work on UMBs was implemented, and dosmid does attempt to load files, but eventually stops loading and hangs. not seeing any action from DOSMID after about an hour. I'm not sure if it's due to the midi file's size (500 KB I think?) but I haven't tried the new version with *only* the EMS driver and EXMS86 loaded, which did work last time I tried.

The UMB part is almost certainly not the culprit since DOSMid does not ask the XMM about UMB, so it might be a regression.

There were 4 versions of EXMS86 so far: two formal (0.9 and 0.9.1) as well as two in-between ("devel1" and "devel2"). Could you please test the 0.9.1 to confirm if it is impacted? If you could also confirm which version exactly was working for you in the same circumstances that would be helpful. I can't test myself so I really need to have as much information as possible.

Alright so I think I found out my issue: putting it in my autoexec fixed the freezes. I originally kept it in my config.sys which, I don't know why, habit? So I threw it in the autoexec with a LH.

However, things did get... Weird after this.

The midi file I mentioned above and managed to load and play this next go round is only a couple of minutes in play time length. With the TSR loaded, the midi file claimed to be 71 minutes long. Some of the voices also stopped playing in the middle of the song, holding notes. So, it's "kind-of" working?

Edit: I'm testing with 0.9.1! Apologies. The very first release I think was the one I used without USE!UMBs and worked okay, although didn't test it as much as I wanted to: it was very late into the night .

Sneakernets wrote on 2025-07-21, 22:39:

Alright so I think I found out my issue: putting it in my autoexec fixed the freezes. I originally kept it in my config.sys which, I don't know why, habit? So I threw it in the autoexec with a LH.

I don't think that loading it through CONFIG.SYS vs AUTOEXEC.BAT makes any difference. If you do load EXMS86 via CONFIG.SYS you must of course use an "INSTALL=" directive, not a "DEVICE=" one since EXMS86 is not a SYS driver. But other than that it should be more or less equivalent. What does change is the order in which your different drivers are loaded (EXMS86, EMS, UMB, ....) this may have an impact.

Sneakernets wrote on 2025-07-21, 22:39:

With the TSR loaded, the midi file claimed to be 71 minutes long. Some of the voices also stopped playing in the middle of the song, holding notes. So, it's "kind-of" working?

I wonder if it is related to the data corruption I notice in some configurations of my virtual setup.

Just to be on the safe side: do you have any way to test your EMS board to be sure it's not a hardware issue? Using some EMS stress tools, or maybe playing some games that aggressively use EMS?

Sneakernets wrote on 2025-07-21, 22:39:

Edit: I'm testing with 0.9.1! Apologies. The very first release I think was the one I used without USE!UMBs and worked okay

When you tested it without USE!UMBS you could not have LH-ed EXMS86 (because of no UMBs). This /might/ be an important difference. Could you try without EXMS86 loaded high? (or even better: without USE!UMBS at all, to be sure?)

Loading the latest version (0.9.1) of EXMS86 from your website, from a boot disk, with only my EMS driver loaded. NO USE!UMBs or DOSMAX was loaded. I used UNISOUND with a SET BLASTER line to initialize my card.

DOSMID fares a little better - the"stopping notes" issue still persists but happens much later in the songs, and at least one of the midis that previously didn't load, now does. DOSMID still has issues with reporting lengths of midis with the driver active. 1:48 length midi is 29:51, for example. Loading that midi with DOSMID with /noxms parameter works perfectly fine and plays with no issues, and the length is reported properly (1:48)

mateusz.viste wrote on 2025-07-22, 09:45:

Just to be on the safe side: do you have any way to test your EMS board to be sure it's not a hardware issue? Using some EMS stress tools, or maybe playing some games that aggressively use EMS?

This is a good idea. I've tested the EMS with CheckIt after installing it, and I've been using PC GEOS, an OS that requires at least 1MB EMS to be a pleasant experience. I've also used Mod Master XT and its EMS capabilities for the longest time on this machine and didn't notice any issues playing back samples.

Unfortunately the best way to test RAM is through the new march ram tests, and I don't know of any utilities on DOS which do this rigorous method of testing. If anyone has any ideas, I'm all ears.

Sneakernets wrote on 2025-07-22, 19:04:

DOSMID fares a little better - the"stopping notes" issue still persists but happens much later in the songs, and at least one of the midis that previously didn't load, now does. DOSMID still has issues with reporting lengths of midis with the driver active. 1:48 length midi is 29:51, for example. Loading that midi with DOSMID with /noxms parameter works perfectly fine and plays with no issues, and the length is reported properly (1:48)

I can actually reproduce this issue. Didn't notice it because it was hidden by my other (data-corruption) issue that may or may not be specific to my virtual setup.

Here is a test version - does it work better with DOSMid on your PC? Do not use this version other than for DOSMid testing, it may crash horribly with other software as it supports only short (16K) XMS transfers.

So I managed to get one midi to play that was causing issues,and the correct length was reported in dosmid! yay! No notes were dropped either. That's big news!

But, the other one seemed to lock up DOSMID on loading. Or maybe it's taking a long time? I am typing this while it is "loading" after 3 minutes, something obviously went south here...

I think a lot of the issue for me testing DOSMID with this is that I can't tell if DOSMID is loading or stuck loading due to lack of feedback from the program other than my HDD light blinks occasionally. Some rotating star or changing ellipses (. .. ...) would be a big help in detecting if the program is still loading, or there's a freeze.

Sneakernets wrote on 2025-07-23, 01:50:

So I managed to get one midi to play that was causing issues,and the correct length was reported in dosmid! yay! No notes were dropped either. That's big news!

It seems positive, but really it is disappointing. The only change in "test1" is that I detect when a transfer is about to cross an EMS page and I cut it in two pieces so the page boundary is never crossed. According to the EMS 4.0 spec this should never be necessary, it makes using the API much less straightforward.

Sneakernets wrote on 2025-07-23, 01:50:

I think a lot of the issue for me testing DOSMID with this is that I can't tell if DOSMID is loading or stuck loading due to lack of feedback from the program other than my HDD light blinks occasionally. Some rotating star or changing ellipses (. .. ...) would be a big help in detecting if the program is still loading, or there's a freeze.

Yes, on a 4 Mhz PC loading a 100K MIDI can take some time, and I wonder sometimes if the PC is still alive. I will see to add some visual feedback.

I did some reading on the Lotech 2MB card:

The driver supports all LIM4 EMS functions, except:

Function 19 (non-volatile handles)
Function 28 (alternate registers - software support only)

Whatever these may be.

EDIT: removed some incorrect info, I misunderstood something about the EMS4 standard.

Couple of hours of work led to EXMS 0.9.2 beta 1, attached. There are two key improvements since yesterday:
1. Pointer normalization for EMS transfers: I now normalize all pointers passed to the EMS driver. This resolves a data corruption issue I encountered: when the offset portion of a far pointer wraps during a transfer, the EMS driver fails to catch it and ends up writing to the start of the segment, potentially overwriting critical data. Normalizing the pointers beforehand ensures that the driver will not have such a surprise.
2. Support for XMS transfers over 16 KB: While this change doesn't impact DOSMid, it should improve compatibility with software that rely on larger XMS blocks.

I did some limited testing with DOSMid and a few MIDI files in my virtual setup, and everything seems to behave nicely so far. Still, I’m puzzled by how much hand-holding the Bocaram EMS driver requires. The EMS 4.0 spec paints a picture of smooth sailing, but real-world implementations are clearly more turbulent. Makes you wonder how many drivers claim EMS 4.0 support without fully adhering to the spec.

Sneakernets wrote on 2025-07-23, 20:47:

I did some reading on the Lotech 2MB card:

The driver supports all LIM4 EMS functions, except:

Function 19 (non-volatile handles)
Function 28 (alternate registers - software support only)

Whatever these may be.

I read the same, but these are irrelevant in our case. EXMS86 only uses Function 24 (albeit with much dancing around now).

mateusz.viste wrote on 2025-07-17, 05:41:

That's a good question, and to be honest I was hoping to find out here with people saying "I can run program xyz now on my 8086!". 😜

I am not sure there are any 8086-compatible programs that require XMS, but I imagine there might be some (esp. games) that use it for improved performances (caching) if it is detected, and these might not bother to look for EMS*.

I don't have time to test at the moment, but Ashes of Empire is one commercial game that I know of that requires either XMS or EMS and will run on a 8088.

Possibly other stuff I have listed in this post that supports/requires EMS, I imagine early-90s Sierra games are a good candidate since they typically ask for "extra memory" without specifying what:
Re: Is there any reason to install more than 1 MB RAM on a 286 PC?

DEAT wrote on 2025-07-23, 23:51:

I don't have time to test at the moment, but Ashes of Empire is one commercial game that I know of that requires either XMS or EMS and will run on a 8088.

There is certainly a lot of software that needs EMS *or* XMS. Finding software that uses only XMS (no EMS support) and works on a pre-386 PC is more challenging. :)
DOSMid is one. FreeCOM is another. That's all I know so far.

Of course EXMS86 can be used on a 386+ as well. The use case is another niche, though. Might make sense for example if said 386 has little RAM but a convenient EMS card that does not emulate XMS itself.

EXMS86 could also be the basis for other sources of XMS memory: for example death-slow XMS from disk or slow-ish XMS from a network server, or maybe some esoteric 32k XMS from hercules VRAM.

mateusz.viste wrote on Yesterday, 05:48:

There is certainly a lot of software that needs EMS *or* XMS. Finding software that uses only XMS (no EMS support) and works on a pre-386 PC is more challenging. 😀
DOSMid is one. FreeCOM is another. That's all I know so far.

The link I posted above also mentions XMS games that run on a 286 - from memory, I believe that all of them had an explicit CPU check or had otherwise crashed when testing on a 8088/V20, but it has been almost two years since I tested those games - the games that I listed as explicitly requiring XMS (as opposed to optionally using XMS) would be a good starting point.

DEAT wrote on Yesterday, 10:04:

the games that I listed as explicitly requiring XMS (as opposed to optionally using XMS) would be a good starting point.

I think that such games are very unlikely to work on an 8086, because of the common assumption that "XMS = 386+". The software that could be potentially more interesting is probably software that do not *require* XMS, but is open to using it to improve performances. Both DOSMid and FreeCOM fall into this category.