DOS ain't dead

(forwarding from news://comp.os.msdos.programmer for Rod Pemberton, 24 Oct. 2011):

(Part One of Two):

In another thread, I previously stated:

> Memory is capped at 1GB for WinSE by HIMEMX, but full 4GB
> should be available in MS-DOS. I've not confirmed though.

and,

> Actually, after playing around a bit with HIMEMX. It now recognizes 2GB
> after adding /NUMHANDLES=128 to it's config.sys line. WinSE is capped
> to 1GB via "MaxPhysPage=3FFFF" in system.ini.

> I'm not sure why HIMEMX isn't mapping more memory.

Well, I now know why I wasn't getting more memory with HIMEMX. It wasn't
HIMEX that was the problem ...

HIMEMX v3.32 (Japheth's 2007 fixes) maps all XMS memory that's available.
That's 4GB minus 768MB or so for via MMIO (video card), PCI bus, and BIOS
mapping which leaves about 3.2 or 3.4GB. However, I was using Franck
Uberto's XMSDSK (v1.9i) to setup a 100MB ramdisk. It reports just over
100MB by DIR. However, Japheth's XMSSTAT (in his JEMM package) shows it's
allocating a total of 1GB! It's allocating 10x as much as it should! I
confirmed the allocation with another XMS status program called XMSTAT. It
also seems to use about 60 XMS file handles, eventually freeing 30 of those.
XMSDSK also has problems if XMS is not capped at 2GB or less. We can guess
why now ...

I did find a 3.33 patch for HIMEMX here that Japheth apparently missed:
http://www.bttr-software.de/forum/board_entry.php?id=6445

That patch has 3 corrections, and 2 errors - 2 unecessary text lines ...
The comments mentions another fix for DRIVER_VER. And, I found one other
error. The second driver version value should be in hex also. This error
is in 3.32 too. v3.32 reports version 3.20 instead of 3.32 because of it.
E.g.,

DRIVER_VER equ 300h+33h

Japheth's HIMEMX and JEMM
http://www.japheth.de/Jemm.html

Unfortunately, I'm not able to rebuild HIMEMX correctly. I had to use
JWasm v2.05 v with OpenWatcom's Wlink from v1.3 instead of the recommended
utilities. That combination produces an incorrect exe header which causes
the info screen to display incorrectly. I'll be attempting to locate the
incorrect memory for the older machine, i.e., 64MB vs 256MB problem, with
HIMEMX shortly. I suspect HIMEMX may need another BIOS call to query
memory.

XMSDSK is on Simtel and other sites. I hope somebody fixes it. Marko
Kohtala's SRDISK didn't seem to work with WinSE ... Can someone else
suggest an XMS ramdisk that works for both (DOS, WinSE)?

Rod Pemberton

=======================================

(Part Two of Two):

I've confirmed that the massive allocation issue is with XMSDSK. I usually
use XMSDSK like so:

XMSDSK 102400 E: /C1 /T /Y

The problem with XMSDSK is with the /T option. With /T, XMSDSK allocates
1GB for a 100MB ramdisk, at least from HIMEMX ... It allocates at the top
of memory which allows WinSE to boot and use the ramdisk. Without /T,
XMSDSK allocates 100MB for a 100MB ramdisk. However, WinSE won't
boot when the ramdisk is allocated low. In both cases, the disk is
accessible to
MS-DOS.

Rod Pemberton

> Unfortunately, I'm not able to rebuild HIMEMX correctly. I had to use

I changed the Himem332.zip file on my site. The Makefile was updated. Optionally, there's now a MAKE.BAT, which uses JWasm without linker.

---
MS-DOS forever!

> I changed the Himem332.zip file on my site. The Makefile was updated.
> Optionally, there's now a MAKE.BAT, which uses JWasm without linker.

BTW why didn't you included the 386sx PM switch patch yet?

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

> BTW why didn't you included the 386sx PM switch patch yet?

I don't know.

Perhaps you are aware that the lion part of a man's decisions are made by instinct. Very often you cannot determine your true motives if you were asked later about the reasons and causality of your decisions. I guess your "why"-question falls into this category.

---
MS-DOS forever!

> Perhaps you are aware that the lion part of a man's decisions are made by
> instinct. Very often you cannot determine your true motives if you were
> asked later about the reasons and causality of your decisions. I guess your
> "why"-question falls into this category.

Oh, I forgot mr. philosoph... I'd like rather to get more straighforward answer like "I didn't have time to do that" or "I don't use 386sx so I don't care" :)
I also have a lot of other work so I have understanding...

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

> Oh, I forgot mr. philosoph... I'd like rather to get more straighforward
> answer like "I didn't have time to do that" or "I don't use 386sx so I
> don't care" :)
> I also have a lot of other work so I have understanding...

IIRC, it was you who hacked and rebuilt it with the patch (unofficially). Yeah, nobody ever updated it, so eventually I just mirrored your build on iBiblio. (To be fair, though, nobody else ever seemed to care, despite it being mentioned several times. Honestly, sad to admit, I guess a lot of people really don't need or use old 386s anymore.)

But anyways, here is Japheth's old reasoning:

> The problem is: I modified this himem thing mainly for myself,
> I don't regard myself as "maintainer". So, since I don't have
> a working 386 computer anymore - and probably also won't buy
> one on Ebay anytime soon -, it might take a while until a
> patch is released.

(part one, 26 Oct. 2011):

> Thanks, or tell him "thank you" for me, if you want. I'll DL that soon.
>
> Unfortunately, I'm delayed for a while at looking into the HIMEMX issue on
> an old machine (64MB vs. 256MB). But, when I do, I may need you to pass on
> the info to Japheth on BTTR.

(part two, 31 Oct. 2011):

> Well, HIMEMX does work correctly for that old machine.
>
> It works with /X. It should work without /X though. I thought I tried /X
> and /NOABOVE16 separately, but I must've tried /X with /NOABOVE16.
>
> The E820h map seems correct to me, so I'm not sure why HIMEMX needs to use
> E801h. Here are the three BIOS memory functions HIMEMX tests returns these
> values in real mode:
>
> INT 15h,AH=88h pass 468KB
> INT 15h,AH=E801h pass 0015360:0245696:0015360:0245696KB
> INT 15h,AH=E820h pass
> 0000000000000000:000000000009F800:001
> 000000000009F800:0000000000000800:002
> 00000000000E7000:0000000000019000:002
> 0000000000100000:0000000003FFD800:001
> 00000000040FD800:0000000000002000:003
> 00000000040FF800:0000000000000400:004
> 00000000040FFC00:000000000BF00400:001
>
> HTH,
>
> Rod Pemberton

> It works with /X. It should work without /X though.
...
> The E820h map seems correct to me, so I'm not sure why HIMEMX needs to use E801h.

> 0000000000000000:000000000009F800:001
> 000000000009F800:0000000000000800:002
> 00000000000E7000:0000000000019000:002
> 0000000000100000:0000000003FFD800:001
> 00000000040FD800:0000000000002000:003
> 00000000040FF800:0000000000000400:004
> 00000000040FFC00:000000000BF00400:001

HIMEMX and old FD Himem stop scanning extended memory once a block starting at 0x100000 has been found. See lines marked with !!! below:


        mov eax,[di].E820MAP.baselow
        cmp eax,100000h ; has to live in extended memory
        setz dl         ;!!!
        jb @@e820_loop

        cmp esi,0
        jne @@e820_checkhole

; we're not able to handle extended base start not exactly at 100000h
;  not big deal to add support later (does this happen, though?)
        cmp dl,1
        jne @@e820_done ;!!!
        mov ebp,eax


I agree this is dumb, but that's exactly why the /X switch exists.

Would be interesting what XMGR does with that configuration.

It's also slightly interesting if the /X switch does really "work". Using Int 15h, ax=E801h, the memory used by ACPI at 0x40FD800 is overwritten once an application uses more that 64 MB. RBIL tells about types 03 and 04:


Values for System Memory Map address type:
 01h    memory, available to OS
 02h    reserved, not available (e.g. system ROM, memory-mapped device)
 03h    ACPI Reclaim Memory (usable by OS after reading ACPI tables)
 04h    ACPI NVS Memory (OS is required to save this memory between NVS


---
MS-DOS forever!

> Would be interesting what XMGR does with that configuration.

Today Jack R. Ellis told me that XMGR is supposed to process both entries with type 01 - and ignore the entries with types 03 and 04.

---
MS-DOS forever!