La explicación de como funciona el 64drive es sencillamente perfecta, pero no me has entendido.
Lo que defines es una interfaz, porque la N64 no tiene capacidad por sí misma de conectarse a una SD. El sistema de direcciones del bus no es compatible de forma directa con el sistema de acceso serie de la SD. Por eso por el lado de la consola requiere de un software, la ROM del menú, que aprovechando un rango relativamente pequeño del bus de direcciones, los 16MB, se hagan lecturas o escrituras concretas que el hardware del cartucho, la FPGA, interprete como comandos para realizar las lecturas. Eso es una interfaz, efectivamente, y se usa una interfaz cuando no se puede directamente.
radorn escribió:Esa interfaz no se cierra porque haya una ROM en memoria. No se cierra en el 64drive y dudo que la situación sea muy diferente con los otros cartuchos.
De nuevo, no me has entendido. Si cargas la ROM de un juego original en el 64drive, su código nunca, jamás, fue concebido para acceder a una SD con la interfaz del 64drive. Ni siquiera para usar 256MB de espacio en ROM del 64drive aunque desde el principio la consola y los kits de desarrollo originales lo permitiesen, pero no hubiese capacidad de fabricar esa cantidad de ROM.
Obviamente si se crea homebrew específico que se apoye en hardware específico, se puede hacer de todo. Si hay cartuchos originales capturadores de vídeo y modems. Pero no tienen "acceso directo", usan una interfaz de alguna forma.
radorn escribió:No te líes con rangos de memoria, TLBs y todo eso. No tienen nada que ver con esto.
Sí tiene que ver. Si no se crea una interfaz y se quiere que la consola tenga un acceso
directo a la SD, solo dispone de los 256MB de direcciones de memoria del cartucho. Usar más direcciones crea conflictos con el TLB y los rangos de memoria reservados. Aparte de algo de hardware para traducir esas direcciones de memoria en sectores de la SD. Y aún así el espacio al que puede acceder, si no hubiese conflictos, no podría superar los 4GB.
Espero haber aclarado los matices concretos entre acceder directamente y el usar una interfaz.
Ahora sobre tu especulación:
radorn escribió:Ahora un poco de especulación. El sistema que acabo de describir es un acceso mediante bloques a la tarjeta, y solo ofrece un pequeño buffer en esa interfaz, por lo que los datos tendrían que copiarse a la RDRAM mediante el PI para poder usarse efectivamente. Una vez en RDRAM, la N64 también podría copiarlos a espacio ROM de vuelta dado que es RW, pero esto no es muy eficiente por la relativa lentitud del PI.
No obstante, hay otra posibilidad, aunque no puedo confirmar que sea posible dado que no se lo suficiente sobre el DMA interno entre SD RAM dentro del cartucho. Se que cuando el menú carga una ROM desde la SD, no usa la inferfaz de los 16MiB porque eso implicaría usar la consola para copiar de SD a RDRAM y luego de RDRAM a ROM-RAM ambas veces a través del PI... y eso sería lentísimo y no permitiría cargar ROMs grandes en segundos como de hecho hace. Así que el menú lee la SD a través de la interfaz, y luego indica al FPGA qué bloques copiar de la SD a RAM en modo DMA sin pasar por la N64. Quizá este acceso DMA se pueda usar también para copiar de SD a RAM en cualquier momento. Si fuera así, podría escribirse un programa que use un segmento del rango PI como cache intermedia donde cargar cosas extra desde la SD sin intermediación de la consola.
¿Juegos multidisco de PS1 con cientos de megas de video que serían dificiles aún con los 256MiB del PI (o los 240 que permite el 64drive? ¿Fondos prerenderizados para alta resolución? Con esto serían posibles.
Lo poco que he podido ver sobre el funcionamiento del 64drive es
el código fuente opensource de un menu para 64drive y SC64, así que no sé si es posible mandarle al 64drive que cargue un archivo concreto en una región concreta de la SRAM para que el código del juego acceda a esos nuevos datos por el PI como si fuese un cartucho normal. Aunque creo que sí sería posible.
Pero sin necesidad de ceñirse al funcionamiento concreto del 64drive, sí sería posible. Así que me venga a la cabeza, se podría dividir los 256MB de acceso directo en bloques de 8 o 16MB, reservar uno o dos para contener el código y assets de uso frecuente o común, y el resto ir cambiando los datos según fuese necesario. La división en bloques debería ser física en el cartucho y con la FPGA haciendo de intermediario entre la consola y la SRAM, con la idea de que el código pudiera acceder a uno de los bloques y mandarle al cartucho mediante interfaz que actualice los datos de otro bloque. Al ser bloques distintos e independientes del PI, la escritura de uno no provocaría retrasos o latencias en el otro.
Esto sería una posible implementación, pero puede haber otras muchas.
Como dices el resultado práctico sería poder almacenar cientos de megas o incluso gigas, pudiendo acceder a videos largos u horas de música en calidad CD.
Sobre los fondos en alta resolución, tenemos el ejemplo práctico del Resident Evil 2 en el que en apenas 30 y pico megas de espacio (el resto estaba reservado para vídeo) había fondos, modelos, texturas, sonidos, música, etc. Por lo que 256MB de vídeo debería ser más que suficiente para centenares de fondos prerenderizados en alta resolución.
Habría que valorar el coste de fabricación del cartucho. Solo con 256MB de capacidad parece ser más que de sobra para añadir mucho contenido. La creación de un cartucho específico que soportase más, o la fabricación de un clon del 64drive, no parece que esté debidamente justificado, especialmente por el coste extra. De hecho, el coste y complejidad de añadir una interfaz para acceder a una SD sería excesivo cuando sería más barato meter una memoria de 512MB, 1GB o más al cartucho y mediante mapper o sistema de bancos cambiar en bloques de 256MB.
![[bye]](/images/smilies/nuevos2/adio.gif "adios")
![[+risas]](/images/smilies/nuevos/risa_ani3.gif "más risas")
Y cuál se necesita para restaurar un save en cartucho original.![[beer]](/images/smilies/nuevos2/brindando.gif "brindis")
