DOS ain't dead

Hello,

finally, after many years of inactivity, an update to programs Jemmex/Jemm386 is available.

The main reason for the update was: on "newer" machines the available physical memory is somewhat scattered, with many holes of "reserved" regions. The old JemmEx's built-in XMS host was unable to handle this condition, which may have resulted in far less free extended memory reported than actually existed.

https://github.com/Baron-von-Riedesel/Jemm/blob/master/bin/JEMM579B.zip

Source is also available at GitHub:

https://github.com/Baron-von-Riedesel/Jemm

---
MS-DOS forever!

> Hello,
>
> finally, after many years of inactivity, an update to programs
> Jemmex/Jemm386 is available.

Thanks!

Thanks for update. What systems have such issues? My i7-2600K works fine with current JEMMEX. The memory map with regions and holes should be reported by some BIOS INT so there was some change how it is reported?

---
DOS gives me freedom to unlimited HW access.

> The memory map with regions and holes should be
> reported by some BIOS INT so there was some change how it is reported?

No, it's an old problem. For example, the memory map of a current PC that I use looks like this (taken from tool 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:
ext. memory below 16 MB: 15360 (0x3c00) KB
ext. memory above 16 MB: 2560 64 KB blocks = 160 MB [1000000-affffff]
Int 15h, eax=E820h:
 address range          size       type
----------------------------------------------------
000000000-00009d3ff      9d400  1 (available)
00009d400-00009ffff       2c00  2 (reserved)
0000e0000-0000fffff      20000  2 (reserved)
000100000-009e0ffff    9d10000  1 (available)
009e10000-009ffffff     1f0000  2 (reserved)
00a000000-00a1fffff     200000  1 (available)
00a200000-00a20bfff       c000  4 (ACPI NVS)
00a20c000-00affffff     df4000  1 (available)
00b000000-00b01ffff      20000  2 (reserved)
00b020000-0d11c6fff   c61a7000  1 (available)
0d11c7000-0d11e5fff      1f000  3 (ACPI reclaimable)
0d11e6000-0da0a3fff    8ebe000  1 (available)
0da0a4000-0da1e1fff     13e000  2 (reserved)
0da1e2000-0da1f1fff      10000  3 (ACPI reclaimable)
0da1f2000-0da336fff     145000  1 (available)
0da337000-0da6f6fff     3c0000  4 (ACPI NVS)
0da6f7000-0db772fff    107c000  2 (reserved)
0db773000-0ddffffff    288d000  1 (available)
100000000-41f37ffff  31f380000  1 (available)
0de000000-0dfffffff    2000000  2 (reserved)
0f8000000-0fbffffff    4000000  2 (reserved)
0fd000000-0fd0fffff     100000  2 (reserved)
0fd500000-0fd5fffff     100000  2 (reserved)
0fea00000-0fea0ffff      10000  2 (reserved)
0feb80000-0fec01fff      82000  2 (reserved)
0fec10000-0fec10fff       1000  2 (reserved)
0fec30000-0fec30fff       1000  2 (reserved)
0fed00000-0fed00fff       1000  2 (reserved)
0fed40000-0fed44fff       5000  2 (reserved)
0fed80000-0fed8ffff      10000  2 (reserved)
0fedc2000-0fedcffff       e000  2 (reserved)
0fedd4000-0fedd5fff       2000  2 (reserved)
0fee00000-0feefffff     100000  2 (reserved)
0ff000000-0ffffffff    1000000  2 (reserved)
----------------------------------------------------
available: 16315 MB, ACPI: 4076 kB, rsvd: 135 MB, total: 16454 MB

The old jemmex's XMS host would have taken just the region 00100000-009e0ffff, which is about 160 MB, and ignored all the rest.

The new version would take all regions marked as available and below the 4 GB border, which results in free XMS memory of about 3.5 GB.

Btw, what you can also see in this example is that the BIOS has a bug. Int 15h, ax=e801 reports free extended memory from 100000-affffff, but the detailed map returned by int 15h, ax=e820, shows an ACPI region at a200000.

---
MS-DOS forever!

Aha, I understand. And what PC is it? On my intel P67 I have the 1st available area almost entire installed 4GB so no problem...

conventional memory (Int 12h): 638 kB
XBDA at segment 9f80, size 2 kB
Int 15h, ah=88h, extended memory: 65472 kB
Int 15h, ax=E801h:
ext. memory below 16 MB: 15360 (0x3c00) KB
ext. memory above 16 MB: 56953 64 KB blocks = 3559 MB [1000000-df78ffff]
Int 15h, eax=E820h:
 address range          size       type
