Hi! >> 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?
My point is that if I am ancient enough to download OAKCDROM somewhere, I will just say "gasp, what does that huge cdrom batch file do? Let me comment it out and put a single line for OAKCDROM into my autoexec instead" ;-) So I do not think the script should auto-detect whether the user has provided proprietary driver files to the script. I think if only UDVD2, ELTORITO, GCDROM and UIDE are free, also given that UIDE is basically the same as UDVD2+UHDD, you can simplify the loader a lot: 1. Make sure UHDD is loaded (harddisk speed, cache for both harddisk and UDVD2) 2. Try to load ELTORITO (works only if booted from CD) if it works, jump to 5 3. Try to load UDVD2 with appropriate device names (ATAPI IDE and legacy-friendly SATA) if it works, jump to 6 4. Try to load GCDROM with appropriate device names (I guess that one is SATA or AHCI?) if it works, jump to 5 else give up 5. Load CDRCACHE with appropriate device names 6. Load SHSUCDX with all device names mentioned so far (try the cdrcache one first, to use that if possible) In cases where you cannot test whether loading worked, you can simply load all 3 CD/DVD drivers, either with deliberately clashing device names or without, then adapt the SHSUCDX options. Of course that might add some complications to CDRCACHE use, but you do not need it for UDVD2 anyway, so you can do: 1. UHDD 2. ELTORITO 3. CDRCACHE 4. UDVD2 5. GCDROM 6. SHSUCDX With different device names for each step and giving SHSUCDX /D:?name... options for all of those names. Tell 3. the output name of 2. as input and give 6. the output name of 3. as preferred over the one of 2. Because 3. will fail if 2. fails, the worst that would happen is having multiple working drivers loaded, yet using only the first. This method also fails to give GCDROM a cache, BUT it is completely free of "IF" lines and it even still works if there is too little RAM which will automatically skip loading CDRCACHE. > Check check for it in FDOS\BIN > if it isn’t there check in current directory Just know where your drivers are. After all, it is you who put them there. See above regarding proprietary ones. > if did not find it, skip to the next driver > output a message saying what driver your going to try > try the driver > output a message saying ion it succeeded or not > if it didn’t go try the next driver > if it did go try to load the cd extensions > same thing for the extender You can do things the complicated way. Or the easy way. > Drivers can be added or removed easily. It is not as if 3 or 4 drivers would be a large loop: ELTORITO, UDVD2 and GCDROM. If we are lucky, AHCICD. > Do you know of any of those that need to go low? The thing is that sometimes UMB are not good for I/O buffers, so it depends more on the chipset than on which CD driver you use. Of course some avoid doing I/O in UMB even when you load them there, for example because they only do I/O to and from user-provided buffers (so the question becomes whether your OTHER apps are in UMB) or because they deliberately alloc buffers at special locations. Interestingly, there is a command line option for lbacache to even alloc a local STACK outside UMB because exotic SCSI BIOS turned out to not like you otherwise. Non-default. > Also, It could try HIGH, then if that doesn’t work Try Low. Would not do that. Non-working usually means transfer errors or crashes, which you cannot probe for by trial and error in a script. I would not make it a parameter either, just hardcode a safe or daring choice for each of the drivers. UDVD2 and ELTORITO use little RAM as far as I know, so you can load them low all the time if you want to be foolproof for all chipsets. (NOTE: I have not checked the UDVD2 docs about this, it may even use smart design to be foolproof in UMB) >> 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. > > I’ll need to give it a try. If I forget, yell at me. Lovely, thanks :-) > I’m probably wrong. But, I thought there wasn’t > really a point in trying to load it there <386 machines. My point was to simplify things by reducing conditionals, but looking at your thoughts on CD/DVD drivers you like to add as much complexity to scripts as you can :-p You are correct that FDAPM is barely of any use pre-386, because even without FDAPM, they don't even need coolers. CPULEVEL can return values between 0 and at least 15, but it will never return 1 because it does not take the effort to distinguish 8086 from 186. There are checks to detect 286 and 386. For everything higher than that, it returns the x86 "x" value according to CPUID. I guess it will return 3 for certain 486 with no CPUID support because of that. The tool is quite small, but exactly good enough for your task ;-) The list of GOOD descriptions ends at Pentium Pro, so all newer CPU will be described as "similar to" Itanium or Xeon, not the proper name. Update if you like ;-) Do you have CPU-specific actions for 186? If so, is it a problem to only trigger on 286 and newer because the detection does not distinguish the "exotic" 186? Regards, Eric _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
