Hilo de detalles y curiosidades de N64

@EMaDeLoC Encontré el archivo que bajé con las demos del kit de desarrollo.
https://cdn.discordapp.com/attachments/ ... mpiled.zip
Es un enlace de de discord, pero yo lo encontré enlazado desde 4chan o en alguno de los videos de youtube puestos ahí también.

@radorn ¡Gracias!

@radorn
El Audio DMA en N64 es doble buffer, si necesitas hacer operaciones como descomprimir o manipular se hacen en un buffer mientras el otro suena, la maquina ya viene pensada para funcionar así, optimizada de hecho.

Si el formato es nativo y lo puede leer sin otras operaciones entonces si se podría copiar directamente del cartucho al buffer de audio y renovarlo a cada frame (hay demos que funcionan así), un PCM 44khz Estéreo creo que son 5KB por frame, dependiendo del framerate, eso da para transportarlo a cada frame del cartucho.

Pero luego como a ese buffer hay que seguir sumándole voces, aplicando efectos como reverb, formato midi, etc tiene sentido el uso del doble buffer (luego habría que sumar otros posibles pozos para cache, si es necesario).

Voy a poner algo que os va a dejar locos, se puede decodificar audio usando el chip gráfico de la consola, con el formato de audio Alaw.
https://github.com/PeterLemon/N64/tree/master/Sound/ALAW/LongShot/STEREO/RDP

Alaw usa una tabla de 256 posiciones para convertir de 8bit a 16bit el sample, ya que viene comprimido en un método similar a como lo haría una imagen, que es justamente lo que hace el RDP al cargar una textura con TLUT de 8bit, convertirla de 8bit a 16bit, entonces se sube a TMEM información de un trozo de audio que se usará como textura, se carga TLUT con el formato de decodificación de Alaw (solo una vez, ya que el algoritmo es siempre el mismo) y se crea un rectángulo de 1 pixel de alto para una lectura linear (el PCM estéreo usa derecha/izquierda intercalados), como la RAM es compartida, se le dice al RDP que dibuje el rectángulo en lugar de en el framebuffer, en el buffer de audio y ala, se van cargando poco a poco para una reproducción continua, un dibujo para la RAM no es más que información, lo mejor es que es increíblemente rápido , tanto como cargar una textura con paleta y pintarla en un rectángulo de 1 linea.

Buena info Conker, se nota que sabes lo que hablas, no como otros que se inventa unos cuentos chinos para alimentar el salseo tratando de aparentar saber de lo que habla.

Así da gusto entrar en el foro, lastima que como tu haya pocos.

@Conker64 entiendo que vADPCM no es "nativo" entonces. De todas formas el proceso que describes con lo de los 5KB parece mas apto para reproducir una pista de audio continua que para sintetizar un midi ¿no?

Lo de decodificar ADPCM A-Law con el RDP es curioso, desde luego.

@A-Jensen A ver si dejas el temita ya, que estás muy pesado. Ya es suficiente.

@A-Jensen Me encanta que te guste los datos que da Conker64, porque precisamente la mayoría de información que doy de la N64 proviene de él.
¿No recuerdas por ejemplo los dos ciclos por pixel del color combiner que expliqué en en el hilo de PS1 y que no parabas de ridiculizar?

EMaDeLoC escribió:
(GIF de Conker64)

EMaDeLoC escribió:Conker64, la eminencia suprema en la consola, lo explicó muy bien.
Aquí explicando el modo 2 Cycle:

¿Y qué decías entonces? Ah, si.

A-Jensen escribió:¿Multitexturas? desde cuando a un código especifico para ello? es simplemente colocar una textura transparente sobre otra. Vamos, que te lo has inventado tu, como si en Tomb Raider, Crash o Legacy of Kain no hubiese agua con transparencias.

Vulevo a recordar que puse especificamente a Conker64 como fuente.

Y si no es de él de donde saco información, pues de documentación oficial de Nintendo o datasheet de componentes electrónicos.

EMaDeLoC escribió:Y desde luego no me lo invento. Manual de programación de la N64, página 187 (189 del PDF):


Se consigue al activar el modo 2 Cycle que efectua dos ciclos de color combiner en un mismo pixel. Página 175, 177 del PDF.

@Conker64 Perdona que hayas acabado metido en estás movidas.
Como siempre magistrales tus clases sobre la consola.
¿Llegaste a leer la información que dí de la RDRAM de la N64? Fue aquí y aquí.
¿Te cuadra con algo que sepas sobre desarrollo en la consola? ¿Se habla en alguna parte de un tamaño recomendado de lectura de datos de la RAM?
¿Sabes como compara el z-buffer de cada pixel? ¿El z-buffer esta en la RAM?

@radorn Yo por mi parte voy a ignorarlo a partir de ahora. Don't feed the troll.

@radorn
Sí, lo he calculado de como sería a velocidad 1X de audio CD (150kbs / 30fps), igual tendría beneficios en proyectos modernos con cartuchos enormes.

También había olvidado por completo ésta imagen de alguno de los manuales filtrados de hace años, que hubiera venido bien para las últimas páginas

Pasos audio con RSP:


PD: El ALAW comprime a la mitad los samples (con perdida), no está mal para consumir tan pocos recursos

@EMaDeLoC
Me lo miro y luego edito o comento

@Conker64 He abierto la guia introductoria de programación para leer la sección de audio.
El proceso parece consistir en inicializar todas las subrutinas de audio y transferir a la RDRAM los archivos de control de los bancos de sonido (en la mayoría de juegos suele haber dos soundbanks, uno para efectos de sonido y otro para instrumentos musicales) y la secuencia MIDI.
Parte de la inicialización habla de una rutina de "DMA callback" que describen así:

Accommodate the DMA callback routine:
As occasion demands, to transfer the waveform data in ROM to RDRAM, you must accommodate the DMA callback routine called from the synthesizer driver. To do this, you need to set the pointer to the DMA initialization routine in the synthesizer driver's configuration structure. This DMA initialization routine is called once for each physical voice; it initializes the DMA buffer with the first call and is set to return the pointer (ALDMAproc) to the function called when actually requiring the waveform data. ALDMAproc receives the address, length, and state pointer of the required data and returns the pointer to the buffer storing its data as the return value.

Entiendo que ese es el proceso que coje los samples al vuelo según lo vaya requiriendo la situación y luego volviéndolos a vaciar. Tambien entiendo que es aquí donde se pone el límite de voces simultáneas para que la caché de samples de audio nunca supere un limite establecido e interfiera con la asignación de RAM a otros procesos.

