Finally I find time to read the changelog examples, thanks! >>> 03/27/2007 >>> bugfix: free EMS pages not always reported correctly.
Wrong amount of free space? Or non-free pages reported as free? >>> bugfix: translation DMA for 16-bit controller (channels 4-7) didn't >>> work. This fix sounds VERY useful. >>> 03/02/2007 bugfix: XMS function 11h (free UMB) always returned an error. Error status? Or failed to work? >>> 10/07/2006 bugfix: allocating a EMS block with zero pages (int 67h, >>> ah=5Ah, bx=0) returned with AH=0, but did not return a valid DX handle. A rare situation? >>> 09/30/2006 >>> bugfix: VDS functions 03, 04, 07 and 08 may have failed if bit 1 of DX >>> was set (request to copy in/out of DMA buffer) and registers BX,CX >>> were <> 0. Int 4b.8103/4/7/8? Lock/Unlock/Request/Release DMA region/buffer? I first thought it was a missing feature, but re-reading the above it was a bug triggered by BX / CX values. Oops :-! >>> bugfix: 1 kB of DMA buffer may have been inaccessible. >>> bugfix: releasing a DMA buffer of size < 1 kB always failed. Probably uncommon, but still an annoying bug fixed by Japheth :-) >>> 09/06/2006 bugfix: writing to "ROM" page FF000 if ALTBOOT wasn't set >>> caused a crash. Yes I remember the times when ALTBOOT was "needed for stability"... >>> 08/25/2006 bugfix: unsupported VDS functions caused a debug display, >>> which didn't work and may have caused corruption of monitor data. Interesting. >>> 08/23/2006 bugfix: DMA buffer is ensured to begin on a 64 kB physical >>> address boundary. I wonder where else it was before. >>> 08/17/2006 bugfix: in VCPI protected mode entry switch to host stack >>> before context is switched. That probably caused random crashes with protected mode apps before? > Note that all of the "bugfix" items listed above are not-long after the > final update for FD-EMM386, meaning that Japheth likely inherited them Maybe some other changes after 2008 made JEMM386 harder to use again? Still trying to find an explanation for Alain's pessimism and troubles experienced by the users of his software when trying to use JEMM386. In any case I agree that JEMM386 has several clear improvements, too. Based on your changelog examples - not on "who is on the base list". > Can't say there, either, as I avoid FD-EMM386 like the PLAGUE! "Clear improvements over FD-EMM386" does not mean that FD-EMM386 was horrible, just old. But my big question is what makes JEMM386 uncomfortable / shaky for Alain even though JEMM386 actually is better than FD-EMM386 and a lot more up to date and maintained. > Good luck waiting for one! But, why wait -- Why not recommend > that users who create "boot" diskettes DO NOT include any "EMM" > driver in such "boot" activities?? I totally agree with your recommendation. > Would you care to GUESS the first message XMGR will give you?? > Something like "NOTE: A20 line found on!", maybe? The FreeDOS kernel only switches A20 by calling HIMEM/XMGR, so if XMGR finds A20 to be already on, then the BIOS probably did that. >> In short, I would be happy about a "force-on" "A20 method". > Glad to hear that, since your own FreeDOS is already DOING so! It is not, but probably it should - with a config sys option to be able to select MS DOS style - A20 off between "exec" and the next "big" int21 call, done for ancient-DOS-app compatibility. >>> XMGR doesn't handle the usually-ignored BIOS calls ... > Why do I say such calls are usually ignored? Because XMGR > has NEVER supported them, and no one has ever "complained" That simply means that all modern systems support port 92 and or keyboard controller style A20. It does not mean that BIOS calls for switching A20 would be broken in BIOS. Just that it is not so useful to call the BIOS for A20 manipulation. Yet I could imagine the BIOS knowing better than DOS which of those two methods (port92 / 8042) is preferred/stable/faster/etc.? >> 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 :-) > > Of course! Proves your point that using the BIOS to manipulate A20 is not necessary, nobody has yet reported non-BIOS to cause problems. > The kernel already IS doing part of the work! Try ALL of the > options on Lucho's "boot" diskette"! You will find that only > MS-DOS and PC-DOS are not hard-enabling "A20", when they load. > DR-DOS, the Russian PTS-DOS, ROM-DOS, and FreeDOS all DO hard- > enable "A20". The FreeDOS kernel contains no 8042, port 92 or int 15.24 style A20 manipulation code (or it would be very well hidden) so the only A20 work of the kernel are calls to XMS driver functions number 5 and 6. Maybe an obscure side-effect of something else distorts your measurement? The boot menu used by Lucho might enable A20 but the MS / PC DOS kernel then disabled it again? > To use an old U.S. phrase, "Don't MESS with success!" I still cannot find *how* the FreeDOS kernel would enable A20 before XMS drivers are loaded. And I think it should not - it should just ask the XMS driver to enable A20, but then there should be a way to tell the kernel to NEVER ask the XMS driver to disable A20 again. For example using a config sys option. >> 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 ... > > I disagree. MS-DOS and PC-DOS have good reason for NOT hard- > enabling "A20" that the other kernel designers have forgotten. Which is why it is good to have the choice whether to hard-enable. > There ARE still a few programs which use their OWN enables and > disables of "A20", and those programs FAIL if the line MAY NOT > be switched-off or switched-on! I do not recall exactly what > programs they are, but I DO recall that the LOADFIX program in > MS-DOS and Windows specifically "remedies" one such problem! I think that was EXEPACK and old LZEXE versions, where pointers would wrap wrongly if apps are loaded in the first 64k with A20 being on. Also something with other old MS compiler/linker/asm? > Given that, I am NOT in favor of adding such a hard-enable for > "A20" in my XMGR driver. If other XMS managers offer such an > option, I hope their users "Know what they are doing!" As all options, the user has to decide whether to use that, yes. 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@Cisco 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
