HIMEMX and XMSDSK

[Rod Pemberton]

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

[Rod Pemberton]

"Rod Pemberton" <do_no...@noavailemail.cmm> wrote in message
news:j84vll$la8$1...@speranza.aioe.org...
>
> In another thread [on comp.os.msdos.programmer], 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'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.

I added comp.os.msdos.misc in case someone there is using these. If you
missed it, there is info on a simple HIMEMX patch and other trivial issues
here:
http://groups.google.com/group/comp.os.msdos.programmer/msg/884a17c989335905


Rod Pemberton

[Rugxulo]

Hi,

On Oct 24, 7:25 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:

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

> 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 took the liberty to quote your posts at BTTR's Forum, and Japheth
later updated his .ZIP:

http://www.bttr-software.de/forum/board_entry.php?id=10752

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

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

Unfortunately, I don't have Win98SE, so I don't know of any compatible
RAM disks.

[Rod Pemberton]

"Rugxulo" <rug...@gmail.com> wrote in message
news:85ebfede-bed3-4a2d...@f36g2000vbm.googlegroups.com...

> On Oct 24, 7:25 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
> wrote:
>
> Well, I now know why I wasn't getting more memory with HIMEMX. It wasn't
> HIMEX that was the problem ...
>
> 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 took the liberty to quote your posts at BTTR's Forum, and Japheth
> later updated his .ZIP:
>
> http://www.bttr-software.de/forum/board_entry.php?id=10752
>
> "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."
>

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. I know he does post occasionally to Usenet,
but it seems rare and he usually contradicts me! :-) It's got a Phoenix
BIOS, so it probably just need another BIOS call to identify memory, I
suspect ...

> > 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)?
>
> Unfortunately, I don't have Win98SE, so I don't know of any compatible
> RAM disks.
>

Well, I found a few more ramdisks on old DOS websites (Garbo, Simtel, Funet,
Hobbes, etc). I was even downloading them if they didn't mention XMS, but
none are working so far ... Sigh. I thought WinSE properly transferred XMS
upon startup, but it must only be with HIMEM.SYS.


Rod Pemberton

[Rod Pemberton]

"Rod Pemberton" <do_no...@noavailemail.cmm> wrote in message

news:j8a3d6$q2h$1...@speranza.aioe.org...

> "Rugxulo" <rug...@gmail.com> wrote in message
> news:85ebfede-bed3-4a2d...@f36g2000vbm.googlegroups.com...
> > On Oct 24, 7:25 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
> > wrote:
> > >
> > > 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 took the liberty to quote your posts at BTTR's Forum, and Japheth
> > later updated his .ZIP:
> >

> > [link]

> >
> > "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."
> >
>
> 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). [...] It's got a Phoenix

> BIOS, so it probably just need another BIOS call to identify memory, I
> suspect ...
>

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

[Rugxulo]

Hi,

On Oct 31, 5:07 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:
> "Rod Pemberton" <do_not_h...@noavailemail.cmm> wrote in message
>
> news:j8a3d6$q2h$1...@speranza.aioe.org...
>

> 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

(quoting verbatim from Japheth):

http://www.bttr-software.de/forum/board_entry.php?id=10752

"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

(end quote)

[Martin Strömberg]

Rod Pemberton <do_no...@noavailemail.cmm> wrote:
> 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.

IIRC, XMSDSK only uses the 2.0 XMS calls (the ones limited to 64MB) to
work with XMS. So if you have a lot of memory and use /T to XMSDSK XMS
will run out of handles because it will need to allocate memory using
(total_mem-xmsdsk_size)/64 handles (my calculations might be wrong).

When XMS runs out of handles XMSDSK becomes unhappy and doesn't
deallocate what it has already allocated, which results in a lot of
XMS allocated to nobody and no free handles.

Just increase the handle count (sufficiently) for the XMS manager.


--
MartinS

[Rod Pemberton]

"Martin Strömberg" <a...@dexter.ludd.luth.se> wrote in message
news:j8rdt0$kt5$1...@speranza.aioe.org...

Increasing the XMS handles to 128 (maximum) for HIMEMX doesn't fix the
issue. Increasing the handles to 512 (modified version) for HIMEMX doesn't
fix the issue either. So, that doesn't seem to be the situation. The
situation seems to be that XMSDSK has a 2GB boundary bug with the /T option.
If more than 2GB of XMS is present with /T option, XMSDSK allocates
everything above 2GB. 2GB is what XMSDSK says it supports ... If I cap XMS
at 2GB or less, XMSDSK does a normal allocation. If I don't use /T, XMSDSK
does a normal allocation, but won't work with Win98SE, just DOS.


Rod Pemberton

[98 Guy]

Rod Pemberton wrote:

