Hello,
> On May 3, 2021, at 11:23 AM, Eric Auer <[email protected]> wrote:
>> [..]
>> 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.
Huh?
If understand correctly… You are referring to the section with
CD.INIT=blah blah
CD.GIVEUP=something else
and so on…
Grep is not used. Those are the “built-in” english translations
used by vecho (V8Power Tools) to display text to the user when/if
the language files and/or NLS path isn’t defined.
> 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?
We cannot distribute the proprietary drivers. So, my reasoning being
if a user installs it, they probably need it because none of the others
work. So, try it first.
> And why that convoluted jumping up and down to try and
> retry?
It can be improved. Possible probing the pci bus on supported hardware.
Then if a specific drive is seen, try its driver first. Always room for
improvement.
> How can we even work with COMPUTED jump targets?
> That does not sound like a normal command.com feature?
Works great. Also, simplified things.
After all, take the first driver…. You would
Check check for it in FDOS\BIN
if it isn’t there check in current directory
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…..
as opposed to
set driver=drivera
go try driver
Its a whole lot of duplication. prone to mistakes and typos.
Drivers can be added or removed easily.
Driver order can be changed without much difficulty.
Paths locations, and load methods can be added to the try section.
>
> 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?
Sure it can be added.
> Storage drivers in UMB can cause troubles, but you only
> use UMB for ALL possible CD drivers. Without a fallback.
Not saying your wrong. I know some drivers and programs
don’t like life on top.
Do you know of any of those that need to go low? Can easily add
several things. First, for know NO-HIGH drivers, a toggle could be
added to the list of drivers. A simple "set _HIGH=“ to turn it off , then
when loading DEVLOAD %_HIGH% wouldn’t do anything.
Also, It could try HIGH, then if that doesn’t work Try Low. Ether for
each driver in turn. Or try all one way than the other.
None of that is hard to add
> 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 present they all just use the same one defined as %_OPTS.CDROM%,
But, that can easily be changed. Thats why its a variable.
Just need to set it when setting the driver name.
> At the moment, your SHSUCDX tries FIVE device
> names because you have not told the CD drivers which
> one you want ;-)
Your right, Thats all legacy cut & paste. It should be shortened up.
No need testing for drivers that aren’t being assigned.
> 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.
>
>> 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’m probably wrong. But, I thought there wasn’t really a point in
trying to load it there <386 machines. If there is, then I’ll keep
it from being skipped over.
>
> I assume you used FDAPM POWEROFF in QEMU, after spinning down?
Yes
> And you say it hangs every few 100 cases? Keep an eye on that?
Like I said once. It could be 1 in hundred, 1 in a trillion or a stray
cosmic ray flipped a bit. I wouldn’t be that worried about it.
>
>>> 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.
Does it return 0 for 8086/88 and 1 for 186?
Good no pipes.
> [..]
> Thank you :-)
>
> Regards, Eric
Your welcome
;-)
Jerome
_______________________________________________
Freedos-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