NOTA para los que no lo sepan: Los soundbanks consisten en un archivo de control que tiene un índice de los samples y la configuracion de cada uno (puntos de bucle, "envelope", etc) y luego un bloque donde realmente están lo samples.

@EMaDeLoC Ufff me "ignoras" tanto que te das el "gusto" de rebuscar en cada uno de mis comentarios jaja,eres patético.

La diferencia entre Conker y tu es que él habla de un tema y no saca otra consola de la nada para "dejarla mal", tu no eres mas que un niño malcriado repitiendo cosas de las que no tienes ni idea de lo que dices.

otra fuente para las muestras de programación oficiales
https://archive.org/download/n64codesamples
no lo he bajado para comparar si hay alguna diferencia con el zip que puse antes, pero parecen ser menos y no esta la "teapot".

MAS: Como recientemente foobar2000 ha incluido descripciones en linea en las actualizaciones automáticas he visto esto en la última actualización del componente vgmstream para archivos de audio de videojuegos:

• Add VADPCM for AIFC + .n64 SDK/src samples

Supongo que no es gran cosa porque casi todo van a ser samples de sonido, lo cual no es muy interesante de escuchar sin mas, pero ahí esta...

EMaDeLoC escribió:Como siempre magistrales tus clases sobre la consola.
¿Llegaste a leer la información que dí de la RDRAM de la N64? Fue aquí y aquí.
¿Te cuadra con algo que sepas sobre desarrollo en la consola? ¿Se habla en alguna parte de un tamaño recomendado de lectura de datos de la RAM?
¿Sabes como compara el z-buffer de cada pixel? ¿El z-buffer esta en la RAM?
.

No prob

- 500MB/s de lectura, de escritura o combinados? De escritura creo que se va a quedar muy lejos de los 500MB/s, en los tests de fillrate conseguía algo cercano a 200MB/s, dibujando rectángulos 320x240x16bit de 1 sola textura sin hacer nada más (target 60fps), sin recarga, tendría que revisar muy bien, porque en las multiplicaciones si me equivoqué en algo puede ser muy arriba o muy abajo el resultado, comprobar que corre de fondo o si podría sacar más, que seguramente sí, porque eran tests en libdragon.

La CPU consigue muy poco ancho de la RAM, es el componente más castigado del sistema en ese aspecto, tienes los tests del autor de CEN64 aquí, que probablemente los hizo en ASM donde nada interfiere (nota: tests sin cache, obligando a la CPU a acceder a RAM)
https://forums.cen64.com/viewtopic.php?f=15&t=35

Aunque sus posts son de 2013, habría que preguntarle ahora 7 años después si eran 100% correctos o si encontró vías más rápidas.

Pero bueno la idea global es que no se puede llegar a 500MB/s usando los componentes por separado y probablemente menos con todos funcionando a la vez en un juego.

Lecturas y escrituras de grandes bloques ayudan a sacarle más partido a la RAM y el rendimiento no es linear, si consigues 2000 sprites a 60fps, no vas a conseguir 4000 a 30fps, serán 4500 y así, cuanto más tiempo le das para trabajar en 1 frame mejor responde N64 y mejores resultados arroja la memoria en sus benchmark.

En mis tests por ejemplo uso como medida el framerate, 30 o 60fps que serían las condiciones reales de un juego, para luego no llevarme sorpresas, pero hay benchmarks también validos como mandar a la consola a hacer 200000 operaciones, calcular cuanto ha tardado, que pueden ser varios segundos y luego sacar un resultado, en ese caso los tests siempre saldrían más favorables.

- El Z-Buffer se hace por hardware, la comparación de pixel la hace el RDP al activar el bit Z-compare (y algunas cosas más), es muy rápido, aunque repercute en el rendimiento, hace 2 lecturas o escrituras por pixel.

- Sí, el Z-Buffer es una región en la RAM.

@Conker64 Cuando dices que el Z-buffer se hace por hardware, te refieres a una funcion incrustada en el silicio o hablamos de un proceso programado en el microcódigo?

@radorn
Es una función fija del RDP, al igual que alpha_compare, que se usa para saber si un pixel es transparente o se pinta.

En el z_compare mira la región de Z-buffer, si el pixel va por delante actualiza el buffer con el nuevo Z y pinta el pixel en el framebuffer, si falla la comparación omite los 2 últimos pasos.

Puedes activarlo o desactivarlo por superficie.

Puedes elegir como se comportará Z de distintas maneras.

En el RSP puedes trabajar con la distancia de Z, en plan si el rango completo de Z es 1 metro o son 1000, como si el espacio es una habitación y puedes hacerla en alta precisión o si es una galaxia, donde tendrás que espaciar más Z y perder precisión o usar distintos truquillos como hace Zelda en la campiña.

Conker64 escribió:2000 sprites a 60fps

Jesús...

Menuda máquina para 2D hubiese sido la n64 aprovechando las ventajas del cartucho. Los planos a base sprites también, imagino.

¿Cuantos sprites necesitaba un plano en tus ejemplos del castlevania?


editado:
2000 sprites... 4000 polígonos... 60fps... eso hacen 240.000 polígonos por segundo, ¿por qué para 2D si pero para 3D no?.

Conker64 escribió:- 500MB/s de lectura, de escritura o combinados? De escritura creo que se va a quedar muy lejos de los 500MB/s, en los tests de fillrate conseguía algo cercano a 200MB/s, dibujando rectángulos 320x240x16bit de 1 sola textura sin hacer nada más (target 60fps), sin recarga, tendría que revisar muy bien, porque en las multiplicaciones si me equivoqué en algo puede ser muy arriba o muy abajo el resultado, comprobar que corre de fondo o si podría sacar más, que seguramente sí, porque eran tests en libdragon.

Si el datasheet de una RDRAM igualita a la de N64 no falla, en escritura la tasa de transferencia sería mayor ya que hay menos latencia al solicitar la escritura (40 nanosegundos en lectura frente a 16ns en escritura). Pero esto solo benefícia sustancialmente si los paquetes son pequeños. Es decir, la velocidad de lectura es mucho menor que la velocidad de escritura si se trata de paquetes más pequeños de 100 bytes.
También tengo que señalar que la hoja no me detalla si hay un tiempo de espera después de una operación de escritura, y que si lo hay, pues evidentemente la tasa de transferencia disminuiría.

