Re: [Freedos-user] Undeserved Comment Re: EMM/JEMM, A20, Etc.
Hi Alain, In creating JEMM386, Japheth did not merely improve things! He made FD-EMM386 RUN PROPERLY! Finaly you agree with me! Michael Devore's emm386 was tested very very much by the members of FreeDOS and Michael fixed ALL issues. You misread that ;-) Saying *Japheth* made FD-EMM386 run properly just meant that JEMM386 is the repaired version of FD-EMM386 and I guess you do not agree with that. But I find it more interesting to check the changelogs, so I will reply to that mail next. 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
Re: [Freedos-user] Undeserved Comment Re: EMM/JEMM, A20, Etc.
Hi Jack, HIMEMX and XMGR both improve on the old 30K MS-DOS HIMEM which is overloaded with obsolete A20 code for now-defunct PCs.Japheth and I have some differences, but I have used HIMEMX and think it is quite equal to XMGR. XMGR does have direct support for UMBPCI, as I note in the README for my drivers, so I have retained XMGR as the real-mode solution for those who do not need a full EMM driver. ... What I see happening on real machine is XMS driver loaded, then some HMA message, then a hang before shell is executed ... If this applies to XMGR, send me a private E-Mail, and I will try to help resolve this. Should NOT happen! Thanks :-) As I note above, XMGR v.s. HIMEMX is an even call, so you can likely keep FreeDOS as-is and go on using HIMEMX as standard. No knowledge of FDXMS286, as I have never used an 80286 system. As far as I remember, FDXMS286 has some issues, but it was the only free XMS driver available for 286 at all, so it is better than none. Boot configurations without at least an XMS driver can be quite troublesome as they consume lots and lots of DOS low-memory ... I would not suggest that either - but I do suggest to avoid EMS/UMB drivers in one-size-fits-all bootdisks because modern machines tend to have too much UMB conflict potential with too little compatible conflict resolution info. I agree with Jack: XMS/HMA are important, so loading HIMEM/XMGR/HIMEMX is good - as long as your A20 is safe. 4DOS is a bit better with this ... You mean auto-choice between XMS and disk swap? But who has no XMS? they DESERVE to be called! Starting with Gates Co., who SHOULD have made CD/DVD logic go directly into the BIOS instead of making a separate MSCDEX with its pack of [lousy!] add-on drivers... But then, e.g. BIOS based VESA sound also never really got off the ground, as a lot of other hardware also stayed without BIOS support. Also, hardware vendors now feel forced to make drivers for all sorts of Windows and it is quite possible that this not only is a burden but also a chance compared to sending everything through BIOS calls. 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 Interesting, so maybe FreeDOS kernel should reconsider mimicking MS here and make hard-enabling the default (as soon as XMS/HMA drivers are detected, call enable A20 once, then stop touching A20) with an config sys option to reactivate MS style A20 toggline which only ancient apps need anyway and for which LOADFIX is a workaround...? 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
Re: [Freedos-user] Undeserved Comment Re: EMM/JEMM, A20, Etc.
Eric,
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?
Not my department, as I've never used actual EMS -- Ask Japheth.
bugfix: translation DMA for 16-bit controller (channels 4-7)
didn't work.
This fix sounds VERY useful.
Might be, if I could ever find a real diskette driver that is not
embedded inside some BIOS.
03/02/2007 bugfix: XMS function 11h (free UMB) always returned an
error.
Error status? Or failed to work?
Not my department, ask Japheth, as above.
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?
Perhaps, but would YOU like to be bitten by this bug?
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 :-!
UIDE uses ONLY VDS lock and VDS unlock, since MS-DOS EMM386 is
absolutely UNRELIABLE for any other VDS calls! VDS lock returns
the 32-bit address of a memory area, without which it is Kiss your
*** GOODBYE!! re: using UltraDMA!!
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 :-)
Depends -- Users with SCSI or old IDE disks (i.e. no UltraDMA) may
just be Sh** out of luck!, as our actor Clint Eastwood once noted!
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...
Another Kiss your *** GOODBYE!!, in my opinion!
08/25/2006 bugfix: unsupported VDS functions caused a debug display,
which didn't work and may have caused corruption of monitor data.
Interesting.
Corruption of monitor data is only INTERESTING, you say?? I might
say many OTHER things, starting with Flat-Ass DISASTER!!
08/23/2006 bugfix: DMA buffer is ensured to begin on a 64 kB physical
address boundary.
I wonder where else it was before.
Who cares -- Does the expression Flat-Ass DEAD!! mean anything to you??
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?
You BET your ***! {our companion to Kissing it, as above)!
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?
Not my department -- Ask Japheth!
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.
Nonetheless, whoever decided to pitch FD-EMM386 and include JEMM386
deserves a MEDAL!
Clear improvements over FD-EMM386 does not mean that FD-EMM386
was horrible, just old.
After all your admissions and my notes above, one DARE NOT only
say FD-EMM386 was old. It was BAD, still IS bad (due to being
abandoned!), and should be updated or flatly ELIMINATED, before
others get burned by any [Interesting] items listed above!!
SORRY for my strong feelings, and friend Brutman can call me
hostile all he wishes. But I felt it my DUTY to provide
responsible opinions [as Sir Edward Murdoch noted to General
Haig, in the 1980 Anzacs Australian T.V. series), and I would
be DERELICT in that duty if I did not express how BAD and RISKY
FD-EMM386 still is!!
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.
Again, Not my department, especially as I know only enough about
protected-mode to get my real mode XMS move logic running within
XMGR and UIDE. Ask Alain.
... 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.
Yahoo! Or Yay-hoo! depending on what U.S. state hatched you!
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.
I really DOUBT IT, or else why do MS-DOS V7.10, MS-DOS V6.22 that I
still use, and PC-DOS in fact NOT give me the same message! Maybe
you need to look a little DEEPER into the FreeDOS kernel!
In short, I would be happy
Re: [Freedos-user] Undeserved Comment Re: EMM/JEMM, A20, Etc.
Op 20-10-2011 7:27, Jack schreef: 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, from his predecessors. So, FD-EMM386 cannot (A) handle a VCPI switch, (B) has DMA-buffer address problems, (C) has VDS function-call problems and (D) has EMS-page problems!! Are those enough examples for you??!! Tom Ehlert and Michael Devore implemented plenty of things in FD-EMM386, there's plenty of stuff to be thankful for. I'm just glad Japheth saw the opportunity to improve things even more. Also your drivers work pretty well. Just for the record, Japheth also has a slightly improved version of HIMEM up, renamed to HIMEMX. I don't know if that's enough for people or if XMGR is a definitive improvement, making HIMEMX (and HIMEM) completely redundant. Nor can I expect my own XMGR or UIDE to be by definition free of bugs since I am not God! Bugs are a fact of life with software, but what need NOT be a fact is how so many do so little to FIX their bugs!! Proper testing can be a nightmare, I still have to create a usable bootdisk(-image), but the trouble is you've got so many configurations. A default layout is: -bootsector -kernel -configuration file (config.sys) -XMS driver -other drivers (EMS for example) -shell -automation/login script (autoexec.bat) What I see happening on real machine is XMS driver loaded, then some HMA message, then a hang before shell is executed. Thus, excluding shell and autoexec.bat is a good thing. For that, you'd need a config.sys driver that can pause so previous driver can be excluded. It gets even more fun when adding things like bootloaders and MEMDISK to the picture. Then why, Eric, does FreeDOS have JEMM/HIMEMX in its Base Software list?? Your comment disparages the very system you support!! As you said lots of software is buggy, I think Japheth's drivers should be considered default, likely with XMGR replacing HIMEMX though. For 286 platforms, FDXMS286 (predating HIMEM) is still the only option to my knowledge. Can't say what code JEMM retains or does-not retain. I only said it retains all of EMM386's memory-dection logic, i.e., its METHODS are the same, no-matter what actual CODE it uses. 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 :-! Can't say there, either, as I avoid FD-EMM386 like the PLAGUE! JEMM was made more compatible to MS EMM386 indeed, altered from previous default FreeDOS behaviour. That's not a bad thing. Not necessarily optimal either, but it seems to work. 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?? If a boot diskette is to get a system RUNNING, and maybe copy-over added files to use if the system boots from a hard-disk, WHO NEEDS an EMM driver in a diskette boot?? I use UMBPCI/XMGR on my own diskettes and have NEVER required an EMM driver when they boot my system! Boot configurations without at least an XMS driver can be quite troublesome as they consume lots and lots of DOS's low memory. The troublesome part here is you can't automatically exit and reload the primary shell either to reclaim large parts of memory: @echo off MEM /C /N echo Uh oh %COMSPEC% eats a lot of low memory.. DEVLOAD XMGR.SYS %comspec% /reload echo Done freeing memory by swapping to XMS A master shell program that in a looping way spawns a non-permanent command.com would be great: SHELLHIGH=C:\RUNSHELL.COM C:\COMMAND.COM where RUNSHELL would do something like: @echo off goto loop :loop exec arg1 arg2 arg3 etc.. goto loop 4DOS is a bit better with this as it by default swaps to disk, but that ofcourse won't work if you're in a read-only environment. My preference would be loading config.sys without any drivers but instead relying on runtime. The only things sacrificed then are HMA and UMBs (XMS driver can be loaded runtime, EMS driver also). You are BADLY misinformed! Make a copy of Lucho's old boot diskette (from the COMBOOTF.EXE file on Johnson Lam's website) and boot from it using Lucho's Option 5, which is FreeDOS. Would you care to GUESS the first message XMGR will give you?? Something like NOTE: A20 line found on!, maybe??!! And if XMGR is the first actual DRIVER loaded, then what-else BUT the FreeDOS kernel is hard-enabling A20??!! A Hairy Thunderer or Cosmic Muffin, perhaps??!! Ah I found this message on my real hardware as well. Not sure if that was only inside MEMDISK, or also if loading FreeDOS directly from USB flash disk. It's worth trying with MSDOS indeed (though that will ruin the USB drive's SYSLINUX bootloader so won't do that for a while). In short, I would be happy about a force-on A20 method. Glad to hear that, since your own FreeDOS is already DOING so! I'm
Re: [Freedos-user] Undeserved Comment Re: EMM/JEMM, A20, Etc.
Bernd, ... Japheth likely inherited [the bugs I listed] from his predecessors. So, FD-EMM386 (A) cannot handle a VCPI switch, (B) has DMA-buffer address problems, (C) has VDS function-call problems and (D) has EMS-page problems!! Are those enough examples for you??!! Tom Ehlert and Michael Devore implemented plenty of things in FD-EMM386, there's plenty of stuff to be thankful for. I'm just glad Japheth saw the opportunity to improve things even more. In creating JEMM386, Japheth did not merely improve things! He made FD-EMM386 RUN PROPERLY! I am not faulting the work of his predecessors, I say only that they stopped too soon in writing FD-EMM386. But, so did Gates Co. stop too soon with EMM386 and left it an even WORSE mess in my opinion, when they flatly abandoned MS-DOS in 1995! Also your drivers work pretty well. Thank you! Just for the record, Japheth also has a slightly improved version of HIMEM up, renamed HIMEMX. I don't know if that is enough for people or if XMGR is a definitive improvement, making HIMEMX (and HIMEM) completely redundant. HIMEMX and XMGR both improve on the old 30K MS-DOS HIMEM which is overloaded with obsolete A20 code for now-defunct PCs.Japheth and I have some differences, but I have used HIMEMX and think it is quite equal to XMGR. XMGR does have direct support for UMBPCI, as I note in the README for my drivers, so I have retained XMGR as the real-mode solution for those who do not need a full EMM driver. ... What I see happening on real machine is XMS driver loaded, then some HMA message, then a hang before shell is executed ... If this applies to XMGR, send me a private E-Mail, and I will try to help resolve this. Should NOT happen! Then why, Eric, does FreeDOS have JEMM/HIMEMX in its Base Software list?? Your comment disparages the very system you support!! As you said lots of software is buggy, I think Japheth's drivers should be considered default, likely with XMGR replacing HIMEMX though. For 286 platforms, FDXMS286 (predating HIMEM) is still the only option to my knowledge. As I note above, XMGR v.s. HIMEMX is an even call, so you can likely keep FreeDOS as-is and go on using HIMEMX as standard. No knowledge of FDXMS286, as I have never used an 80286 system. JEMM was made more compatible to MS EMM386 indeed, altered from previous default FreeDOS behaviour. That's not a bad thing. Don't tell ME, Sir, since I use and recommend JEMM386! Tell all those who put DOWN JEMM386, for a lot of often-INVALID reasons! ... Why not recommend that users who create boot diskettes DO NOT include any EMM driver in such boot activities?? ... Boot configurations without at least an XMS driver can be quite troublesome as they consume lots and lots of DOS low-memory ... I did NOT say No XMS driver, I said No 'EMM' driver, i.e. no JEMMEX/JEMM386/EMM386/QEMM/386MAX/etc.!! I agree that the lack of an HMA for the DOS kernel would use all 640K low-memory, in a hurry! XMS drivers are less complex and thus more reliable on unknown systems than EMM drivers often prove to be! 4DOS is a bit better with this ... Like many one size fits all programs, starting with the original IBM/360 full OS in the 1960s, ANY program that tries to Satisfy everybody will end-up Satisfying NOBODY! I finally gave-up on 4DOS because it became simply too BLOATED in size to be useful any more, and I no-longer recommend it! You are BADLY misinformed! Make a copy of Lucho's old boot diskette (from the COMBOOTF.EXE file on Johnson Lam's website) and boot from it using Lucho's Option 5, which is FreeDOS. Would you care to GUESS the first message XMGR will give you?? Something like NOTE: A20 line found on!, maybe??!! ... Ah I found this message on my real hardware as well. Not sure if that was only inside MEMDISK, or also if loading FreeDOS directly from USB flash disk. It's worth trying with MSDOS indeed ... I guarantee you will NOT get XMGR's message with V7.10 nor with V6.22 MS-DOS, as I have tested both for years and use V6.22 every day. And, as Lucho's boot diskette does NOT have a MEMDISK, I can ALSO guarantee that XMGR's message IS coming from FreeDOS!! In short, I would be happy about a force-on A20 method. Glad to hear that, since your own FreeDOS is already DOING so! I'm wondering about what JEMMEX does different, as it does work for me, while others find it trashing their system and/or data. Not my department -- Ask Japheth. ... Such [BIOS A20] calls were defined by Gates Flunkeys about 20 years ago! Never underestimate BIOS writers for their spaghetti code ... I do NOT underestimate them, I rather call them the BLOODY FOOLS they DESERVE to be called! Starting with Gates Co., who SHOULD have made CD/DVD logic go directly into the BIOS instead of making a separate MSCDEX with its pack of [lousy!] add-on drivers, back about 1988!! Imagine how much farther-along PC systems might be, if many All we
Re: [Freedos-user] Undeserved Comment Re: EMM/JEMM, A20, Etc.
Em 20-10-2011 17:22, Jack escreveu: In creating JEMM386, Japheth did not merely improve things! He made FD-EMM386 RUN PROPERLY! Finaly you agree with me! The Michel Devore's emm386 was tested very very much by the members of FreeDOS and Michel fixed ALL issues. Michel started with somethin, I don't remember what. But he grew so much disgusted with these fights that when the last issue got fixed, he *disapeared* Alain -- 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
Re: [Freedos-user] Undeserved Comment Re: EMM/JEMM, A20, Etc.
Alain, In creating JEMM386, Japheth did not merely improve things! He made FD-EMM386 RUN PROPERLY! Finaly you agree with me! Michael Devore's emm386 was tested very very much by the members of FreeDOS and Michael fixed ALL issues. I DO NOT agree with you, and HE DID NOT fix all issues! As far as I know, the many bugfix items I noted in my E-Mail to Eric REMAIN in FD-EMM386! They were fixed ONLY when Japheth did so within his own JEMM386, and FD-EMM386 itself remains NEVER-UPDATED!! Michael started with something, I don't remember what. But he grew so much disgusted with these fights that when the last issue got fixed, he *disapeared* Read the FD-EMM386 source file, to see what he started with. You should more-correctly say When the last issue HE KNEW ABOUT got fixed, he *disappeared*! If that were not so, then like I noted to Eric, HOW do you explain all those bugfix items which Japheth had to address LATER??!! But, Have it your way, Alain! If you wish to continue with a 5-year-old FD-EMM386 that has known BUGS and is NO-LONGER on the Base Software list for FreeDOS, then You go right ahead! and use FD-EMM386. As for me and quite a lot of others, I will use JEMM386, which I consider to be FAR superior and always WILL be! Jack R. Ellis -- 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
Re: [Freedos-user] Undeserved Comment Re: EMM/JEMM, A20, Etc.
Hello, As for me and quite a lot of others, I will use JEMM386, which I consider to be FAR superior and always WILL be! What exactly are the advantages of JEMM386? Is there a noticeable difference over FD-EMM386 if I am only using EMS for ramdisks/drivers? Are the bugs dependent on hardware? Jeffrey -- 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
Re: [Freedos-user] Undeserved Comment Re: EMM/JEMM, A20, Etc.
Jeffrey, As for me and quite a lot of others, I will use JEMM386, which I consider to be FAR superior and always WILL be! What exactly are the advantages of JEMM386? 1) Under current maintenance, not abandoned like FD-EMM386. 2) Many never-fixed FD-EMM386 bugs ARE fixed in JEMM386, as you can read in the JEMM ChangeLog at www.japheth.de. 3) Part of the FreeDOS Base Software list, meaning Cleverer minds than me! value JEMM386 above FD-EMM386, for FreeDOS. Is there a noticeable difference over FD-EMM386 if I am only using EMS for ramdisks/drivers? If you mean the very-old Lotus/Intel/Microsoft Expanded Memory then I cannot comment, as I have never used actual EMS memory. If by EMS you actually mean XMS memory, there should be little performance difference, as the XMS driver handles allocation/use of that memory. Are the bugs dependent on hardware? Most are not, but a few are. Read the JEMM ChangeLog, then you can decide which hardware-dependent problems might have affected its predecessor FD-EMM386. Jack R. Ellis -- 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
Re: [Freedos-user] Undeserved Comment Re: EMM/JEMM, A20, Etc.
Hi Jack, First of all, let me clear one MISSUNDERSTANDING... The EMM386 that works ok is from Michel Devore, which was extensevely tested by the members of FreeDOS. Most of your answer regards GatesCo product, sory for the confusion About the A20 issue. I used it because I had a very stange problem: after a crash (with only XMS) the machine never booted again from the disk!!! I had to boot once from a CD and reboot adain from the disk. That never happend to me and is completely unheard of... Alain Em 18-10-2011 23:25, Jack escreveu: 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 -- 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
Re: [Freedos-user] Undeserved Comment Re: EMM/JEMM, A20, Etc.
Alain, First of all, let me clear one MISUNDERSTANDING ... The EMM386 that works ok is from Michael Devore, which was extensevely tested by the members of FreeDOS. Most of your answer regards Gates Co. product, sorry for the confusion NEITHER a misunderstanding, NOR any confusion, at least not in MY mind! Do note what I posted AFTER my comments about the EMM386 drivers from my [obviously] much adored Gates Co. -- ... 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! Extensively tested, you say?? If so, and given that the last FD-EMM386 upgrade is still dated 27-Aug-2006, then how would you explain all the updates, in Japheth's Changelog for his JEMMEX and JEMM386 drivers, that are dated AFTER 27-Aug-2006??!! Also, note that JEMM386/JEMMEX are now part of the FreeDOS Base Software list, while FD-EMM386 is no-longer so included. I have reviewed Japheth's Changelog, I believe much of what he had to do changing FD-EMM386 to JEMM386 are Flat-Ass DISASTERS and I shall continue to AVOID using FD-EMM386, just like I would avoid the PLAGUE!! About the A20 issue. I used it because I had a very strange problem: After a crash (with only XMS) the machine never booted again from the disk!!! I had to boot once from a CD and reboot again from the disk. That never happened to me and is completely unheard of ... I suggest that a lot of other things besides the A20 line could have caused such a problem. In my opinion, you need quite a bit more evidence, BEFORE you can fault the A20 line only because your crash appeared to occur with only XMS!! Jack R. Ellis -- 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
Re: [Freedos-user] Undeserved Comment Re: EMM/JEMM, A20, Etc.
In my previous post about FD-EMM386 being changed to JEMM386, and to be perfectly clear, those Flat-Ass DISASTERS I noted are not at ALL in JEMM386 but are in FD-EMM386 and had to be CORRECTED by Japheth! Sorry for any confusion caused by me -- JEMM386/JEMMEX ARE the EMM drivers of choice, in my opinion! -- 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
Re: [Freedos-user] Undeserved Comment Re: EMM/JEMM, A20, Etc.
Jack, FD-EMM386 is very outdated, yes. But when it was still maintained, updates were often tested by a number of users. With JEMM, it is more like here is an update, enjoy. I have reviewed Japheth's Changelog, I believe much of what he had to do changing FD-EMM386 to JEMM386 are Flat-Ass DISASTERS and I shall continue to AVOID using FD-EMM386... Thanks for taking the time to read the changelog, can you give some examples of bad FD-EMM386 bugs which were fixed by JEMM? Of course there are zero JEMM bugs fixed by FD-EMM386, but that does not mean that JEMM is by definition free of bugs. I do believe Alain when he says that he did have data loss with the latter - which may not be due to bugs at all, maybe it is just that JEMM makes it easier for the users to shoot their own foot. Which is why I still think that FD-EMM386 also has some pretty nice sides. Even though I would NOT recommend to upgrade to a 5 year old FD-EMM386 for THAT reason. 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
Re: [Freedos-user] Undeserved Comment Re: EMM/JEMM, A20, Etc.
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
Re: [Freedos-user] Undeserved Comment Re: EMM/JEMM, A20, Etc.
Eric, FD-EMM386 is very outdated, yes. But when it was still maintained, updates were often tested by a number of users. With JEMM, it is more like here is an update, enjoy. I can sympathize with Japheth re: testing JEMM, as I have the same problem testing UIDE: Very FEW who DESIRE to test our drivers!! I have reviewed Japheth's Changelog, I believe much of what he had to do changing FD-EMM386 to JEMM386 are Flat-Ass DISASTERS [in FD-EMM386] and I shall continue to AVOID using FD-EMM386... Thanks for taking the time to read the changelog, can you give some examples of bad FD-EMM386 bugs which were fixed by JEMM? Ask, and Ye shall receive!, from the ChangeLog on the JEMM page at www.japheth.de -- 03/27/2007 bugfix: free EMS pages not always reported correctly. bugfix: translation DMA for 16-bit controller (channels 4-7) didn't work. 03/02/2007 bugfix: XMS function 11h (free UMB) always returned an error. 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. 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. bugfix: 1 kB of DMA buffer may have been inaccessible. bugfix: releasing a DMA buffer of size 1 kB always failed. 09/06/2006 bugfix: writing to ROM page FF000 if ALTBOOT wasn't set caused a crash. 08/25/2006 bugfix: unsupported VDS functions caused a debug display, which didn't work and may have caused corruption of monitor data. 08/23/2006 bugfix: DMA buffer is ensured to begin on a 64 kB physical address boundary. 08/17/2006 bugfix: in VCPI protected mode entry switch to host stack before context is switched. 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, from his predecessors. So, FD-EMM386 cannot (A) handle a VCPI switch, (B) has DMA-buffer address problems, (C) has VDS function-call problems and (D) has EMS-page problems!! Are those enough examples for you??!! Of course there are zero JEMM bugs fixed by FD-EMM386, but that does not mean that JEMM is by definition free of bugs. Nor can I expect my own XMGR or UIDE to be by definition free of bugs since I am not God! Bugs are a fact of life with software, but what need NOT be a fact is how so many do so little to FIX their bugs!! I do believe Alain when he says that he did have data loss with the latter - which may not be due to bugs at all, maybe it is just that JEMM makes it easier for the users to shoot their own foot. Then why, Eric, does FreeDOS have JEMM/HIMEMX in its Base Software list?? Your comment disparages the very system you support!! ... I absolutely REFUSE using old EMM386 by Gates Co. ... Nobody suggested to use the EMM386 by MS ... Glad to hear THAT, since neither do I!! ... I also want NOTHING to do with FD-EMM386 and anyone who wonders why can read the Revision Notes for JEMM386 ... Examples please ... See above, or read the JEMM ChangeLog yourself if you want more. ... 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. I get NO nightmares from FD-EMM386, since I have never USED it! On working to improve JEMM386, I like it as-is, I trust Japheth to make it better using HIS judgement, and I admit to NOT being enough of a protected-mode programmer to test it properly. We are all specialists in software, and my specialty is device drivers and caching, not protected-mode! 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? Can't say what code JEMM retains or does-not retain. I only said it retains all of EMM386's memory-dection logic, i.e., its METHODS are the same, no-matter what actual CODE it uses. 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 :-! Can't say there, either, as I avoid FD-EMM386 like the PLAGUE! 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. 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?? If a boot diskette is to get a system
