[Freedos-user] re: FreeDOS Post-1.0 todo list

[Eric Auer]

Hi Bernd, why would you want HIMEM to take XMS control
away from FDXMS286 / replace FDXMS286? The simpler way
is to load HIMEM first - if 386 present - and then load
FDXMS286: The latter will fail if either HIMEM loaded
successfully (386 or better CPU) or if a pre-286 CPU is
present. Makes more sense than loading HIMEM second and
making it replace FDXMS286: Replacing a loading FDXMS286
would be easy (ignore loaded driver, replace the handler)
but completely against specs and a waste of RAM (as the
FDXMS286 would stay in RAM without further use).

Eric


---
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS Post-1.0 todo list

[Bernd Blaauw]

Michael Devore schreef:

It isn't relevant, as it is overly specific for the example and 
ignores the real issue of conditional processing the example is used 
for.  But if you want an overly specific reply, it won't help that 
fdxms286 checks for a 286+-level if a 386-level driver is already loaded.


Again a nice theoretic discussion :) Anyway, are FreeDOS related 
programs and drivers also ment to be used on MSDOS or not as partial 
replacement?
If yes, then each driver will have to do the hard work itself, as we 
cannot change the MSDOS kernel (including config.sys parsing) even if we 
could change the FreeDOS kernel.


By the way, are drivers able to hijack interfaces from each other?
would first loading FDXMS286 and later HIMEM or FDXXMS.SYS gain access 
to XMS3.0 and 4GB (overriding FDXMS286 completely) or would these 
drivers *always* fail with a simple "XMS driver already loaded" ?


If they all worked I wouldn't need to use one instead of the other for 
reliable CD access.  Which I do.   In mathematical logic terms, that 
demonstrates a counterexample which falsifies the original statement.


Yes, it proves that both cdrom drivers are not universal enough. Each of 
them works for 99%.
I have no idea what happens if you try to load different drivers with 
same arguments.

DEVICE=VIDECDD.SYS /D:TEST2
DEVICE=MTMCDAI.SYS /D:TEST2
DEVICE=OAKCDROM.SYS /D:TEST2

It is almost impossible that you would fail to see the power of 
open-source load control of closed-source drivers at boot time, 
however it is implemented, yet you act deliberately obtuse on the 
matter.  Why, I don't know and don't care, the capability remains a 
powerful, flexible, and realistic goal.


There's many possibilities, and not only for CPU checks, but also XMS 
(and amount of it), presence of Memdisk arguments, etc.


Without doubt some interested person someday will find time to implement 
conditional parsing :)


Bernd


---
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS Post-1.0 todo list

[Michael Devore]

At 11:28 PM 10/10/2005 +0400, Arkady V.Belousov wrote:


MD>   %IF CHECK386 DEVICE=EMM386

 Why to duplicate checks, which already present in himem and emm386?


Why depend on on drivers to unload cleanly if they fail, which they already 
do not always do in closed-source drivers, despite protestations to the 
contrary.  Why not allow external load control based on any of a thousand 
conditions the driver was never and could never have been written to consider?


Someday I may also show you a device driver which uses UMBs, disproving the 
claim that none do.



MD>   ; CHECK286 program returns nonzero if 286-level chip found
MD>   %IF CHECK286 DEVICE=FDXMS286

 Isn't fdxms286 checks for 286?


It isn't relevant, as it is overly specific for the example and ignores the 
real issue of conditional processing the example is used for.  But if you 
want an overly specific reply, it won't help that fdxms286 checks for a 
286+-level if a 386-level driver is already loaded.



MD>   ; ISFLASH program detects USB flash driver presence with nonzero return
MD>   %IF ISFLASH DEVICE=USBASPI.SYS

 Who will write isflash.sys driver?


Well, let's see, it would be open-source or close-sourced as the author(s) 
choose.  Who will write FreeDOS?  Who will write EMM386?  Who will write Linux?


Nor need ISFLASH be a SYS driver; a COM or EXE would be fine.  COM 
obviously would be easiest to support.



 Both vide-cdd and oakcdrom are generic IDE drivers and there not need
other drivers, if you already use one of them.


If they all worked I wouldn't need to use one instead of the other for 
reliable CD access.  Which I do.   In mathematical logic terms, that 
demonstrates a counterexample which falsifies the original statement.



PS: No, I not see there useful examples.