Voy a clarificar lo de los paquetes porque igual no se me entendió bien.
A la memoria no le puedes pedir que te lea o escriba 1MB del tirón. Has de decirle una dirección de memoria y un tamaño del paquete de datos que quieres leer o escribir. En el caso de la RDRAM, los paquetes pueden ser de entre 4 y 256 bytes. Si quieres leer 512 bytes, tendrás que pedir dos paquetes de 256, y si quieres pedir 300 bytes, pues un primer paquete de 256 y otro de 44bytes. Y si quieres pedir 1MB, pues 1048576 / 256 = 4096 paquetes. En principio de gestionar esto se encarga el RCP o el sistema operativo y el desarrollador no lídia con esto.
La cuestión es que debido a la latencia un paquete pequeño no va tan rápido como uno grande. Por ejemplo, leer 4bytes nos va a tardar 48ns, pero leer 28bytes tardará 96ns. En este caso tardando el doble de tiempo obtenemos 7 veces más datos. Sin embargo esto no es proporcional, ya que por ejemplo con un paquete de 108 bytes tarda 256ns, y con 236bytes tarda 512ns, un poco más de doble de datos con el doble de tiempo.
Nota: por simplificar los bytes son de 8bits, no los 9 del bus de la RAM.

Esto significa que el rendimiento de la memoria varía y mucho dependiendo del tamaño de los paquetes que se estén manejando. Cuanto más grandes más velocidad conseguiremos, pero cuando sean pequeños, la velocidad se desploma.

Basandome en los datos del datasheet hice una hoja de cálculo con una tabla de velocidad por tamaño de paquetes, y el resultado es este gráfico de tasas de transferencia muy ilustrativo:


Como se puede ver, por debajo de los 50 bytes el ancho de banda se nos va al garete.
Para quién le interese ver la hoja de cálculo, pinchar aquí.

Un ejemplo práctico de este problema lo tenemos con el rellenado del framebuffer. Hace un tiempo se habló de que era más eficiente estirar los polígonos horizontalmente que verticalmente. Como el framebuffer se organiza en la memoria una línea horizontal seguida de otra, escribir 10 píxeles horizontales es una escritura de un paquete completo de 10 píxeles seguidos, pero escribir 10 píxeles verticales significa 10 saltos en la memoria, y por tanto 10 paquetes distintos y encima de apenas un par de bytes por paquete. Resultado: la línea horizontal se pinta a tasas cercanas a 400MB/s, la línea vertical a menos de 200MB/s. Justo esa cifra es la que te daba con tu prueba de pintar rectangulos, ¿no? Parece que por algún motivo pinta los rectángulos pixel a pixel.

En resumen, y fijándonos en el gráfico, la velocidad ronda los 400MB/s, pero dependiendo de las operaciones que se hagan puede caer estrepitosamente.

Conker64 escribió:La CPU consigue muy poco ancho de la RAM, es el componente más castigado del sistema en ese aspecto, tienes los tests del autor de CEN64 aquí, que probablemente los hizo en ASM donde nada interfiere (nota: tests sin cache, obligando a la CPU a acceder a RAM)
https://forums.cen64.com/viewtopic.php?f=15&t=35

No me extraña porque debe tener una latencia enorme entre que solicita un dato, el RCP lo solicita a la RAM, esta le responde y se lo pasa a la CPU. De todas formas es una cosa que ya comenté hace tiempo, el grueso de la necesidad de memoria del pipeline gráfico se establece entre RCP y RAM. La CPU no debería necesitar tanto ancho de banda y limitarse a operaciones pequeñas que pueda hacer con sus 8kb de caché. Es decir, la CPU está perjudicada pero a efectos de un juego no debería ser vital en el funcionamiento. Pero es opinión mía.

Conker64 escribió:- El Z-Buffer se hace por hardware, la comparación de pixel la hace el RDP al activar el bit Z-compare (y algunas cosas más), es muy rápido, aunque repercute en el rendimiento, hace 2 lecturas o escrituras por pixel.

Habría que ver como lee y compara el RCP este z-buffer. No creo que vaya pixel por pixel porque el rendimiento sería mucho peor del que vemos. ¿Es posible que lea una línea entera y la cargue en el RCP para hacer la comparación y después escribir el resultado?

Conker64 escribió:- Sí, el Z-Buffer es una región en la RAM.

¿Pero es una región separada del framebuffer o cada pixel de este tiene información de Z? Creo recordar que alguién dijo que debido al bus de 9bits cada pixel eran 15 bits de color y 3 bits de Z (o 16 y 2, no lo recuerdo bien). Por lo que he comentado antes, sería mucho más óptimo de esta manera al solicitar a la RAM paquetes de mayor tamaño.
Aviso: según como sea esto, se nos puede caer el mito del World Driver Championship.

Vaya tochete técnico...

Entonces, ¿un juego 2D, simulando sprites con 2 polígonos, puede alcanzar 240.000 polígonos por segundo gracias a que resulta mas eficiente pintandolos horizontalmente que un juego 3D?.

¿No se podría transladar a entornos 3D?.

EMaDeLoC escribió:

Conker64 escribió:- Sí, el Z-Buffer es una región en la RAM.

¿Pero es una región separada del framebuffer o cada pixel de este tiene información de Z? Creo recordar que alguién dijo que debido al bus de 9bits cada pixel eran 15 bits de color y 3 bits de Z (o 16 y 2, no lo recuerdo bien). Por lo que he comentado antes, sería mucho más óptimo de esta manera al solicitar a la RAM paquetes de mayor tamaño.
Aviso: según como sea esto, se nos puede caer el mito del World Driver Championship.

Vaya tochete técnico...

¿qué quieres decir con lo de WDC? Explícamelo como si fuera una abuela.

EMaDeLoC escribió:¿Pero es una región separada del framebuffer o cada pixel de este tiene información de Z? Creo recordar que alguién dijo que debido al bus de 9bits cada pixel eran 15 bits de color y 3 bits de Z (o 16 y 2, no lo recuerdo bien). Por lo que he comentado antes, sería mucho más óptimo de esta manera al solicitar a la RAM paquetes de mayor tamaño.
Aviso: según como sea esto, se nos puede caer el mito del World Driver Championship.