----------------------------------------------------
000000000-00009f7ff      9f800  1 (available)
0000f0000-0000fffff      10000  2 (reserved)
0fec00000-0ffffffff    1400000  2 (reserved)
0f4000000-0f7ffffff    4000000  2 (reserved)
00009f800-00009ffff        800  2 (reserved)
0df7f0000-0df7fffff      10000  2 (reserved)
000100000-0df78ffff   df690000  1 (available)
0df7b3000-0df7effff      3d000  3 (ACPI reclaimable)
0df790000-0df7b2fff      23000  4 (ACPI NVS)
100000000-11effffff   1f000000  1 (available)
----------------------------------------------------
available: 4071 MB, ACPI: 384 kB, rsvd: 84 MB, total: 4155 MB

---
DOS gives me freedom to unlimited HW access.

> Aha, I understand. And what PC is it?

Ist's an ASUS B450M with cpu Ryzen 5 3600.

---
MS-DOS forever!

Well, the latest Ryzen, how it is friendly to DOS (e.g. IDE emulation or INT13 only?) and older Windows - did you tried WinXP or Win7? ACPI issues? I read that Ryzen 2 can run Win 7 but there are some problems with scheduler affecting performance...

---
DOS gives me freedom to unlimited HW access.

> Well, the latest Ryzen, how it is friendly to DOS (e.g. IDE emulation or
> INT13 only?) and older Windows - did you tried WinXP or Win7? ACPI issues?
> I read that Ryzen 2 can run Win 7 but there are some problems with
> scheduler affecting performance...

Ryzen 3700X with B450 motherboard works well with Win7 here.

OK, good to know. Didn't you tried WinXP? On latest intel there are ACPI issues but someone made ACPI.SYS fix to run then on intel Z390 Cofeelake, also mentioned Ryzen but not specified what generation...

---
DOS gives me freedom to unlimited HW access.

At last a bug was fixed in JemmEx that caused shrinking EMBs not to work correctly. It happens with Volkov Commander, for example - I always thought this a bug in VC, but finally realized it was a bug in JemmEx.

https://github.com/Baron-von-Riedesel/Jemm/blob/master/bin/JEMM579B.zip

changes:

02/02/2020: v5.79
- if physical address of DMA buffer was beyond 16M, its size was reset
to zero. This is no longer done.
- default linker is now JWlink.
- debug displays added for mode switch calls.
- Jemm will now use info returned by Int 15h, ax=E820h to mark regions
in the upper memory area as reserved.
- VME (virtual mode extensions) is now off by default; there exist CPUs
that claim to support VME but actually don't.
- JemmEx's built-in XMS host will now use up to 8 memory blocks listed
by ACPI (int 0x15, ax=0xe820). Previously it could just use the one
with base address 0x100000.
- fixed: shrinking an EMB didn't work correctly.

---
MS-DOS forever!

The DOS system is started from UMBPCI.
Previous versions of JEMM386 run from the command line with the "load" option alone detected UMB enabled by UMBPCI.
The new version does not detect UMB, you must add the option X=C000-FFFF to prevent the system from crashing.

> The DOS system is started from UMBPCI.
> Previous versions of JEMM386 run from the command line with the "load"
> option alone detected UMB enabled by UMBPCI.
> The new version does not detect UMB, you must add the option X=C000-FFFF to
> prevent the system from crashing.

I was under the impression that you were normally expected to "JEMM386 LOAD I=TEST X=TEST". Try that, and see what happens.

> Previous versions of JEMM386 run from the command line with the "load"
> option alone detected UMB enabled by UMBPCI.

I haven't tested this yet, but AFAIK Jemm does NOT and never did detect UMBs provided by UMBPCI. It may display the warning: "system memory found at x-x, region might be in use". To include such regions into Jemm's UMB pool one has to use the S=xxxx option ( not recommended, because ram activated by UMBPCI may have restrictions [ DMA, access time ] ).

However, there was a (documented) change in v5.79: Jemm calls int 15h, ax=e820h to get "reserved" regions in C000-FFFF. If this call is supported, it relies upon the result, and does partly skip its own testing ( it still scans for ROMs ).

---
MS-DOS forever!

