@Sneakernets - here is the 0.9.2 beta 2 version. No major changes, just cleanup and some refactorization. It fails some of my tests and I struggle to know if it's because of the virtualization or if it would also fail on real hardware. I've included a test program. Would you mind running it on your PC and tell me what it says? The program performs a set of XMS copying tests and displays the results (OK/ERROR) for each.

I have released EXMS86 v0.9.2. EXMS86 does all kinds of little things that are supposed to be done by the EMS 4.0 cards, like far pointer normalization, segmentation of multiple-pages transfers and such (at the cost of slightly worse performances and increased memory footprint).

EXMS86 works perfectly now on my wonky virtual setup so hopefully it should work on hardware as well. I tested it with DOSMid, Wolf3D, FreeCOM, and my own custom suite of XMS tests.

mateusz.viste wrote on 2025-07-24, 10:12:

I think that such games are very unlikely to work on an 8086, because of the common assumption that "XMS = 386+".

XMS = 386+ would be a very strange assumption. But the assumption that any system that has an XMS driver contains a 286 processor seems reasonable, as the point of the Extended Memory Specification is to manage memory that is mapped into the processor space above 1MB, and such memory did not exist before the 286.

Using the XMS API like a RAM disk that can read and write blocks into a "black box" clearly makes sense for real-mode DOS software (and that's why EXMS86 works), but limiting XMS to that use is in no way specification compliant. Real XMS up to 16MB might for example be used for DMA transfers. I wonder whether any 286 game loaded Sound Blaster samples into XMS, and directly played them from XMS. At the moment, this sounds like a very clever idea to me, as this means that the samples are directly accessible for the DMA system and take up zero space in precious conventional memory.

mkarcher wrote on Yesterday, 21:30:

Using the XMS API like a RAM disk that can read and write blocks into a "black box" clearly makes sense for real-mode DOS software (and that's why EXMS86 works), but limiting XMS to that use is in no way specification compliant.

EXMS86 is compliant to the XMS 2.0 spec. It does not implement *all* of it, but that's not mandatory - the spec explicitly states that "Developers should keep in mind that some of the XMS API functions may not be implemented by all drivers and will return failure in all cases."
For example EXMS86 has no support for XMS functions related to HMA, UMB and A20. It also does not support the call "give me the physical location of the XMS memory allocated to my handle".

mkarcher wrote on Yesterday, 21:30:

Real XMS up to 16MB might for example be used for DMA transfers. I wonder whether any 286 game loaded Sound Blaster samples into XMS, and directly played them from XMS. At the moment, this sounds like a very clever idea to me, as this means that the samples are directly accessible for the DMA system and take up zero space in precious conventional memory.

Sounds plausible, yes, albeit there is one difficulty: DMA cannot cross 64K boundaries, so it would require a bit of heavy lifting to locate a proper place in the XMS space. It would also require to "lock" the XMS handle to ensure the driver will not relocate the data at some inconvenient time... but the spec says that "Locked blocks should be unlocked as soon as possible", so I wonder how that would play out in practice.

mkarcher wrote on Yesterday, 21:30:

I wonder whether any 286 game loaded Sound Blaster samples into XMS, and directly played them from XMS. At the moment, this sounds like a very clever idea to me, as this means that the samples are directly accessible for the DMA system and take up zero space in precious conventional memory.

From my work on vsbhda I know that "Legend of Kyrandia 2" and "Sword and Fairy 1" use XMS memory for a SB sound buffer. Both games don't check whether the physical address returned by the XMS lock function is within the first 16 MB of the address space.

Baron von Riedesel wrote on Today, 04:53:

From my work on vsbhda I know that "Legend of Kyrandia 2" and "Sword and Fairy 1" use XMS memory for a SB sound buffer. Both games don't check whether the physical address returned by the XMS lock function is within the first 16 MB of the address space.

Thanks for your input. I am surprised to head that this applies to a game released in 1993 and a game release in 1995(!). In 1995, everyone should have heard about PCs with a processor that has an address space bigger than 16M, albeit the typical RAM amount still was 8 to 16MB, so I think this explains why the manufacturer still got away with it.

BTW, as you mention VSBHDA: Last week I submitted https://github.com/crazii/SBEMU/pull/163 , which you might be interested in as well.

mkarcher wrote on Today, 07:25:

BTW, as you mention VSBHDA: Last week I submitted https://github.com/crazii/SBEMU/pull/163 , which you might be interested in as well.

Indeed Interesting! As it happens, I own such a board - a cheap Medion MB. I used it trying to make sound work in sbemu for ES1731, but I didn't got it working ( neither with sbemu nor in Win9x ), so I assumed it's dysfunctional and gave up.

mkarcher wrote on Yesterday, 21:30:

mateusz.viste wrote on 2025-07-24, 10:12:

I think that such games are very unlikely to work on an 8086, because of the common assumption that "XMS = 386+".

XMS = 386+ would be a very strange assumption. But the assumption that any system that has an XMS driver contains a 286 processor seems reasonable, as the point of the Extended Memory Specification is to manage memory that is mapped into the processor space above 1MB, and such memory did not exist before the 286.

Using the XMS API like a RAM disk that can read and write blocks into a "black box" clearly makes sense for real-mode DOS software (and that's why EXMS86 works), but limiting XMS to that use is in no way specification compliant. Real XMS up to 16MB might for example be used for DMA transfers. I wonder whether any 286 game loaded Sound Blaster samples into XMS, and directly played them from XMS. At the moment, this sounds like a very clever idea to me, as this means that the samples are directly accessible for the DMA system and take up zero space in precious conventional memory.

What comes to mind..

The PCE emulator provides XMS for an emulated 8088/8086 XT class system.
I haven't really checked the sources, though, so I don’t know how it's implemented.

The AST Rampage series of memory boards had a rex.sys driver that seemingly converted EMS/XMA (as provided by remm.sys driver) to Extended Memory (int15h BIOS function, not XMS).

E.3 Extended Memory Emulator - REX.SYS
REX interfaces with the REMM program to make Rampage 286 expanded memory act like extended memory.
This allows you to use AST's fASTdisk, SuperDrive, and SuperSpool (also IBM DOS 3.x VDISK.SYS utility with the "/E" option) to
create RAM disks or a print spooler in Rampage 286 expanded memory which emulates extended memory.
[..]
REX intercepts calls on read-only memory basic input/output system (ROM BIOS) functions designed for extended memory
use, and interfaces them to the REMM software so that they can use Rampage 286 expanded memory As with applications
that use the REMM software, program code portions of the SuperPak programs must reside in the 640 KB of PC-AT memory.
However, data associated with SuperPak utilities can use Rampage 286 expanded memory.