El Zbuffer es otro framebuffer de 16 bits independiente de los búferes gráficos, y, además, debido a cómo funciona la RAM o el controlador de memoria, para mejorar el rendimiento un poco (o, para no ahogarlo tanto), se suele almacenar en una región apartada de la de los gráficos. Creo que es algo de que cada bloque de 1MB o 512K tiene replicados ciertos mecanismos de control, así que se alivia algo el problema de la latencia si escribes alternativamente a uno y a otro.

Luego grabaré una demostración con el visor de memoría del AR/GS, que permite ver toda la memoria de la consola como gráficos y puedes ver claramente el framebuffer (frecuentemente doble, a veces triple, según el juego) y hasta ver el framebufer como gráficos (se ve raro)

Lo de los bits extra no es el framebufer, si no una parte complementaria del anti-aliasing: Con un framebuffer de 16bit, tienes dos bytes de 9bit, así que te sobran 2 bits por pixel. Esta información puede ser rellenada por el RDP durante el renderizado para asignar valores de mezcla de color que luego interpreta el VI. Con dos bits los valores son 0, 1, 2, y 3. Cuando el VI se encuentra un valor de 0 en un pixel, no hace nada. Si se encuentra 1, 2 o 3, mezcla en el color de ese pixel, algo de los colores adyacentes, en proporción de 25%, 50% o 75%. El algorítmo exacto que determina de qué pixel/es adyacentes toma el color a mezclar en el actual lo desconozco.
Este proceso es el responsable de que, por ejemplo, cuando una arista de un polígono cruza con otro, o con el borde de la imagen, se vea como si se pegase, y haya ese baile de puntitos en las zonas de contacto.
El objetivo de todo esto es complementar el antialiasing que si hace el RDP (no hace AA en aristas flotantes) y también mejorar la cobertura entre aristas adyacentes para enmascarar los huecos entre polígonos que tan prevalentes son en algunos juegos de PS1, por ejemplo. En muchos juegos aún sin esto no hay muchos huecos de esos, y opino que el suavizado no compensa la borrosidad que resulta. Esta es también una de las cosas que se desactivan con los parcheados anti-AA que aparecieron hace unos años.

cegador escribió:¿qué quieres decir con lo de WDC? Explícamelo como si fuera una abuela.

Imagino que se estaría refiriendo a su especulación de que si el zbufer fuera en esos 2 bits extra por pixel, o bien WDC no ganaría nada por prescindir de el, o, supuestamente, seguiría teniendo framebufer.
El caso es que un framebufer de 2 bit por pixel solo podría tener 4 distancias (aqúi, allá, y entre ellas, dos posiciones intermedias) en vez de 65536, y sería totalmente inutil para cualquier entorno 3D.
Quizá para 2D, si se puediera aprovechar de esa manera, valdría para tener 4 planos de superposición, pero para 3D no valdría para nada.

cegador escribió:¿qué quieres decir con lo de WDC? Explícamelo como si fuera una abuela.

Me refería a que la ventaja del WDC al eliminar el z-buffer no sería por el acceso a memoria, sino por una mejora de rendimiento del RCP al saltarse ese paso. Pero por lo explicado por @radorn no van por ahí los tiros.

radorn escribió:El Zbuffer es otro framebuffer de 16 bits independiente de los búferes gráficos, y, además, debido a cómo funciona la RAM o el controlador de memoria, para mejorar el rendimiento un poco (o, para no ahogarlo tanto), se suele almacenar en una región apartada de la de los gráficos. Creo que es algo de que cada bloque de 1MB o 512K tiene replicados ciertos mecanismos de control, así que se alivia algo el problema de la latencia si escribes alternativamente a uno y a otro.

Mmmm... quizá tenga algo que ver con un diagrama de bloques que hay en el datasheet de la memoria, en el que divide la RAM de 2MB en dos bloques de 1MB cada uno con una cache de 2KB. Pero compartiendo el mismo bus no veo como puede aliviarse el problema.

Si el z-buffer va a parte, entiendo que para comparar carga ese punto concreto y de hacer falta lo sobreescribe en el framebuffer o no. Al menos a mí me parece más efeciente así que cargar pixel y z-buffer. Y más eficiente si carga los datos a sobreescribir, pero eso ya no sé como lo hace el RCP.

Y si, me había confundido con esa parte de mezcla de píxeles del VI.

EMaDeLoC escribió:Pero compartiendo el mismo bus no veo como puede aliviarse el problema.

Bueno, el bus en sí no tiene por que tener tanta latencia o ninguna. La latencia viene dada por las celdas de la RAM y el proceso para leer y escribir en ellas. Tu mismo analisis de que leer tiene mas latencia que escribir lo atestigua.
Cuando tu escribes datos, algún intermediario/caché acepta el bloque que envías y te da el OK, y luego ya, el proceso de almacenamiento queda oculto para ti aunque aún no se haya completado. Es como echar la carta en el buzón. Tu ya la has entregado, cuando llegue ya es otro asunto. Lo único que esperas tu es el tiempo entre que solicitas almacenar algo y el momento en que se acepta tu paquete. Lo que tarde después el encargado en llevarlo al almacen ya no es cosa tuya.
Pedir datos es otro tema, y en ese caso te chupas todas las esperas. Primero llamas a la puerta, luego dices lo que quieres, el dependiente se va a buscarlo, lo prepara, lo empaqueta y, finalmente, te lo entrega. De cara al controlador de memoria el trabajo no ha acabado hasta que se termina todo el proceso.

Bien... pues, si internamente hay bloques separados en los chips de RAM, entiendo que eso significa que hay cierta circuitería de control repetida encargandose de bloques de memoria distintos y son estos los que se encargan de almacenar y recuperar los datos de parte de la interfaz con el bus.
Si tu tarea permite separar los datos en dos bloques diferentes, puedes rascar un poco en las latencias si vas alternando escrituras en bloques internos distintos. Digamos que solicitas escribir un paquete en uno de los bloques, y, una vez acabado, va a haber un poco de espera hasta que ese bloque haya acabado y esté listo para recibir uno nuevo. Sin embargo, tu ya estás listo para enviar un paquete nuevo. Si en vez de esperar a que ese mismo bloque te de luz verde para el siguiente, vas y escribes en el otro bloque, parecería razonable que te ahorrases algo de tiempo de espera.

Todo esto es extrapolación mía en base a la explicación que leí alguna vez acerca de la razón por la que el bufer de video y el bufer de Z estuviesen separados en distintos bloques internos de la RAM.

@EMaDeLoC
- El problema es que con algunos datos teóricos no puedo hacer nada.

