I am DISMAYED by some of the recent comments on this board
regarding "old EMM386" v.s. JEMM386/JEMMEX, the "A20" line
etc.!
First, I use and recommend JEMM386/JEMMEX with my UIDE and
other drivers. I absolutely REFUSE using "old EMM386" by
Gates & Co. because it has (A) Never-fixed BUGS in its VDS
logic, (B) FAR too much "Custom Crap" for wretched Win/311
as anyone can "see" in its 1.8-MB of source files, and (C)
is a 125- or 130K driver that "eats" FAR too much run-time
memory! "It sucks!" in short, and I view UIDE "lucky" to
be able to use its OWN UltraDMA, instead of what Gates and
all his "flunkies" left us with as "DMA" when they DROPPED
MS-DOS in 1995! I also want NOTHING to do with FD-EMM386
and anyone who wonders why can read the Revision Notes for
JEMM386, to view all of what Japheth had to do BEFORE poor
old FD-EMM386 worked even "plausibly" as the new JEMM386!
Re: JEMM386/JEMMEX failing on some systems, this is likely
due to "modern" address spaces that the JEMM drivers can't
detect. But Japheth once told me that he CHOSE to retain
all of EMM386's memory-detection logic, so his drivers are
"compatible" with what Gates & Co.'s [never updated] TRASH
will do! So, do you really expect EMM386 will do a much
better job of detecting memory?? I would NOT!! If some
system has a "problem" loading JEMM386, or loading EMM386,
its user MUST "experiment" with the I= and X= commands, to
selectively include/exclude address areas, until a desired
EMM driver DOES load successfully! Never-was, and never-
will-be a "fully automatic" PC system, and sometimes a few
experiments loading drivers (mine included) are NECESSARY!
Finally, it is a bit "LATE in the game!" to be thinking of
new schemes for handling the "A20" line. My own XMGR has
exactly 4 methods:
(A) IGNORE "A20" if it is found "enabled" when XMGR loads
i.e. the DOS kernel turns it on forever.
(B) Use keyboard-port logic if /PN was given.
(C) Use port 92h i.e. IBM PS/2 logic if /PA was given.
(D) "Ask the BIOS" if port 92h logic is there, if neither
/PA nor /PN is given.
XMGR doesn't handle the usually-ignored BIOS calls, any of
the "ancient" Compaq, H/P, ATT 6300 or other 1990s-vintage
schemes to handle "strange A20 logic" (all of which caused
Gates & Co. HIMEM.SYS to reach 30K!), etc. Except for a
"bug" in its port 92h logic, back in 2009, nobody has ever
"complained" to me that XMGR's "A20" logic was inaccurate,
inadequate, etc.!
So, why don't we just leave current "A20" handling as-is??
For 99.44% of us, it works fine! Any "strange" system on
which it does not work usually needs TROUBLE-shooting, NOT
yet-another new "A20 handling" scheme!!
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
