Was ist ein Soundkartentreiber unter MS-DOS wirklich?
Meines Wissens bieten weder MS-DOS noch BIOS irgendeine API für Soundkarten. Daher fehlt das Konzept eines "Fahrers", wie wir es heute kennen. Was benötigt ein DOS-Programm, um eine Soundkarte zu verwenden, abgesehen von Zubehör, Beispieldateien und Windows-Inhalten, die im Setup-Paket enthalten sind?
Eine Sache, die ich irgendwo gelesen habe und nicht mehr finden kann, ist, dass einige Soundkarten beim Einschalten "inaktiv" sind und eine Art Initialisierung benötigen, um zu funktionieren. Können Sie dies bitte kommentieren?
Antworten
Die typische Möglichkeit, "Treiber" -Dienste für andere Programme unter DOS bereitzustellen, besteht darin, ein TSR-Programm (Terminate and Stay Resident) auszuführen, das einen Software-Interrupt-Vektor installiert, sodass beim Ausführen von DOS-Programmen diese INT für Dienste aufgerufen werden kann (siehe Ralph Browns Interrupt-Liste ).
Im Soundkontext führen Programme die Geräte-E / A jedoch in der Regel direkt durch, indem sie E / A-Ports direkt lesen und schreiben und bei Bedarf Interrupts und DMA-Übertragungen verarbeiten. Vielleicht zumindest teilweise aufgrund der Tatsache, dass sich Multimediadienste schnell weiterentwickelten.
Ohne die von DOS bereitgestellte Ressourcenverwaltung müssten Sie Geräte manuell erkennen, was etwas schwierig sein und möglicherweise Abstürze auslösen kann, je nachdem, was gerade im E / A-Bereich installiert wurde. Es ist möglich, dass einige Geräte nur einen minimalen E / A-Platzbedarf überwachten, bis eine Init-Sequenz ausgeführt wurde, um dieses Risiko zu verringern. Dies ist jedoch kein Verhalten, das ich anhand der Soundroutinen erkenne, die ich selbst für AdLib, Roland MPU-401 MIDI und den klassischen SoundBlaster geschrieben habe Karten.
Die Erkennung basierte hauptsächlich auf herkömmlichen E / A-, IRQ- und DMA-Zuweisungen, ergänzt durch Konventionen für Umgebungsvariablen, in denen diese Konfigurationspunkte angegeben wurden.
Sie haben im Grunde genommen einen Code geschrieben, der nur ein bestimmtes Ergebnis in der Präsenz des erwarteten Geräts liefern sollte (fx Einrichten der integrierten Timer auf der AdLib-Karte) und ihn blind gegen die herkömmlichen oder angegebenen E / A-Adressen und Sägen ausgeführt was vom Himmel fiel.
Zusammenfassung:
Real Sound Blasters benötigen keinen Treiber, um sie zu initialisieren oder zu unterstützen. Klone müssen möglicherweise einmalig initialisiert werden. Exotische Karten benötigen möglicherweise speicherresidente Übersetzungsschichten.
Spiele verwenden eine Sammlung von Kartentreibern, um mit den entsprechenden Hardwareschnittstellen zu "sprechen". Diese können fest in das Spiel oder eine Sammlung externer Dateien wie in HMI oder Miles codiert werden.
Abhängig von Ihrer Situation kann eine oder beide davon zutreffen.
Um Halloween Harry auf einem echten Sound Blaster zu spielen, werden keine zusätzlichen Dateien benötigt. Die SB-Unterstützung ist fest codiert.
Um Theme Hospital auf einer SB Live PCI unter MS-DOS zu spielen, verwendet das Spiel einen Miles-Treiber eines Drittanbieters, um die SB-Karte zu abstrahieren. Für die Karte selbst ist ein Live-Treiber erforderlich, um die Hardwareschnittstelle einer älteren SB-Karte zu imitieren.
Alle hier bisher gegebenen Antworten sind für verschiedene Szenarien richtig. Was verwirren kann, ist, dass es zwei unterschiedliche Phasen gibt, die beide korrekt als "Treiber" bezeichnet werden könnten. Lassen Sie mich beschreiben, was ich meine:
Hier gilt so ziemlich alles für die digitalisierte Audioausgabe und die AdLib / OPL2 / OPL3-Unterstützung gleichermaßen.
1) Initialisierung und Unterstützung für die Bereitstellung der Schnittstelle
Legitime Sound Blaster-Kartenserien von Erstanbietern werden direkt über E / A-Ports programmiert. An Bord befindet sich ein Chip namens "DSP" *, der die gesamte Datenbewegung zur und von der Karte übernimmt. Wenn Sie einen echten Sound Blaster haben und das Spiel weiß, wie man Sound Blaster über die im Hardware-Programmierhandbuch der Sound Blaster-Serie beschriebene Schnittstelle mit dem DSP "spricht" , ist dies alles, was benötigt wird.
* (Nicht zu verwechseln mit einem 'DSP' in der späteren Verwendung, der normalerweise einen programmierbaren Effekt wie Hall liefert.)
Wenn Sie eine Klonkarte oder eine kompatible Karte eines Drittanbieters haben, gilt eine der folgenden Bedingungen:
- Die Klonkarte fungiert genau als eine der Karten der Sound Blaster-Serie, und es ist kein weiteres Eingreifen eines "Treibers" erforderlich.
- Die Karte startet "inert" und erfordert eine Initialisierung. Dies ist bei PnP-kompatiblen Karten von 1995-1997 üblich, deren IRQ- und DMA-Einstellungen nicht über Jumper, sondern über Software vorgenommen werden. Für meine Avance ALS100 + -basierten Karten und CMI8330-Karten muss ein Startprogramm ausgeführt werden, bevor sie funktionieren. Dieses Programm spricht mit der Karte, teilt ihr mit, welche IRQ und DMA verwendet werden sollen, und ab diesem Zeitpunkt fungiert die Karte als Klonkarte. Im Speicher befindet sich kein dauerhaftes Programm, mit dem die Sound Blaster DSP-Befehle eines Spiels in Avance-Befehle usw. übersetzt werden können. Wenn Sie den 'Treiber' für eine klonähnliche Karte installiert haben, trifft dies höchstwahrscheinlich auf Sie zu.
- Wenn die Karte nicht direkt als Klonkarte fungieren kann, weil sie exotisch ist wie ein Gravis-Ultraschall oder eine sehr neue (relativ gesehen: nach 1996) Sound Blaster / Ensoniq-PCI-Karte, kann sie nicht einfach als Karte initialisiert werden SB-Klonkarte. Für diese Karten muss eine Software-Shim-Schicht geladen werden, um Sound Blaster DSP-Befehle abzufangen und in Echtzeit in Befehle zu übersetzen, die die Karte versteht. Für die GUS ist dies SBOS. Wenn das Spiel, das Sie spielen, von Haus aus GUS unterstützt, benötigen Sie kein SBOS. Bei Karten ohne vorhandene FM-Chips / Klon-Chips kann die Shim-Schicht das Audio in Software in Echtzeit mit gemischten Ergebnissen synthetisieren.
2) Spielunterstützung, um die Schnittstelle zu konsumieren
Völlig unabhängig von den oben genannten ist der "Treiber", der dem Spiel die Möglichkeit bietet, mit einer bestimmten Soundkarte zu sprechen. Dies könnte genauer als Audiobibliothek bezeichnet werden, aber da es auch mit den DSP-Prozessoren Sound Blaster / Windows Sound System usw. kommunizieren muss, ist es auch ein Treiber. In dieser Hinsicht ist ein DOS-Spiel wie ein Mini-Betriebssystem für sich.
Dieser Treiber hat die Form einer Bibliothek von Routinen, die die Basisprimitive der Soundkartenschnittstelle in einen nützlichen, konsistenten Befehlssatz für Spieleentwickler abstrahieren.
Ein Sound Blaster bietet für sich genommen einen einzigen Audio- und FM-Ausgangsstrom. Ein Gravis Ultrasound oder SB AWE bietet eine Wavetable-Schnittstelle zu mehreren kurzen Loop-Streams von Soundkarten-RAM-residenten Samples (zusätzlich zum digitalisierten SB-Stream und FM für den AWE). Der PC-Lautsprecher piept.
Der Spielprogrammierer möchte nicht über diese Detailstufe nachdenken - er möchte Musik starten, eine Explosion spielen usw. Es wäre Aufgabe des Fahrers, diese Details zu abstrahieren: Ausgabe starten / stoppen, Soundeffekte starten / stoppen, mischen sie, Volumen ändern, etc.
In frühen Spielen wurden diese Treiber auf eine Art Ad-hoc-Weise direkt in das Spiel codiert - Halloween Harry kann nur Original-Sound Blasters unterstützen, und die Unterstützung ist fest im Spiel codiert. Rise of the Triad verfügt über eine eigene riesige Soundbibliothek. Da RoTT Open Source ist, können Sie alle verschiedenen Initialisierungs- und Unterstützungsroutinen auf Github anzeigen .
Für späte, ausgereifte MS-DOS-Spiele wie Theme Hospital wird eine Bibliothek wie Miles oder HMI verwendet. Wenn Sie einen Bildschirm zum Einrichten einer Soundkarte mit Dutzenden verfügbarer Soundkarten gesehen haben, verwenden diese höchstwahrscheinlich eine dieser Bibliotheken. Ich weise darauf hin, da die verschiedenen Soundkartentreiber in einem Verzeichnis als .386
oder .ovl
oder .hmi
Dateien angezeigt werden können. Epische MegaGames Jensen-Bibliotheksspiele wie One Must Fall 2097 und Jazz Jackrabbit speichern ihre Soundkartentreiber in MDRV---R.MUS
Dateien.
Die Soundkartentreiber in 1) werden bei Bedarf zusammen mit Ihrer Soundkarte auf einer Installationsdiskette bereitgestellt.
Die Soundkartentreiber in 2) würden mit oder als Teil der Spiele selbst bereitgestellt.
Die meisten PCI-Soundkarten bieten keine Hardwareunterstützung für Spiele und andere Anwendungen, bei denen ein SoundBlaster oder AdLib vorhanden sein soll. Ältere Karten haben besondere Anstrengungen unternommen, um die so genannte "Kompatibilität auf Registerebene" bereitzustellen, damit sie mit einer Vielzahl vorhandener Spiele verwendet werden können. Als PCI eintraf, war Windows das PC-Betriebssystem der Wahl, sodass die Kompatibilität mit DOS-Spielen auf Hardwareebene weniger wichtig war.
Der DOS- "Treiber" für diese neueren Karten ist eine Emulationssoftware, die Zugriffe auf die E / A-Ports abfängt, die normalerweise von Adlib- und SB-Hardware belegt werden, und diese in Befehle für die tatsächlich vorhandene Soundkarte konvertiert. Dies kann das Durchführen einer Audiosynthese und / oder das Mischen in Software umfassen.
Wie bei jeder Hardware muss die Hardware einer Soundkarte nach dem Einschalten in einem nicht konfigurierten Zustand „betriebsbereit“ sein.
Normalerweise besteht dies darin, bestimmte Werte in bestimmte Hardware-Ports und / oder Speicheradressen zu schreiben (nach dem Testen auf das Vorhandensein der Soundkarte). Danach ist die Soundkarte betriebsbereit.
In Windows oder anderen modernen Betriebssystemen wird dies von einem Treiber ausgeführt, wenn das Betriebssystem gestartet und nach vorhandener Hardware gesucht wird. Unter DOS wird diese Konfiguration (normalerweise) vom Spiel oder der Anwendung unter Verwendung der Soundkarte beim Start vorgenommen. Vor dem Start der Anwendung ist die Hardware noch nicht konfiguriert.
Bei der Einführung des Sound Blaster bestand die dokumentierte Möglichkeit zur Verwendung der digitalisierten Audiofunktionen darin, einen mitgelieferten Code-Blob zu verwenden, der von Creative Labs bereitgestellt wurde. Wenn Speicherplatz zur Verfügung steht, muss dieser Code-Blob unter Verwendung eines Vielfachen von 16 Adressen in den RAM eingelesen und mit einer normalisierten Form dieser Adresse aufgerufen werden (Versatz Null des Segments, bei dem er gerade begonnen hat). Wenn Speicher dient, wurde die MIDI-Schnittstelle in Bezug auf E / A-Port-Operationen definiert, und in der Dokumentation wurde möglicherweise angegeben, wie Code, der schnell genug ausgeführt werden konnte, einzelne Samples an einen E / A-Port ausgeben konnte, ohne DMA zu verwenden [was endete wie viele Programme tatsächlich den SoundBlaster verwendet haben], aber ich denke, Creative Labs erwartete, dass die Leute den mitgelieferten Code-Blob verwenden würden. Ich glaube jedoch nicht, dass es klar warob sie erwartet hatten, dass Programmierer diesen Blob immer in eine Datei mit einem bestimmten Namen an einer bestimmten Stelle einfügen würden, damit er durch alternative Implementierungen ersetzt werden kann, oder wie viel Speicherplatz sie von Programmierern erwarten würden, um ihn zuzuweisen.