Si al RDP le dices que enchufe un rectángulo de 320x240x16bit con una textura las opciones de configuración son muy cortas, puede importar si estás usando atomic_prim o no, si la textura está estirada como dices, pero una vez puesto en marcha el chip hace su trabajo.

Podrás configurarlo previamente con comandos, usar load_block en lugar de load_tile, para alinear la memoria a la hora de subir la textura a TMEM (solo se sube una y no se actualiza, así que en éste caso no importa) y podrás tocar diferentes estados y modos, como COPY, colocar el framebuffer en regiones concretas de memoria (z y frame en diferentes bancos como ya se ha comentado), usar GCC más modernos o distintas opciones de compilador, pero creo que se entiende, en ASM hacer que la consola pinte un rectángulo con textura son muy pocas lineas, es algo muy automatizado.

Es más grave que algunos juegos solo logren pintar 5-15MB/s de framebuffer final a que algún test aislado fuera de frame pueda llegar a conseguir 400MB/s en alguna operación concreta, ahí es donde veo el margen de mejora

@Señor Ventura
Serían 2000 de 16x16 en cycle1, en copy algunos más (conseguí las mismas cifras que Nintendo)



Aunque:
- Es un benchmark donde todos usan la misma textura, el rendimiento sería peor de tener cada uno la suya
- Los polígonos planos o rectángulos necesitan mucho menos cálculo que los 3D, pintar un triángulo lleva muchos más pasos

Texturizar es más lento, en el test de los copos con FILL conseguía cerca de 400K/s, por eso se recomienda goraud donde sea posible en 3D


La demo del Castlevania usa tiles de 16x16 en el plano principal (256x224/16 = 224, más una fila/columna extra para la transición de tiles), las capas de fondo varían de tamaño, pero uso un render inteligente para no pintar lo que está completamente tapado por delante.

@EMaDeLoC

Descripción escribió:Este cartucho de "trucos" tiene una funcion opcional por la cual se puede activar un programa de monitorización junto con el juego. El cartucho, además, tiene un botón extra que si es pulsado durante una partida con el monitor activado, permite acceder a funciones de búsqueda de trucos y también visualizadores de memoria, incluído uno que interpreta toda la RAM con el formato de datos de framebuffer, con el visualizador enfocado en el framebuffer que se está mostrando en pantalla actualmente.
La mayoría de juegos tienen un buffer doble, como el caso de GoldenEye, demostrado en este video, que le permite mostrar una imagen mientras la siguiente se está dibujando. En el primer ejemplo del video se puede ver esto claramente, pues he tenido la suerte de interrumpir el renderizado cuando el siguiente cuadro aún no ha terminado de renderizarse.
También hay juegos con triple buffer

Además de esto, desplazándonos por el resto de la RAM acabamos encontrándonos con el Z buffer, otro búfer de 16bits del mismo tamaño que los de imagen, que almacena los valores de profundidad a medida que se va dibujando la escena para poder determinar si el pixel nuevo debe dibujarse por encima del anterior.

En el segundo ejemplo vemos una de las torres de vigilancia con cristales, y vemos como estos no se muestran en el framebufer. No tengo una teoría clara en este momento de cómo funciona el tema de las transparencias, pero, imagino que, para empezar, se dibujarán en último lugar, después de que todo lo demás haya sido renderizado, y tendrán algún tratamiento especial.

@Conker64 224 sprites para un plano deja una barbaridad de margen para meter toda la tralla del mundo... 1776 sprites para objetos... es muchísima tela eso.

¿Cuantos sprites puedes animar a la vez dentro de un frame?, es decir, actualizar su estado para crear frames de animación de explosiones, movimiento de personajes, y cosas así.


Lo de los 400.000 polígonos en gouraud me parece una brutalidad, ¿que cifras arroja la versión ps2 del virtua racing?.

radorn escribió:Bueno, el bus en sí no tiene por que tener tanta latencia o ninguna. La latencia viene dada por las celdas de la RAM y el proceso para leer y escribir en ellas. Tu mismo analisis de que leer tiene mas latencia que escribir lo atestigua.

No hombre, el bus no tendrá latencia, pero mientras se realiza una operación en el bus no puede realizarse otra hasta que acabe la anterior.
Ten en cuenta que el bus es compartido entre direcciones y datos. Es decir, mediante los 9bits se envía la dirección de memoria y el tamaño de los paquetes y tras la latencia correspondiente por esos mismos 9 bits llegan los datos pedidos o los que deben guardarse. Si se hicieran dos operaciones sin que se esperase a acabar una, se mezclarian datos y direcciones.
Lo que tú sugieres ya debe ocurrir dentro de la memoria en los dos bloques. Se envían y reciben los datos en double data rate (dos datos por ciclo de reloj) y seguramente el controlador interno de la RAM alterne de un bloque a otro para conseguir esos datos dobles en el mismo ciclo de reloj.

No creo que lo de los bancos o regiones de memoria funcione como piensas. Para poderse alternar adecuadamente debería haber dos bancos físicos separados con su respectivo bus, y en la N64 solo tenemos un bus y en las últimas revisiones solo un chip de memoria. Lo de las regiones de memoria distintas será para que el RCP tenga su propio puntero a cada una y además sea reservada y no se vea afectada involuntariamente por otro proceso.

@Conker64 Entonces el bajo rendimiento de pintar rectangulos de 320x240x16bit podría tratarse de un tema de microcódigos a la hora de leer y escribir datos en la RAM, que no esté todo lo optimizada que debería.
Es curioso ver en el gráfico que adjuntas que los tiles horizontales sean más rápidos que los verticales siendo la misma cantidad de píxeles, aunque también nos dice el gráfico que el rendimiento del RDP se ve afectado por el tamaño de estos.

@radorn de nuevo:
Muy chulo lo del cartucho GameShark. Efectivamente ahí se ve el z-buffer separado del framebuffer.
Lo de las transparencias, se pintan encima de triángulos ya pintados con un valor de color, así que se hace en un segundo paso. Supongo que no salen en el z-buffer debido a que cuando se pintan no alteran el z-buffer, de hecho cuando se pintan transparencias no hace falta escribir datos nuevos en el z-buffer, solo leer lo que ya hay.
No sabía esto de los Action Replay. Has hecho que ahora quiera uno.

Perdón por meter la cuchara en este hilo, pero estoy leyendo que sin z bufare y corrección de perspectiva la n64 podría alcanzar los 600.000 polígonos por segundo.

