Email from Jack R. Ellis:
===
Johnson,
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
> SHCDX33A.
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
diskettes!
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
> FDXXMS.
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
BETTER!!
> 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
NEED IT!"
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:\command.com /e:512 /p=a:\fdauto.bat
device=a:\qhmboot.sys
dos=high,umb
device=a:\qdboot.sys
device=a:\umbpci.sys
devicehigh=a:\qhimem.sys /n32
devicehigh=a:\qdma.sys /o /d /f /l
devicehigh=a:\qcdrom.sys /d:mscd001 /uf /l
fileshigh=12
buffers=8,0
stackshigh=8,256
lastdrivehigh=h
***** My diskette FDAUTO.BAT *****
@echo off
set path=a:\
loadhigh a:\ctmouse.exe
loadhigh a:\shcdx33a.com /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!
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
