Uy, hace más tiempo del que pensaba sin meterme en el foro, lo que hace una mudanza
![más risas [+risas]](/images/smilies/nuevos/risa_ani3.gif)
. Gracias por invocarme y siento la tardanza en contestar!
Warning: megachapa incoming!
A ver, básicamente han contestado bastante bien los compis el cómo funcionan estos chips de apoyo. Voy a intentar ir un poco a más bajo nivel (por si interesan algunos detalles más), sobre todo del tema del SVP.
Lo de meter hardware en los cartuchos es más antiguo que cagar sentao, en parte porque tiene todo el sentido del mundo: al final el propio cartucho es hardware, la ROM es hardware... y meterle más "extras" no deja de ser una extensión del concepto del cartucho en sí. Por ejemplo en MSX los cartuchos tenían un pin por el que el propio cartucho podía mandar sonido, y aparte de la ROM algunos juegos metían chips FM que el ordenador podía programar y generar canales de sonido extras. Estos canales de sonido se mezclaban en uno, se mandaban a través del pin de sonido y el ordenador lo mezclaba todo con lo que generaba su propio chip de sonido (y se conseguían 4 canales de audio en vez de 2, por ejemplo).
Lo normal es que el cartucho sea accesible a través de la memoria del ordenador. Imaginad que el cartucho en sí (la ROM) se puede leer entre las direcciones 0x400000 y 0x500000 (normalmente el mapa de memoria es más complicado que esto, es sólo un ejemplo). El cartucho tiene pines que representan estas direcciones (si buscáis "cartridge pinout" de vuestra consola favorita, veréis muchos pines cuyo nombre empieza por A, de address), aparte pines de datos (que suelen empezar en los pinouts por "D", y que suelen ser de lectura y escritura), un pin que usa la consola para definir si lo que se va a hacer es leer o escribir (suele aparecer como R/W o cosas así), y aparte otro que cuando está activo inicia la operación de lectura o escritura.
En un cartucho "normal", esos pines van directos a la ROM y la ROM responde a las peticiones y a juír. Pero si le metes por ejemplo una memoria SRAM para grabar partidas, ya necesitas algo de lógica extra para saber si la consola quiere leer de la ROM o de la SRAM... o si quiere escribir en la SRAM. También puede ocurrir que el mapa de memoria de la consola para código sea pequeño, por ejemplo en las CPUs de 8 bits. En la Gameboy o la NES es normal que el cartucho tenga un chip mapeador, que tiene "direcciones especiales" en el mapa de memoria que sirven para definir operaciones. Por ejemplo para definir "páginas de memoria" y poder tener una ROM 4-8 veces más grande de lo normal. La consola le dice al cartucho "quiero leer de la página 2 de la ROM", y luego empieza a leer de la ROM como si sólo ocupase el espacio que le permite normalmente el mapa de memoria... pero resulta que está leyendo de la mitad de una ROM bastante más grande.
Si extendemos este concepto al tema de los chips de apoyo 3Ds que salieron en su día pues es un poco parecido. Del SuperFX no tengo idea para nada, pero en el caso del SVP imaginad los pines del cartucho como una "interfaz" con el que la consola se comunica con la otra CPU (realmente DSP) que hay dentro del juego. Un detalle importante aquí, es que todas las peticiones que hace el M68000 a memoria durante la ejecución de un juego se reflejan en el puerto de cartuchos. Lo único es que, en juegos normales, normalmente el cartucho está diseñado para ignorar todo lo que no sean direcciones destinadas a leer de la ROM. Esta característica nos abre la puerta a definir direcciones alternativas en la que poder ordenar al cartucho que se comporte de diferentes maneras, o que nos permita leer de chips alternativos que no son la ROM.
En el caso del SVP hay direcciones del mapa de memoria del juego que sirven para sincronizar las operaciones con el SVP desde el lado de la Mega Drive. Por ejemplo la Mega Drive puede leer un bit de cierta dirección para saber si el SVP está haciendo algo o está "libre" para hacer algo. También puede acceder a través del mapa de memoria para leer los gráficos que crea el SVP en su RAM externa, o escribir en ella para dejar listas de polígonos y parámetros (ej: número de frame en el que tiene que dibujar el logotipo de SEGA del inicio del juego). O puede escribir en un bit para decirle "churra, te he dejado datos en la RAM que hay en el cartucho para que dibujes el logotipo de SEGA del principio de juego" (el código del juego define varias operaciones que la consola le pasa a través de una de esas direcciones de memoria al chip para que dibuje el logo de SEGA, o los coches desde tal vista, o los menús del juego...). El chip también tiene su mapa de memoria, sólo que algo más complicado porque realmente tiene dos (uno interno, donde ve su "parte" del código de la ROM, una memoria RAM interna que sirve para poder meter rutinas y ejecutarlas "rápidamente", y aparte la ROM interna que encontré hace unos añitos investigando toda esta mierda

).
Sin embargo las operaciones de sincronía con la Mega Drive (decirle que está libre u ocupado, o ver si el M68000 le ha dicho que genere las tiles para un frame en concreto) se acceden a través de registros del DSP; no a través del mapa de memoria. Esto es por cómo se diseñaban los DSPs en su día: normalmente el DSP en sí no hace gran cosa (es una CPU básica que multiplica mu rápido), y todos iban a tener que ir conectados a hardware externo. Por ejemplo el primer DSP comercial en el que se basa el que usa el SVP, se usó al principio para procesar señales de audio de faxes y luego también para audífonos. El DSP del SVP tiene hardware externo también: una RAM grandota (128KB, en la que la Mega Drive también puede leer y escribir), una ROM con código fijo (la que comenté antes) y aparte circuitería de sincronía y de comunicación con la Mega Drive. Todo eso en conjunto es el chip SVP, y el DSP realmente es una parte relativamente pequeña del mismo (si entráis en mi repositorio que pasó el compi antes, hay un decap del chip donde se ve cada parte lo que ocupa en el chip).
Todo este mega-rollo para llegar a la enjundia de cómo funciona el juego en sí. Cada iteración del juego la Mega Drive comprueba si el DSP está libre. Si lo está, le dice lo que quiere de él (pintar el logo de SEGA, los menús, dibujar X sprite...). Luego espera a que el DSP le avise de que ha acabado, se trae los gráficos que ha generado el DSP desde la RAM externa a la VRAM de la consola y eso se dibuja en el siguiente frame. Acordaos de que el lado de la MD en este juego (hasta donde yo sé) sólo dibuja los fondos de cuando estás jugando, sonidos, música, la lógica del juego en sí (posición de los coches, velocidades, si estás jugando o estás en un menú...) y la coordinación con el SVP. Todo lo demás está dibujado por el SVP, incluyendo las letras, el logo de AM2 que sale al principio del juego... no sólo el 3D. No penséis en el chip como un acelerador 3D moderno, no está hecho expresamente como un pipeline en el que tratar con polígonos. Es una CPU reducida que multiplica a toda hostia. Todo lo demás es software del lado del DSP, gestionando los polígonos o los sprites que le manda la Mega Drive.
Un detalle importante para ir acabando es cómo el M68000 se trae los datos que genera el DSP a su "lado". La Mega Drive no puede pintar en pantalla nada que no esté en VRAM, por lo que todo lo que genere el SVP tiene que pasar sí o sí del cartucho a la consola. La consola tiene un dispositivo llamado DMA (Direct Memory Access) que permite al M68000 programar operaciones en memoria que ocurren "en paralelo" de manera bastante rápida, de esa manera te evitas que la consola tenga que ir leyendo y copiando palabra por palabra (palabra = 2 bytes). Si no fuera así, el juego no podría funcionar en la vida, ya que el tiempo entre frames es finito y bastante corto.
El problema es que el DMA de la consola es rápido de cara al M68000 que va a 7MHz y pico, pero el DSP de la consola va al triple (creo que son 23 MHz y pico lo que medí en su día). El DMA no vale pa un carajo aquí, teniendo en cuenta que en la RAM externa se generan las "tiles" que se van a dibujar en toda la pantalla. Al ser demasiada información, se tuvieron que hacer sacrificios para que el DMA pudiera traerse toda la información frame a frame: la resolución es más baja, los colores limitados (creo que 16), y el juego va a 15fps. El chip en sí puede hacer BASTANTE más de lo que consigue el juego, pero el DMA es un cuello de botella bastante insalvable. Algunos devs me dijeron que hay trucos para paliar esos problemas que antes no se sabían... pero aunque disminuyas esas historias, el cuello de botella está ahí.
De ahí que para el 32X, SEGA tirara por otra vía: el add-on dibuja toda la capa 3D, la consola dibuja los fondos 2D, y ambas imágenes se mezclan analógicamente mediante un cable que va del 32X a la MD. Alguien de la scene (no recuerdo quién) me dijo que SEGA usó para el 32X los SH2 de Hitachi no porque la serie SSP16xx de Samsung (el SVP usa el SSP1601) no fuera suficientemente potente... sino porque por lo visto en fábrica fallaban más que una escopeta de feria. De ahí que todas las copias de Virtua Racing tienen un test de hardware incluido (al que se puede acceder mediante Game Genie, o con un mando con todos los botones pulsados - incluyendo los cuatro cursores). De hecho, gracias a ese "código de test" tenemos Virtua Racing emulado, porque todos los "periféricos" que van conectados al DSP de Samsung dentro del SVP son propietarios y se sabe cómo se comportan (al menos lo que usa el juego) gracias a esos tests internos.
En fin, perdonad la tardanza y la macrochapa. Respecto al proyecto mío en sí, tengo un emulador cutre del SVP medio hecho desde 2024, pero está ahí parado por motivos de vida adulta

DD (la idea es poder usarlo para desarrollar algoritmos del DSP y hacer pruebas y tal). Si tenéis preguntas de lo que os he puesto o comentarios dejádmelos por aquí e intentaré leerlos más a menudo (o podéis contactarme por email a taiyou[a]gmail.com).
Gracias por la discusión, el hilo está del carajo!
Taiyou