Thanks,
What is that dma channel count about ?
Maybe it would it depend on the ems type ?

Below are details of the various fields from the LIM EMS spec and also some notes on alternate register sets. I know you didn't ask about the latter, but it might be useful. Comparatively, when using MS-DOS 5 or 6.22 in a VirtualBox VM with EMM386, DMA_channels also reports 0 while alternate_register_sets reports 7. 0 _seemed_ like the safe value for both in DOSBox, but I could be way off base on that.

hardware_info_struct STRUC
raw_page_size DW ?
alternate_register_sets DW ?
context_save_area_size DW ?
DMA_channels DW ?
DMA_channel_operation DW ?
hardware_info_struct ENDS

ES:DI = hardware_info
Contains a pointer to a memory area that the operating
system supplies where the memory manager will copy expanded
memory hardware information. The structure contains these
five members:

.raw_page_size
The first member is a word which contains the size of a raw
mappable physical page in paragraphs (16 bytes). LIM
standard pages are always 16K bytes. However, other
implementations of expanded memory boards do not
necessarily comply with this standard and can emulate a
16K-byte page by mapping in multiple smaller pages. This
member specifies the size of a mappable physical page
viewed from the hardware implementation level.

.alternate_register_sets
The second member is a word which specifies the number of
alternate mapping register sets. The additional mapping
register sets are termed alternate mapping register sets in
this document.

All expanded memory boards have at least one set of
hardware registers to perform the logical to physical page
mapping. Some expanded memory boards have more than one
set of these mapping registers. This member specifies how
many of these alternate mapping register sets exist (beyond
the one set that all expanded memory boards have) on the
expanded memory boards in the system. If an expanded
memory card has only one set of mapping registers (that is,
no alternate mapping register sets) this member has a value
of zero.

.context_save_area_size
The third member is a word which contains the storage
requirements for the array required to save a mapping
context. The value returned in this member is exactly the
same as that returned by Function 15 (Get Size of Page Map
Save Array subfunction).

.DMA_channels
The fourth member is a word which contains the number of
register sets that can be assigned to DMA channels. These
DMA register sets, although similar in use to alternate
register sets, are for DMA mapping and not task mapping.

If the expanded memory hardware does not support DMA
register sets, care must be taken when DMA is taking place.

In a multitasking operating system, when one task is
waiting for DMA to complete, it is useful to be able to
switch to another task. However, if the DMA is taking
place in memory that the second task will need to remap,
remapping would be disastrous.

If the expanded memory hardware can detect when DMA is
occurring, the OS/E should allow task switches and
remapping during DMA. If no special support for DMA is
available, no remapping should be done when DMA is in
progress.

.DMA_channel_operation
The fifth member is a word which specifies a special case
for the DMA register sets. A value of zero specifies that
the DMA register sets behave as described in Function 28.
A value of one specifies that the expanded memory hardware
has only one DMA register set. In addition, if any channel
is mapped through this register set, then all channels are
mapped through it. For LIM standard boards, this value is
zero.

Multiple memory maps
Another important EEMS hardware feature implemented in EMS 4.0 is the concept of multiple sets of mapping registers. These allow operating environments, such as Windows and DESQview, to efficiently perform multitasking operations. Because this is a hardware feature not designed into the original EMS 3.2, such boards can not offer this functionality even with EMS 4.0 software drivers.

With multiple sets of registers, application programs running concurrently under the control of an operating environment, can each have their own map. Each time the operating environment switches from one program to another, the newly active program can access its map almost instantly. The result is that switching from one application to another is much faster and becomes a viable means of increasing PC productivity by reducing the amount of time spent moving between applications.

EEMS memory boards manufactured by AST include two sets of mapping registers. EMS 4.0 provides for as many as 32 alternate sets of registers <196> further enhancing AST's design.

Again, EMS 3.2 memory boards can not implement this feature of the new EMS 4.0 standard. Such boards simply are not designed for multiple sets of registers. So, without the alternate registers, an operating environment must save and restore mapping information to memory. This save and restore process must occur every time the operating environment needs to access an expanded memory page not in the present memory map, and hinders the performance of multitasking operating environments.

okay, so emm386 reports 0 for the dma channels. I thought that maybe they would report something there, as they do influence dma transfers, but it seems really geared towards boards.
The additional registers. 0 might work for those as well. Although I wonder, where are those alternative registers located. It might be that win3.x in enchanced mode touches that (for the multitasking).
Might want to check if it uses that function.

I _think_ that, if either of those values report non-zero, we'd also need to have subfunction 5B implemented. I'm not sure either where those alternate registers are located (I suspect it's internal to each implementation, though I'm admittedly getting out of my depth on that one), but 5B provides the ability for the system to be able to allocate those registers and enable DMA. My understanding is that Win 3.1 Enh not only doesn't use int67, but it actually returns errors to Windows apps trying to call it while non-windows apps can still call them. I did verify via the DOSBox debugger that Windows doesn't make any int67 calls during startup and idling, and I verified that DOS apps in a command prompt under Windows can still call it. Here is an SDK-related reference that surely does a better job explaining the latter than I can: https://www.infania.net/misc/kbarchive/kb/057 … 7954/index.html

It might use the deviceread (ReadFromControlChannel on the emm device))

But it's good that it doesn't care about that function with the alternatives registers.

@emuslor your patch was included in the latest dosbox-x release.