@Señor Ventura Normalmente eso suelen ser con pruebas específicas bastante favorables. Muchas veces se trata de un triángulo de tamaño normal en el centro de la pantalla, sin procesos extra ni dificultades, y luego los datos de velocidad se extrapolan.

@EMaDeLoC
No, no hay ningún ucode, no se usa el RSP, es un test de estrés de fillrate puro y duro.

Claro, rectángulos alargados a la hora de pintar, texturas alargadas a la hora de subir a TMEM y framebuffer / z-buffer alargados también si puedes, como vendría ser 640x240 si vas a usar "alta resolución"

@Señor Ventura
Serían 255 (17*15), sumamos fila y columna extra para los desplazamientos por capa.

Si texturizas cada cosa de forma distinta no podrás llegar a 2000, tuve que usar recarga inteligente de texturas y otras técnicas para incrementar el rendimiento.

Tras poner todas las capas para el escenario más complejo de SOTN aún rondaba los 100fps, podría poner Alucard y algún bicho gigante, más algunos efectos, pero libdragon no es el mejor ejemplo para eso, especialmente cuando no se usa hilos (audio sobretodo) ni el RSP.

Los 400K serían rectángulos, recuerdo que daba lo mismo si eran de 4x4 que de 8x8, a partir de 16x16 perjudicaban el rendimiento, en 3D habría que estudiarlo todo de nuevo, de todas formas si la consola llegaba a 100-120K texturizando como en el caso de World Driver, alcanzaría cifras superiores si todo fuera goraud o flat, creo que podríamos partir de ahí.

¿Qué posibilidades veis de que ahora que han decompilado el Mario 64 consigan hacerlo con más juegos? Me refiero a si al haber conseguido hacerlo con M64 sería más fácil hacerlo con futuros juegos o no? Estaría bien por si pueden corregir errores como hicieron con M64 https://www.romhacking.net/hacks/4905/

Conker64 escribió:Tras poner todas las capas para el escenario más complejo de SOTN aún rondaba los 100fps, podría poner Alucard y algún bicho gigante, más algunos efectos, pero libdragon no es el mejor ejemplo para eso, especialmente cuando no se usa hilos (audio sobretodo) ni el RSP.

Pues esto no suena muy bien, ¿no?, hay veces que se concentra bastante acción en pantalla, y por lo que dices no llegaría a poder dibujar tanto...

¿Cuantos sprites de 16x16 puedes actualizar para crear animaciones en cada frame?.

Conker64 escribió:Los 400K serían rectángulos, recuerdo que daba lo mismo si eran de 4x4 que de 8x8, a partir de 16x16 perjudicaban el rendimiento, en 3D habría que estudiarlo todo de nuevo, de todas formas si la consola llegaba a 100-120K texturizando como en el caso de World Driver, alcanzaría cifras superiores si todo fuera goraud o flat, creo que podríamos partir de ahí.

Perfecto que sean 400.000 rectángulos, pero 16x16 no es muy rectangular.

¿El virtua racing arcade sería factible en n64?, recordemos que encima va a 30fps... el de ps2 a lo mejor si que se escapa, con ciertos efectos de post procesado y sombras complejas, además de 60fps.

@SuperPadLand El proyecto de GitHub https://github.com/n64decomp donde está la decompilación de Mario 64 tiene también otros repositorios donde se está trabajando en la decompilación de Zelda OoT y MM, GoldenEye y Perfect Dark. Del PD tienen un sitio web que lista un porcentaje de progreso de 12.81% para las ROMs NTSC r00 y r01 (hace unos días cuando lo ví por ultima vez estaba al rededor del 12.6% así que parece que están activos).
No se cuánto tardarán, pero se ve que hay alguien trabajando en ello.

No obstante, yo tenía entendido que el caso del Mario 64 era especial porque Nintendo había generado la ROM con unas opciones de compilador inusuales que produjeron código máquina con una estructura más reveladora de lo habitual acerca de la forma original del código fuente original y que eso es lo que facilitó el proceso de decompilación.
No se si es que en estos juegos también pasa lo mismo, o es que lo que han aprendido con Mario 64 es aplicable otros juegos aunque no tengan esas "pistas", o cómo funciona todo esto. Es todo demasiado técnico y hasta científico.

@radorn a mi sobre todo me interesa lo de que quizás puedan optimizarlo para correr en N64. Supongo que es muy difícil, pero el PD por ejemplo si le encontrasen cosas mejorables y le suben algo al framerate sería una delicia jugarlo en N64.

@SuperPadLand Lo de la falta de optimización del Mario 64 NTSC fue que, por lo visto, la estabilidad de las optimizaciones del compilador no estaba garantizada en el momento del lanzamiento y no se quisieron arriesgar a producir millones de cartuchos con un juego propenso a cuelgues.
Ahora se puede hacer tranquilamente porque los compiladores están mucho mas depurados, además de que las optimizaciones son aún mas agresivas que las de entonces.

Respecto a lo de hacer lo mismo con PD... no se, yo no me esperaría demasiado. Optimizado o no, el juego carga la consola de lo lindo. No creo que sea precisamente la ejecución de código a nivel de la CPU lo que de problemas al juego.

Claro que ahora que se han filtrado los materiales de desarrollo del hardware y las librerías de la consola, se abren muchas puertas a mejoras.

Una cosa interesante, aparte de la posible aparición N64s SoaC (aunque dudosa, por varias razones legales dificiles de evitar y, mucho mas, demostrarlo ante un juez), sería portar los juegos a N64s con overclock tanto en la CPU como en otros componentes.

En fin, que se abren muchas posibilidades... POSIBILIDADES, no certezas. Y aprovecho para insistir en lo negro que está el futuro, especialmente en España, así que no se yo si lo veremos o estaremos en posicion de disfrutarlo...

@Señor Ventura
No creo que hubiera problema de manejar el min 7:20 en libdragon, 1 bicho grande, un enemigo, Alucard, rastro y algo de explosiones.


Una pantalla negra sin nada más en libdragon eran 500fps, mientras 1200-1400fps en libn64 (no es que sea 3 veces más rápida a la hora de hacer otras cosas, pero esos son los resultados), luego bajar de 100 a 60 requiere más carga que de 200 a 100 por ejemplo, el objetivo es que siempre vaya algo holgada.

Ni idea Virtua Racing sin saber assets, pero que casi todo sea flat facilita las cosas desde luego

