DOS ain't dead

Oso2k 14.01.2020, 01:21 @ Japheth	jemm update Post reply
	> Hello, > > finally, after many years of inactivity, an update to programs > Jemmex/Jemm386 is available. Thanks!

RayeR

CZ,
14.01.2020, 18:23

@ Japheth

jemm update

Post reply

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.

Japheth

Germany (South),
14.01.2020, 20:14

@ RayeR

jemm update

Post reply

> 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!

RayeR

CZ,
16.01.2020, 00:37

@ Japheth

jemm update

Post reply

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.

Japheth

Germany (South),
16.01.2020, 19:08

@ RayeR

jemm update

Post reply

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

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

---
MS-DOS forever!

RayeR

CZ,
16.01.2020, 22:02

@ Japheth

jemm update

Post reply

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.

roytam 17.01.2020, 06:41 @ RayeR	jemm update Post reply
	> 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.

RayeR

CZ,
18.01.2020, 02:14

@ roytam

jemm update

Post reply

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.

Japheth

Germany (South),
02.02.2020, 20:25

@ Japheth

jemm final version 5.79

Post reply

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!

CandyMan 14.02.2020, 19:56 @ Japheth	jemm final version 5.79 Post reply
	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.

Rugxulo Usono, 14.02.2020, 21:48 @ CandyMan	jemm final version 5.79 Post reply
	> 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.

Japheth

Germany (South),
15.02.2020, 07:42

@ CandyMan

jemm final version 5.79

Post reply

> 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!

iw2evk Magenta (Italy), 08.03.2020, 10:25 @ Japheth	jemm final version 5.79 Post reply
	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

Laaca

Czech republic,
08.03.2020, 13:31

@ iw2evk

jemm final version 5.79

Post reply

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!

Japheth

Germany (South),
08.03.2020, 19:14

@ iw2evk

jemm final version 5.79

Post reply

> 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!

Japheth

Germany (South),
09.03.2020, 13:32

@ CandyMan

jemm v5.80pre1

Post reply

> 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!

Rugxulo

Usono,
11.03.2020, 02:17

@ Japheth

HimemX 3.34

Post reply

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.

Doug 11.03.2020, 06:55 @ Rugxulo	HimemX 3.34 Post reply
	> 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.

Japheth

Germany (South),
11.03.2020, 12:28

@ Rugxulo

HimemX 3.34

Post reply

> > 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!

Wengier

31.03.2020, 03:12

@ Japheth

jemm v5.80pre1

Post reply

> > 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.

Wengier

31.03.2020, 03:39
(edited by Wengier, 31.03.2020, 03:49)

@ Wengier

jemm v5.80pre1

Post reply

> 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)

jemm update (Announce)

jemm update

jemm update

jemm update

jemm update

jemm update

jemm update

jemm update

jemm update

jemm final version 5.79

jemm final version 5.79

jemm final version 5.79

jemm final version 5.79

jemm final version 5.79

jemm final version 5.79

jemm final version 5.79

jemm v5.80pre1

HimemX 3.34

HimemX 3.34

HimemX 3.34

jemm v5.80pre1

jemm v5.80pre1