DOS ain't dead

Hello,

I'm proudly announcing HimemSX, source to be found on github:

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

HimemSX is an XMM, implementing XMS v3.5.

The SX in HimemSX stands for "Super-eXtended" - HimemSX can manage extended memory up to 1 terrabyte .

To allow some tests with this "super tool", there's a patched version, also on github, of Jack R. Ellis' nice tool RDISK ( a ramdisk driver ). It uses HimemSX's new functions to allocate its XMS memory beyond the 4 GB barrier, thus it doesn't need any "legacy" extended memory.

Here's the HimemSX readme:
https://github.com/Baron-von-Riedesel/HimemSX/blob/master/Readme.txt

---
MS-DOS forever!

Hello Japheth,

The first URL should probably read github.com and not guthub.com?

Anyway, this looks cool, and I hope to find out how it all works.

Thank you!

---
https://gitlab.com/tkchia · https://codeberg.org/tkchia · 😴 "MOV AX,0D500H+CMOS_REG_D+NMI"

"...will fail if cpu is in v86-mode..." :(
Is is technically possible to overcome this obstacle when acessing beyond 4GB and make it compatible with V86 mode? Same problem with NDN64 and other Candyman's 64-bit stuff...

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

> Hello,
>
> I'm proudly announcing HimemSX, source to be found on github:
>
> https://github.com/Baron-von-Riedesel/HimemSX
>
> HimemSX is an XMM, implementing XMS v3.5.
>
> The SX in HimemSX stands for "Super-eXtended" - HimemSX can manage extended
> memory up to 1 terrabyte .
>
> To allow some tests with this "super tool", there's a patched version, also
> on github, of Jack R. Ellis' nice tool RDISK ( a ramdisk driver ). It uses
> HimemSX's new functions to allocate its XMS memory beyond the 4 GB barrier,
> thus it doesn't need any "legacy" extended memory.
>
> Here's the HimemSX readme:
> https://github.com/Baron-von-Riedesel/HimemSX/blob/master/Readme.txt

I compiled HimemSX with JWASM and it works, with interesting results.

I also patched the included RDISKSX.COM to allow the creation of up to a 4095M ramdrive, from 2047M. Above 2048M, the ramdrive is created as FAT16 with the 64-kb cluster size. Beyond 4GB for ramdrive is impossible without a FAT32 ramdrive for DOS and / or sector size > 512 bytes.

The interesting result is that XMS function call ah=0x89 via access at 0x0c9 results in about 50x slower XMS throughput. That is the rate of filling a 2048M file of 0x00 onto the ramdrive is about 100 MB/sec using 0x0c9 to access XMS beyond the 4GB barrier, while accessing XMS the "old" way results in writing a 2GB file of nulls in about 0.5sec. Of course, it is impossible to write a file of >2047M because of the signed 32-bit limit in filelength. Or, is there some patch to DOS which will allow the creation the file to its 32-bit unsigned maximum value of 4096M-1 byte?

I'm super impressed, but is the slowdown the expected behavior?

I am unable to attach the 6.8 kb binary of my compiled version of HIMEMSX to this post for others to test. The ZIP includes the patched version of RDISKSX.COM as well.

> I'm super impressed, but is the slowdown the expected behavior?

A significant slowdown is expected, but 100 MB/sec is definitely slower than expected.

The XMS block move command has an "interrupt window", that is, the block is copied in 8 kB chunks. For each such chunk it's necessary to enter/leave protected-mode and paging (setting GDTR, CR0, CR3 and CR4 registers ). That's indeed some overhead.

However, an increase of the "chunk" size to, let's say, 32kB will probably not help much, because I don't think that RDISK calls the XMS block move with such large sizes.

What can be done is to implement the new features into JemmEx. Inside the v86-monitor, there's no need to enter/leave protected-mode and setting/resetting the control registers. Then one could compare the speeds.

[edit]
I did some tests on my own and cannot confirm your results. I get a slowdown of 20% for RDISKSX compared to RDISK ( 60ms vs 48ms ) for writing a file of 180 MB. Writing it to HDD needs 6000ms, to SSD 2500ms. I used a self-written DPMI32 app to copy the file, Smartdrv was loaded.
[/edit]

---
MS-DOS forever!

> I compiled HimemSX with JWASM and it works, with interesting results.

I have not tried this. Would it even work on a "lowly" 4 GB RAM laptop?? Though it does remind me of CandyMan's similar EMS64 hack from a few years ago (2016).

> I also patched the included RDISKSX.COM to allow the creation of up to a
> 4095M ramdrive, from 2047M. Above 2048M, the ramdrive is created as FAT16
> with the 64-kb cluster size. Beyond 4GB for ramdrive is impossible without
> a FAT32 ramdrive for DOS and / or sector size > 512 bytes.

Who was it that first supported 64 kb clusters in FAT16, was it NT 4.0? (Well, FAT32 wasn't added to NT until Win2k, right?)

> Of course, it is impossible to write a file of >2047M because of the
> signed 32-bit limit in filelength. Or, is there some patch to DOS
> which will allow the creation the file to its 32-bit unsigned
> maximum value of 4096M-1 byte?

I could be wrong, but I believe Win9x (not sure when) supported 4 GB files in limited ways, e.g. you had to create them with int 21h, 716Ch only. DJGPP "beta" 2.04 had some support for this, allegedly. Unfortunately, I don't think NT (XP, etc.) ever supported those sizes (at least not for DOS APIs). Also, FreeDOS (IIRC) still doesn't either due to "signed long" bugs (hence max file size is still 2 GB there even on FAT32).

Jack has asked me to convey the following message:

> HimemSX as written has some SERIOUS "issues". Its "block move"
> call cannot be used in "V86" mode, or the PC will CRASH! Aside
> from DOS Extenders or packages like DJGPP, "regular" DOS systems
> still use either real-mode or "V86" protected-mode set by JEMMEX
> or JEMM386. Many users may be VERY upset at losing "V86" mode!

> HimemSX's "block move" function also uses 8K-byte "move windows"
> during which it goes in-and-out of the mode which handles "high"
> XMS memory. This is also done in a normal XMS driver for real-
> mode moves, that require a switch to protected-mode (or "unreal"
> mode) to move XMS data. But, 8K-byte blocks are NOT needed for
> "V86" moves, since JEMM386/JEMMEX "know how" to leave interrupts
> ENABLED across the entire move!

> And what about "special" drivers, e.g. XHDD? Since 2007, UIDE/
> XHDD have called the XMS manager only to "get" memory or enable/
> disable the "A20" line. All actual XMS moves are done by logic
> in the caching drivers, as any XMS manager must do lots of ERROR
> checks on every XMS request. Such checks DESTROY speed and are
> never necessary, after a driver has been DEBUGGED!

> What is needed is to update the "Int 15h, AH-87h" request within
> JEMM386/JEMMEX to support "high XMS" memory. If done properly,
> DOS systems will NOT lose "V86" mode, and "special" drivers like
> XMGR or XHDD should need only minor changes (adding a "high XMS"
> page number, etc.). This minimizes the changes needed in other
> drivers (XDVD2, RDISK, etc.) and programs which do "call the XMS
> manager" for XMS moves, thus reducing their own logic.

> I would accept updated JEMM386/JEMMEX drivers with such changes.
> And I would accept updating XMGR/XHDD to work with such drivers,
> also updating XDVD2/RDISK to call an updated XMGR, HimemSX, etc.
> which issue updated "Int 15h, AH-87h" requests, then let JEMM386
> or JEMMEX handle the actual protected-mode move, as they do now.

> But unless it is only a "proof of concept", HimemSX is the WRONG
> place to do "high XMS" moves! XMGR and XHDD will NEVER give up
> 13 years of FAR more general-purpose logic, "V86" protected-mode
> and MUCH faster speed, only to use HimemSX as it is now written!
> One can expect MANY other DOS developers might feel the same!

> Jack R. Ellis

---
Glory to God for all things

> > I compiled HimemSX with JWASM and it works, with interesting results.
>
> I have not tried this. Would it even work on a "lowly" 4 GB RAM laptop??
> Though it does remind me of CandyMan's similar
> EMS64 hack
> from a few years ago (2016).
>
> > I also patched the included RDISKSX.COM to allow the creation of up to a
> > 4095M ramdrive, from 2047M. Above 2048M, the ramdrive is created as
> FAT16
> > with the 64-kb cluster size. Beyond 4GB for ramdrive is impossible
> without
> > a FAT32 ramdrive for DOS and / or sector size > 512 bytes.
>
> Who was it that first supported 64 kb clusters in FAT16, was it NT 4.0?
> (Well, FAT32 wasn't added to NT until Win2k, right?)

Correct, but MS-"DOS" 7.1 does support 64-kb clusters just fine for me, as evidenced by the fact that I was able to create a 4GB ramdrive, read and write to it without errors, with a max filesize of 0x7FFFFFFF

>
> > Of course, it is impossible to write a file of >2047M because of the
> > signed 32-bit limit in filelength. Or, is there some patch to DOS
> > which will allow the creation the file to its 32-bit unsigned
> > maximum value of 4096M-1 byte?
>
> I could be wrong, but I believe Win9x (not sure when) supported 4 GB files
> in limited ways, e.g. you had to create them with int 21h, 716Ch only.
> DJGPP "beta" 2.04 had some support for this, allegedly. Unfortunately, I
> don't think NT (XP, etc.) ever supported those sizes (at least not for DOS
> APIs). Also, FreeDOS (IIRC) still doesn't either due to "signed long" bugs
> (hence max file size is still 2 GB there even on FAT32).

Yes, I remember the Win98 DOS API *does* support reading and writing of unsigned long integer filesizes between 2GB and 4GB. Why are "signed long" integers even necessary for filesize lengths? You can't have a negative filesize, so we've wasted the high bit, thereby depriving ourselves of "2-4 GB" filesizes access in DOS. I've wondered why FreeDOS hasn't fixed this bug. Implement int 21h and 716Ch access without a signed long limit. This could work even on FAT16 drives with 64-kb clusters.

> [edit]
> I did some tests on my own and cannot confirm your results. I get a
> slowdown of 20% for RDISKSX compared to RDISK ( 60ms vs 48ms ) for writing
> a file of 180 MB. Writing it to HDD needs 6000ms, to SSD 2500ms. I used a
> self-written DPMI32 app to copy the file, Smartdrv was loaded.
> [/edit]

My results differ greatly. I wish I only got a 20% slowdown. Results using the "disk benchmark" feature of SPINRITE for DOS on 2048M RDISK.COM and normal XMS calls: 1.57 GB / sec burst transfer rate, and with RDISKSX 53.5 MB/sec burst transfer. Even things like decompressing a 200MB ACE / ZIP / RAR file are slowed significantly. With normal XMS calls, file decompresses in 8.1 sec, with HIMEMSX XMS calls, file takes 11.7 sec. to decompress, due to slowed RDISKSX throughput in calling XMS beyond 4GB barrier.

May you suggest a DOS diskbenchmark program which makes 32-bit calls and / or provide the program you used for your results?

You may download my compiled version of HIMEMSX and RDISKSX at this link:
https://mega.nz/file/EJYGhBQQ#B_DffctKl9Ao-H14RrG9VgDPKqW2k1WTX8KzF8IVHBI

Perhaps I somehow miscompiled, but I think everything went perfectly well. My HIMEMSX.EXE is 6750 bytes.

These results are on a clean boot, with only HIMEMSX and RDISKSX loaded. For A20 option, I used /METHOD:FAST, but all other options on HIMEMSX default.

My only current system with > 4GB RAM is this one I'm testing, a Lenovo laptop with 8GB dual-channel DDR3 RAM, and i5 5200 CPU.

Not sure of other systems, or if the problem is specifically my laptop BIOS / localized hardware, etc.

Hello Jack,

first, thanks for your RDISK utility, which doesn't use "unreal"-mode and therefore was a very good candidate for HimemSX test!

> > HimemSX as written has some SERIOUS "issues". Its "block move"
> > call cannot be used in "V86" mode, or the PC will CRASH!

It may crash, true. However, with the patched RDISK I only get a simple I/O error when accessing the ramdisk after Jemm386 is loaded. And after Jemm386 has been unloaded, access to the ramdisk is possible again.

> > What is needed is to update the "Int 15h, AH-87h" request within
> > JEMM386/JEMMEX to support "high XMS" memory. If done properly,
> > DOS systems will NOT lose "V86" mode, and "special" drivers like
> > XMGR or XHDD should need only minor changes (adding a "high XMS"
> > page number, etc.).

True. It's already mentioned in the HimemSX readme.txt: "It's planned to extend Jemm386 so that HimemSX's function 0Bh will fully work together with Jemm386 in the future."

> > But unless it is only a "proof of concept", HimemSX is the WRONG
> > place to do "high XMS" moves!

No, since I prefer "UMBPCI/XMS-only" systems these days.

I should probably mention: the main reason for development of HimemSX was to allow full usage of a system's RAM for 64-bit apps, using dos64stb. The "super-extended" block move feature was just a "goodie".

---
MS-DOS forever!

> May you suggest a DOS diskbenchmark program which makes 32-bit calls and /
> or provide the program you used for your results?

https://github.com/Baron-von-Riedesel/HimemSX/tree/master/Test

> You may download my compiled version of HIMEMSX and RDISKSX at this link:
> https://mega.nz/file/EJYGhBQQ#B_DffctKl9Ao-H14RrG9VgDPKqW2k1WTX8KzF8IVHBI

Probably more interesting would be the benchmark program you are using for download.

---
MS-DOS forever!

> > May you suggest a DOS diskbenchmark program which makes 32-bit calls and
> /
> > or provide the program you used for your results?
>
> https://github.com/Baron-von-Riedesel/HimemSX/tree/master/Test
>
> > You may download my compiled version of HIMEMSX and RDISKSX at this
> link:
> >
> https://mega.nz/file/EJYGhBQQ#B_DffctKl9Ao-H14RrG9VgDPKqW2k1WTX8KzF8IVHBI
>
> Probably more interesting would be the benchmark program you are using for
> download.

Sure, the "benchmark" utility is just Gibson's SPINRITE v. 6.0. Under its settings, there is an option to "benchmark selected partition" which seems to be pretty good and thourough. I uploaded it at this link for you to test:

https://www.grc.com/spinrite.htm

This is where I get the 1.5GB/sec RDISK vs. the 53 MB/sec RDISKSX results.

EDIT: With Himemsx.exe loaded, and using your "copy" utility, I get the following results for a 768M file on a 1536M Ramdisk:

RDISK.COM: 303 ms read, 269 ms write
RDISKSX.COM: 13713 ms read, 9736 ms write

This is copying the file directly to the Ramdisk. not to an SSD or hard drive.

I'm still perplexed as to the vast disparity in XMS below / above 4GB barrier!

> I'm still perplexed as to the vast disparity in XMS below / above 4GB
> barrier!

I guess your machine has 4 GB true RAM only, and anything above 4 GB is emulated by SMM code, backuped by hard disk space.

---
MS-DOS forever!

> > I'm still perplexed as to the vast disparity in XMS below / above 4GB
> > barrier!
>
> I guess your machine has 4 GB true RAM only, and anything above 4 GB is
> emulated by SMM code, backuped by hard disk space.

It is a joke or it can be true on some systems?

---
DOS-u-akbar!

I think he's joking due to the speed, similar to cheap chinese e.g. 128GB USB flash drives that had real 4GB (e.g.) and rest would overwrite from the beginning, just kind of WOM (Write Only Memory).

BTW it would be great to implement it in JEMM(EX) to make it compatible with V86 mode.

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

My Win98SE and XP-SP3 can both work with up to 4GB files on FAT32 volumes but I have them heavily patched by various official and unofficial updates so I'm not sure if it can handle that in vanilla MS OS version.
I didn't tried manipulate with 2+ GB files by dos tools under 98/XP.
But for compatability reason I rather prefer to e.g. split multivolume archives to 2GB parts.

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

> Why are "signed long"
> integers even necessary for filesize lengths? You can't have a negative
> filesize, so we've wasted the high bit, thereby depriving ourselves of "2-4
> GB" filesizes access in DOS.

If you only have signed types, you don't need unsigned helpers (libgcc or equivalent), which keeps library size down.

This might have been a factor in the early days, and then simply stuck as DOS/win9x platform grew

> > I'm still perplexed as to the vast disparity in XMS below / above 4GB
> > barrier!
>
> I guess your machine has 4 GB true RAM only, and anything above 4 GB is
> emulated by SMM code, backuped by hard disk space.

It is indeed strange, as memory > 4GB access in Win10 and Linux is at normal fast speed... At moment, I only have this laptop with > 4GB RAM. I'm going to configure one of my other systems with 8 GB, just for the purposes of seeing if HIMEMSX runs as slowly on them, also... I'll report back of course.

BTW: a very good use for long-unsigned filesizes in true DOS would be to play 2 to 4 GB .VOB files with Khusraw's wonderful DJGPP MPLAYER DOS port. That's what I used to do in Win98's DOS API (and how I know that it supports long unsigned filesizes), and it would play these files in Win98 with the DOS port, but not in true DOS.

> I'm
> going to configure one of my other systems with 8 GB, just for the purposes
> of seeing if HIMEMSX runs as slowly on them, also... I'll report back of
> course.

That's a good idea.

I uploaded my XMS tools, which I use to test Himem(S)X, to GitHub. They already know HimemSX. With tool XMSCopy you can directly copy from file/EMB to file/EMB, avoiding RDISKSX.

---
MS-DOS forever!

> > I'm
> > going to configure one of my other systems with 8 GB, just for the
> purposes
> > of seeing if HIMEMSX runs as slowly on them, also... I'll report back of
> > course.
>
> That's a good idea.
>
> I uploaded my XMS
> tools, which I use to test Himem(S)X, to GitHub. They already know
> HimemSX. With tool XMSCopy you can directly copy from file/EMB to file/EMB,
> avoiding RDISKSX.

My problem seems solved, with a caveat.

The trouble was RayeR's MTRRLFBE utility which enabled Linear Framebuffer writecombine caching to speed up VESA graphics by ~2500% on my system. Upon disabling Writecombining cache to LFB frame, according to MTRRLFBE lfb WC /d
Host machine CPU vendor: GenuineIntel, ID: 306D4h

VESA 3.0 Intel(R) HSW Mobile/Desktop Graphics Chipset Accelerated VGA BIOS [32704 kB]
N/A
N/A
N/A
LFB address: B0000000h
MTRR #0: base = 000000000h ( 0MB), mask = F80000000h ( 2048MB), WB, used
MTRR #1: base = 09D000000h ( 2512MB), mask = FFF000000h ( 16MB), UC, used
MTRR #2: base = 09E000000h ( 2528MB), mask = FFE000000h ( 32MB), UC, used
MTRR #3: base = 0A0000000h ( 2560MB), mask = FE0000000h ( 512MB), UC, unused
MTRR #4: base = 0C0000000h ( 3072MB), mask = FC0000000h ( 1024MB), UC, used
MTRR #5: base = 0B0000000h ( 2816MB), mask = FFF000000h ( 16MB), WC, used
MTRR #6: base = 080000000h ( 2048MB), mask = FE0000000h ( 512MB), WB, used
MTRR #7: base = 000000000h ( 0MB), mask = 000000000h ( 0MB), UC, unused
MTRR #8: base = 000000000h ( 0MB), mask = 000000000h ( 0MB), UC, unused
MTRR #9: base = 000000000h ( 0MB), mask = 000000000h ( 0MB), UC, unused
Setting MTRR #5 to desired area...
MTRR area B0000000-B0FFFFFFh was set to mode: WC

My HIMEMSX speed was reduced to ~50 mb/sec, but when I disable WC on the LFB, I got over 2000 mb/sec:
file size: 767578 kB
time for read: 395 ms
time for write: 361 ms

using rdisksx

This compares to:
file size: 767578 kB
time for read: 313 ms
time for write: 277 ms

for normal RDISK with normal XMS calls, which is about 20.8% slower, as confirmed by your initial tests.

I should have known LFB conflicts somehow with HIMEMSX, and so we can't speed up VESA graphics with XMS memory > 4 GB available and utilized.

Perhaps RayeR can explain this further...

I tested himemxs and rdisksx on my system and it works as expected. BTW normal rdisk when loaded it cause me every DJGPP program will crash on Page Fault while with rdisksx they works fine.
I have only 4GB physical RAM but thanks to BIOS enabled some remapping I have ~450MB of usable RAM beyond 4GB that would be overlapped by MMIO. I can install 400MB rdisksx, speed seems to be ~400MB/s and when I load MTRRLFBE the speed doesn't change.
I can imagine one reason - if MTRR would be manipulated that way it disable Write Back caching for region 4GB-END then it would run in very slow uncached mode. But from your debug listing I cannot see that any other MTRR was touched than #5 that seems to be correctly set to WC without touching anything other. It's strange that in the listing I cannot see any MTRR that would cover 4GB+ range with WB so the rdisksx should be slow also before MTRRLFBE. Try to run MTRRLFBE twice if second debug print show something different. Or run MTRRLFBE first for vga range, it should then not touch veriable MTRRs only prints them.

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

> "...will fail if cpu is in v86-mode..." :(
> Is is technically possible to overcome this obstacle when acessing beyond
> 4GB and make it compatible with V86 mode?

Yes, of course. Today I updated Jemm386 on github (new v5.8 prerelease) - it has now an extended Int 15h, ah=87h emulation that allows HimemSX to access up to 1 TB in v86-mode.

---
MS-DOS forever!

I tried new version but it doesn't work for me. I load:

DEVICE=C:\DOS\HIMEMSX.EXE /METHOD:FAST /NUMHANDLES=64 /VERBOSE
DEVICE=C:\DOS\JEMM386.EXE SPLIT FASTBOOT VERBOSE

The XMSSTAT sees the super-extended area:

XMS call address: 29b:83e
XMS version: 3.50, driver version: 3.80
HMA handled by XMS host, HMA is allocated
v2 free memory largest/total (kB): 65535/65535
v3 free memory largest/total (kB): 3594344/3594344, highest addr: df78ffff
v3.5 free memory > 4GB largest/total (kB): 507904/507904
XMS handle table at 29b:38, handle cnt/size=96/10
XMS handle array at 29b:890

 no handle   region              size(kB) locks  flags
------------------------------------------------------------
  1  890    004176000- 0df78ffff  3594344    0   1 free
  2  89a    100000000- 11effffff   507904    0   1 free
  3  8a4    000111000- 00014dfff      244    1   2 used
  4  8ae    00014e000- 004175fff    65696    2   2 used
------------------------------------------------------------
                                  4168188 (3660284 kB below 4G)
free handles: 92
no free UMBs available


but rdisksx cannot create ramdisk there.
And there's another problem that running any DJGPP program cause JEMM to crash: http://www.rayer.g6.cz/1tmp/jemm.jpg

When I replace HIMEMSX by normal HIMEMX it doesn't crash (and of course don't have SXMS). When I load HIMEMSX without JEMM then rdisksx and DJGPP progs work OK.

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

> I tried new version but it doesn't work for me. I load:

You need the newest HimemSX, of course. Did you download the source and create it?

> but rdisksx cannot create ramdisk there.

You need to be a little bit more specific. What does rdisksx tell you exactly?

---
MS-DOS forever!

No, you didn't mention that himemsx was updated too.
I mean XMS init error as on sceenshot.
I'll try tonight...

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

> > "...will fail if cpu is in v86-mode..." :(
> > Is is technically possible to overcome this obstacle when acessing
> beyond
> > 4GB and make it compatible with V86 mode?
>
> Yes, of course. Today I updated Jemm386 on github (new v5.8 prerelease) -
> it has now an extended Int 15h, ah=87h emulation that allows HimemSX to
> access up to 1 TB in v86-mode.

Thank you! I compiled new HIMEMSX.EXE (10-27-2020), size of new binary is 6666 bytes! This version works well for me in v86 mode, on preliminary tests, I can invoke RDISKSX /s4095, and get a 4gb ramdisk which will write without access errors, at excellent speed, about 1.5 gb per second.

(but unfortunately I still must disable write combining on my linear framebuffer VESA graphis, but enabling write combining for VGA area by MTRRLFBE or fastvid works, greatly enhances VGA speed, with NO slowdown of HIMEMSX, or JEMMEX).

Well, I built new himemsx and tried again. Now rdisksx loads with jemm at full SXMS capacity available. But I still have problem with crashing jemm when running DJGPP apps (need hard reset). Funny is that they don't crash when rdisksx is loaded, only when I run them without rdisksx...

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

> full SXMS capacity available. But I still have problem with crashing jemm
> when running DJGPP apps (need hard reset).

I also have problems with DJGPP apps (at least on my Ryzen), but they crash no matter what memory manager (himemx, himemsx with/without EMM) or DPMI host ( cwsdpmi5, cwsdpmi7, hdpmi32 ) is loaded . It's a page fault, however, and they simply exit to DOS. And it's not a problem of cwsdpmi, because the FreePascal binaries run without issues.

EDIT: I reinstalled djgpp and now it works fine, no crash. Doesn't matter if I run it with HimemSX alone or various combinations of HimemSX/Jemm386/RDisk/RDiskSX.

---
MS-DOS forever!

What do you mean by reinstall DJGPP? It's just unpacking of zip packages and settion one env.var to djgpp.env file.

In my case the crash is by jemm before the app can print anything itself, I got this nice matrix waterfall screensaver :)
http://www.rayer.g6.cz/1tmp/jemm.jpg
I also tried some FPC program (Laaca's blocek) and crashes too.

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

> What do you mean by reinstall DJGPP? It's just unpacking of zip packages
> and settion one env.var to djgpp.env file.

Yes, I missed the environment setting.

> I also tried some FPC program (Laaca's blocek) and crashes too.

Ok, so the first thing to find out is whether it's a generic problem with cwsdpmi. Run cwsdpmi manually and then start a very simple DPMI app (dpmi.exe from hdpmi32, for example). Does this crash as well? Will the DJGPP/FPC programs also crash if you install hdpmi32.exe before launching them?

---
MS-DOS forever!

> Yes, I missed the environment setting.

I think it's important only for DJGPP toolchain not for standalone apps.

Seems to be problem with cwsdpmi...
cwsdpmi -r - OK
ls.exe - crash

hdpmi32 -r - OK
ls.exe - OK

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

> Seems to be problem with cwsdpmi...
> cwsdpmi -r - OK
> ls.exe - crash
>
> hdpmi32 -r - OK
> ls.exe - OK

For me cwsdpmi works. No idea why it crashes on your system. You must do something wrong

You can try newest JemmEx v5.80 prerelease. Support for XMS v3.5 has been added recently. Perhaps it works on your machine ...

---
MS-DOS forever!

I compiled the latest version of himemsx and jemm, I also simplified my boot config so only himem and jemm was loaded, nothing else but still the same (with jemmex too), except jemm crash is printed only once:

http://www.rayer.g6.cz/1tmp/jemm.jpg

I tried also cwsdpr0 -r and also the same.
(with HDPMI it works as before).

Jemmexl works (no SXMS, no crash).

UPDATE:
I found that also some other non-DJGPP programs have problem, e.g. Borland Turbo Debugger 4.0. It just hangs, no error displayed. I think TD doesn't use DPMI, sure it doesn't load cwsdpmi.exe

Then I found another interesting thing. When I run and exit DOS Navigator Opensource after boot then I can run DJGPP programs. I found there's a difference before/after DN run via xmsstat that reported more XMS handles created/used (BTW isn't it DN's memory leak when it doesn't free some handle?) maybe a hint...

before DN:


XMS call address: 29b:866
XMS version: 3.50, driver version: 3.80
HMA handled by XMS host, HMA is allocated
v2 free memory largest/total (kB): 65535/65535
v3 free memory largest/total (kB): 3594344/3594344, highest addr: df78ffff
v3.5 free memory > 4GB largest/total (kB): 507904/507904
XMS handle table at 29b:34, handle cnt/size=64/10
XMS handle array at 29b:8b8

 no handle   region              size(kB) locks  flags
------------------------------------------------------------
  1  8b8    004176000- 0df78ffff  3594344    0   1 free
  2  8c2    100000000- 11effffff   507904    0   1 free
  3  8cc    000111000- 00014dfff      244    1   2 used
  4  8d6    00014e000- 004175fff    65696    2   2 used
------------------------------------------------------------
                                  4168188 (3660284 kB below 4G)
free handles: 60
no free UMBs available


after DN start&exit:


XMS call address: 29b:866
XMS version: 3.50, driver version: 3.80
HMA handled by XMS host, HMA is allocated
v2 free memory largest/total (kB): 65535/65535
v3 free memory largest/total (kB): 3591382/3594334, highest addr: df78ffff
v3.5 free memory > 4GB largest/total (kB): 507904/507904
XMS handle table at 29b:34, handle cnt/size=64/10
XMS handle array at 29b:8b8

 no handle   region              size(kB) locks  flags
------------------------------------------------------------
  1  8b8    00445a800- 0df78ffff  3591382    0   1 free
  2  8c2    100000000- 11effffff   507904    0   1 free
  3  8cc    000111000- 00014dfff      244    1   2 used
  4  8d6    00014e000- 004175fff    65696    2   2 used
  6  8ea    004176000- 004457fff     2952    0   1 free
  8  8fe    004458000- 00445a7ff       10    0   2 used
------------------------------------------------------------
                                  4168188 (3660284 kB below 4G)
free handles: 58
no free UMBs available


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

> Jemmexl works (no SXMS, no crash).

Ok, I guess "jemmex.exe MAXS3XT=0" will also work? [I had to "obfuscate" the option to make the forum sw swallow it ]

I see that you run cwsdpmi v7. Does cwsdpmi v5 work?

> I found that also some other non-DJGPP programs have problem, e.g. Borland
> Turbo Debugger 4.0. It just hangs, no error displayed. I think TD doesn't
> use DPMI, sure it doesn't load cwsdpmi.exe

My version of TD (1996) is a DPMI16 client. In v86mode it exits with "unhandled exception 0x000e" when I try to start it (and it also forgets to release XMS handles). It runs on my machine if I install HDPMI16.exe first.

Edit: it seems to be a problem with too much VCPI memory for Borland's DPMI16BI.OVL DPMI host - setting JemmEx option MAX=32M makes the exceptions disappear on my machine.

> Then I found another interesting thing. When I run and exit DOS Navigator
> Opensource after boot then I can run DJGPP programs. I found there's a
> difference before/after DN run via xmsstat that reported more XMS handles
> created/used (BTW isn't it DN's memory leak when it doesn't free some
> handle?) maybe a hint...

Yes, that may help.

---
MS-DOS forever!

I also recomend the option MAX=32. I don't remember the details but in the past it also fixed some my compatibility problems.

---
DOS-u-akbar!

> I can imagine one reason - if MTRR would be manipulated that way it disable
> Write Back caching for region 4GB-END then it would run in very slow
> uncached mode.

> But from your debug listing I cannot see that any other MTRR
> was touched

There's the SYSCFG msr, which may determine ( at least on AMD systems, haven't checked Intel as of yet ) how the cpu sees memory beyond 4 GB (bit 22 of SYSCFG).

I uploaded SetMtrr (my old VesaMtrr tool, now renamed) to github. It may give a hint.

---
MS-DOS forever!

Intel doesn't seems to have any SYSCFG MSR but its MTRRs can be set in whole range of physical address (36/40bit).

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

I did some more tests:

CWSDPMI 1 to 6 - same as with 7

MAX=32M doesn't make TD working with SXMS but I didn't need this option without using SXMS, it ran fine. Loading hdpmi16 -r makes TD run also wit SXMS (same as hdpmi32 -r helps DJGPP programs)

MAXS EXT=0 (no S.e.x, drugs & rocknroll!) option works same as using jemmexl, as expected...

Then I play with XMStools\xmsalloc and xmsfree to simulate the condition after DN start&exit. I can simulate it by e.g.
xmsalloc 512
xmsalloc 1
xmsfree [handle of 512k block]

then I got such XMS handles list:

 no handle   region              size(kB) locks  flags
------------------------------------------------------------
  1  8b8    0041f6400- 0df78ffff  3593831    0   1 free
  2  8c2    100000000- 11effffff   507904    0   1 free
  3  8cc    000111000- 00014dfff      244    1   2 used
  4  8d6    00014e000- 004175fff    65696    2   2 used
  5  8e0    004176000- 0041f5fff      512    0   1 free <- allocated and freed by me
  6  8ea    0041f6000- 0041f63ff        1    0   2 used <- allocated by me
------------------------------------------------------------
                                  4168188 (3660284 kB below 4G)
free handles: 58
no free UMBs available


This is enough to make DJGPP programs run. I guess that CWSDPMI is trying to reuse freed handle 8e0 instead of handles 8c2 or 8b8 and it makes it happy. When I free handle 8ea it also removes handle 8e0 and I got crash. When I allocate only a few kB for 8e0 then it also crashes. Allocating only one block doesn't help, BTW in case of hdpmi32 -r I can see this list:


 no handle   region              size(kB) locks  flags
------------------------------------------------------------
  1  8b8    00784e000- 0df78ffff  3538184    0   1 free
  2  8c2    100000000- 11effffff   507904    0   1 free
  3  8cc    000111000- 00014dfff      244    1   2 used
  4  8d6    00014e000- 004175fff    65696    2   2 used
  5  8e0    004176000- 00784dfff    56160    1   2 used
------------------------------------------------------------
                                  4168188 (3660284 kB below 4G)
free handles: 59
no free UMBs available


Do you have some debug tool that could trap XMS calls and log them? It could help to see what CWSDPMI is doing with it...

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

> This is enough to make DJGPP programs run. I guess that CWSDPMI is trying
> to reuse freed handle 8e0 instead of handles 8c2 or 8b8 and it makes it
> happy.

But cwsdpmi has no control about what handle it is to receive or what free block the XMM is using to satisfy the request. For allocations, the XMM has no "best fit" strategy, it always uses the first free block that's large enough.

What's that handle 8d6 (65696 kb)? Who has allocated it? It might be an application that uses more memory than allocated, thus trashing the adjacent memory...

> Do you have some debug tool that could trap XMS calls and log them? It
> could help to see what CWSDPMI is doing with it...

Jemm has a debug version, with selective displays, one could create a version that displays xms calls onto the screen. It can't write to a file, though.

---
MS-DOS forever!

> What's that handle 8d6 (65696 kb)? Who has allocated it? It might be an
> application that uses more memory than allocated, thus trashing the
> adjacent memory...

It is Jack's XHDD cache. I remember that I had some issues with my BIOS virtual DMA and I use XHDD to fix it. When I don't load XHDD then non-realmode dos programs hangs when accessing disk. This problem is only in V86 mode.

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

> Do you have some debug tool that could trap XMS calls and log them? It
> could help to see what CWSDPMI is doing with it...

I scrutinized cwsdpmi's behavior. It looks like cwsdpmi in v86 uses VCPI only to allocate memory, XMS isn't used at all. That isn't optimal, since VCPI memory is restricted; see the MAX=xxx option in jemm, default is 128M, best compatibility is 32M. cwsdpmi still works if VCPI mem is out, but only because of its swapfile usage, decreasing speed.

I checked Jemm's EMS/VCPI memory handling and found a bug, which might have caused the troubles. There's a chance that the newest prerelease fixed the issue:

https://github.com/Baron-von-Riedesel/Jemm/releases/download/v5.80pre8/JemmB_v580pre8.zip

---
MS-DOS forever!

> I uploaded
> SetMtrr (my old
> VesaMtrr tool, now renamed) to github. It may give a hint.

The -cA000-BFFF option on my Intel processor makes some programs not working. For example, a mario game that uses A000-AFFF memory as a buffer displays "artifacts". Other programs, including text programs, blink.
Fortunately, you can go back to the standard settings (option -uA000-BFFF). Everything worked fine on the previous computer (AMD processor).

> can install 400MB rdisksx, speed seems to be ~400MB/s

that's actually suspiciously slow.

raw speed measures on my AMD give me about 4 GB/sec with himemsx alone and 8 GB/sec with himemsx+jemm386/jemmex.

to measure raw xms copy speed, I do:

C:\>xmsalloc -x 1024000 ;allocates about 1 GB s3xt mem
ok, handle 1234
C:\>xmscopy -t :1234 :1234 ;copies block to itself

and get about 250ms with himemsx and 120ms with jemmex.

---
MS-DOS forever!

OK, it would be a better test but I just note that I don't see difference between accessing memory <4GB or >4GB neither if MTRRLFBE used or not.

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

Good job, the pre8 version fixed my problem, thanks!
Now DJGPP programs and also the Turbo Debugger works fine and I didn't see any other issue. What was the problem in VCPI of JEMM you found?

Why is CWSDPMI prefering using VCPI? It could call XMM same way as in realmode, couldn't it? And what if is in v86 mode but VCPI not available at all? Also it should have option if there's any XMM but I don't know details about how it handles memory in what conditions.
Would it be easy to change CWSDPMI preference on this? I should check some get max dpmi mem in DJGPP... I think that CWSDPMI v6 and 7 should handle more memory than v5 if I remember...

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

> What was the problem in VCPI of JEMM you found?

The VCPI/EMS memory-pool code directly modifies the XMS handle array. It wasn't adjusted yet to the new 3.5 version.

> And what if is in v86 mode but VCPI not available at all?

Then it has to give up - it can't even switch to pmode.

---
MS-DOS forever!

Is possible to write some tool which would try to provocate the crash/freeze/restart?
It could be useful for testing paramaters like I=mmmm-nnnn

---
DOS-u-akbar!

I just digged a bit about cwsdpmi and VCPI / XMS and it seems neither is optimal. Also for some old programs I wanna have VCPI by default in my DOS config.
CWSDPMI & RM-XMS
+ more memory available, 4MB pages
- CWSDPMI get all available XMS and when you nested-execute other DJGPP program from your caller DJGPP or XMS-using program it will not left enough memory for it.

CWSDPMI & VCPI
+ no problem with nested calling
- VCPI mem. limitations (mostly by old EMM386 to 32MB or even worse some older only 256kB)
- no 4MB pages
- interesting problem reported here: https://groups.google.com/forum/#!topic/comp.os.msdos.djgpp/4UkalDo_tO8 EMM386 from Win98 under MSDOS 7.1 ambiguously rported VCPI is installed even with NOVCPI, NOEMS at command line that drives CWSDPMI crazy to silent exit.

I also read that CWSDPMI is able to switch to use XMM when available VCPI memory is exhausted. I looked in source valloc.c at line 192 there's a check:

if (vcpi_capacity()) {
      use_vcpi = 1;
      SHOW_MEM_INFO("VCPI memory: %ld Kb", (vcpi_capacity() * 4L));
    } else if(use_xms) {
      use_vcpi = 0;     /* Just in case multiple pass with all allocated */
      xms_alloc_init(); /* Use XMS memory with VCPI mode switch */
}


So it would be easy to modify code to always pass to XMM (but it doesn't solve XMS exhaust).

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

> Is possible to write some tool which would try to provocate the
> crash/freeze/restart?

You mean the jemmex problems with cwsdpmi up to v5.80 pre8? Yes:

1. allocate all free "legacy" XMS blocks (<4GB) using tool xmsalloc, so that only the block beyond 4 GB is "free".
2. run the program that allocates a lot of VCPI/EMS pages.

---
MS-DOS forever!

I was able to compile modified cwsdpmi with disabled vcpi and now DJGPP programs sees ~3,5GB like with disabled VCPI in JEMM.

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

> - CWSDPMI get all available XMS and when you nested-execute other DJGPP
> program from your caller DJGPP or XMS-using program it will not left enough
> memory for it.

Actually, cwsdpmi just grabs the largest free block - on my system with scattered ext. memory there's still left some free mem.

Also, the cwsdpmi host can handle multiple clients, so nested execution probably don't needs additional extended memory.

---
MS-DOS forever!