@Conker64 bueno, en teoría sin corrección de perspectiva ni z-buffer la n64 puede calcular y pintar muchísimos más polígonos que la playstation, así que bien pensado no hay motivos para pensar que no se pueda hacer. Además tienes la ventaja del cartucho.

Que hablando del cartucho... no se si es porque no existe el dato, pero a la hora de actualizar sprites, ¿se sabe cual es el máximo teórico para hacer animaciones?.

@Señor Ventura No hay ningún juego que acceda a los recursos gráficos desde el cartucho durante el dibujado de la pantalla. Igual que otros datos, las texturas se transfieren por DMA a la RAM y se usan desde ahí. N64 no funciona como una NeoGeo o NES, dibujando la pantalla directamente con los gráficos del cartucho, ni tampoco como la SNES o MD, que llenan una caché en cada frame con los recursos necesarios para el cuadro actual.
Casi cualquier escena de un juego de N64 mínimamente decente contiene demasiados recursos como para usarse directamente desde el cartucho en tiempo real o, incluso, transferirse enteramente desde este a la RAM para cada frame. No es solo que castigaría el ancho de banda de la RAM. Es que además el cartucho no es lo suficientemente rápido para semejante tarea.
No, hay que cargarlos en RAM con adelanto con suficientes datos para, al menos, empezar el nivel actual o sesión de juego. Esta carga puede ser completa de todo lo que se vaya a necesitar hasta acabar el nivel, o, dependiendo de la situación, el programador puede hacer una carga inicial suficiente para empezar el nivel, y dejar otros elementos en el cartucho para irse cargando según se necesiten.
Por ejemplo, en GoldenEye parte de las texturas, especialmente de objetos y armas, se van cargando en memoria a medida que avanza el nivel y te vas encontrando los objetos que las necesitan o desenfundando las armas correspondientes. Son cargas relativamente pequeñas y se lo pueden permitir (a veces puedes notar un pequeño renqueo o tardanza inicial en cargar un arma por primera vez, por ejemplo, aunque es algo bastante sutil)

Además, recuerda que ya se ha comentado que la mayoría de datos en los cartuchos van comprimidos de una forma u otra, así que requiren una descompresión previa antes de usarlos, imposibilitando el uso directo incluso aunque el bus fuera lo suficientemente rápido.

@radorn entiendo... al menos igualmente la n64 también tiene mas ram que la playstation, así que también precargando debería no quedarse por debajo de lo que requeriría un castlevania sotn.

Que pena, con lo bestia parda que podria haber sido esta máquina con las 2D, ¡y a 640x480!.

La música del SotN es en midi?

SuperPadLand escribió:La música del SotN es en midi?

Iba a decir que no, pero fui a comprobarlo y resulta que el paquete de música ripeada del juego si que contiene dos pistas ripeadas en PSF, o sea que son algo sintetizado en tiempo real por la máquina (midi, mod o lo que sea). No obstante también tiene una pista CD-DA y el resto son todo pistas ADPCM CD-XA.

@radorn lo digo porque sería un problema a tener en cuenta de querer hacer un port a N64, supongo que alguien que sepa hacer música en midi podría adaptar la música.

@SuperPadLand Bueno, en mi opinion, los homebrews de N64 hoy día no deberían limitarse a los 64MB de máximo oficial de ROM.

Está el 64drive HW2 que ofrece hasta 240MB, que no está nada mal. Pero, además de eso, tanto el 64drive como la familia EverDrive ofrecen algún tipo de acceso a la tarjeta SD también. Opino que debería aprovecharse esto también si se necesita almacenamiento masivo para, por ejemplo, video y audio pregrabado.

Claro que esto sería fuente de algunos problemas: Primero, que la forma de acceder a uno y otro no es la misma, así que habría que hacer una librería de acceso universal que soportase ambos o una solución al estilo de DLDI, que se hizo para la DS y su millón de tarjetas "pirata", una librería de acceso intermedio y un sistema de drivers provistos por los menús de las distintas tarjetas que se encargasen de traducir las llamadas genéricas de DLDI a las específicas del hardware.

Esto también podría abrir otra brecha entre emuladores y cartuchos flash, además de limitar el uso en placas repro, cuyo hardware tendría que volverse mucho mas complejo para acojer este tipo de homebrew.

... en fin. mira en qué lio me he metido xD

También hay la demo de la OST completa en OGG, aunque ese formato no lo usaría para el juego, lo pongo de nuevo, igual se ha perdido entre las páginas.


https://mega.nz/#!Y9pQjYgC!S3LojMylb3lQ-RWEpdtdVxzCJKy9Td1b9AHr7Sq370w

@Conker64 Como aún no me he revisado todo el hilo, desconocía esa demo. No recordaba que hubiesen portado Vorbis a N64.

Veo que el led de actividad del 64drive se pone loco cuando cambio de pista ¿pre-buffer?

Aprovecho para sacar a relucir mi insufrible pedantería y decir que no es "OGG" si no Ogg Vorbis.
Vorbis es el codec de audio, y Ogg (que no OGG, pues no son siglas si no una palabra pronunciable) es el formato contenedor (avi, mp4, matroska/mkv/mka...) creado por Xiph para sus formatos multimedia de software libre, sin licencias, y sin patentes.

Hablando de música pregrabada: Si no recuerdo mal, siguiendo la tradición de NES y SNES, y, creo que también MS y MD, la ranura de cartuchos de N64 tiene un par de patillas por las que la consola acepta audio analógico proveniente del cartucho y lo mezcla con la salida de audio normal. Estaría bien si alguno de los cartuchos hiciese decodificación de audio internamente y lo sacase por esas patillas. Probablemente ninguno vaya a hacerlo jamás, ya que no hay software que lo use, la scene homebrew sigue siendo bastante minoritaria, y no se podría justificar el aumento de precio por algo que casi nadie aprovecharía. Es una pena, pero que se le va a hacer.

----------------------------------

En otro orden de cosas, en los hilos de 4chan sobre la filtración alguien ha comentado que el creador de bsnes/higan, byuu, aparentemente bajo otro pseudónimo, aún después de haber anunciadio en su sitio web que "abandona internet por una temporada", parece ser que ha empezado el desarrollo de un nuevo emulador de N64 https://twitter.com/ares_emu
No tengo claro si es el o un colaborador suyo o cómo va la cosa, pero en los twits se mencionan cosas de la 64.
También hay un patreon.

