Hi Jack, Bret, Japheth, Alain, others, > 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
Nobody suggested to use the EMM386 by MS... By the way, MS does have a lovely little I/O virtualization API which might be much weaker than JEMM VLM, but would still be very welcome for certain drivers. I think the Bret Johnson USB drivers for example could do cool things if JEMM supported that API :-) > 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! Examples please - it does not help when Alain says that his customers have burning computers with JEMM and you say you get nightmares from FD-EMM386... There must be something in which BOTH Alain and you are right, and finding that would help to convince Alain to trust JEMM and help to improve it. Because really, I do doubt that JEMM already is perfect... > 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 How can JEMM retain code from MS EMM, I would rather assume it retains FD-EMM code? If JEMM mimicks MS, then that could explain why JEMM is harder to tame than FD-EMM for the user as AFAIR, FD-EMM tried to have quite cautious detection :-! > 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... You know my conclusion - EMM drivers are just not suited for one size fits all boot disks. But this is a pity and I would be happy if some EMM driver could eventually prove me wrong. > 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. If you mean FreeDOS: No the kernel does NOT turn on the A20, it asks the XMS driver to do that. But it would be NICE if the driver could explicitly switch A20 ON and THEN does not touch it any more... Also, I think some BIOSes give you A20 DISABLED at boot, so ignoring / not touching it at all would not be a very useful choice for most DOS users... In short, I would be happy about a "force-on" "A20 method". > (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. Fair enough. I hope the BIOS is reliable for the detection. > XMGR doesn't handle the usually-ignored BIOS calls, any of What makes you think they are usually ignored? Would the BIOS not at least ANNOUNCE that they are ignored, detection-wise? In any case, BIOS calls tend to do (B) or (C) anyway, just in a slower way, so you are right to ignore those calls, and the ancient stuff as well, of course :-) > So, why don't we just leave current "A20" handling as-is?? See above. Or maybe the KERNEL could do part of the work: Ask the XMS driver to switch ON the A20 as soon as the driver is loaded, but never ask the driver to switch the A20 OFF. Still other DOS apps or drivers MIGHT come up with the bad idea to ask the XMS driver to switch off the A20 "again" after use... > 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!! Depends... Note that my suggestion is NOT related to Alain's "I had vague problems and think A20 changes help". It is more my GENERAL suggestion - namely that we should stop switching around a dusty rusty address gate line. Let's just make SURE at boot that the gate is OPEN, then keep it like that. As an OPTION for the command line of any XMS driver, for example. This is also useful in the context of BIOSes doing a bad job in implementing 8042 / keyboard style handling of real, PS/2 and USB keyboards already, so for cases where I have to use the slow keyboard-port style A20 method, I would prefer to at least only touch that A20 ONCE. For example if there was a 0.5% chance that USB and/or A20 crash at switching, either in general or after you load DOS USB drivers or whatever. While port 92 A20 handling tends to be more foolproof, there is still another chance that a stupid BIOS messes up when an A20 switch happens at the wrong moment. As said, I say that some people would sleep better when they could tell the XMS driver and/or DOS to switch A20 on and then leave it on :-) Regards, Eric ------------------------------------------------------------------------------ The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Ciosco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
