PnP: Pruefen, ob I/O-Port belegt ist
-
Hiho.
Wenn der PC auf dem man gerade arbeitet kein Plug&Play-BIOS hat, muss man selbst handanlegen, und alle Plug&Play-Geraete initialisieren, bevor man diese nutzen kann.
Dazu muss man uA. pruefen, ob die Ressourcen, die man dem Geraet zuweisen will nicht schon belegt sind.Ich mache das bei den I/O-Ports im Moment so, dass ich ueberpruefe, ob die Ports den Wert FFh zurueckliefern. Wenn dem so ist, sollte da eigentlich nichts dranhaengen.
Dummerweise funktioniert das irgendwie nicht so, wie ich mir das gedacht habe - einige der Ports (die mit ziemlicher Sicherheit eigentlich unbelegt sind) liefern irgendeinen anderen Muell zurueck...
So schaut die Pruefroutine aus (ist fuer SoundBlaster PnP) :
;disable device mov dx ,0279h mov al ,30h out dx ,al mov dx ,0A79h mov al ,00h out dx ,al ;get free IO Port by looking for high impendance (FF) mov dx ,0220h @@GetIOPort0: mov cx ,0010h @@GetIOPort1: in al ,dx inc al jnz short @@NextPortRange0 inc dx loop @@GetIOPort1 add dx ,-10h jmp short @@PortRangeOK0 @@NextPortRange0: and dx ,02E0h add dx ,0020h cmp dx ,0280h jbe short @@GetIOPort0 mov al ,01h retf @@PortRangeOK0:Nun bin ich mir nicht mehr so ganz sicher:
Ist nur dieser ueber 10Jahre alte PC langsam dabei sein Leben auszuhauchen oder ist meine Ueberpruefungsmethode zu unsicher - dh. kennt jemand von euch eine bessere?
Danke schonmal im Voraus fuer eure Bemuehungen.
-
Ich hab zwar gerade nichts besseres zur Hand, aber kann ein Port an dem was dranhängt nicht auch aus ganz anderen Gründen 0xFF zurückgeben, z.B. weil er den Wert 0xFF gerade hat?
-
Ja, das kann auch sein, IMHO ist es jedoch eher unwahrscheinlich, dass dann dieses Geraet in mehr als einem Port nur FF zurueckgibt.
Tjoar, schon schlecht, dass die Creative-Karten keine PnP-I/O-Range-Check unterstuetzen.
[edit]Interessant ist uebrigens, dass alles problemlos unter DOS laeuft, sobald EMM386 geladen wurde.
[/edit]