Hi Japheth,
a question : it's possible in next release of Jemm implementing a command for load TSR drivers into a reserved space in XMS?
I remember a older program called Cloaching (or similar name) with this possibility..
Can cause crashes the loading of tsr drivers in XMS?
In others hands this can set free more standard memory used for TSR drivers (use of UMB's).
Thanks

Roberto iw2evk

Jemm already can load TSR modules into XMS. There is a driver JLoad wich can load DLLs. There is already available driver for UltraDMA/disk caching.

---
DOS-u-akbar!

> a question : it's possible in next release of Jemm implementing a command
> for load TSR drivers into a reserved space in XMS?

You can't just load a DOS TSR into an XMS block - a DOS TSR must reside and run in conv. memory.

---
MS-DOS forever!

> The new version does not detect UMB, you must add the option X=C000-FFFF to
> prevent the system from crashing.

This will be fixed in v5.80.

https://github.com/Baron-von-Riedesel/Jemm/blob/master/bin/JemmB_v580pre1.zip

---
MS-DOS forever!

I'm a bit confused whether this is referring to HIMEMX or JEMMEX [sic], but Eric Auer wanted to mention to you:

> http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/himem/himemx/himem334-unofficial-rp.zip
>
> (Pemberton 2013 patch)
>
> has the issue that it only checks carry flag after int 15.8a, but
> that is not enough to catch every BIOS without proper support. And
> it rarely is necessary to use int 15.8a at all ("Dimitrios case").
>
> himemx 3.32 used int 15.e820 - int 15.e801 - int 15.88 whereas
>
> himemx 3.34 does [15.e820 multiblock] [15.e801 - 15.8a - 15.88]
>
> While the JEMM updates reminded me of himem multiblock, I suggest to
> change (not e820alloc, but only) geti15mem from try_8Ah to try_88h
> to either: 1. NOT call int 15.8a at all, or 2. pre-load DX:AX with a
> magic value, then see if it really changed, or 3. not use int 15.8a
> UNLESS some new command line option enables it. I guess 1. is fine.
>
> This would be a small but helpful change to HIMEMX

Although, FYI, I think Mateusz Viste did some minor cleanups and mirrored HimemX to SourceForge here (in 2015). I haven't diff'd these versions, though.

> Although, FYI, I think Mateusz Viste did some minor cleanups and mirrored
> HimemX to SourceForge
> here
> (in 2015). I haven't diff'd these versions, though.

If i recall correctly, Mateusz also incorporated a few 'fixes' to that version of HiMemX that had been floating around the 'net.

- Doug B.

> > While the JEMM updates reminded me of himem multiblock, I suggest to
> > change (not e820alloc, but only) geti15mem from try_8Ah to try_88h
> > to either: 1. NOT call int 15.8a at all, or 2. pre-load DX:AX with a
> > magic value, then see if it really changed, or 3. not use int 15.8a
> > UNLESS some new command line option enables it. I guess 1. is fine.

I also included the "multiblock" feature to himemx:

https://github.com/Baron-von-Riedesel/HimemX

There's no binary, though, one has to create it from the source.

---
MS-DOS forever!

> > The new version does not detect UMB, you must add the option X=C000-FFFF
> to
> > prevent the system from crashing.
>
> This will be fixed in v5.80.
>
> https://github.com/Baron-von-Riedesel/Jemm/blob/master/bin/JemmB_v580pre1.zip

Thanks for your work, Japheth. Meanwhile, I think it is probably a good idea to implement the GEMMIS interface for JEMM386 so that it will be compatible with the Windows 3.1 (386 Enhanced mode) and WFW 3.11. The open-source DOSBox project has already implemented GEMMIS for some time, in the file ems.cpp (https://sourceforge.net/p/dosbox/code-0/HEAD/tree/dosbox/trunk/src/ints/ems.cpp), so you may want to take a look at the code and implement the interface for JEMM386 too.

> Thanks for your work, Japheth. Meanwhile, I think it is probably a good
> idea to implement the GEMMIS interface for JEMM386 so that it will be
> compatible with the Windows 3.1 (386 Enhanced mode) and WFW 3.11. The
> open-source DOSBox project has already implemented GEMMIS for some time, in
> the file ems.cpp
> (https://sourceforge.net/p/dosbox/code-0/HEAD/tree/dosbox/trunk/src/ints/ems.cpp),
> so you may want to take a look at the code and implement the interface for
> JEMM386 too.

Japheth, you can also see the changes in DOSBox's ems.cpp directly related to GEMMIS support here:

https://sourceforge.net/p/dosbox/code-0/2601/

(The changes are smaller than one might think, apparently)