Email from Jack R. Ellis:


You are free to post this entire E-Mail on FD-User, EXACTLY as it is!

Regarding "friend" Eric's latest comments posted on FD-User --

> You might have noticed that Dima had even MORE memory free even
> though he does NOT use QHIMEM ;-)
> Conventional          639K        14K       625K
>                                             ----

Read my MEM display shown at the end of this E-Mail with my FDCONFIG
and FDAUTO files.   I still use V6.22 MS-DOS, not FreeDOS.    If I
knew more about FreeDOS, as Dima does, GUESS what my MEM listings
might show!

> 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

So what is WRONG with the /C option??   It WORKS, last I noticed, and
it gives NO problems of which I am aware!   Use it and LOVE it, if you
want to SAVE low-memory!

And "uhm", there are REASONS why I revised SHSUCDX into SHCDX33A. It
SAVES over 1000 bytes of file space, for my "poor old" 1.4-MB

And its directory buffers are all "aligned" to 4-byte boundaries so
REAL ULTRADMA (not XMS memory nor "PIO mode") can be used with
directory I-O!

I do not fault Jason Hood at ALL by saying this; he did a GREAT job
with SHSUCDX!   But, UltraDMA has RULES Jason would not have noticed
in using only VIDE-CDD, which offers no UltraDMA.   QCDROM/SHCDX33A DO
offer it!

> 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,968    SHCDX33A  0276h       80        ..      
> Device=QHMBOOT
>   C802h      ..       2,000    Device=QHIMEM
>   029Eh      160        ..     Device=UMBPCI
> 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

The 2000-byte value above is for V1.0 QHIMEM with all 128 "Handles",
and few people need that many.   Using V1.2 QHIMEM with its default
value of 32 "Handles", the above will show 1728 bytes, and all 4-GB of
XMS memory CAN be accessed!   We need to talk about saving 700 BYTES,
not just 300!

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

If the FDXMS/FDXXMS writers intended their driver to be "modified",
then WHY did they use its "obscure" assembly-language format, whose
2-operand commands are BACKWARD v.s. any other 80x86 assembler I ever
saw??   Even if I really WANTED to "re-learn the wheel" and alter such
assembly code, there is NO comment in FDXMS/FDXXMS about WHICH
assembler it requires or where to GET that assembler!!

As for "questionable sources", they are easily available on the
Internet in a downloadable ZIP file and are FAR from "questionable",
which anyone with Half-a-BRAIN will realize after READING those files!

QHIMEM is a full REWRITE with over 75% of source lines my OWN. QHIMEM
saves 20% of size, offers 4-GB capability with only 7-byte "Handles"
(NO miserable 10 byte types), and offers MUCH better "re-entrancy"!
The creators of the original files should be ASHAMED for a
"re-entrant" Free Memory function which might do unlimited "Handle"
table scans with interrupts DISABLED!!

QHIMEM "cures" this problem, among many others!

I will NEVER "apologize" for doing a BETTER job or for fixing the
"bugs" and ERRORS made by others!   If others have their "Egos" and
"Don't want to TALK about it!", that is THEIR problem, not mine!   The
files I began with, in creating QHIMEM, were TERRIBLE code and BEGGED
to be "revised"!

Nor was it at ALL my intent to "annoy" anyone in writing QHIMEM!   I
did QHIMEM because I wanted a SMALL driver which SAVES low-memory and
offers BETTER features, written using an assembly-language I could
"LIVE With"!

I was using the Russian PTS-32 HIMEM driver, a 5600-byte file using
only 752 bytes of low-memory, not-bad.   But, as in other HIMEM
drivers, some protected-mode "scheme" MAPS OUT much of the driver, and
it DOESN'T WORK in FreeDOS, leaving that driver at a 2480-byte size if
FreeDOS loads it!

I couldn't figure what-was-going-on, and with no source files, NO
CHOICE as-always but to do my OWN driver from available sources.    If
software now marches ONLY to an "All we want is MONEY!" basis, they
must EXPECT a few of us who know what we are DOING to GO AROUND them!
Glad I did, as protected-mode was UNNEEDED!    QHIMEM uses an 80-byte
low-memory "stub" and Ye Olde Ordinary JUMPS to upper-memory!   The
Russians and the well-known software guys could have SAVED 672
low-memory bytes!    And though protected-mode "schemes" FAIL, Ye Olde
"Jmp" commands WORK with FreeDOS!

Are THOSE enough REASONS for you, Eric??

Such groundless and FALSE "assumptions", before ever inquiring about
the REAL reasons for QHIMEM, absolutely mark Eric Auer as somebody who
still needs to learn he should WATCH HIS BLOODY MOUTH!!!

> A really good driver more or less by Jack is actually XCDROM/QCDROM:
> Johnson:
>  C8E4h      ..       2,400    Device=QCDROM
>  (by the way, what is qbuf...?)
>  027Ch      528        ..     Device=QDBOOT
> Eric:
>   cae8     5008    VIDE-CDD    device 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 :-)).

