Hi Tom,
>> - being incompatible with VME, INVLPG or PGE in JEMM... >> - being incompatible with UHDD UltraDMA modes > > it would be helpful for people with these environments if you could > provide PRECISE instructions how to determine if these > incompatibalities exist or are solved. no 14KB rant, but like > > run EMM386 with option XYZ > see if program ABC works (and a clear description how Joe Average can > determine if program ABC works). Sure, can do that. I also liked your summary in the direction of "if things do not work, try tuning your config and autoexec" :-) So: Dear people with VirtualBox, Bochs, QEMU, VMware, Virtual PC! Please let me know if you can trigger any problem as follows: - load JEMMEX with options VME PGE I=TEST without NOINVLPG (load JEMMEX in config sys for that experiment, no HIMEM) http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/1.3/pkg-html/jemm.html - do the same with first loading HIMEMX, then JEMM386 (JEMM386 options VME PGE I=TEST etc. also in config sys) http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/1.3/pkg-html/jemm.html - do the same with first loading XMGR, then JEMM386 (with XMGR instead of HIMEMX, otherwise as above) http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/1.3/pkg-html/xmgr.html - load UHDD with the options /H /O using DEVLOAD (HIMEMX must be loaded before, DOS=HIGH required) http://mercurycoding.com/downloads.html#DOS (which is newer than the UHDD of the 1.3rc4 distro) Those are the most risky options which I think would be worth testing. Something like I=B000-B7FF is NOT to be used as default for any sane config anyway :-p You can do the UHDD test with or without EMM drivers, so maybe you can test "both" (or more: different EMM). Obviously, if your experiments do produce problems, retry with one of the "risk options" removed, until you know which of the options actually were not compatible with your virtual computer. Please tell which options have failed for you, as well as which version of which virtual computer you have used. Thank you! :-) Several other new compatibility topics: It would also be nice to test UHDD and UDVD2 together with ELTORITO, but given that it can be a lot of work to boot in a way where ELTORITO is supported, I do not dare to ask for that. I actually have good news about UHDD: You can load it before JEMMEX or JEMM386 to SOLVE problems with BIOS protected mode DMA bugs, by letting UHDD do the DMA instead of letting the BIOS do the DMA. Also, it turns out that the UHDD /E option is NOT needed for compatibility even with systems without UDMA support: It just saves some RAM by unloading the UDMA engine if you KNOW beforehand that your system will not use it. But EVERYBODY should use UHDD without /E by default, because UHDD always detects automatically whether it will use UDMA :-) As the current Live CD fails to keep your CPU cool: https://sourceforge.net/p/freedos/feature-requests/75 If we are really afraid of side effects of FDAPM APMDOS then simply use FDAPM ADV:REG instead, which saves a bit less energy, but avoids a slowdown for Novell. Now given that our Live CD includes no Novell drivers, this would probably never have been an actual problem anyway ;-) Another VERY annoying detail about our new packages is https://sourceforge.net/p/freedos/feature-requests/78/ the fact that they have lost all timestamps so you have no chance to know which file changed when :-( Probably another collateral casuality of GIT, sigh. I hope the timestamps can be reconstructed from old packages on ibiblio. After all, not that much has really changed recently. I suggest to use existing ZIP where possible, not re-create ZIP from individual content files, to make sure that timestamps survive. You can also use ZIP -o to timestamp a zip to the timestamp of the newest file inside the zip :-) Finally: I notice that JEMMEX and JEMM386 now default to no longer use VME because 2017 Ryzen editions have broken VME. I hope Japheth can improve that by explicitly excluding only the affected chip. Actually there even is a BIOS-workaround and second generation Ryzen fix the issue anyway: http://www.os2museum.com/wp/vme-broken-on-amd-ryzen/ https://www.os2museum.com/wp/vme-fixed-on-amd-ryzen/ Regards, Eric _______________________________________________ Freedos-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-user
