#1 S-CPU (5A22)

El 5A22 es el chip que contiene en su interior la CPU y la unidad DMA.

#1.1 CPU (65C816)

La primera vez que se vio Super Famicom/SNES fue el 23 de Diciembre de 1988 con PC-Engine y Mega Drive en el mercado japonés llevaba pocos meses en el mercado. Es imposible que Nintendo en poco tiempo hubiese armado una consola como respuesta a Sega, es más, Nintendo acabo por eliminar la compatibilidad con la Famicom y la primera vez que mostraron un prototipo funcional del sistema tambíén presentaron un re-diseño de la Famicom.

SFC-881216-1c

Yamauchi quería compatibilidad hacía atrás en el nuevo sistema pero Uemura y su equipo habían hecho los cambios suficientes para que el hardware de la consola fuese completamente distinto pese a tener un funcionamiento aparentemente evolucionado en teoría respecto a la Famicom/NES. Todos los procesadores se re-diseñaron desde cero excepto la CPU que es un vestigió de la étapa inicial del proyecto.

La CPU de SNES es un clon modificado del 65c816 que es la versión de 16 bits del 6502, es la misma CPU que Apple utilizo en el Apple II GS para la compatibilidad hacía atrás con el Apple II original y en este caso la elección por parte de Nintendo fue inicialmente para ello ya que dicha CPU tiene un modo «Famicom» donde puede ejecutar nativamente código de su antecesora, en dicho modo la CPU se coloca a unos 1.79 Mhz de velocidad.

En realidad debería verse como una extensión a 16 bits del 6502 y la polémica que ha seguido durante años es el hecho de que como extensión que es realmente no tiene más capacidad de calculo que un 6502 a la misma velocidad de reloj. ¿Que cambios incorpora entonces? Pues registros de 16 bits, un direccionamiento de memoria de 24 bits (puede tener hasta 16MB/128 Mbits) y una instrucción que permite enviar datos en bloque que el 6502 no podía. Es curioso que Nintendo rechazará el HuC6280 que les ofreció Hudson Soft/NEC y que disponía de la mayoría de estas cosas de antemano para que en un año y medio más tarde presentar la Super Famicom. Nintendo completamente centrada en la Game Boy retraso el lanzamiento de su consola de 16 bits hasta 1990 en Japón.

Ahora bien… ¿Donde esta la polémica con la CPU? Primero esta en su velocidad de reloj que es variable dependiendo de la velocidad de la ROM del cartucho. Las dos velocidades estándar son 2.68 Mhz y 3.58 Mhz y su rendimiento como es obvió depende de la velocidad de la ROM de los cartuchos y he aquí un secreto que no comente en su día, a Genesis/Mega Drive y PC-Engine les pasaba lo mismo solo que Nintendo fue sincera en ese hecho desde el principio. La polémica esta en el hecho que el 68K es mejor procesador por el hecho de ser más avanzado y facilitar enormemente el trabajo a los desarrolladores, era una CPU estandar en la CPU de los 16 bits ya que todos los sistemas lo utilizaban y el ensamblador en el 65C816 complicaba enormemente las cosas a no ser que vinieras del 6502 que es de donde venía Nintendo y los licenciatarios/editores independientes de la Famicom. No obstante el 68K tiene un problema enorme que es la la latencia con la memoria externa. A nivel de registros internos el resultado era inmediato, a nivel de memoria externa el rendimiento bajaba a 1/4 por la latencia de 4 ciclos por lo que el 68K de Genesis/Mega Drive que funcionaba a 7.67 Mhz en realidad operaba como si trabajase a 1.92 Mhz.

