DOS 6.22 with LIM 4.0 Expanded Memory

DOS 6.22 with LIM 4.0 Expanded Memory

[Daniel L. Srebnick]

I have a need to run an old MSDOS 6.22 image with an application that
makes use of EMS 4.0.

After some extensive testing, it seems that DOS' EMM386 driver cannot
find a 64k page frame that it can use.  I can manually designate the
block beginning at D800 as a page frame but then shortly after start
the system hangs.

I have a test program that is used to determine if the system is seeing
the EMS as expected and this fails.

If anyone is interested in taking a look at this I'll provide the XML
for the VM, a config.sys as well as the EMSTEST program which can be
used to validate a proper environment.

If this is not the right place to raise this issue please point me in
the proper direction.

Many thanks,

Dan Srebnick

Re: DOS 6.22 with LIM 4.0 Expanded Memory

[Gustavo Romero]

Hi Dan,

On 10/1/25 19:14, Daniel L. Srebnick wrote:
> I have a need to run an old MSDOS 6.22 image with an application that
> makes use of EMS 4.0.
> 
> After some extensive testing, it seems that DOS' EMM386 driver cannot
> find a 64k page frame that it can use.  I can manually designate the
> block beginning at D800 as a page frame but then shortly after start
> the system hangs.

Certainly I'm not the right person to ask about DOS and i386 machines,
but I'm curious: why 0xD800 (54k)? Shouldn't the EMS window be in the
640K-1M range?


> I have a test program that is used to determine if the system is seeing
> the EMS as expected and this fails.
> 
> If anyone is interested in taking a look at this I'll provide the XML
> for the VM, a config.sys as well as the EMSTEST program which can be
> used to validate a proper environment.

I think that would be a start yes, but I really don't remember anybody
looking at DOS in QEMU in the last couple of years. The problem I can
see is that the original EMM386 driver is closed source so it would be
tricky to debug it and observe what action is possibly causing the VM
misbehavior (I'm not saying it's a VM issue). Maybe the issue can also
be reproduced with FreeDOS, where the EMS driver is open source and can,
no idea how, be debugged?

A command line to start the VM would be better than the XML file, IMHO.


> If this is not the right place to raise this issue please point me in
> the proper direction.

If it's an issue with one of the machines we support, yes. Better if it
reproduces with QEMU built from upstream master branch. The problem is:
how to confirm it's a VM issue and not an issue in the DOS sw stack?
Ideally, we need a much simpler reproducer for it. Also, is it a regression?
Like, does any other QEMU version runs the same sw stack without hangs? In
this case you could use the sw stack to bisect the QEMU code.


Cheers,
Gustavo

> 
> Many thanks,
> 
> Dan Srebnick
> 

Re: DOS 6.22 with LIM 4.0 Expanded Memory

[Daniel L. Srebnick]

> Certainly I'm not the right person to ask about DOS and i386 machines,
> but I'm curious: why 0xD800 (54k)? Shouldn't the EMS window be in the
> 640K-1M range?

D800 (used as the EMM386 frame parmameter) actually refers to D800:0000.  So yes,
the window is in the upper memory space.

Re: DOS 6.22 with LIM 4.0 Expanded Memory

[Daniel L. Srebnick]

On Wed, 2025-10-01 at 23:42 -0300, Gustavo Romero wrote:
> 
> A command line to start the VM would be better than the XML file,
> IMHO.
> 

qemu-system-i386 MS-DOS_6.22.qcow2 -machine pc-i440fx-9.2

Assuming that the qcow2 files has an MS-DOS 6.22 image.

In config.sys, you'd need a line like:

device=c:\dos\emm386.exe ram