Hi Eric, > On May 3, 2021, at 5:05 AM, Eric Auer <e.a...@jpberlin.de> wrote: > > > Hi Jerome :-) > > I notice that in what probably gets installed to harddisk > > https://github.com/shidel/FDI/blob/master/FDISETUP/AUTOEXEC.BAT > <https://github.com/shidel/FDI/blob/master/FDISETUP/AUTOEXEC.BAT>
Close. But, no. The AUTOEXEC AND CONFIG in that directory are Templates used by the RBE to create the ones used by the various primary install boot media. They are not installed to the hard disk. They are only for the install media. So should be as universally compatible as possible. The ones that are processed and installed by the installer are located under https://github.com/shidel/FDI/tree/master/FDISETUP/SETUP <https://github.com/shidel/FDI/tree/master/FDISETUP/SETUP> Look for AUTOEXEC.* and CONFIG.* in that subdirectory. *.DEF is the default when a CPU/VM specific version is not provided. In other words, VirtualBox gets the normal AUTOEXEC.DEF but the special CONFIG.VBX. > > you have "outsourced" loading CD-ROM drivers to a separate > file. It would be nice to avoid that, there are not so many > drivers, I believe. Also, you load no CD cache (cdrcache or, > better, load uhdd before udvd2 and only use cdrcache for > eltorito and gcdrom) and have commented out, but not given > explanations for FDAPM, DOSLFN and LBACACHE. The syntax > used for LBACACHE is a deprecated one: Instead of your Some of the REMs are just leftover legacy boot stuff. But, some of the REM items are processed and “uncommented” and/or removed by the RBE during the build process based on what media it is going onto. With the handling of CD’s becoming much more that “load this driver". Trying different drivers. Looking for other vendor specifications ones that may or may not be present. It greatly increases the complexity of the AUTOEXEC and makes it much more difficult to read and edit. So, it has all been “off-loaded” into a CD specific initialization batch. The CD initialization among with a few other batch files are part of the new FDHELPER package. (please note: the eltorito driver is only present on the CD media. It is not installed or present on other media.) This has numerous benefits. It standardizes CD support for both the install media and the installed system. We can easily update just that package and potentially improve CD support everywhere. Also, improvements to CD support need not wait on a “new” release. the package can be updated at any time. > > rem FDAPM APMDOS > rem DOSLFN > rem LBACACHE.COM buf 20 flop > > I would suggest for example "LBACACHE 2048 FLOP" but as > said, UHDD would be even better, in particular because > it can share cache RAM with UDVD2. Only when using the > other CD drivers, you will have to add CDRCACHE, as in: > > 1. Load UHDD with options for your choice to cache harddisk > 2. Load CD-ROM driver to provide device e.g. RAWCDROM > 3. Load CDRCACHE.SYS RAWCDROM CDRCACH$ 12 > 4. Load SHSUCDX /D:CDRCACH$,N to assign drive N: to it > > When using UDVD2, you would instead: > > 1. Load UHDD with options of your choice to cache both > 2. Load UDVD2 and let it connect to UHDD for caching > 3. Do not load CDRCACHE and enjoy the low XMS usage :-) > 4. Load SHSUCDX /D:YourChosenUDVD2Name... > > Note that you can also tell SHSUCDX to try several > device names and silently skip those which are not > present, making it easy to add some flexibility. > > Please add ";" in front of comment lines even if > you skip them with a "goto". That helps for syntax > highlighting in editors. Ask for better syntax highlighting. LOL. > > As https://github.com/shidel/FDI/blob/master/FDISETUP/CONFIG.SYS > is very minimalistic, I would suggest to: The config is for the boot media. And should be very very minimal for maximum compatibility. > 1. not use SHELLHIGH, it could fail in some cases and > does not make much difference in RAM usage because we > already have the XMS Swap feature. Yeah, that should go. It’s a leftover from earlier configs. > 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? > 3. You may also consider options such as: > > SWITCHES=/E > BREAK=ON > COUNTRY=049 > lastdrivehigh=Z > fileshigh=20 > stacks=0,0 > fcbs=4,0 > > ... but of course that depends on country and taste ;-) > > Not sure what generates your CDROM.BAT so I cannot say > whether I have suggestions for that, but of course feel > free to ask for details if any of the other suggestions > above lack clarity. It’s not generated. It’s part of the fdhelper package. https://gitlab.com/FDOS/base/fdhelper <https://gitlab.com/FDOS/base/fdhelper> Your more than welcome to submit pull requests to it. Or, i guess you could just suggest them. :-) > Note that FDAPM is supposed to only use 386 specific > code in situations where the BIOS already supports > things only present on newer computers. So if there > are problems on 8086 or 286 PC, please let me know. I’m not aware of any CPU issues related to FDAPM. If I find or hear of them, I let you know. Interestingly, I did see something odd once related to FDAPM. Basically, during creation of the new RBE, I have spawned hundreds of VMs running FreeDOS under QEMU on Linux inside VirtualBox. When done in the QEMU instance FreeDOS, it terminates using FDAPM to shutdown. Exactly ONE time, the VM froze at the end of the "spinning down….” instead of terminating. I assume this was just some completely random issue with QEMU and not FDAPM. Like I said once out of hundreds of times doing. > That would simplify your current approach to have it > in CPU model dependent autoexec variants in setup, > as FDAPM is built with UPX --8086 by default. > > https://github.com/shidel/FDI/tree/master/FDISETUP/SETUP > > Also, you can use the 2 kB "CPULEVEL" tool instead of > VINFO but I guess you install VINFO everywhere anyway. Possibly. VINFO does more than just CPU level detection and I’d need to see if CPULEVEL is any use to the batch portion of the installer without a writeable filesystem and pipes. But, I’m not against using it. > >> C:\>cpulevel >> CPULEVEL - public domain by Eric Auer 2004-2007 >> CPU brand is GenuineIntel / CPU is family 5 model 2 revision c >> >> CPUID level 1 EAX_.... EBX_.... ECX_.... EDX_.... >> values are: 0000052c 00000000 00000000 000001bf >> >> CPUID level 1 feature bits in EDX: >> [FLOATING POINT] [VM EXT FLAGS] [debug ext] [Page Size Ext.] >> [TIMESTAMP COUNT] [Pentium MSR] [mce exception] [cmpxchg8b op] >> >> C:\>echo %errorlevel% >> 5 > > Of course you can do cpulevel > NUL if you prefer silence. > > You may also like my LOCALIZE tool for a low disk space, > but less elegant way of having language-specific strings > in batch scripts, for example for your floppy distro. > > Another useful trick is to load FDAPM ADV:REG (see fdapm.txt) > instead of FDAPM APMDOS, to avoid possible slower performance > with Novell network and Norton Utilities because ADV:REG is > slightly more humble in energy saving. > > Why are you avoiding CTMOUSE on 8086 PC? I think there had > been a thread about a patch to fix some forgotten 286-only > instructions, has that not been applied to CTMOUSE yet? Only based on looking at it. Could just be left over detritus and be fine with an 8086. Unfortunately, I haven’t had much luck running PCem or equivalents to test compatibility. Nor do I have anything older than a 486 for real hardware testing. > It seems important to use FDAPM APMDOS or similar in your > dosbox specific autoexec, too. Are there compatibility bugs? > As above, please use ";" in the dummy dosbox config.sys ;-) > > Your 286 config tries to use UMB and SHELLHIGH: Neither of > the two is possible because you do not load any UMB driver > and both EMM386-style and UMBPCI-style drivers would need > 386 or newer anyway. Few 286 mainboards had UMB, which did > come with special proprietary drivers at that time. Also, > the DOS=HIGH can only work for option 1 and you basically > only have 2 actually distinct options anyway: XMS or not. For the primary installer, it isn’t much of an issue. Since, seeing neither a USB port or CD-ROM is going to be in anything less than a 386, it won’t use them. But, they DO need fixed. The Floppy Only edition uses them. (no point in having duplicates of the 386+ in two projects, so they all just live with the primary installer). If I recall correctly, the 286 I had could load stuff in UMBS. But, that was a really long time ago and I could be completely wrong. > > https://github.com/shidel/FDI/blob/master/FDISETUP/SETUP/CONFIG.286 > > Because your AUTOEXEC does not seem to make choices based on > which MENU item people select in config.sys, your 186 config > probably should not have any menu at all: Looking at the wrong AUTOEXEC. The AUTOEXEC.DEF get installed on most systems. It uses both the config menu choice and CPU testing. However, in the future to simplify the autoexec for the end user, it may be better to just have different ones for the installer to pick from instead of doing it later at system boot in the autoexec itself. > https://github.com/shidel/FDI/blob/master/FDISETUP/SETUP/CONFIG.186 > > As far as I remember, I=TEST could be too aggressive in your > > https://github.com/shidel/FDI/blob/master/FDISETUP/SETUP/CONFIG.DEF > > and you should change "Expanded Memory" to "EMS 3.2 compatible" > and the "no EMS (most UMBs)" into "(EMS 4.0 only, more UMBs" to > reflect what the NOEMS option of JEMM386 and JEMMEX *really* is. > > Also, please remove the I=B000-B7FF from the JEMM386 line and > into the JEMMEX line: This option belongs to the category of > extreme efforts to get most UMBs, not to standard EMM386 use. > > For similar reasons, I suggest to use SHELLHIGH only for the > "max RAM free" option and not for the normal, JEMM386 item 2. > > While menu claims item 4 would have no drivers, I would just > call that "HIMEM only" or something like that, because you do > load HIMEM for all items anyway (in JEMMEX, it is a built-in). Thats a bug that will need fixed. "No drivers” should be NO DRIVERS. > Alternatively, you could switch to NOT even loading HIMEM in > item 4 to actually let it load "no drivers", as the menu says. > > Please make sure to use DOS=HIGH for item 3 and, if you keep > HIMEM for that, item 4. This gives you significantly more RAM. > > Last but not least, I think option 2 instead of the aggressive > "try to have most UMB and most free DOS RAM" choices of item 1 > should become the default. I think both option 1 and 2 *have* > caused problems for people so the proposed default "2" will be > more "humble" while option 1 will try everything to save RAM. > > Obviously, I suggest the same options for CONFIG.VBX and would > like to ask why Virtual Box has a separate config in the first > place: It looks pretty much identical to the default config? VirtualBox really doesn’t like option 1. So, for it the default is option 2. Only. difference between them. It is possible, that changing some of the settings in the default config.sys could eliminate the need for a special VirtualBox version. > I hope I have not overlooked too many other issues :-) As said, > let me know if you need more exact examples for some cases. You make a lot of good suggestions. The installed configs are far from perfect and could use a lot of fine tuning. I’ll look into it. If you want, you could always hop on GitHub make the changes you want and issue a pull request. :-) > > Thanks for updating! Regards, Eric :-) Jerome
_______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
