Hi Johnson,
> I sincerely ask Jack's to let me host his drivers because I want to
> provide the DOS user an alternative, a choice. His QHIMEM let me have
> 620K base memory, I got plenty of base memory for me...
You might have noticed that Dima had even MORE memory free even
though he does NOT use QHIMEM ;-)
> Conventional 639K14K 625K
> >Note: SHCDX33A now in conventional memory, thaks to Eric Auer for advice.
> Did you found SHCDX33A have any problem when loaded high? Can you
> share your experience with us?
The trick is that if you load SHSUCDX in "normal" way, it
relocates itself to UMB. But if you LOADHIGH (LH) SHSUCDX,
it relocates itself AWAY from UMB. To stop this, you have
to use the /c option of SHSUCDX (if you use LH), or you
have to stop using LH (then SHSUCDX can relocate itself high).
This happens for both SHSUCDX and SHSUCDX, uhm, SHCDX33A.
> And please don't blame Jack, he have no intention to compete with
> FD-HIMEM, he just want a "simpler" XMS manager.
Those who want a stripped down XMS manager can already use FDXXMS.
Dima:
> SHCDX33A 8,416(8K)
> FDXXMS 2,432(2K)
> UMBPCI 176(0K)
Johnson:
> CC91h .. 5,968SHCDX33A
> 0276h 80.. Device=QHMBOOT Attr=A000h Name=QHMLOW$
> C802h .. 2,000Device=QHIMEMAttr=A000h Name=QHIMEM$
> 029Eh 160.. Device=UMBPCIAttr=E000h Name=UMBPCIXX
I assume that Dima has more cdrom drives, so his SHSUCDX takes more RAM.
Your two MEM tools differ somehow in how they measure, but you can
assume that QHIMEM+QHMBOOT together take 300 bytes less RAM than FDXXMS.
It would have been a good idea if Jack had written a patch for FDXXMS
to let it use QHMBOOT instead of re-inventing the wheel and writing
QHIMEM, based on questionable sources. After all, it is a good idea to
let the XMS driver be loaded into UMB (as possible with QHMBOOT+QHIMEM)
but it is NOT a good idea to annoy people by introducing yet another
XMS manager, indirectly blaming the others of being so bad that it would
not be worth the effort to improve them.
A really good driver more or less by Jack is actually XCDROM / QCDROM:
Johnson:
> C8E4h .. 2,400Device=QCDROMAttr=C800h Name=SHSU-CDN
(by the way, what is qbuf...?)
> 027Ch 528.. Device=QDBOOTAttr=8000h Name=QBUF$
Eric:
> cae8 5008VIDE-CDDdevice driver
Note that saving 2.5k of memory is quite good but that it is not
necessary at all as we both have the driver in UMB anyway :-)).
For comparison of memory drivers:
028e 2672HIMEM device driver
0336 3360EMM386 device driver
...
040f 3152 COMMAND program
04d5 [free area starts here]
ca02 400KBD-EA2 device driver
ca1c 3248NANSI device driver
cae8 5008VIDE-CDDdevice driver
cc22 7552CDRCACHEdevice driver
cdfb 624MORESYS device driver
ce23 2496FILES data area
cec0 2288LASTDRV data area
cf5612976 LBACACHEprogram
d4a3 912 FDAPM program
d4dd 3312 CTMOUSE program
d5ad [rest is free - almost: COMMAND environment at dfdf, 0.5k]
(some lines omitted)
So I have 620k low DOS RAM and 41k UMB free and I even have a 64k
EMS 3.0 page frame (otherwise I would have more UMB free) and a
VESA VBE 3.0 compatible BIOS :-). 620k are 635,120 bytes to be exact.
As I have not seen programs which need more than 590k low DOS RAM,
all available drivers are good enough. The only too big driver in
my collection is the network card packet driver, because it does
not work well when loaded into UMB. I usually do not use networking
in DOS normally, so most of the time, I simply do not load the driver.
Have a nice DOS :-)
Eric
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