En realidad es paradójico que el 68K se convirtiese en una CPU para sistemas de videojuegos precisamente por su lentitud. La mayoría de sistemas basados en el 68K con esa función tuvieron que desarrollar mecanismos para paliar dicho problema y especialmente en el envió y recepción de datos tanto si se tenía una máquina con búfer de imagen como una con generador de patrones/sprites. Cosas como las unidades Blitter de los ordenadores de 16 bits como el Amiga y el Atari ST por un lado y los mecanismos DMA de Genesis/Mega Drive se desarrollaron para paliar ese problema. Además fijaos como comente que la unidad DMA de Genesis/Mega Drive esta en el VDP y no como co-procesador del 68K. ¿El motivo? La horrenda latencia de acceso a memoria y se ha de tener en cuenta que en algunos casos puede llegar hasta los 14 ciclos. El 65816 y el 6502 tienen una latencia media de 0 ciclos aunque hay instrucciones que tardan unos 2 ciclos en completarse, pero eso solo es la mitad de la historia, en realidad el 65C816 a igualdad de velocidad de reloj efectiva es más lento que el 68000 por lo que el recorte en velocidad del 68K en cuanto a memoria externa se ve paliado por… Bueno, hay un benchmark en la revista Byte, precisamente en su número de Enero de 1983 donde se hace una comparación entre el 68K y el 65C816 donde se demuestra que el procesador de Motorola es más rápido.

¿El otro punto de la polémica? El bus de 8 bits, el cual hace que en el caso del 5A22/65C816 sea necesario gastar 2 ciclos por 1 instrucción de 16 bits por el hecho que el bus de memoria es de 8 bits, esto signifa que cualquier transferencia hacía y desde la S-CPU se hará a 1.79 MB/s, 2.68 MB/s o 3.58 MB/s dependiendo de la velocidad de reloj a la que funcione el 5A22, la cual dependerá de la velocidad de reloj de la ROM del cartucho y la velocidad a la que funcione esa sección de la RAM en concreto.

#1.2 DMA y HDMA

El 5A22 tiene dos buses de direccionamiento, uno de 24 bits llamado Bus de Direccionamiento A y el otro de 8 bits llamado Bus de Direccionamiento B. Como están conectados los diferentes dispositivos de la consola a ambos buses lo podeis ver en el siguiente diagrama.

SNESDiagram

La configuración de memoria de Super Famicom/SNES es bastante complicada y me ha llevado varios intentos de intentar explicarlo de tal manera que no pareciese demasiado confuso. ¿Al final? Pues después de un par de días con esta sub-sección de la entrada siendo escrita continuamente he decidido, literalmente…

tenor (2).gif

El 5A22/65C816 a través del bus de direcciones A solo puede ver las siguientes memorias:

  • RAM del sistema (128K)
  • ROM/RAM en el cartucho (hasta 32 Mbits/4MB)

El 5A22 tiene un mecanismo llamado «Open Bus» que es que cuando un programa hace una petición a memoria de un dato que no esta mapeado en el bus A no devuelve el dato sino que devuelve la propia referencia que le hemos pasado por lo que es necesario pasar los datos asignados de un bus de de direcciones a otro. Los registros de la S-PPU se encuentran en el bus de direcciones B a los que no se puede acceder desde el bus de direcciones A. ¿Entonces como se realiza la comunicación para pasar los datos de la Name Table? El 5A22 tiene un mecanismo «DMA» que se utiliza para pasar datos del bus de direcciones A al bus de direcciones B.

