Hi! > Look for AUTOEXEC.* and CONFIG.* in that subdirectory.
I have commented those, too, in some cases. In cases where they had the same bugs as commented for other files, I have not repeated the bug description in my mail each time. >> 2. use IDLEHALT=1 in config.sys to lower CPU usage on >> real and virtual systems even if you insist on avoiding >> to spend 912 bytes on FDAPM APMDOS ;-) > > Since it is only the installer, does it need it? Can it > introduce ANY compatibility or stability issues at all? If you want to be on the safe side, use only IDLEHALT=1, but FDAPM ADV:REG also is very tame. FDAPM APMDOS which is synonymous to ADV:MAX may slow down Novell or Norton Utils, which you both do not use in the installer anyway, though. > https://gitlab.com/FDOS/base/fdhelper https://gitlab.com/FDOS/base/fdhelper/-/blob/master/BIN/CDROM.BAT I guess those CD.xyz=... lines are later grepped from the file. Apparently the algorithm is to first try VIDE-CDD, OAKCDROM, GSCDROM, then UDVD2, ELTORITO, GCDROM, UIDE in that order, in spite of the first few not even being included? Why? And why that convoluted jumping up and down to try and retry? How can we even work with COMPUTED jump targets? That does not sound like a normal command.com feature? Classic style would be "load x, if worked jump to end, load y, if worked jump to end, load z, etc." :-) Given that you also attempt non-bundled drivers, add AHCICD? Storage drivers in UMB can cause troubles, but you only use UMB for ALL possible CD drivers. Without a fallback. How do you determine which drivers get which command line options? Those can differ per driver. For example if you load UDVD2 after UHDD, both can share cache, but if you use ELTORITO, you will have to load CDRCACHE as well, after ELTORITO. I think you want per-driver command line option configs anyway. At the moment, your SHSUCDX tries FIVE device names because you have not told the CD drivers which one you want ;-) Suggestion: 1. Load UHDD 2. Try various CD drivers, but let each one try to be FDCDROM1 3. If UDVD2 is not active, load CDRCACHE FDCDROM1 CDRCACH1 1024 4. Load SHSUCDX with ... /D:?CDRCACH1,D /D:?FDCDROM1,D so you only need 2 names. > Your more than welcome to submit pull requests to it. > Or, i guess you could just suggest them. :-) I do suggest them, in terms of the recommended changes. > I’m not aware of any CPU issues related to FDAPM. I meant because you take the effort to skip it pre-386 at boot. Of course it will not help much on those at all and probably just show a message anyway. I assume you used FDAPM POWEROFF in QEMU, after spinning down? And you say it hangs every few 100 cases? Keep an eye on that? >> Also, you can use the 2 kB "CPULEVEL" tool instead of >> VINFO but I guess you install VINFO everywhere anyway. For example for the 720k/... floppy edition, to save space. As said, CPULEVEL returns the generation as errorlevel, e.g. 2 for 286 and 3 for 386 and so on. No pipes needed. #special topic# Let me know whether CTMOUSE has been updated to 8086 or whether the patch got lost somewhere instead. No hurries, of course. I think it was something like "SHR with fixed count", either in the main code or in one of the include files: (the count2x macro is only used with CL) ctmouse.asm has "shl al,3" at 5 places, "shr ax,2" at 3 and "sar ax,2" at 1 in version 2.1beta2 for example. Not all are "if USE_286". See "updateposition", "gettxtoffset", "softreset_21" etc. Both CTMOUSE 2.1beta2 and CTMOUSE 1.9 are affected, but at different places, the latter also having a "shr si,2" and more "shr ax,3". The same for CTMOUSE 2.1beta3, so you would need something even newer if my analysis "no immediate shifts on 8086" is correct. I may have overlooked other problematic opcodes as well? #back on topic# >> Your 286 config tries to use UMB and SHELLHIGH Not sure if SHELLHIGH does auto-fallback to SHELL, or whether DOS=UMB or DOSDATA=UMB shows a warning. In any cases, it gives a bad example & impression ;-) > If I recall correctly, the 286 I had could load stuff in UMBS. As said, that needed special drivers and chipsets. Only 386 can use EMM386, only PCI can use UMBPCI, everything before that depended on chipsets and specific drivers. > VirtualBox really doesn’t like option 1. So, for it the default is option 2. As said, 1 is too aggressive to be default. Make one option "try hard to get most UMB" and the other "behave well and provide EMS 3.2 or at least (noems case) 4.0" and let the latter be the default. Or even let the HIMEM-only one be the default, if you like. But I guess on modern PC with weird A20, EMM386 can be more stable than HIMEM *if* you ask EMM386 to be humble in UMB selection. No I=... stuff! > The installed configs ... could use a lot of fine tuning. I’ll look into it. Thank you :-) Regards, Eric _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
