Che cos'è veramente un driver della scheda audio in MS-DOS?
Per quanto ne so, né MS-DOS né BIOS offrono alcun tipo di API per le schede audio. Quindi il concetto di "guidatore" è assente, così come lo conosciamo oggi. A parte gli accessori, i file di esempio e le cose relative a Windows che si trovano nel pacchetto di installazione, quali sono gli elementi essenziali necessari affinché un programma DOS utilizzi una scheda audio?
Una cosa che ho letto da qualche parte e non riesco più a trovare è che alcune schede audio sono "inattive" all'accensione e necessitano di una sorta di inizializzazione per funzionare. Puoi per favore commentare questo?
Risposte
Il modo tipico per fornire servizi "driver" ad altri programmi in DOS è eseguire un programma TSR (Terminate and Stay Resident) installando un vettore di interrupt software in modo tale che l'esecuzione di programmi DOS possa richiamare questo INT per i servizi (vedere l'elenco degli interrupt di Ralph Brown ).
Nel contesto del suono, tuttavia, i programmi tipicamente eseguono l'I / O del dispositivo direttamente leggendo e scrivendo direttamente le porte I / O, gestendo gli interrupt e i trasferimenti DMA quando pertinente. Forse a causa, almeno in parte, della rapida evoluzione dei servizi multimediali.
Senza la gestione delle risorse fornita dal DOS, dovresti rilevare manualmente i dispositivi che potrebbero essere un po 'complicati e potenzialmente innescare arresti anomali a seconda di ciò che è successo per essere installato nello spazio I / O. È possibile che alcuni dispositivi abbiano monitorato solo un footprint I / O minimo fino a quando non è stata eseguita una sequenza di inizializzazione per ridurre questo rischio, ma questo non è un comportamento che riconosco dalle routine sonore che ho scritto io stesso per AdLib, Roland MPU-401 MIDI e Classic SoundBlaster carte.
Principalmente, il rilevamento si basava su allocazioni convenzionali di I / O, IRQ e DMA integrate da convenzioni di variabili di ambiente che specificano questi punti di configurazione.
Fondamentalmente hai scritto un pezzo di codice che dovrebbe dare solo un certo risultato nella presenza del dispositivo atteso (fx che imposta i timer di bordo sulla scheda AdLib) e lo hai eseguito alla cieca contro gli indirizzi I / O convenzionali o specificati e visto ciò che è caduto dal cielo.
Sommario:
I Real Sound Blaster non hanno bisogno di un driver per inizializzarli o supportarli. I cloni potrebbero richiedere un'inizializzazione una tantum. Le carte esotiche potrebbero richiedere livelli di traduzione residenti in memoria.
I giochi utilizzano una raccolta di driver per scheda per "dialogare" con le interfacce hardware appropriate. Questi possono essere codificati nel gioco o una raccolta di file esterni come in HMI o Miles.
A seconda della situazione, uno o entrambi possono essere applicati.
Per riprodurre Halloween Harry su un vero Sound Blaster, non sono necessari file aggiuntivi. Il supporto SB è hardcoded.
Per riprodurre Theme Hospital su un SB Live PCI in MS-DOS, il gioco utilizza un driver Miles di terze parti per astrarre la scheda SB. La scheda stessa richiede un driver Live per imitare l'interfaccia hardware di una vecchia scheda SB.
Tutte le risposte qui fornite finora sono corrette, per diversi scenari. Ciò che può confondere è che ci sono due fasi distinte che entrambe potrebbero essere correttamente chiamate "driver". Lasciatemi descrivere cosa intendo:
Praticamente tutto qui si applica sia all'uscita audio digitalizzata che al supporto AdLib / OPL2 / OPL3 allo stesso modo.
1) Inizializzazione e supporto per fornire l'interfaccia
Le serie di schede Sound Blaster legittime e originali vengono programmate direttamente tramite le porte I / O. C'è un chip a bordo noto come "DSP" * che gestisce tutti i movimenti di dati da e verso la scheda. Se disponi di un vero Sound Blaster e il gioco sa come "comunicare Sound Blaster" al DSP utilizzando l'interfaccia descritta nella Guida alla programmazione hardware della serie Sound Blaster, è tutto ciò che serve.
* (Da non confondere con un "DSP" nell'utilizzo successivo che in genere fornisce un effetto programmabile come il riverbero.)
Se si dispone di una carta clone o di una "carta compatibile" di terze parti, si applica una delle seguenti condizioni:
- La scheda clone agisce esattamente come una delle schede della serie Sound Blaster e non è necessario alcun ulteriore intervento da parte di un "driver".
- La scheda inizia "inerte" e richiede una certa inizializzazione. Questo è comune con le schede compatibili PnP 1995-1997 le cui impostazioni IRQ e DMA vengono eseguite nel software piuttosto che tramite ponticelli. La mia scheda basata su Avance ALS100 + e le schede CMI8330 richiedono un programma di avvio per essere eseguito prima di poter funzionare. Questo programma parla alla scheda, le dice quale IRQ e DMA usare e da quel momento in poi la scheda agisce come una carta clone. Nessun programma persistente risiede nella memoria per tradurre i comandi DSP di Sound Blaster di un gioco in comandi Avance, ecc. Se hai installato il "driver" per una scheda simile a un clone, molto probabilmente questo si applica a te.
- Se la scheda non è in grado di agire direttamente come una scheda clone perché è esotica come una Gravis Ultrasound, o una nuovissima (relativamente parlando: post 1996) scheda Sound Blaster / Ensoniq PCI, allora non può essere semplicemente inizializzata per agire come una Carta clone SB. Queste schede richiedono il caricamento di uno strato di shim software residente per intercettare i comandi DSP di Sound Blaster e tradurli in tempo reale in comandi che la scheda comprende. Per il GUS, questo è SBOS. Se il gioco a cui stai giocando supporta nativamente GUS, non hai bisogno di SBOS. Per le schede senza chip FM / chip clone presenti, lo strato di shim può sintetizzare l'audio nel software in tempo reale, con risultati contrastanti.
2) Supporto del gioco per -consumare- l'interfaccia
Completamente indipendentemente da quanto sopra, è il "driver" che fornisce la capacità del gioco di parlare con una specifica scheda audio. Questo potrebbe essere chiamato più precisamente una libreria audio, ma poiché deve anche parlare con i processori DSP Sound Blaster / Windows Sound System, ecc., È anche un driver. Sotto questo aspetto, un gioco DOS è una sorta di mini-sistema operativo in sé.
Questo driver assume la forma di una libreria di routine che astraggono le primitive di base dell'interfaccia della scheda audio in un insieme utile e coerente di comandi per gli sviluppatori di giochi.
Di per sé, un Sound Blaster fornisce un unico flusso di uscita di audio e funzionalità FM. Un Gravis Ultrasound o SB AWE fornisce un'interfaccia wavetable a più flussi di loop brevi di campioni residenti nella RAM della scheda audio (oltre al flusso digitalizzato SB e FM, per AWE). L'altoparlante del PC emette un segnale acustico.
Il programmatore del gioco non vuole pensare a questo livello di dettaglio: vuole avviare la musica, riprodurre un'esplosione, ecc. Sarebbe compito del conducente astrarre questi dettagli: inizio / interruzione dell'output, avvio / arresto degli effetti sonori, mix loro, alterare i volumi, ecc.
I primi giochi avrebbero codificato questi driver direttamente nel gioco in una sorta di modo ad hoc: Halloween Harry può supportare solo Sound Blasters originali e il supporto è hard-coded nel gioco. Rise of the Triad ha la sua enorme libreria di suoni; poiché RoTT è open source, puoi vedere tutte le diverse routine di inizializzazione e supporto su Github .
Per i giochi MS-DOS più recenti e maturi come Theme Hospital , viene utilizzata una libreria come Miles o HMI. Se hai visto una schermata di configurazione della scheda audio con dozzine di schede audio disponibili, molto probabilmente usano una di queste librerie. Lo faccio notare poiché i diversi driver della scheda audio possono essere visualizzati in una directory elencata come file .386
o .ovl
o .hmi
. I giochi della libreria Epic MegaGames Jensen come One Must Fall 2097 e Jazz Jackrabbit memorizzano i driver della scheda audio in MDRV---R.MUS
file.
I driver della scheda audio in 1) verranno forniti su un disco di installazione con la scheda audio, se necessario.
I driver della scheda audio in 2) sarebbero forniti con o parte dei giochi stessi.
La maggior parte delle schede audio PCI non dispone del supporto hardware per giochi e altre applicazioni che prevedono la presenza di SoundBlaster o AdLib. Le schede più vecchie facevano uno sforzo speciale per fornire la cosiddetta "compatibilità a livello di registro", in modo che potessero essere utilizzate con un'ampia gamma di giochi esistenti. Quando arrivò il PCI, Windows era diventato il sistema operativo per PC preferito, quindi la compatibilità con i giochi DOS era meno importante a livello hardware.
Il "driver" DOS per queste nuove schede è in realtà un software di emulazione, che intercetta gli accessi alle porte I / O normalmente occupate dall'hardware Adlib e SB, e li converte in comandi sulla scheda audio presente. Ciò può includere l'esecuzione di sintesi audio e / o missaggio nel software.
Come qualsiasi hardware, l'hardware di una scheda audio deve essere "preparato per il funzionamento" dopo essere stato acceso in uno stato non configurato.
Di solito si tratta di scrivere determinati valori su determinate porte hardware e / o indirizzi di memoria (dopo aver testato la presenza di detta scheda audio). Dopodiché, la scheda audio è pronta per il funzionamento.
In Windows o in qualsiasi altro sistema operativo moderno, questo viene fatto da un driver all'avvio del sistema operativo e alla ricerca di qualsiasi hardware presente. In DOS questa configurazione viene (di solito) eseguita dal gioco o dall'applicazione utilizzando la scheda audio quando viene avviata. Prima dell'avvio dell'applicazione, l'hardware non è ancora configurato.
Quando Sound Blaster è stato introdotto per la prima volta, il modo documentato di utilizzare le funzionalità audio digitalizzate era quello di utilizzare un blob di codice fornito da Creative Labs. Se la memoria serve, l'uso di questo blob di codice richiedeva di leggerlo nella RAM a un indirizzo multiplo di 16 e invocarlo con una forma normalizzata di quell'indirizzo (offset zero di qualunque segmento fosse iniziato). Se la memoria serve, l'interfaccia MIDI è stata definita in termini di operazioni sulla porta I / O e la documentazione potrebbe aver specificato come il codice che è stato in grado di funzionare abbastanza velocemente potrebbe inviare singoli campioni a una porta I / O senza usare DMA [che è finito essendo quanti programmi utilizzavano effettivamente SoundBlaster], ma penso che l'aspettativa di Creative Labs fosse che le persone usassero il blob di codice fornito. Non credo fosse chiaro, tuttavia,se si aspettassero che i programmatori mettessero sempre quel blob in un file con un certo nome in un certo posto in modo da permetterne la sostituzione con implementazioni alternative, o quanto spazio si aspettavano che i programmatori gli assegnassero.