My GAWD!  A NICE comment from "friend" Eric regarding one of my
drivers! "Incroyable!", as the French might say!

"By the way", QBUF is a diskette buffer, reserved by QDBOOT for
diskette ISA DMA above 640K, which cannot be handled by UMBPCI "shadow
RAM" upper memory.   It is equivalent to the buffer used by the old
LOWDMA program. Same as QDMA I-O above 640K goes through XMS memory,
diskette I-O beyond 640K goes through the QBUF buffer.   Slower, as it
must be done 1 sector at a time.   However, NO "shadow RAM" CRASHES
occur, and that is why the QBUF buffer is an "automatic" feature of
the QDBOOT driver!

> For comparison of memory drivers:
>   028e     2672    HIMEM       device driver
>   0336     3360    EMM386      device driver

I guess Eric must enjoy giving up 6032 bytes of low-memory for
FD-HIMEM and FD-EMM386.   His choice.   I prefer NOT to give up that
much, which is why I use UMBPCI and wrote QHIMEM to complement it!

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

Read my MEM display listing below.   A few differences, as my video
card takes 16K more than the regular C000-C7FFh, and as I declare only
drives A: through H: on my system.    Why lose 1500 bytes more
upper-memory for drives I: through Z: which I do not HAVE??    After
one subtracts 65,536 bytes for an EMS "page", which I ALSO do not
need, Eric will find that I have about the SAME upper-memory he has,
and 5K more LOW-memory as well!

This is from using only a "basic" FreeDOS diskette.   If I were not
just a "casual" FreeDOS user and knew more of it, YOU BET I would do

> As I have not seen programs which need more than 590k low DOS RAM,
> all available drivers are good enough ...

Others HAVE seen such programs, DOS "video games" and the like, that
use ALL available low-memory.   I did not begin this "low-memory
race".   My drivers only HELP by requiring minimal low-memory:  80
bytes for QHIMEM, 528 bytes for QBUF, and 160 bytes for Uwe Sieber's
latest UMBPCI.    All other drivers or TSRs can then be put in
upper-memory.   Eric is welcome to try and find another "combination"
which takes less.   I have 6 words for him:  "Good LUCK!  You will

If Eric thinks the current DOS/FreeDOS drivers are "good enough", he
can STAY with them, and let others of us who care to do a BETTER job
proceed with our efforts!   Such "sniveling" comments, from Eric AND
others, are the reasons why I have QUIT FreeDOS and shall Damned-Well
NEVER return!!

Johnson Lam, and George at AXCEL16, are both welcome to post my
drivers, with my compliments and my Thanks.

Jack R. Ellis


***** My diskette FDCONFIG.SYS *****

shell=a:\ /e:512 /p=a:\fdauto.bat
devicehigh=a:\qhimem.sys /n32
devicehigh=a:\qdma.sys /o /d /f /l
devicehigh=a:\qcdrom.sys /d:mscd001 /uf /l

***** My diskette FDAUTO.BAT *****

@echo off
set path=a:\
loadhigh a:\ctmouse.exe
loadhigh a:\ /d:mscd001 /c

***** My resultant FreeDOS MEM display *****

Segment   Size       Name         Type
------- --------  ----------  -------------
   0273     1024   DOS         system data
   0275      192    FILES       data area
   0282       80    QHMBOOT     device driver
   0288      528    QDBOOT      device driver
   02aa      160    UMBPCI      device driver
   02b4       96               free
   02bb     2992   COMMAND     program
   0377      128   MEM         environment
   0380    48240   MEM         program
   0f48   591712               free
   9fc0   181248               reserved
   cc00     9040   DOS         system data
   cc02     1728    QHIMEM      device driver
   cc6f     1584    QDMA        device driver
   ccd3     2400    QCDROM      device driver
   cd6a      480    FILES       data area
   cd89      704    LASTDRV     data area
   cdb6     2048    STACKS      data area
   ce36      128               free
   ce3f     3312   CTMOUSE     program
   cf0f     6032   SHCDX33A    program
   d089   128336               program
   efdf      512   COMMAND     environment

Testing XMS memory ...
XMS version               3.00          XMS driver version        1.02
HMA state                 exists        A20 line state enabled
Free XMS memory           266953728 bytes
Largest free XMS block    266953728 bytes
Free handles              29

  Block   Handle     Size     Locks
------- --------  --------  -------
       0     1504    196608        1
       1     1511    105472        0
Free upper memory         144 bytes
Largest upper block       144 bytes

Memory Type        Total       Used       Free
----------------  --------   --------   --------
Conventional          639K        14K       625K
Upper                 144K       144K         0K
Reserved              241K       241K         0K
Extended (XMS)    261,100K       403K   260,697K
----------------  --------   --------   --------
Total memory      262,124K       802K   261,322K

Total under 1 MB      783K       158K       625K

Largest executable program size       625K (639,968 bytes)
Largest free upper memory block         0K (    144 bytes)
FreeDOS is resident in the high memory area.

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!
Freedos-user mailing list

Reply via email to