> If I cap XMS at 2GB or less, XMSDSK does a normal allocation.
> If I don't use /T, XMSDSK does a normal allocation, but won't
> work with Win98SE, just DOS.

Win-98 won't start if sees more than 1.5 gb of ram. I've used HimemX as
a replacement for himem.sys for win-98 systems running with 2 gb of
actual ram installed on the motherboard for experimental purposes, but
for final-build purposes I will probably just have 1 gb installed.

While win-98 can make use of 1.2 gb of ram, it's a bit of a waste to
install 2 gb in a system just to gain access to the extra 200 mb. I've
looked for 256 mb DDR-2 ram (to have a system with 1.25 gb installed
ram) but I've never found any. Can't even find 512 mb DDR-2 sticks.

[Rod Pemberton]

"98 Guy" <9...@Guy.com> wrote in message news:4EB48B26...@Guy.com...

> Rod Pemberton wrote:
>
> > If I cap XMS at 2GB or less, XMSDSK does a normal allocation.
> > If I don't use /T, XMSDSK does a normal allocation, but won't
> > work with Win98SE, just DOS.
>
> Win-98 won't start if sees more than 1.5 gb of ram.
>

I know ... Well, roughly 1GB here, AFAICT. 98 seems to get "sketchy" with
more than 1GB, but I haven't thoroughly tested over 1GB.

Everytime I mention capping XMS over 1GB, someone mentions Win98SE limit.
In fact, I've made the mistake once or twice myself when posting. However,
Win98SE is not capped by available XMS memory. Win98SE is capped by
MaxPhysPage and MaxFileCache in system.ini.

These work with HIMEM.SYS for 4GB during Win98 install:

[386enh]
MaxPhysPage=22000
[vcache]
MaxFileCache=560000

These work with after Win98SE install with HIMEMX.SYS for 4GB:

[386enh]
MaxPhysPage=3FFFF
[vcache]
MaxFileCache=524288

HIMEMS.SYS can be switched for HIMEM.SYS during 98's install *after* the
first reboot. Edit the setup's system.ini too.

> I've used HimemX as
> a replacement for himem.sys for win-98 systems running with 2 gb of
> actual ram installed on the motherboard for experimental purposes, but
> for final-build purposes I will probably just have 1 gb installed.
>

I had 1GB, now have 4GB. It was a gift. 768MB or so is used for via MMIO
(video card), PCI bus, and BIOS mapping which leaves about 3.2GB for XMS.

> While win-98 can make use of 1.2 gb of ram, it's a bit of a waste to
> install 2 gb in a system just to gain access to the extra 200 mb. I've
> looked for 256 mb DDR-2 ram (to have a system with 1.25 gb installed
> ram) but I've never found any. Can't even find 512 mb DDR-2 sticks.

Sorry, either my memory modules are in use, planned use, or packed away,
whether new or old ...


Rod Pemberton

[Rod Pemberton]

> "Rugxulo" <rug...@gmail.com> wrote in message

> news:2602b511-55a8-4cb9...@t8g2000yql.googlegroups.com...

> > On Oct 31, 5:07 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm>

> > news:j8a3d6$q2h$1...@speranza.aioe.org...
>
> > [HIMEMX] 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.
>

> > [e820h map]
>
> (quoting verbatim from Japheth):
> [link]

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

> [code]

>
> "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":

> [RBIL values]
>

1) I have no answers for you on the reclaim of type 3 or 4 memory or the
"Does /X switch really work?" issue. I would hope that if that region was
used as memory, that the hardware would map in memory there, e.g., with DOS.
Someday, I may get a chance to check, but no promises ...

2) I attempted to disable ACPI in order to change the e820h memory map,
i.e., to remove the two reserved blocks. Disabling and enabling various
BIOS options does not change e820h map. ACPI 3 and 4 memory seems to be for
an AGP video controller. Win98SE maps it at those addresses, even if those
addresses are virtual. I've got no idea what happens if a DOS application
writes there.

3) Jwasm compiles himemx.asm using the params from the updated make.bat.
I'm not sure if the .bat or makefile works.

4) You didn't update other bugs I mentioned or Ninho's patch for himemx.asm.
I hope you noted them for the future.

5) Martin Strömberg (Stroemberg) said XMSDSK has a handles issue. I don't
see that. XMSDSK seems to have an 'allocate all XMS above 2GB bug' when
used with the /T option. I'm not sure of anyone modding XMSDSK to fix this.

6) I posted some e820 memory maps to alt.os.development and code to test.
We're still working out the bugs in the code. One machine doesn't mention a
100000h block in the e820 map even though it has one ... Data from another
person's machine has e820 but no e801. Other odd stuff ...


Rod Pemberton