It is almost impossible that you would fail to see the power of open-source 
load control of closed-source drivers at boot time, however it is 
implemented, yet you act deliberately obtuse on the matter.  Why, I don't 
know and don't care, the capability remains a powerful, flexible, and 
realistic goal.





---
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] re: FreeDOS Post-1.0 todo list

[Arkady V.Belousov]

Hi!

10-Окт-2005 20:57 [EMAIL PROTECTED] (Eric Auer) wrote to
freedos-user@lists.sourceforge.net:

EA> selection. I also think that the kernel should
EA> auto-detect floating point support, as several BIOSes
EA> fail to initialize the FPU, so the OS should do so before
EA> the first FPU-using program is launched.

 Just write initializing program and insert its call to start of
autoexec. BTW, which initialization for FPU does BIOS?





---
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS Post-1.0 todo list

[Arkady V.Belousov]

Hi!

10-Окт-2005 13:35 [EMAIL PROTECTED] (Michael Devore) wrote to
freedos-user@lists.sourceforge.net:

>>  Even if I introduce new interface, then it will be useful only for new
>>drivers. It will be useless for all existing drivers.
MD> Wrong.  It will be useful for _everything_:
MD> CONFIG.SYS:
MD>   ; CHECK386 program returns AL nonzero if 386+ level chip found
MD>   %IF CHECK386 DEVICE=C:\WHATEVER\PATH\HIMEM.EXE
MD>   %IF CHECK386 DEVICE=EMM386

 Why to duplicate checks, which already present in himem and emm386?

MD>   ; CHECK286 program returns nonzero if 286-level chip found
MD>   %IF CHECK286 DEVICE=FDXMS286

 Isn't fdxms286 checks for 286?

MD>   ; ISFLASH program detects USB flash driver presence with nonzero return
MD>   %IF ISFLASH DEVICE=USBASPI.SYS

 Who will write isflash.sys driver?

MD>   %IF ISFLASH DEVICE=DI1DI.SYS
MD>   ; ISVIDECD program detects whether CD needs VIDE driver
MD>   %IF ISVIDECD DEVICE=VIDE-CDD.SYS
MD>   ; otherwise try another generic driver
MD>   %IFNOT ISVIDECD DEVICE=OAKCDROM.SYS

 Both vide-cdd and oakcdrom are generic IDE drivers and there not need
other drivers, if you already use one of them.

MD>   ; if known broken BIOS fails critical operations, load workaround driver
MD>   %IF DETFAIL DEVICE=FIXBIOS.SYS

 Why not built checks into fixbios, when you will write it?

PS: No, I not see there useful examples.





---
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] re: FreeDOS Post-1.0 todo list

[Eric Auer]

Hi, I would like to comment on the method of first
running a TESTER and then doing a conditional DEVICE=...

Personally I think that detecting the CPU level (8086,
286, 386, 486, 586) can be useful in automatic config
selection. I also think that the kernel should
auto-detect floating point support, as several BIOSes
fail to initialize the FPU, so the OS should do so before
the first FPU-using program is launched.

On the other hand, I think that many drivers just skip loading
if no suitable hardware is found anyway - for example most CD-
ROM drivers do and UDMA2 does. First checking if there is some
ATA/IDE CD-ROM drive and then, if yes, running VIDE-CDD would
mean that you have to scan the bus twice, unnecessarily. Or you
would have to pass the bus scan results to VIDE-CDD as command
line options, of course.

I would recommend to check WHICH device drivers would gain from
the ability of running "if such hardware present then device="
style conditional load modes around them. I assume only a few
do, and most of them would be DEVLOADable anyway, so you can do
TESTER / IF errorlevel ... DEVLOAD DRIVER ... later in autoexec
and do not have to do conditional stuff in config sys.

Depending on which drivers are LEFT, we should decide about
kernel abilities to run testers / about kernel built-in testers.
I personally think that a CPU-level check would be enough,
and a conditional DEVICE=... would be enough (i.e. no need for
conditional versions of other config sys commands like INSTALL=),
although a CPU-level-conditional SHELL line can be useful. On
the other hand, I can write a wrapper which implements the
latter as "if enough free XMS is present then run FreeCOM XMS
swap, else run FreeCOM 8086 CALL /S version".