El direccionamiento de memoria esta organizada para el bus en 256 bancos de memoria (2^8) con unas 64KB de memoria por banco (2^16), donde accede el bus A no puede acceder el bus B y viceversa. De todo el direccionamiento de memoria, el bus B tiene acceso a las direcciones 2100-21FF de los bancos de memoria que van del 00-3F (64 bancos) y del 80BF (64 bancos) por lo que tenemos unos 32KB de direccionamiento de memoria asignados el bus B. Si os habéis fijaso el 21xx ya nos descarta unos 8 bits de memoria del direccionamiento, pero nos siguen faltando los bits correspondientes a los bancos de memoria y en todo caso no podemos acceder a los datos de todos los bancos de memoria, incluyendo los bancos del espacio de memoria que corresponden al cartucho. ¿Como se transmiten los datos entonces? Utilizando el banco 43 que esta asignado en exclusivo al control de la unidad DMA. 

  • Byte 0 (bit 0): Dirección del envio de datos, si leemos del banco de memoria o si enviamos al banco de memoria.
  • Byte 0 (bit 1): Direccionamiento… ¿Queremos obtener el dato en la dirección de memoria o queremos obtener otra direccion de memoria?
  • Byte 0 (bit 2): No se utiliza
  • Byte 0 (bit 3): El recorrido de los bancos de memoria… ¿va de manera ascendente o descendente?
  • Byte 0 (bit 4): Se activa cuando se quiere ir pasando en modo recursivo los datos de un mismo banco de memoria.
  • Byte 0 (bit 5-7): Canal DMA que queremos utilizar para transmitir los datos (Tenemos unos 8 canales DMA en total).
  • Byte 1: Dirección en B desde la que queremos empezar a transmitir, esto no es el banco sino el xx en la dirección 21xx. Hay que tener en cuenta que hay direcciones en espejo que corresponden a registros de configuración de las S-PPU
  • Byte 2: Parte baja de la dirección de memoria en A.
  • Byte 3: Parte alta de la dirección de memoria de A.
  • Byte 4: Banco en el que se encuentran los datos en A.
  • Byte 5: Parte baja de la cantidad de Bytes a transmitir.
  • Byte 6: Parte alta de la cantidad de Bytes a transmitir.

Es decir, podemos transmitir hasta unos 64KB de memoria al bus de direcciones B que es donde se encuentran los registros de la S-PPU estos van de los bytes 00 a 3F (unos 64 Bytes en total) pero vamos a asignar los que son más importantes para la generación de los gráficos, no voy a describir los registros, pero dentro de esos 64 bytes de registros están aquellos que nos permiten generar la OAM y las Name Tables del fondo por lo que al generar estos no basta en arrastrar los datos a a VRAM sino que las S-PPU intepretaran una serie de direcciones de la WRAM en el bus de direcciones B de una manera concreta que le servirán para configurar como ha de dibujar la siguiente escena y donde se encuentran los datos, incluyendo información como la localización de la OAM, la configuración de las Name Tables (Tamaño en Celdas, Tamaño de las Celdas, Scroll), los modos gráficos… Es más, activando un registro concreto los datos se volcarán directamente en B desde el espacio de direcciones de A.

¿En teoría deberíamos poder cambiar los parametros de estos registros al vuelo no? Pues…

tenor (3).gif

