Yo..
 PH> CH> basicly, you do this (In Pascal..sorry!) :
 PH> nothing wrong with pascal compiled pascal code isn't so bad...
 PH> I know the code, but what I was saying is that : You don't know the
 PH> SB address, so you write #1 to some ports between $210 and $280.
 PH> Although most PCCard manufacturers avoid this range, it range can
 PH> also be used by other cards that are not soundcards. (e.g. I have
 PH> a videocard and DAQ board which can be configured so that tey use
 PH> one of these addresses)You don't know what will happen if such a
 PH> card gets a #1 in his port. The card may do nothing, it may crash,
 PH> it may corrupt the picture on screen, it may corrupt some data used
 PH> by other progs or by the system, which may cause the computer
 PH> to crash.
 PH> I know... this "try 'till it works"-method works most of the time,
 PH> but I don't like that. A good prog may not conflict with unknown
 PH> hardware. I once had a 256-color handscanner with a little interface
 PH> card. I always had to remove my soundcard before scanning, cause
 PH> otherwise my scanner would not work.
you raise some _very_ interesting points.
I'll speak about the issue of locating the SB first.
Firstly, the scan order is important. Only $210 and $220 will be touched in 
_most_ cases... the higher addresses (which are more likely to be used by 
other things) are not touched as you break out of the loop as soon as you 
find a card. Scanning highest to lowest would definately be more dangerous.
The SB 2.00+ only supports 210 and 220 so if your code needs these models, 
ignore testing >220 anyhow.
Finally, the code I posted is the "official" method, issued by Creative labs 
for detecting the SB. This code is used almost universally by "just about 
every sound program" including Microsoft windows... therefore any hardware 
that does conflict must be incompatable with any code using the SB, including 
Windows... therefore  the likelyhood of such hardware existing in this day 
and age is very low. you mention your hardware above that can be configured 
to conflict. I submit to you that any confiction thus created would render 
both devices inpoerable and thus this situation would not exist in a 100% 
working PC. It would only occurr in the workshops of technicians who would 
soon find the fault and fix it. (or in ignorant meddling users PC's!)
Now, for hardware detection code in general.
I would refer you to the source code to Linux, which implements a very 
reliable set of "auto-detect" drivers. Linux goes to great pains to avoid a 
"crashed by detection code" situation, and does so very well.
Linux keeps, amongst other things, tables of "already used" I/O ports, IRQ's, 
DMA's etc and won't test cards already using proposed test ports. This is a 
good start. Linux also loads it's drivers in an order designed to avoid
interdependancy issues, where possible, eliminates PnP, EISA, MCA & PCI 
devices before ISA ones, etc etc
In the end though, it's just NOT possible to do it perfectly every time, on 
every hardware platform. For example, you can crash some types of hardware 
just doing a READ from an I/O port!!
I always try to stick to the manufacturer's recommended hardware detection 
code.. that is usually far more reliable than any other method, when it's 
available. Some hardware, though, just can't be detected by software.. a good 
example is hardware with _only_ write-only ports, and no IRQ's or DMA's... it 
is really "invisible" to software, and easily upset by random port-writes.
       Craig
--- FMail/386 1.0g
---------------