Attached to this post is the file pmexamp.zip. It's a 32-bit DOS protected mode program. It's written with JWASM for DOS, but should also work with MASM.
I linked the OBJ files with TLINK, but other linkers should do the job as well. In this case, the batch file must be modified accordingly. Therefore I've attached
the binary files to the archive in case someone doesn't have the used software available.
The source files are PMSHELL.ASM (32-bit DPMI Shell) and examp1.asm (the DOS program). The application outputs some information about the available memory,
then fills a memory area over 1 MB with values and finally displays them on the screen. The program is tested under different virtual machines (DOSBox, VirtualBox,
VMwarePlayer) and under native DOS. I used Japhet's DOS Extender HX, which I can only recommend.
The test under other configurations is interesting for me. I thank you already now for your help.
I have again a similar situation as in July 2013 (http://masm32.com/board/index.php?topic=2100.msg22385#msg22385). On my old machine, the program can request 3.5 GB of RAM with HX.
The new machine only allows 1.2 GB. This will be sufficient in most cases. But what is the cause of this behavior?
I suspect that the hardware manufacturers have installed memory holes again.
That's what xmsstat brings.
XMS call address: FFFF:3253
XMS version: 3.0
HMA handled by XMS host, HMA is allocated
largest free memory block (v2) in kB: 65535, total free: 65535
largest free memory block (v3) in kB: 871464, total free: 1228748
XMS handle table at FFFF:34F8, handle cnt/size=48/10
XMS handle array at FFFF:3318
no handle region size(kB) locks flags
--------------------------------------------------------
1 3318 00110000-35419FFF 871464 0 01 free
2 3322 3A317000-4FFFFFFF 357284 0 01 free
--------------------------------------------------------
1228748
free handles: 46
no UMB handler installed
Hopefully this will be some help to Japheth. Thank you.
Hi Gunther!
I try in DOSBox-X but look it have a problem to set path. LATER: path in config file is working, and exactly same DosBox result.
No problem in DosBox:
HSE,
thank you for trying the program under DOSBox. It works as expected.
Did you reassemble or used the attached EXE?
Hi gunther!
Quote from: Gunther on January 17, 2022, 12:07:38 PM
It works as expected.
Yes. Could be different in DOSBox-X, but apparently is the same.
Quote from: Gunther on January 17, 2022, 12:07:38 PM
Did you reassemble or used the attached EXE?
Attached EXE. Evidently I don't build assembly dos programs after I discover MASM32 SDK, because I don´t have that tools in this machine. I still keep the old machine, but I don't know where is hard disk :biggrin:
HSE,
Quote from: HSE on January 18, 2022, 01:29:14 AM
Attached EXE. Evidently I don't build assembly dos programs after I discover MASM32 SDK, because I don´t have that tools in this machine. I still keep the old machine, but I don't know where is hard disk :biggrin:
That's all right. Please don't bother about the missing old hard disk with the tools.
Hi,
I also just ran the EXE included. What version of MASM is required?
Anyway, here are the results from running in a VDM with a rather old
system.
System and Memory Information:
==============================
Start Address 16 Bit Code = 78672
Start Address 32 Bit Code = 82304
Start Address private data for DPMI Host = 88768
Start Address DOS buffer = 89808
DOS buffer length in byte = 562480
Largest available free Extended Memory Block in bytes = 16777216
First free address above 1 MB = 4194304
Last free address above 1 MB = 20971520
Filling an array in the Extended Memory with values.
Done.
Reading these values back: 14680060
Done.
Press any key to end the application...
Regards,
Steve N.
Steve,
thank you for your test results.
Quote from: FORTRANS on January 18, 2022, 03:17:57 AM
What version of MASM is required?
That's a good question. The decisive factor is probably the corresponding linker. Here is the rough logic of the program: It starts as Real Mode application and ends
as a 16-bit Protected Mode program. In the meantime, however, it's switched to 32-bit protected mode and should be able to use the entire address space linearly.
This all happens in PMSHELL.ASM. The source code is well commented and you can find all the details there. The trick now is that the program contains a 16-bit and
a 32-bit segment. So the linker must be able to link both segments properly. TLINK does this without complaint. Whether the 16-bit linker from MS can do this would
have to be tried.
Which VDM did you use?
Hi,
Quote from: Gunther on January 18, 2022, 05:02:42 AM
Which VDM did you use?
OS/2 version 4.
Cheers,
Steve N.
Steve,
Quote from: FORTRANS on January 18, 2022, 05:55:14 AM
OS/2 version 4.
that's not surprising. OS/2 has always had a very solid DOS emulation. I'm thinking of setting up Warp 4 as a virtual machine. JWASM has an OS/2 version.
Earlier there was also a GCC for OS/2 maintained by Eberhard Mattes. I don't know what the situation is like today.
Hi Gunther,
Quote from: Gunther on January 18, 2022, 05:02:42 AM
Quote from: FORTRANS on January 18, 2022, 03:17:57 AM
What version of MASM is required?
That's a good question. The decisive factor is probably the corresponding linker.
Actually, a linker I have works, and my MASM setup for DOS is too old.
The linker linked the two object modules in your zip file to an EXE that
worked. Though it was four bytes different in size.
Microsoft (R) Segmented-Executable Linker Version 5.15
Copyright (C) Microsoft Corp 1984-1991. All rights reserved.
Usage:
LINK
LINK @<response file>
LINK <objs>,<exefile>,<mapfile>,<libs>,<deffile>
Valid options are:
/? /ALIGNMENT
/BATCH /CODEVIEW
/CPARMAXALLOC /DOSSEG
/DSALLOCATE /EXEPACK
/FARCALLTRANSLATION /HELP
/HIGH /INCREMENTAL
/INFORMATION /LINENUMBERS
/MAP /NODEFAULTLIBRARYSEARCH
/NOEXTDICTIONARY /NOFARCALLTRANSLATION
/NOGROUPASSOCIATION /NOIGNORECASE
/NOLOGO /NONULLSDOSSEG
/NOPACKCODE /OVERLAYINTERRUPT
/PACKCODE /PACKDATA
/PADCODE /PADDATA
/PAUSE /PMTYPE
/QUICKLIBRARY /SEGMENTS
/STACK /TINY
/WARNFIXUP
As far as GCC, there is something on the Hobbes OS/2 repository.
Though it looks a bit skimpy.
Regards,
Steve
Steve,
it is a bit cumbersome, but the following way works: I have assembled both files with the MASM from the MASM32 package.
e:\masm32\work>\masm32\bin\ml /c PMSHELL.ASM
Microsoft (R) Macro Assembler Version 6.14.8444
Copyright (C) Microsoft Corp 1981-1997. All rights reserved.
Assembling: PMSHELL.ASM
e:\masm32\work>\masm32\bin\ml /c examp1.asm
Microsoft (R) Macro Assembler Version 6.14.8444
Copyright (C) Microsoft Corp 1981-1997. All rights reserved.
Assembling: examp1.asm
TLINK then linked the resulting OBJ files without complaint. The resulting EXE files are different in size but have the same functionality.
Quote from: FORTRANS on January 18, 2022, 08:44:38 AM
As far as GCC, there is something on the Hobbes OS/2 repository.
Though it looks a bit skimpy.
I'll take a look at it.
Quote from: Gunther on January 17, 2022, 07:53:04 AM
The new machine only allows 1.2 GB. This will be sufficient in most cases. But what is the cause of this behavior?
Huge parts of physical memory might be mapped beyond the 4 GB barrier. The highest address 4FFFFFFF showed by xmsstat might suggest that only 1.25 GB are mapped below 4 GB.
BIOS function int 15h, ax=E820h is the method to get the system's memory map. tool memstat in https://github.com/Baron-von-Riedesel/Jemm/releases/download/v5.80/JemmB_v580.zip (https://github.com/Baron-von-Riedesel/Jemm/releases/download/v5.80/JemmB_v580.zip) uses that call.
Usually there were at least 3 GB below 4 GB, but with 64-bit systems being now the standard that may have changed. Also, the PCIe graphics card may reserve quite some address space below 4 GB to map its video ram there.
Andreas, thank you for your fast answer.
Quote from: _japheth on January 19, 2022, 12:45:36 AM
Usually there were at least 3 GB below 4 GB, but with 64-bit systems being now the standard that may have changed. Also, the PCIe graphics card may reserve quite some address space below 4 GB to map its video ram there.
This could be the cause. Here is the result of MEMSTAT:
conventional memory (Int 12h): 629 kB
XBDA at segment 9d40, size 11 kB
Int 15h, ah=88h, extended memory: 0 kB
Int 15h, ax=E801h failed
Int 15h, eax=E820h:
address range size type
----------------------------------------------------
000000000-00009d3ff 9d400 1 (available)
00009d400-00009ffff 2c00 2 (reserved)
0000e0000-0000fffff 20000 2 (reserved)
000100000-035419fff 3531a000 1 (available)
03541a000-03779cfff 2383000 2 (reserved)
03779d000-037826fff 8a000 3 (ACPI reclaimable)
037827000-0388a7fff 1081000 4 (ACPI NVS)
0388a8000-03a316fff 1a6f000 2 (reserved)
03a317000-04fffffff 15ce9000 1 (available)
100000000-89fffffff 7a0000000 1 (available)
050000000-06fffffff 20000000 2 (reserved)
0fe000000-0fe010fff 11000 2 (reserved)
0fec00000-0fec00fff 1000 2 (reserved)
0fed00000-0fed00fff 1000 2 (reserved)
0fee00000-0fee00fff 1000 2 (reserved)
0ff000000-0ffffffff 1000000 2 (reserved)
----------------------------------------------------
available: 32432 MB, ACPI: 17452 kB, rsvd: 590 MB, total: 33039 MB
ACPI eats up a lot of memory.
Probably I have to switch to the BIOS interrupt 15h after all.
Quote from: Gunther on January 19, 2022, 09:06:07 AM
Probably I have to switch to the BIOS interrupt 15h after all.
That depends what you want to achieve. Accessing memory beyond the 4 GB barrier requires some low-level work for a DOS app, since there exists no "unreal"-mode trick to do that.
Andreas,
Quote from: _japheth on January 19, 2022, 09:41:52 PM
That depends what you want to achieve.
a Beowulf cluster with FreeDOS.
Quote from: _japheth on January 19, 2022, 09:41:52 PM
Accessing memory beyond the 4 GB barrier requires some low-level work for a DOS app, since there exists no "unreal"-mode trick to do that.
that's surprising at all. I thought this is only possible in Long Mode. Are there any examples of this?
Quote from: Gunther on January 21, 2022, 07:13:58 AM
a Beowulf cluster with FreeDOS.
I see.
Quote from: Gunther on January 21, 2022, 07:13:58 AM
that's surprising at all. I thought this is only possible in Long Mode. Are there any examples of this?
Memory beyond 4 GB can be accessed by using special paging types:
1. PSE paging. I used it in https://github.com/Baron-von-Riedesel/HimemSX (https://github.com/Baron-von-Riedesel/HimemSX) to create a special XMS host that can access up to 1 TB.
It's also used by CWSDPMI v6/7 to backup virtual memory up to 4 GB.
2. PAE paging. That's more powerful ( and the type of paging also used in long mode). For a simple usage in DOS see https://github.com/Baron-von-Riedesel/DOS32pae (https://github.com/Baron-von-Riedesel/DOS32pae)
Andreas,
thank you for your advice.
Quote from: _japheth on January 21, 2022, 06:53:04 PM
Memory beyond 4 GB can be accessed by using special paging types:
1. PSE paging. I used it in https://github.com/Baron-von-Riedesel/HimemSX (https://github.com/Baron-von-Riedesel/HimemSX) to create a special XMS host that can access up to 1 TB.
It's also used by CWSDPMI v6/7 to backup virtual memory up to 4 GB.
1 TB for a DOS application sounds very impressive. If I understand correctly, HimemSX can be included under FreeDOS. That would already be a viable alternative for me. This should then even work in a virtual machine.
Quote from: _japheth on January 21, 2022, 06:53:04 PM
2. PAE paging. That's more powerful ( and the type of paging also used in long mode). For a simple usage in DOS see https://github.com/Baron-von-Riedesel/DOS32pae (https://github.com/Baron-von-Riedesel/DOS32pae)
That would be almost Long Mode. I'll have a look at that as well.
Andreas,
I found this on FreeDOS (https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.2/repos/pkg-html/jemm.html). It's JEMM version 5.79d.
In the XMS v3.5 API you've written:
Quote
In V86 mode, the XMM's 'move extended memory' function (AH=0Bh) will need the
help of the Expanded Memory Manager (EMM), since privileged code has to be
executed. The only EMMs that currently support accessing memory beyond 4 GB
are Jemm386/JemmEx v5.80+. Their Int 15h API has been exhanced as well.
Is there a binary package available for download of version 5.80?
Quote from: Gunther on January 22, 2022, 10:59:39 AM
Is there a binary package available for download of version 5.80?
Yes, https://github.com/Baron-von-Riedesel/Jemm/releases/download/v5.80/JemmB_v580.zip (https://github.com/Baron-von-Riedesel/Jemm/releases/download/v5.80/JemmB_v580.zip)
Thank you. :thumbsup: