@Arkziel @EMaDeLoCEL RCP (Reality Co-Processor) contiene varios componentes, principalmente el RSP (Reality Signal Processor) y el RDP (Reality Display Processor).
El RSP en concreto es el que ejecuta esos microcódigos. El termino microcódigo, aunque oficial, es un tanto ambiguo, aunque no tengo claro demasiados detalles. Pero para hacerse una idea, la CPUs de PC modernas todas funcionan por micocódigo. Una CPU x86 o x64 moderna no implementa la ISA sobre el silicio directamente, si no que tiene una microarquitectura especial, y, sobre ella, es un binario de microcódigo el encargado de implementar las instrucciones de la ISA concreta que se quiere usar (que no tengo claro si se carga desde memoria interna de la CPU o desde la Bios, o desde donde exactamente, porque, por lo visto, hasta Windows hace algo con los microcódigos de las CPUs...). Imagino que quizá no sería imposible implementar un microcódigo PowerPC, ARM, RISC-V o lo que fuera sobre una microarquitectura intel o AMD, pero no lo verán tus ojos, baby xD
En el caso del RSP del RCP de N64, los microcódigos no configuran el RSP durante toda la sesión, si no que son cargados dinámicamente multiples veces por segundo para renderizar graficos y audio.
El funcionamiento a grandes rasgos (y con la posiblidad de que mi conocimiento sea impreciso), es de esta guisa: El RSP tiene sus instrucciones nativas, pero usarlas directamente no es eficiente, así que lo que se hace es encargarle al programa de la CPU que procese la escena del juego y genere un "display list" o "audio list" y lo envíe al RSP para ser procesado con un microcódigo concreto. Se puede incluso enviar varios display lists para un mismo cuadro/frame de video o bufer de audio. Cada microcódigo corre en la RSP y procesa el display list o audio list y almacena el resultado en el framebuffer o audiobuffer. Se pueden ejecutar tantos microcódigos con sus "listas" por cada frame como se quieran antes de dar la orden de enviar el búfer de audio o video al DAC a través del VI (Video Interface) o AI (Audio Interface). Por ejemplo, en el caso de los display lists, se puede emplear un microcódigo de procesamiento 3D para la escena del "mundo" y un segundo microcódigo 2D para el HUD (marcadores). Todo esto lo tiene que organizar el ingeniero que construye lo que en conjunto se llama el engine o motor del juego.
Esto ya es especulación, pero, escribiendo todo esto se me ha ocurrido que es posible que los juegos multijugador a pantalla partida funcionen en N64 enviando display lists independientes para cada pantalla de cada jugador por separado, marcando la zona de renderizado que debe dibujar sobre el framebuffer. y luego una lista con microcódigo 2D para los elementos del HUD (Heads Up Display, los marcadores de energía, municion, velocidad, etc)
Obviamente, los comandos/instrucciones que "entiende" cada microcódigo son distintas, o funcionan distintamente, porque todo depende de lo que el microcódigo vaya a hacer con ellas.
En definitiva, el trabajo del microcódigo es tomar display lists generadas por la CPU y procesarlas, dando como resultado comandos nativos del RSP.
Las audio lists se procesan enteramente en el RSP y el resultado va directo al búfer de audio, pero con las display lists también entra en juego el RDP antes mencionado. No tengo claro exactamente cómo se divide el trabajo entre RSP y RDP y cómo se comunican el uno con el otro, pero en general, el RSP hace transformaciones geométricas y otros calculos, mientras que el RDP se encarga del rasterizado, aplicando texturas y efectos de color (shading).
Estos microcódigos eran provistos por Nintendo y Silicon Graphics como parte del kit de desarrollo, y están detallados en la documentación. Los desarrolladores debían estudiar su funcionamiento y escojer los microcódigos adecuados para cada situación dentro de sus juegos. Inicialmente solo Nintendo y SG tenían las herramientas para desarrollar estos microcódigos, y se suministraban en forma binaria con el resto de las librerías, así que los third parties no tenían el código fuente, ni compiladores o debuggers para hacer sus propios microcódigos (y la mayoría tampoco se meterían a ello aun teniéndolos, por lo complejo del proceso). Mas tarde algunos desarrolladores importantes como la second party Rareware, obtuvieron permiso de Nintendo para usarlas y desarrollaron sus propios microcódigos o versiones modificadas de los oficiales, en algunos de sus juegos.
En fin, todo este rollazo es preambulo para explicar que es LLE, Low Level Emulation, y HLE, High Level Emulation.
Cuando se empezó a emular N64 a finales de los 90, los PCs de consumo no tenían ni remotamente suficiente potencia para emular el RSP, RDP y todos los demás elementos del RCP directamente, de forma que ejecutasen los microcódigos para procesar las listas de audio y pantalla como lo hace el hardware original. Esto vendría a ser un estilo de emulación LLE, que en años mas recientes ha empezado a ser posible en tiempo real con las CPUs modernas.
Lo que hicieron los desarrolladores de los primeros emuladores de N64 fue tratar de emular los resultados de los distintos microcódigos. O sea, "emularon" el microcódigo en si, como si fuera el hardware, en vez de emular el hardware real sobre el que corría el micocódigo.
Aprovechándose del numero limitado de microcódigos existentes en juegos licenciados (aunque no exactamente escaso, contando ramas principales, versiones y variaciones) los binarios fueron identificados y documentados poco a poco, de forma que el emulador podía ver qué microcódigo se cargaba en el RSP en cada momento, y así emularlo en estilo HLE, lo que siginfica que traducen los comandos de los "display list" a comandos de Direct3D o OpenGL.
Este proceso es mucho mas ligero de procesar que emular el RSP para que ejecute el microcódigo nativamente, pero también es un proceso que limita las posibilidades del emulador, introduce imprecisiones, y requirere de emular todos y cada uno de los microcódigos posibles, en vez de emular un único RSP que pueda correr todos los microcódigos igual que la consola. Cuando HLE funciona bien, no hay problema, pero al final se vuelve un proceso mucho mas complejo y propenso a errores, imprecisiones, y cosas que sencillamente no se pueden imitar o que resultan enormemente enrevesadas. Un ejemplo clásico son los efectos basados en manipular el framebuffer, como las pantallas gigantes de mario kart 64 en Luigi's Raceway y Wario Stadium, donde el juego, en un proceso paralelo, copia una versión reducida del framebuffer previa aplicación de los marcadores, y la usa como textura en el siguiente frame. Esto, que es bastante facil de hacer en LLE, se vuelve complejo con HLE ya que HLE no emula directamente el hardware.
Los problemas con la emulación estilo HLE, que por supuesto también tiene sus ventajas, es la responsable de la mayor parte de las variaciones de compatibilidad y precisión de los resultados que tienen la mayoría de emuladores de N64.
------------------------
AÑADO: No estoy seguro, pero creo que el RE2, para decodificar las secuencias de video comprimidas como MPEG, implementa el codec como microcódigo sobre el RSP, de forma que el microcódigo vendría a ser un decodificador de MPEG y la displaylist un bloque de video MPEG.
Así mismo, existe código de un emulador de SNES sobre N64 que usa microcódigo para emular el chip grafico PPU de SNES. Lo vi hace mucho, y no se en qué estado se encuentra. Había una rom que mostraba una imagen fija, supuestamente procesada como tilemap de SNES.
---------------------------------------------------------------------------
@X_Glacius No sé que telele es ese que le da a tu pantalla, pero te confirmo que con un CRT no sucede nada semejante. No es problema de la N64 ni del cartucho de ROMs, si no que es cosa de tu TV.
Lo cierto es que, en general, todas las consolas previas a la implantación de las conexiones de video digital de consumo, o sea, las que nativamente estaban pensadas para video analógico, no están diseñadas para sacar señales ni remotamente normativas cuando te sales del tiesto y usas ROMs de otras regiones por medios extraoficiales.
Podría repetir aqui algunas de las particularidades sobre qué sucede cuando usas una ROM NTSC en la consola PAL o al reves, pero lo cierto es que no sé qué aspecto de esa señal extraña (que las TVs clásicas analógicas tienden a aceptar sin problemas) es el que le está sentando mal a tu TV digital, pero está claro que ese es el problema.
Recibe una señal extraña y algo no le cuadra, y no tiene ni idea de cómo convertirla correctamente a digital, y, como resultado, te sale ese desastre.
![[carcajad]](/images/smilies/nuevos/risa_ani2.gif "carcajada")
![[beer]](/images/smilies/nuevos2/brindando.gif "brindis")
![[buuuaaaa]](/images/smilies/nuevos/triste_ani3.gif "a lágrima viva")
. ![[buenazo]](/images/smilies/nuevos/risa_tonta.gif "buenazo")
![[sonrisa]](/images/smilies/nuevos/risa_ani1.gif "sonrisa")
