¿Qué es realmente un controlador de tarjeta de sonido en MS-DOS?
Que yo sepa, ni MS-DOS ni BIOS ofrecen ningún tipo de API para tarjetas de sonido. Por tanto, el concepto de "conductor" está ausente, tal como lo conocemos hoy. Aparte de los accesorios, archivos de muestra y cosas relacionadas con Windows que se encuentran en el paquete de instalación, ¿cuáles son los elementos esenciales necesarios para que un programa de DOS utilice una tarjeta de sonido?
Una cosa que he leído en alguna parte y ya no puedo encontrar es que algunas tarjetas de sonido están 'inactivas' en el encendido y necesitan algún tipo de inicialización para funcionar. ¿Puedes comentar sobre esto?
Respuestas
La forma típica de proporcionar servicios de "controlador" a otros programas en DOS es ejecutar un programa TSR (Terminar y permanecer como residente) instalando un vector de interrupción de software de modo que la ejecución de programas de DOS pueda invocar este INT para servicios (consulte la Lista de interrupciones de Ralph Brown ).
Sin embargo, en el contexto de sonido, los programas normalmente realizarían la E / S del dispositivo directamente leyendo y escribiendo puertos de E / S directamente, manejando interrupciones y transferencias DMA cuando sea relevante. Quizás debido, al menos en parte, al hecho de que los servicios multimedia estaban evolucionando rápidamente.
Sin la administración de recursos proporcionada por DOS, tendría que detectar dispositivos manualmente, lo que podría ser un poco complicado y potencialmente desencadenar fallas dependiendo de lo que sucedió que se instaló en el espacio de E / S. Es posible que algunos dispositivos solo monitoreen una huella de E / S mínima hasta que se realizó una secuencia de inicio para reducir este riesgo, pero este no es un comportamiento que reconozco de las rutinas de sonido que escribí yo mismo para AdLib, Roland MPU-401 MIDI y SoundBlaster clásico. tarjetas.
Principalmente, la detección se basó en asignaciones de E / S, IRQ y DMA convencionales complementadas por convenciones de variables de entorno que especifican estos puntos de configuración.
Básicamente, escribió un fragmento de código que solo debería dar un resultado determinado en la presencia del dispositivo esperado (fx configurando los temporizadores integrados en la tarjeta AdLib) y lo ejecutó a ciegas contra las direcciones de E / S convencionales o especificadas y vio lo que cayó del cielo.
Resumen:
Los Real Sound Blasters no necesitan un controlador para inicializarlos o admitirlos. Los clones pueden necesitar una inicialización única. Las tarjetas exóticas pueden necesitar capas de traducción residentes en la memoria.
Los juegos utilizan una colección de controladores por tarjeta para "comunicarse" con las interfaces de hardware adecuadas. Estos pueden estar codificados en el juego o en una colección de archivos externos como en HMI o Miles.
Dependiendo de su situación, es posible que se apliquen uno o ambos.
Para jugar a Halloween Harry en un Sound Blaster real, no se necesitan archivos adicionales. El soporte SB está codificado de forma rígida.
Para jugar Theme Hospital en un SB Live PCI bajo MS-DOS, el juego usa un controlador Miles de terceros para abstraer la tarjeta SB. La tarjeta en sí requiere un controlador Live para imitar la interfaz de hardware de una tarjeta SB más antigua.
Todas las respuestas dadas aquí hasta ahora son correctas, para diferentes escenarios. Lo que puede confundir es que hay dos fases distintas que ambas podrían denominarse correctamente "impulsores". Déjame describir lo que quiero decir:
Casi todo aquí se aplica tanto a la salida de audio digitalizada como a la compatibilidad con AdLib / OPL2 / OPL3 por igual.
1) Inicialización y soporte para -proporcionar- la interfaz
La legítima serie de tarjetas Sound Blaster de primera mano se programa directamente a través de puertos de E / S. Hay un chip integrado conocido como 'DSP' * que maneja todo el movimiento de datos hacia y desde la tarjeta. Si tienes un Sound Blaster real y el juego sabe cómo "hablar Sound Blaster" con el DSP utilizando la interfaz descrita en la Guía de programación de hardware de la serie Sound Blaster , eso es todo lo que necesitas.
* (No debe confundirse con un 'DSP' en un uso posterior que normalmente proporciona un efecto programable como la reverberación).
Si tiene una tarjeta de clonación o una 'tarjeta compatible' de un tercero, se aplica una de las siguientes opciones:
- La tarjeta de clonación actúa exactamente como una de las tarjetas de la serie Sound Blaster y no es necesaria ninguna otra intervención de un "controlador".
- La tarjeta comienza 'inerte' y requiere cierta inicialización. Esto es común con las tarjetas compatibles con PnP 1995-1997 cuya configuración de IRQ y DMA se realiza en software en lugar de mediante puentes. Mi tarjeta basada en Avance ALS100 + y las tarjetas CMI8330 requieren que se ejecute un programa de inicio antes de que funcionen. Este programa habla con la tarjeta, le dice qué IRQ y DMA usar y, a partir de ese momento, la tarjeta actúa como una tarjeta de clonación. Ningún programa persistente reside en la memoria para traducir los comandos DSP de Sound Blaster de un juego en comandos de Avance, etc. Si ha instalado el 'controlador' para una tarjeta similar a un clon, lo más probable es que esto se aplique a usted.
- Si la tarjeta no es capaz de actuar directamente como una tarjeta de clonación porque es exótica como una Ultrasonido Gravis, o una tarjeta Sound Blaster / Ensoniq PCI muy nueva (relativamente hablando: posterior a 1996), entonces no se puede inicializar simplemente para que actúe como una Tarjeta de clonación SB. Estas tarjetas requieren que se cargue una capa de compensación de software residente para interceptar los comandos DSP de Sound Blaster y traducirlos en tiempo real a los comandos que la tarjeta entiende. Para GUS, esto es SBOS. Si el juego al que estás jugando es compatible de forma nativa con GUS, entonces no necesitas SBOS. Para tarjetas sin chips de FM / chips de clonación presentes, la capa de compensación puede sintetizar el audio en el software en tiempo real, con resultados mixtos.
2) Soporte del juego para -consumir- la interfaz
Completamente independiente de lo anterior, es el 'controlador' el que proporciona la capacidad del juego para hablar con una tarjeta de sonido específica. Esto podría llamarse más precisamente una biblioteca de audio, pero dado que también tiene que comunicarse con los procesadores DSP de Sound Blaster / Windows Sound System, etc., también es un controlador. En este sentido, un juego de DOS es como un minisistema operativo en sí mismo.
Este controlador toma la forma de una biblioteca de rutinas que abstraen las primitivas básicas de la interfaz de la tarjeta de sonido en un conjunto de comandos útil y consistente para el desarrollador de juegos.
Por sí mismo, un Sound Blaster proporciona una única salida de audio y capacidad FM. Un ultrasonido Gravis o SB AWE proporciona una interfaz de tabla de ondas para múltiples flujos de bucle corto de muestras residentes en la tarjeta de sonido y la RAM (además del flujo digitalizado SB y FM, para AWE). El altavoz de la PC emite un pitido.
El programador del juego no quiere pensar en este nivel de detalle: quiere iniciar música, reproducir una explosión, etc. Sería trabajo del conductor abstraer estos detalles: iniciar / detener la salida, iniciar / detener los efectos de sonido, mezclar ellos, alterar volúmenes, etc.
Los primeros juegos tendrían estos controladores codificados directamente en el juego de una manera ad-hoc: Halloween Harry solo puede admitir Sound Blasters originales, y el soporte está codificado en el juego. Rise of the Triad tiene su propia biblioteca de sonidos enorme; Dado que RoTT es de código abierto, puede ver todas las diferentes rutinas de inicialización y soporte en Github .
Para juegos de MS-DOS maduros y tardíos como Theme Hospital , se utiliza una biblioteca como Miles o HMI. Si ha visto una pantalla de configuración de tarjeta de sonido con docenas de tarjetas de sonido disponibles, lo más probable es que utilicen una de estas bibliotecas. Señalo esto ya que los diferentes controladores de la tarjeta de sonido se pueden mostrar en una lista de directorios como archivos .386o .ovlo .hmi. Epic MegaGames Los juegos de la biblioteca Jensen como One Must Fall 2097 y Jazz Jackrabbit almacenan los controladores de su tarjeta de sonido en MDRV---R.MUSarchivos.
Los controladores de la tarjeta de sonido en 1) se proporcionarían en un disco de instalación con su tarjeta de sonido, si es necesario.
Los controladores de la tarjeta de sonido en 2) se proporcionarían con los juegos o formaron parte de ellos.
La mayoría de las tarjetas de sonido PCI no tienen soporte de hardware para juegos y otras aplicaciones que esperan que esté presente un SoundBlaster o AdLib. Las tarjetas más antiguas hicieron un esfuerzo especial para proporcionar lo que se conoce como "compatibilidad de nivel de registro", de modo que pudieran usarse con una amplia gama de juegos existentes. Cuando llegó PCI, Windows se había convertido en el sistema operativo de PC preferido, por lo que la compatibilidad con los juegos de DOS era menos importante a nivel de hardware.
El "controlador" de DOS para estas tarjetas más nuevas es en realidad un software de emulación, que intercepta los accesos a los puertos de E / S normalmente ocupados por el hardware Adlib y SB, y los convierte en comandos para la tarjeta de sonido actual. Esto puede incluir realizar síntesis de audio y / o mezclar en software.
Como cualquier hardware, el hardware de una tarjeta de sonido debe estar "preparado para funcionar" después de haber sido encendido en un estado no configurado.
Por lo general, esto consiste en escribir ciertos valores en ciertos puertos de hardware y / o direcciones de memoria (después de probar la presencia de dicha tarjeta de sonido). Después de esto, la tarjeta de sonido está lista para funcionar.
En Windows o cualquier otro sistema operativo moderno, esto lo hace un controlador al iniciar el sistema operativo y escanear en busca de cualquier hardware que esté presente. En DOS, esta configuración la realiza (normalmente) el juego o la aplicación que utiliza la tarjeta de sonido cuando se inicia. Antes de que se inicie la aplicación, el hardware aún no está configurado.
Cuando se introdujo por primera vez Sound Blaster, la forma documentada de utilizar las funciones de audio digitalizado era hacer uso de un blob de código suministrado por Creative Labs. Si la memoria funciona, el uso de este blob de código requirió leerlo en la RAM en una dirección múltiple de 16 e invocarlo con una forma normalizada de esa dirección (compensación cero de cualquier segmento en el que haya comenzado). Si la memoria funciona, la interfaz MIDI se definió en términos de operaciones del puerto de E / S, y la documentación puede haber especificado cómo el código que podía ejecutarse lo suficientemente rápido podía enviar muestras individuales a un puerto de E / S sin usar DMA [que terminó siendo cuántos programas usaban realmente SoundBlaster], pero creo que la expectativa de Creative Labs era que la gente usara el blob de código suministrado. Sin embargo, no creo que esté clarosi esperaban que los programadores siempre pusieran ese blob en un archivo con un nombre determinado en un lugar determinado para permitir que se reemplazara con implementaciones alternativas, o cuánto espacio esperaban que los programadores le asignaran.