So my suggestion is: Review the needs, and think about a
new DEVICE variant CPUDEVICE[HIGH]=[minlevel],[maxlevel],[driver and args]
or similar, where you could do for example
CPUDEVICE=1,2,FDXMS286 ...
CPUDEVICE=3,,HIMEM ...
CPUDEVICE=3,,EMM386 ...
(the CPUDEVICE command would be combineable with n?command=...
style FreeDOS menu system, e.g. to select whether to try to load EMM386)

Eric



---
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS Post-1.0 todo list

[Michael Devore]

At 02:36 PM 10/9/2005 +0400, Arkady V.Belousov wrote:


>>  And how this should be look? Drivers doesn't return errorlevels,
>>whereas INSTALL= executed after DEVICE=.
MD> Perhaps you could have it conditional on a register return value from an
MD> application,

 Even if I introduce new interface, then it will be useful only for new
drivers. It will be useless for all existing drivers.


Wrong.  It will be useful for _everything_:

CONFIG.SYS:

 ; CHECK386 program returns AL nonzero if 386+ level chip found
 %IF CHECK386 DEVICE=C:\WHATEVER\PATH\HIMEM.EXE
 %IF CHECK386 DEVICE=EMM386
 ; CHECK286 program returns nonzero if 286-level chip found
 %IF CHECK286 DEVICE=FDXMS286
 ; ISFLASH program detects USB flash driver presence with nonzero return
 %IF ISFLASH DEVICE=USBASPI.SYS
 %IF ISFLASH DEVICE=DI1DI.SYS
 ; ISVIDECD program detects whether CD needs VIDE driver
 %IF ISVIDECD DEVICE=VIDE-CDD.SYS
 ; otherwise try another generic driver
 %IFNOT ISVIDECD DEVICE=OAKCDROM.SYS
 ; if known broken BIOS fails critical operations, load workaround driver
 %IF DETFAIL DEVICE=FIXBIOS.SYS

The actual %IF and %IFNOT were arbitrarily chosen as the conditional 
commands, of course.


If you want to get fancy, you allow stacking multiple conditionals per 
line, e.g. %IFNOT CHECK386 %IFNOT CHECK286 DEVICE=manager>.  As long as you're not spreading out conditionals along multiple 
lines with IF/ELSE/ENDIF -- a behavior which seems much more complicated 
and nasty to implement -- it could be a simple parse loop added to the 
original conditional.





---
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Soundblaster setup

[Tom Lee Mullins]

[EMAIL PROTECTED] wrote:


Yes, that was a rather stupid question about win drivers for DOS.
And is there any tip for a 100% DOS compatible PCI sound card? I mean no 
drivers, etc needed? 
Thanks in advance!


--- Original message ---
From: Brolin Empey <[EMAIL PROTECTED]>
To: freedos-user@lists.sourceforge.net
Subject: Re: [Freedos-user] Soundblaster setup
Date: Friday 07 October 2005 19:50
 


[EMAIL PROTECTED] wrote:
   


I've find some drivers here for this card
(http://members.driverguide.com/driver/detail.php?driverid=71335)
but as I can see those drivers for windows. Is there any chance that I
can make them work in FreeDOS?
 


No, you cannot use Windows drivers with FreeDOS.

Why don't you make things a lot easier and simply buy an ISA
SoundBlaster card?  Depending on the model, you do not need any drivers,
Plug & Play initialisation utilities, or any other software because DOS
applications supporting the SB provide their own routines to "drive" the
card.

I have two CT2960 (ViBRA 16C, according to the IC labelled U3 on the
board) cards which work with all DOS applications written to drive a
plain SB or SB16.


---
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
   



 


http://list.driverguide.com/list/DOS/company967/
Partial List of SoundBlaster DOS Drivers
http://list.driverguide.com/list/DOS/company258/

http://list.driverguide.com/list/DOS/company258/
soundblaster drivers for dos 


http://www.computing.net/windows31/wwwboard/forum/10418.html

I found the above results with Google. Does any of the above help?


--


TomLeeM / BigWarpGuy * * * * * *  * *
OS2eCS.org Director  of Communications *
* * * * OS/2 Warp - eComStation Org * * *  *
* * * *  http://www.os2ecs.org  * * * * * * * * *
Supporting Past OS/2 Uers and Future eCS Users
* * * * * * * * * * * * * * * * * * * * * * * * * * *  *



---
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user