No se que saldrá de todo esto, pero ahí esta para quien le interese.

@radorn es que lo interesante es no pasarse de los limites que había en su momento, más que nada si lo que estamos hablando es de como hubiera sido SotN en N64 en aquellos años. En 1997 creo que no había ni juegos de 32mb aunque podemos comprar que el juego hubiera salido más tarde en el 2000 y usar 64mb. Es como si alguien modifica el hardware de PSX para meterle 16mb de RAM y el mod de OC a 66mhz y de repente empieza a decir que la máquina hubiera podido mover los juegos 2D mucho mejor que Saturn y todo a 60fps.

Esto supongo que irá para gustos de cada uno claro, pero para mi la gracia de una consola es que son sistemas cerrados que tenían sus propias virtudes y limitaciones, ver que se consigue hacer dentro de esas normas es lo que me produce satisfacción. El resto me parecen curiosidades, pero me da un poco igual que una NES corra el Crysis usando una rasberry enchufada al cartucho. Bueno, tú ya lo sabes porque con los hacks busco lo mismo, que funcionen en la consola y no en un emulador que se salta los límites.


Edit: Con esto no estoy diciendo que reniegue de juegos de 256mb si salen ahora en cartucho a la venta por parte de la scene. Digo que lo realmente interesante de como hubiera sido un juego en los 90 es aceptar las normas de los 90.

@SuperPadLand Entonces, música mono a 22k con mucha compresión cargando los buses con el tráfico y los procesadores con la decodificación, y probablemente editada para acortar partes.
Aceptarías usar un 64DD (real o emulado por el cartucho) como almacenamiento extra para música?

O adaptaciones MIDI...

@radorn
Hay errores reportados en 64drive, igual tendría que compilarla en z64, Vorbis es la primera librería que porté a N64

Pides demasiado, yo no me fijo en esos detalles

@SuperPadLand No me parece que un cartucho gran tamaño se salte las normas de los 90. En aquella época no se usaron por temas de costos, pero se podrían haber usado tranquilamente (otra cosa es que serían más caros que los de NEOGEO).

Igualmente, me parece que en si el tamaño de cartuchos de la 64 es el menor de sus problemas (Siendo los importantes el tamaño de la caché de texturas y la latencia de la RAM si he oído bien).

Conker64 escribió:Vorbis es la primera librería que porté a N64

¿A qué te refires con que hay errores? yo no veo error ninguno, cambio de pista y suena. Solo preguntaba cual era el proceso de carga, porque veo una fuerte acitividad de aceso en el momento del cambio y luego ya se calma a un nivel mucho mas bajo. Por eso preguntaba si es qeu hacía un pre-buffer grande al inicio de la pista.

Lo de "Z64" o"V64" no cambia nada porque los cartuchos detectan el orden de los cuatro primeros bytes 80 37 12 40 y corrije el orden antes de cargar. Y en todo caso, yo ya hice el byteswap manualmente en un editor antes de copiarlo a la SD. Pero si no lo hubiera hecho, tampoco habría habido diferencia alguna... quizá un tiempo de transferencia ligerísimamente mas rápido desde la SD a la RAM del cartucho al no tener que hacer la reordenación.

Y si el programa accede a la ROM de forma normal, no veo por qué tendría que haber ningun problema ya sea en un 64drive, ED o repro.

@radorn
En otro foro se quejaban de que se colgaba en 64drive al cambiar de pista (yo solo tengo ED64 2.5), libdragon tiene una extraña lista de bugs

Sí, cuando cambias de canción inyecto silencio al buffer de audio, para que no tartamudee, luego la lib recorre la canción antes de subir el primer trozo a memoria, eso lo notarás en las canciones más largas, ya que tardan un poco más en iniciar, como la pista 31 "Final Toccata" (creo)

radorn escribió:@SuperPadLand Entonces, música mono a 22k con mucha compresión cargando los buses con el tráfico y los procesadores con la decodificación, y probablemente editada para acortar partes.
Aceptarías usar un 64DD (real o emulado por el cartucho) como almacenamiento extra para música?

O adaptaciones MIDI...

Técnicamente el 64DD no debería aceptarse a menos que seas japonés e incluso siéndolo no fue precisamente un addon muy popular a diferencia de la expansión de RAM. Prefiero el midi que a fin de cuentas todo apunta que es a lo que hubieran recurrido de tener que sacar el juego en 1997.

Edit: Que conste que esto no va reñido con sacar una versión con 64DD que seguramente sería una delicia, sólo hablo de como hubiera sido el juego realmente si sale en 1999.

MasterDan escribió:@SuperPadLand No me parece que un cartucho gran tamaño se salte las normas de los 90. En aquella época no se usaron por temas de costos, pero se podrían haber usado tranquilamente (otra cosa es que serían más caros que los de NEOGEO).

Igualmente, me parece que en si el tamaño de cartuchos de la 64 es el menor de sus problemas (Siendo los importantes el tamaño de la caché de texturas y la latencia de la RAM si he oído bien).

Tú mismo te contestas de porqué un cartucho de 256 megas se saltaría las normas de los 90, pero además se salta otras normas de espacio físico sino busca como funcionan realmente los cartuchos de 64 megas en N64 para saltarse el límite de 32 megas de aquellos años.

SuperPadLand escribió:Tú mismo te contestas de porqué un cartucho de 256 megas se saltaría las normas de los 90, pero además se salta otras normas de espacio físico sino busca como funcionan realmente los cartuchos de 64 megas en N64 para saltarse el límite de 32 megas de aquellos años.

Voy a suponer primero de que estamos hablando de MegaBytes y no Megabits, ya que si no recuerdo mal el Resident Evil 2 y el Conker's Bad Fur Day ocupaban 512mb y el kof98 de NeoGeo creo que llegaba al Gigabit.

Por otra banda según he leído el bus de direcciones de la N64 era de 32 bits (lo normal por aquella época), por lo que si mi memoria no me falla eso significa que es capaz de direccionar hasta 4 Gigabytes de memoria (RAM+ROM).

Esto me lleva a suponer que el problema es más por un tema de las EPROMS de la época que de la máquina en sí. No soy ingeniero electrónico, por lo que no se si hay algún problema simplemente añadiendo más chips al cartucho con algún chip de mapeo de direcciones si fuese necesario (Además del costo y el posible tamaño físico del cartucho, cosas que no cuento para este experimento teórico).

¿Voy bien encaminado?