El DMA solo es accesible durante el V-Sync. ¿Entonces? Existe un mecanismo alternativo que es que el HDMA que funciona durante el H-Sync pero que solo puede transmitir unos pocos bytes para cambiar unos pocos registros asignados a las S-PPU durante el HBlank. La velocidad de envio del DMA es de unos 3.58 MB/s (bus rápido) pero solo transmite datos en el periodo VSync pudiendo transmitir unos 226 bytes por linea, el periodo V-Sync depende de la resolución vertical que escojamos para renderizar la escena (224 lineas o 240 lineas en modo entrelazado o 448 o 480 lineas en modo progresivo. Esto es debido a que el DMA es utilizado por la S-PPU durante el periodo de dibujado en pantalla.

El HDMA en cambio funciona a unos 2.86MB/s pero solo transmite datos durante el HBlank. En teoría deberíamos poder transmitir unos 42 bytes por linea por el HBlank, pero el hardware solo nos permite enviar entre 1 y 4 bytes por linea de escaneo en realidad. Aunque esto es suficiente para cambiar algunos registros concretos que lee la S-PPU y cambiar el comportamiento asignado a estos registros al vuelo. Esto permite realizar a nivel de linea de patrones/sprites ciertos efectos gráficos especiales. En este video de una romhack de Super Mario World se puede ver el uso del HDMA para conseguir ciertos efectos gráficos:

#1.3 Cartuchos

La organización de la ROM de los cartuchos no es por bancos sino que es lineal, esto requiere un traductor de direcciones que se encuentra en cada cartucho de la SNES, sin dicho traductor de direcciones entonces no puede haber comunicación entre la memoria del cartucho y la consola.

cartpcb_illustrated

Hay muchos tipos de cartuchos de SNES y su organización interna dependerá del tipo porque algunos incluso contienen chips de apoyo que varian el funcionamiento de la SNES y tienen un mapa de memoria propio, poner todos los mapas de memoría aqui haría que estemos hasta el dia del juicio final. Pero si, Super Famicom/SNES debido a eso más la complejidad del Bus A y el Bus B la convierten en una consola dificil de programar en comparación con Genesis/Mega Drive.

De los bancos 00 a BF todos los datos que van desde la dirección 8000 a FFFF, esto significa que de cada banco de memoria unos 32KB de 64KB se asignan al cartucho de las 192 bancos iniciales. esto son unos 6MB o mejor dicho unos 48 Mbits en total que es el tamaño máximo que tenían los cartuchos de la Super Famicom/SNES. A los cartuchos con bancos de 32KB los llamaron LoROM, pero la cosa se complica un poco si tenemos en cuenta que existén otro tipo de organización de la ROM, la que asigna al cartucho los bancos que van del 40 al 7D y del C0 al FF al completo por lo que los bancos son de 64KB en ese caso.

Y luego para terminar estaba la velocidad de las ROMs las que eran más rápidas eran más caras y hacían que a CPU funcionase a unos 3.58 Mhz. Las más lentas hacían que funcionase esta a 2.68 Mhz, con tal de que no hubiese un desajuste de sincronía entre la velocidad de la ROM y del sistema se cambiaba el primer bit de la dirección 420d de un banco cualquiera para seleccionar la velocidad  para las operaciones de lectura del cartucho. Y si, por si no os habeis enterado en cada banco se asignan una serie de registros fijos que son siempre los mismos para tareas claves del sistema.

#1.4 RAM

Super Famicom/SNES tiene unos 128KB de memoria RAM a nivel físico, esta es accedida a 2.68 MB/s y esta asignada a los bancos 7E y 7F. Ahora bien, a nivel de direccionamiento hay dos pozos de RAM distintos que son RAM1 y RAM2. El primero son los 8KB primeros y se encuentran ocupando las direcciones 0000-1FFFF en modo espejo de los bancos 00 a 3F y los bancos 80 a BG. ¿Esto a que es debido? Pues debido al hecho que cuando Nintendo presento la consola a finales de 1988, esta solo tenía 8KB de RAM y el resto de la memoria se añadió después.

 

#2 S-PPUs

En vez de hacer evolucionar la PPU de NES el equipo de Uemura decidió renovar el subsistema gráfico por completo, el cual ha pasado de tener un chip a tener 2 chips distintos que son el S-PPU1 y el S-PPU2. Los dos están conectados a unos 64KB de memoria VRAM aunque no trabajan en paralelo y es el mismo tipo de combnación existente entre el HuC6270+HuC6260 de la PC Engine/Turbo Grafx-16 pero con la diferencia que el equivalente al HuC6260 que sería el S-PPU2 es algo más avanzado y permite realizar más funciones.

Sus especificaciones técnicas son:

  • Resolución de 256×224 pixeles.
  • 128 patrones/sprites en pantalla.
  • Hasta 32 patrones/sprites por linea de escaneo

El resto de especificaciones las ire desglosando en la siguientes sub-secciones.

#2.1 Color

La Super Famicom/SNES puede reproducir gráficos a través de sus S-PPU en los siguientes modos:

Modo Sprites BG0 BG1 BG2
0 4 Colores 4 Colores 4 Colores 4 Colores
1 16 Colores 16 Colores  4 Colores .
2 16 Colores 16 Colores
3 256 Colores  16 Colores
4 256 Colores 4 Colores
5 16 Colores 4 Colores
6 16 Colores
7 256 Colores
7EXT 256 Colores 128 Colores

Los modos más comunmente utilizados en los juegos son el Modo 1 y el Modo 7.

Si os fijáis en como reproduce el color la SNES os daréis cuenta que como mucho se pueden tener patrones de 2 o 4 bits de color en los fondos. Esto choca enormemente con su ancho de banda de la memoria que le permite enviar y recibir unos 8 bits por ciclo de reloj. Hay que tener en cuenta que el el sistema de todo generador de patrones/sprites cuando genera una linea y existe conflicto entre dos o más patrones/sprites en el mismo punto de la pantalla genera en su búfer de linea el pixel de mayor prioridad y descarta al resto. El Line Buffer de la linea siguiente a reproducir lo escribe la S-PPU2 en pantalla que es el chip encargado del color pero el que «escoge» cual es el pixel a dibujar es el S-PPU1 a través del bit de preferencia de las tablas, esta explicación es común en todos los derivados del TMS9918A/TMS9928A y la cantidad de colores por patrón/sprite que pueden dibujar dependen del ancho de banda por ciclo de reloj de la memoria. Por ejemplo, la Colecovision tiene una memoria de solo 1 bit de ancho de banda, de ahí a que la cantidad de colores a reproducir por patrón/sprite es de 2 colores, más adelante se avanzo a la memoria de 2 bits y por tanto 4 colores, 4 bits para 16 colores y 8 bits para 256 colores.

La S-PPU2 tiene una memoria interna que es la Color RAM que puede almacenar hasta 8 paletas distintas de 16 colores cada una  (15+1) en dos bancos distintos hasta llegar a los 256 colores en pantalla. La Color RAM es de unos 512 bytes y almacena los colores en formato RGB555 ocupando unos 2 bytes por lo que es posible escoger entre 32.768 colores distintos. Hay que tener en cuenta que Super Famicom/SNES no tiene paletas fijas sino que dependiendo de como ordenemos la paleta a la hora de hacer referencia a ellas en la tabla de patrones/sprites puede salir un color u otro dependiendo de como esta organizada la Color RAM en la S-PPU2. Es en este punto donde las similitudes con la PC-Engine se terminan porque en la PC-Engine las paletas son fijas, en este caso Nintendo le copio a Sega (recordemos que el concepto de la Color RAM en el generador de patrones/sprites estaba en la SMS/Mark III).

Pero dado el tamaño de la paleta de colores, 512 bytes, y el hecho de que el sistema de memoria sea tan lento es imposible realizar un cambio de paletas utilizando el HDMA durante el periodo de HBlank por el hecho que no es posible enviar los 512 bytes de golpe a la Color RAM por el hecho de que no hay el suficiente ancho de banda para hacer el cambio necesario en la Color RAM. En cambio por el menor tamaño y la mayor velocidad en Genesis/Mega Drive si que es posible hacer cambios de paleta que permitan superar el limite de los 64 colores. En todo caso con 256 colores en pantalla la ventaja en el color respecto a los 16 bits de Sega esta clara y el cambio de paleta al vuelo no es tan necesario.

Otro de los temas a destacar en Super Famicom/SNES son los efectos de blending utilizados para cosas como la simulación de transparencia, estas se consiguen combinando dos patrones/sprites en un mismo punto pero con las siguientes condiciones:

  • La suma de bits de color en ambos no puede superar los 8 bits.
  • Hay 4 tipos de operación de blending: suma, substraccion, suma y media, resta y media.

Esto permite una serie de efectos gráficos en los juegos via hardware que son imposibles en los juegos de las otras consolas de la misma generación incluyendo la Neo-Geo.

#2.2 Patrones/Sprites

La S-PPU puede colocar hasta unos 128 patrones/sprites distintos en pantalla y hasta unos 32 distintos por linea de escaneo. Al igual que en la Famicom/NES y Game Boy existe una memoria interna (En el S-PPU1) llamada OAM que contiene la información de como el generador de patrones/sprite ha de dibujar el primer plano. Como todos los derivados del TMS9918A/TMS9928A la información se almacena en unas tablas que como hemos ido viendo cambian de sistema en sistema, pero la organización solamente, en general todos comparten más o menos información similar.

En el caso de SNES la tabla esta configurada de la siguiente manera:

  • Byte 0: Posición horizontal en pantalla del Patrón/Sprite. Si la resolución es de 512 pixeles en horizontal la posición representan 2 pixeles en pantalla.
  • Byte 1: Posición vertical en pantalla del Patrón/Sprite. Si la resolución es de 448 pixeles en vertical la posición representan 2 pixeles en pantalla.
  • Byte 2 (Bit 0): Verticalmente el Patrón/Sprite se dibuja a la inversa.
  • Byte 2 (Bit 1): Horizontalmente el Patrón/Sprite se dibuja a la inversa.
  • Byte 2 (Bits 2-3): Prioridad del Patrón/Sprite, también sirve para marcar si queremos que el Patrón/Sprite se represente en el primer plano (00), en el fondo 1 (01), en el fondo 2 (10) o en el fondo 3 (11) en ese caso reemplazará
  • Byte 2 (Bits 4-6): Elección de paleta, hasta 8 distintas.
  • Byte 2 (Bit 7)+Byte 3: Posición de referencia en el banco de patrones/sprites que se encuentra en la VRAM. Se pueden almacenar hasta unos 512 patrones/sprites, el Byte 2 (Bit 7) marca a a cual de los dos bancos de patrones/sprites hace referencia.

La OAM solo almacena en pantalla los patrones/sprites que se van a presentar en dicho plano, viene acompañada además de una lista de 32 bytes que hace referencia a los mismos 128 patrones/sprites transmitidos a la OAM  (4 bits por objeto) y que tambien se encuentra en la memoria interna de la S-PPU1. Esta segunda tabla nos sirve para marcar el tamaño (y de paso cuantas celdas de la Name Table, ocupará el patrón/sprite).

n=0 n=1
n001 8×8 16×16
n010 8×8 32×32
n011 16×16 64×64
n100 16×16 32×32
n101 32×32 64×64
n110 16×32 32×64
n111 16×32 32×32

Estos 512+32 Bytes que van a parar a la OAM son generados en cada fotograma por el 5A22 (o por la CPU al cargo que este en ese momento). Al igual que en Famicom/NES y en Game Boy se transmiten a la OAM a través de un canal de comunicación que es la OAMDMA donde se copian del espacio de la RAM donde han sido generados a la memoria interna durante el VBlank con tal de preparar el nuevo fotograma.

#2.3 Name Tables (Fondos)

Las Name Tables correpondientes a los fondos son generadas por la CPU al principio de cada nivel y se quedan en la VRAM hasta terminar el nivel donde vuelven a ser construidas de nuevo por lo que no se construyen fotograma por fotograma aunque un juego puede si es necesario volver a dibujar las Name Tables de los fondos si el desarrollo de la acción lo requiere.

El tamaño de las tablas es el mismo que el de Famicom/NES, pero hemos de tener en cuenta que ahora no disponemos solo de un fondo/background sino hasta 2 adicionales. Aparte de ello las Name Tables ahora utilizan un 2 bytes por celda en vez de un byte, ambos bytes están configurados de la siguiente manera:

  • Byte 0 (bit 0): Verticalmente el Patrón/Sprite se dibuja a la inversa.
  • Byte 0 (Bit 1): Horizontalmente el Patrón/Sprite se dibuja a la inversa.
  • Byte 0 (Bit 2): Prioridad.
  • Byte 0 (Bits 3-5): Paleta a escoger (de un total de 8 posibles)
  • Byte 0 (Bit 7)+Byte 1: Posición de referencia en el banco de patrones/sprites que se encuentra en la VRAM. el Byte 0 (Bit 7) marca a a cual de los dos bancos de patrones/sprites hace referencia.

El tamaño que ocupan en la VRAM dependiendo de la cantidad de fondos y el tamaño de las Name tables es el siguiente:

 

Tamaño BG0 BG1 BG2
32×32 2 KB 4 KB 6 KB
32×64 4 KB 8 KB 12 KB
64×32 4 KB 8 KB 12 KB
64×64 8 KB 16 KB 24 KB

 

#2.4 Modo 7

giphy (1).gif

El Modo 7 es un modo especial (con un submodo llamado Modo 7 EXT) que permite que un fondo pueda ser rotado, escalalado y sesgado. Las capacidade de la SNES estandar con el modo 7 son ciertamente limitadas y se hace necesario el uso del chip de apoyo S-DSP1 para poder realizar ciertos tipos de rotación y escalado, esto es debido a las limitaciones del 5A22 que bien tiene la capacidad de realizar operaciones de manipulación de patrones/sprites no esta pensado para hacerlo en las tres dimensiones del espacio.

#3 Chips de Apoyo

SNES tuvo una serie de chips de apoyo con la particularidad que en algunos casos reemplazaban a la CPU, otro a las S-PPU y permitian llevar a la máquina más allá de lo que el hardware base permitía por si solo.

#3.1 S-DSP1

El S-DSP1 es un chip de apoyo para el 5A22 que estaba incorporado en el prototipo de la Super Famicom y que Nintendo por motivos de coste decidió sacar a última hora. Es el responsable de algunos efectos especiales de los juegos que utilizan el Modo 7 que por limitaciones el 5A22 no puede realizar.

El DSP-1 funciona unicamente como co-procesador del 65C816, el 65C816 envía una instrucción+dato al DSP-1 y el DSP-1 lo calcula y envía el resultado de vuelta al 65C816. ¿Que es lo que hace realmente? Pues lo que realiza son operaciones trigonométricas a muy alta velocidad que el 65C816 no es que no pueda hacer sino que no las puede hacer con suficiente velocidad.

#3.2 SuperFX/GSU

Se trata de una CPU RISC creada por Argonoaut para el juego Star Fox, su funcionalidad es muy parecida a la del SVP de la Sega Genesis/Mega Drive. Simplemente re-emplaza como procesador gráfico a la S-PPU1 y le otorga a la SNES un framebuffer tradicional completo, el cual se encuentra como RAM asignada al chip. Esto le permite actuar como procesador gráfico alternativo y le permite a la SNES realizar gráficos que con su generador de patrones/sprites serían imposibles.

Esto es posible hacerlo porque el que dibuja en pantalla es el S-PPU2 y lo hace linea por linea, habitualmente el S-PPU2 recibe del S-PPU1 los datos que tiene que dibujar en la siguiente escaneo de linea en forma de Line Buffer, esto lo hace de manera transparente y sin que el desarrollador tenga que tocar nada pero es aprovechado por el SuperFX para transmitir su búfer de imagen a través de la unidad DMA de la CPU para pasarle el Line Buffer directamente al S-PPU2 haciendo bypass al S-PPU1.

Salieron dos versiones del SupeFX, una a 10.74 Mhz y otra a 21.48 Mhz.

#3.3 Super Accelerator-1

El SA-1 es un 5A22 funcionando a 10.74 Mhz que son cuatro veces la velocidad de reloj del incluido de serie en la SNES, su velocidad de reloj aumentada le permite realizar las mismas funciones que el DSP-1 a la misma velocidad sin necesidad que el co-procesador estuviese incluido de serie. No reemplaza al 5A22 dado que no tiene acceso a las S-PPU y tiene que utilizar la unidad DMA/HDMA dentro del 5A22. En realidad debe verse como una versión programable y mejorada del DSP-1.

El SA-1 contiene además una unidad que convierte mapas de bits en formatos de patrones/sprites y paletas que los S-PPU pueden entender.

Y con esto terminamos, me ha costado muchos días realizar esta entrada, por lo que os pido perdón por la tardanza.