Hilo de detalles y curiosidades de N64

@SuperPadLand puedes probar con el que recomiendan el video https://wermi.neocities.org/emuguide/gliden64_link/, o usar alguno de los mencionado en la wiki https://emulation.gametechwiki.com/index.php/Nintendo_64_emulators, yo usaba el mupen64plus, pero con el tiempo me empezó a dar problemas, ya que pedía muchos recursos, y mi notebook no daba para mas .

doblete escribió:@SuperPadLand puedes probar con el que recomiendan el video https://wermi.neocities.org/emuguide/gliden64_link/, o usar alguno de los mencionado en la wiki https://emulation.gametechwiki.com/index.php/Nintendo_64_emulators, yo usaba el mupen64plus, pero con el tiempo me empezó a dar problemas, ya que pedía muchos recursos, y mi notebook no daba para mas .

El mupen con el plugin gráfico glide anda en casi cualquier equipo. Mi notebook tendrá 13 años y funciona bien, incluso a 2x de resolución.

Otra cosa muy diferente es con los plugins que recomendaron unos posts más atrás (que son mucho más precisos visualmente).

Parece que son todas las versiones desde Project 64 1.7 hacia atrás, yo usaba la 1.7 cuando tenía todo el entorno configurado, que soporta bastante mejor plugins modernos, desde que instalé Win10 ya solo uso la consola (sin tocar el slot de SD del Everdrive que tengo roto), a ver que tal sale la de Analogue.

Tenía por ahí los instaladores de PJ64 2.0, 2.1 y 2.3 que me los tacho de adware/malware Windows, aún no sé porqué guardaba eso y no los ficheros en versión portable

Tiny3D , nueva libreria 3D con su propio Ucode para usar junto a LibDragon, basada en Open GL 1.1.,con un rendimiento entre F3D y F3DEX2/3 pero más cercano al segundo, aún tienen que hacer más pruebas y mejoras para ver hasta donde llega de rendimiento.
https://github.com/HailToDodongo/tiny3d/


Salud.

Estupenda noticia, un empujoncito más para que haya más homebrew en la scene de la N64.

Me encontré con esto y me pareció interesante:

https://n64squid.com/

Dejo una muy interesante entrevista a Julian Eggebrecht, cofundador de Factor 5 que versa principalmente sobre la etapa N64: la transición de las 2D a las 3D, el primer contacto con los prototipos de la consola, SW: Rogue Squadron, SW Battle for Naboo, Indiana Jones and the Infernal Machine, y alguna sorpresa más...

RiGaL escribió:Dejo una muy interesante entrevista a Julian Eggebrecht, cofundador de Factor 5 que versa principalmente sobre la etapa N64: la transición de las 2D a las 3D, el primer contacto con los prototipos de la consola, SW: Rogue Squadron, SW Battle for Naboo, Indiana Jones and the Infernal Machine, y alguna sorpresa más...

Está bastante bien, pero lo del sonido que dice a la hora de preferir el cartucho no sé bien a que se refiere, si es a tener música dinámica, eso está soportado por PS1 y es la principal razón de porque muchos juegos usaron MIDI en lugar música CD porque con lo primero podían hacer música adaptativa a lo que pasara en la pantalla, con la música CD tienes que reproducir el soundtrack linealmente. Según el tipo de juego se usaba uno u otro.

No recuerdo ya juegos que usasen para poner varios ejemplos, pero Soul Reaver sí lo hace, según la zona que visites cambian, cuando aparecen enemigos también, cuando los liquidas también. Según google también la usa Busby 3D, Syphon Filter, FFVII y Crash Team Racing. Aunque si la usa FFVII, seguramente también la use FFVIII y FFIX.

Supongo que se refiere a que con un cartucho es más fácil cargar nuevos samples de música al vuelo.

riffraff escribió:Supongo que se refiere a que con un cartucho es más fácil cargar nuevos samples de música al vuelo.

En MIDI es testimonial, toda la música de FFVII ocupa 784KB y PS1 tiene 512KB de memoria de sonido más el buffer del CD que creo que eran 32KB. Más los 2MB de memoria principal. Me parece raro que sea eso.

@SuperPadLand Si dices esta parte:

It’s a common sentiment that cartridges were one of the Nintendo 64’s weaknesses. We really didn‘t like the loading times and error rates of CDs in the early days. Sure, you had more memory and if you had linear music, it made that very easy. But in the case of the music, we always loved to create very interactive, changing and cross-fading music. That was not possible on the PlayStation, and the memory constraints of cartridges were easily overcome if the team was technologically proficient

Con la música no linear se refiere a interactiva, cambiando según el momendo de la acción o fundiendose de una a otra. Supongo que la parte que no es posible en PS1 es la de fundir, y puede que también los cambios rápidos aunque con música en formato XA se podía hacer cambios con ciertas limitaciones. Pero lo más importante es que se tenía que seguir leyendo de CD que necesitaba de tiempos de acceso largos para reproducir los archivos, y eso en 2x de velocidad sigue siendo un tiempo largo y dificulta mucho lo que querian hacer en Factor5, y eso si el CD estaba perfecto y sin rayones que dificultaran la lectura.

Así que sí, me parece que los tiros van por la velocidad de acceso y de lectura del cartucho, tremendamente superiores al del CD.

Recupero este quote de otro hilo:
hilo_hardware-de-n64-revolucionario-o-catastrofe_2486704

celgadis_84 escribió:Bump Mapping Demo

Blog explain it

Creía que me había guardado ese .mp4, porque la verdad es que en movimiento impresiona (bump mapping + ambient occlusion en tiempo real, recuerda mucho a lo que es el doom 3, ¡y en una nintendo 64!). No parece que en el artículo se proporcione, y google no encuentra nada.

Atención a este vídeo de Kaze Emanuar que asegura que fue un error que la N64 sea de 64bits:



Así por encima, el cálculo en 64bits supone algunas operaciones más que en 32bits en ciertas condiciones, y encima los compiladores podían ir saltando de modos de 32 a 64 bits cuando les daba la gana, provocando código extra y desoptimizando el código.
Ciertamente 32bits es precisión de sobras para un juego 3D de 1996, pero el marketing es el marketing y era muy difícil vender que la nueva consola era más potente con un chip equivalente al de PS1, por mucho que tuviese soporte de coma flotante que la de Sony no tenía en sus gráficos.

Aparte que Nintendo 64 mola más que Nintendo 32.

El chip gráfico usa comandos de 64bits, si el bus de la consola fuera de 64bit igual la cosa hubiera sido distinta, por lo menos con llamadas a bajo nivel.

Aún así, en la libdragon cambie variables sueltas por variables unificadas de 64bit para cada comando, dividiendo los bits altos/bajos antes de mandarlo al ringbuffer y hubo aumento de rendimiento, mínimo, pero no afecto negativamente en tests que todo lo que hacen es llamar a esas funciones para dibujar en pantalla, supongo que también importa un compilador del 2016.. a uno con 20 años menos.

Es algo que comenta en el vídeo, que el SM64 apenas usa ese tipo de variables en todo el código, salvo contadas ocasiones relacionadas con la libultra, la cual si las usa, para temas internos.

En un juego enteros de 64bit puede que no tenga demasiado sentido, yo usaría el tipo de variable que mejor encaje en su propósito, se va a guardar en el Controller pak? Variables de 8bit, todos esos juegos con medidor de vida que llegan hasta "250" como los Turok, están usando variables de 8bit y no dejan que lleguen a 255 (como hace los Resident Evil) por ser un detalle "feo", es el mejor tipo de variable cuando quieres garantizar que ocupe poco, para cosas como coordenadas obviamente no debe usarse.

@EMaDeLoC pero podía haberse inventado un blast processing, por ejemplo hacer todo de 32bits normal y que el bus fuera de 64 Creo que no fue solo por el marketing porque eso se maquilla rápido, vease que Sony hizo lo mismo con su PS1 frente a N64 siendo inferior. Creo que Nintendo realmente quiso hacer una máquina claramente superior en todo a la competencia y no salió como esperaba tanto por falta de experiencia real en el 3D como por el señoro puño de hierro pidiendo milagros a cuatro céntimos.

Conker64 escribió:El chip gráfico usa comandos de 64bits, si el bus de la consola fuera de 64bit igual la cosa hubiera sido distinta, por lo menos con llamadas a bajo nivel.

¿Como de distinta?.

Algún día serán legítimos los rediseños para la escena. Ver como hubiera rendido una n64 totalmente equilibrada...

@SuperPadLand Me lo creería... si no fuese porque el bus que une CPU y RCP es de 32bits, y que era la CPU de 64bits más barata de la época (o al menos de las más baratas).
Que es un buen procesador con buen rendimiento para su precio, pero buscaban más decir que la consola tenía una CPU de 64bits, que usar realmente un procesador de 64bits.

Tenéis idea si el SH4 de Dreamcast de 64 bits y el EE de PS2 de 128 bits, utiliza código de más de 32bits que no sean cosas internas de bajo nivel?

Salud.

Señor Ventura escribió:¿Como de distinta?.

Algún día serán legítimos los rediseños para la escena. Ver como hubiera rendido una n64 totalmente equilibrada...

Pues que empezarías a eliminar los distintos cuellos de botella de la consola, aunque puestos a invertir yo lo haría en mejorar la latencia o ancho de banda de la RAM, o una mejor distribución al estilo GC.

La forma normal de enviar los comandos al RDP es usando el RSP que está en el mismo chip, así que ese problema del bus existiría solo en modo RDP->RAM o cuando la CPU necesita enviar ciertas cosas a RAM, ciertos listados al RSP o directamente al RDP.

Otra cosa es que gracias al bus permitiera enviar o recibir más datos, sería una inversión para mejorar varios fps sobre cientos creo yo, tal como se comenta en el vídeo, la CPU de N64 tiene potencia de sobra en la mayoría de casos y suele quedarse sin hacer nada.

dirtymagic escribió:Tenéis idea si el SH4 de Dreamcast de 64 bits y el EE de PS2 de 128 bits, utiliza código de más de 32bits que no sean cosas internas de bajo nivel?

Salud.

Dice Sexy Motherfucker que

el SH-4 de Dreamcast es un micro de 32 bits y el de PS2 de 64 bits, ambos con buses de 64.

@SuperPadLand
Sí acabo de mirar y el SH4 es 32 bits, aunque juraría que en su época los datos que daba SEGA era de que era de 64 bits aunque a saber si se referían al bus, del EE sólo he visto que es de 128 bits, pero suponiendo que sea de 64, ¿los utiliza en código general?

Salud.

dirtymagic escribió:@SuperPadLand
Sí acabo de mirar y el SH4 es 32 bits, aunque juraría que en su época los datos que daba SEGA era de que era de 64 bits aunque a saber si se referían al bus, del EE sólo he visto que es de 128 bits, pero suponiendo que sea de 64, ¿los utiliza en código general?

Salud.

https://en.wikipedia.org/wiki/Emotion_Engine#CPU_core

operated on 128-bit wide groups of either 32-bit, 16-bit, or 8-bit integers in single instruction, multiple data (SIMD) fashion

CPU de 32 bits.

https://en.wikipedia.org/wiki/Emotion_E ... l_data_bus

handled by a 128-bit wide internal data bus

Bus interno de 128 bits.

Han ido saliendo nuevos prototipos como Riqa, que ha pasado un poco desapercibido:


Lo han filtrado los mismos desarrolladores, así que no ha problema en pasarse por archive.org y ver las distintas versiones, algunas parcheadas, no tiene perdida.

Lo he estado jugando un rato y es una mezcla rara de géneros, un cruce entre los movimientos mecánicos de Tomb Raider, con algo de Jet Force Gemini y Perfect Dark, en el vídeo se ve más fluido, en base a lo que comenta en la descripción quizás lo grabó en Mupen 64.

El juego en el estado del prototipo no es muy jugable, 2 disparos aguanta el personaje, no me ha parecido ver desplazamiento lateral, así que al plantarse en un sitio para apuntar somos objetivo fácil, con una IA de pocos recursos que tiende a plantarse para disparar en un mismo intervalo de tiempo entre tiros, los enemigos tienen un 99.9% de probabilidad de acierto, siempre disparan a la última posición.

Esquinas con caja de colisión cuadrada, así que no puedes esconderte detrás de paredes para disparar con ventaja, si sales de una sala y vuelves a entrar se restauran los enemigos, incluso los que están posicionados en la misma puerta por la que acabas de entrar.

Tras un rato se cuelga, en un fallo de excepción que deja funcionando la música, la cual está genial, con temas de rollo electrónico.

Se puede seleccionar nivel y tiene modo debug pero no he profundizado demasiado.

pues tenía muy buena pinta ese Riqa. Hubiese sido un añadido excelente para el catálogo.

@Misscelan está cacharreando con libdragon y ha porteado su WIP de PS1 y Satun: hilo_homebrew-noah-and-the-poohludies-wip_2422603#p1754907663

Los problemas para retomar Portal 64

ALCAMJI escribió:Los problemas para retomar Portal 64

Resumen: Valve no le da la licencia y a partir de ahí todo son excusas.
Quiero decir que vale, usar LibUltra puede ser un problema, pero hace un par de años salió 40 Winks para N64 con cartucho y todo y problemas 0. Y no será porque Valve no puede mandarle una cartita a NoE y pedirle que deje distribuir una ROM con LibUltra con alguna licencia barata o incluso gratis. Que no es una compañía pequeña con la que Nintendo no pueda hablar de temas serios.
Lo que pasa que Valve habrá hecho números, habrá visto que había más problemas que solventar que beneficios y le ha chapado el proyecto a James con la excusa del LibUltra, aunque también es verdad que es la parte que no depende de Valve y han decidido dedicarle 0$ a solventarlo.
Al menos, todo hay que decirlo, han estado hablando con James, en vez de mandarle la típica carta de cese y desista.

No sé hasta qué punto la mecánica de los portales es propiedad de Valve, para que James haga su propio juego rompecabezas de portales con una historia diferente y así al menos aprovechar el motor del juego, pero como prefiere hacer otro proyecto que no le dará problemas de licencias, copyright y demás historias, casi que mejor, aprovecha más el tiempo.

@EMaDeLoC no creo que la mecánica de los portales pertenezca a Valve en exclusiva porque sino Nintendo ya se habría encargado de que durante los 80 y 90 nadie pudiera hacer un plataformas 2D like Super Mario Bros. Yamauchi todavía se pone erecto en su tumba sólo de pensar en esa posibilidad.

@SuperPadLand No sé, no pondría la mano en el fuego. La mecánica de los portales se originó en un juego de un trabajo de final de carrera, Narbacular Drop, y los de Valve no dudaron en contratar al grupillo que desarrolló el juego.
Hay que tener en cuenta que los de Namco crearon el sistema de añadir un minijuego en las pantallas de carga del Ridge Racer, y los cabrones lo patentaron, por lo que nadie podía copiarles la idea sin su permiso. Así que varias generaciones se han comido pantallas de carga sin hacer nada porque los de Namco lo patentaron.
Por eso no me extrañaría que la mecánica de portales tuviese alguna protección legal de ese estilo. Si hasta el Bridge Constructor tiene una variante con portales que esta tematizada con Portal, cuando perfectamente podrían inventarse cualquier cosa y seguir usando esa mecánica.

Me imagino que James ya habrá tenido esa conversación con los de Valve y le habrán dicho que no, que la mecánica de portales les pertenece a ellos.

@EMaDeLoC pues he buscado superficialmente en internet por juegos parecidos a portal y aunque sí hay listados, ninguno usa portales, se limitan a recomendar juegos en primera persona de resolver puzzles, pero con otras mecánicas.

Me parece un tanto fuerte que se pueda patentar así una mecánica jugable porque limita bastante la evolución de los juegos si todas las compañías empezaran a hacer lo mismo. Pero bueno, cosas más raras se han visto.

Pero lo de las mecánicas patentadas tiene truco. Si tú usas una de ellas te meten un paquete, pero si añades alguna diferencia a esa idea entonces sí puedes usarla. No sé si recordáis juegos como Crazy Taxi, en donde había una flecha que te indicaba el camino a seguir, pues bien, en juegos posteriores esa idea evolucionó para convertirse en un mapa con una flecha, como en los GTA.

Yo diría que la primera vez que se vio un videojuego con portales fue el Prey de 1997 que nunca se lanzó, no sé si lo que no se puede es utilizar los portales como mecánica jugable, y no como recurso para pasar de un escenario a otro, que es lo que hacía Prey.

Salud.

EMaDeLoC escribió:Me imagino que James ya habrá tenido esa conversación con los de Valve y le habrán dicho que no, que la mecánica de portales les pertenece a ellos.

Pues que no le de permiso, ¡que lo produzca!.

Creo que esto puede llegar a interesar:


--
Es alucinante ver la lista de colaboradores que tiene ahora libdragon, cuando empecé a trastear allá por el 2016 la última actualización de la lib era de 2012.

Conker64 escribió:Creo que esto puede llegar a interesar:

--
Es alucinante ver la lista de colaboradores que tiene ahora libdragon, cuando empecé a trastear allá por el 2016 la última actualización de la lib era de 2012.

Al ver el título del vídeo pensaba que se trataba de descompilar el juego y volver a compilarlo pero con compiladores optimizados para que el código fuese más rápido, pero no.
Estaría bien probar si un código recompilado para N64 sin los problemas que Kaze expresó en un vídeo reciente podría correr mejor, aunque no es precisamente en la CPU donde reside el mayor cuello de botella de la consola y no se soluciona solo recompilando, hay que retocar bien el código.

De todas formas a efectos de preservación o para crear remasters de calidad, eso es muy interesante.

Conker64 escribió:Creo que esto puede llegar a interesar:

--
Es alucinante ver la lista de colaboradores que tiene ahora libdragon, cuando empecé a trastear allá por el 2016 la última actualización de la lib era de 2012.

Pronto tendremos la deseada demo de Daytona USA 64

@EMaDeLoC
Imagino que primero se obtiene el código original y luego se convierte a PC para ser compilado nativamente.

Si no es así sería fácil de implementar (viendo lo que hace) una opción de "como lo extraes", con los assets y demás, para ser recompilado después con el kit de desarrollo oficial.

Estaba pensando que el código extraído no tendría comentarios, y aunque es cierto, la herramienta puede identificar muchas rutinas de la libultra y ayudar un poco en ese tema cuando componga el código, como ponerle nombres un poco más "humanos" a las funciones o incluso comentar, aquí hay.. rutinas de vídeo, aquí de audio, ordenar/separar el código con un poco de sentido, etc..

Aún así todo eso de un click para un port nativo con mejoras y hasta panorámico, suena a fantasía

@Conker64 ¿recuerdas las demos de la mega textura y del ambient occlusion + bump mapping?.

¿Que tal todo junto? (no hablo de rendimiento, aunque me sorprende que la n64 no pueda servirse de chips de apoyo).

Señor Ventura escribió:@Conker64 ¿recuerdas las demos de la mega textura y del ambient occlusion + bump mapping?.

¿Que tal todo junto? (no hablo de rendimiento, aunque me sorprende que la n64 no pueda servirse de chips de apoyo).

Creo que no se puede usar ambos a la vez porque ambos usan el canal Alpha del CC para hacer el efecto, también los inabilita para usar niebla gradual junto alguno de esos 2 efectos.

Salud.

dirtymagic escribió:

Señor Ventura escribió:@Conker64 ¿recuerdas las demos de la mega textura y del ambient occlusion + bump mapping?.

¿Que tal todo junto? (no hablo de rendimiento, aunque me sorprende que la n64 no pueda servirse de chips de apoyo).

Creo que no se puede usar ambos a la vez porque ambos usan el canal Alpha del CC para hacer el efecto, también los inabilita para usar niebla gradual junto alguno de esos 2 efectos.

Salud.

Y lo del chip de apoyo no habíamos ya hablado algo de que no era posible o que no era posible para corregir los cuellos de botella del sistema? Me suena algo así en plan que la máquina va sobradísima de procesadores, los problemas son otros y no son solucionables con un chip de apoyo, salvo que hablemos de meter una rasp en el cartucho que ejecute el Crysis a 480p y lo streamee a 30fps que no sé si en esta consola es posible.

Hola1 dos preguntas,
el 64dd aparte del almacenamiento teniaa algún extra de hardware?(Más RAM, algún chip extra)

Es posible y facil overclockear la N64? Hasta cuántos MHz es la media? (Entiendo que se tendría q poner algún disipador) Ganas unos cuantos FPS en los juegos que más cuestan mover?

Saludos!

ziu escribió:Hola1 dos preguntas,
el 64dd aparte del almacenamiento teniaa algún extra de hardware?(Más RAM, algún chip extra)

Es posible y facil overclockear la N64? Hasta cuántos MHz es la media? (Entiendo que se tendría q poner algún disipador) Ganas unos cuantos FPS en los juegos que más cuestan mover?

Saludos!

El 64DD venía con Expansion Pak como buffer de datos y una biblioteca de instrumentos para la música.

El overclock en N64 a no ser que programes con ese overclock en mente, suele acelerar el juego en sí, vamos que modifica el timming del juego, por lo que va todo más acelerado-

Salud.

SuperPadLand escribió:Y lo del chip de apoyo no habíamos ya hablado algo de que no era posible o que no era posible para corregir los cuellos de botella del sistema? Me suena algo así en plan que la máquina va sobradísima de procesadores, los problemas son otros y no son solucionables con un chip de apoyo, salvo que hablemos de meter una rasp en el cartucho que ejecute el Crysis a 480p y lo streamee a 30fps que no sé si en esta consola es posible.

Yo llegué a la conclusión de que el cuello de botella principal esta en la RAM. No porque sea lenta, que es de las más veloces de la época, sino por ser única e ir saturada.
Solucionar eso es practicamente imposible.
Bueno, se podría solucionar ampliando el ancho de banda de la memoria de los 8 o 9 bits al doble, o mejor aún, dandole memoria dedicada al framebuffer para aliviar a la RAM unificada, aunque necesitaría que se pudiera manipular por la CPU. Pero para hacer cualquiera de estas cosas habría que modificar el controlador de memoria, y este va embebido en el RCP. Así que o a alguien se gasta la millonada en desarrollar un RCP v2.0, o es imposible.

ziu escribió:Es posible y facil overclockear la N64? Hasta cuántos MHz es la media? (Entiendo que se tendría q poner algún disipador) Ganas unos cuantos FPS en los juegos que más cuestan mover?

Como te dice el compi, los overclokeos estandar aceleran los juegos.
Hay overclokeos más especializados que actuan solo en el RCP, mejorando el framerate, pero en cuanto se toca mucho, la salida de vídeo se va fuera del estandar y ya no sale imagen por la consola, a menos que se use algún sistema especializado como un FPGA.


Este vídeo tiene 10 años y es lo mejor que se ha hecho de overclock en la consola, mejorando rendimiento sin acelerar el juego. Si en 10 años no se ha mejorado nada más, no esperes ninguna otra mejora.

Con una excepción: que se mejore el core de N64 del MisterFPGA.

@EMaDeLoC claro, pero eso a nivel de chip de apoyo no es viable y menos en la época. N64 no tiene pinta que fuera diseñada con eso en mente, se lanzó ya con unos procesadores que triplicaban a la competencia, no es como SNES. Y tampoco lo veo necesario, cuando juegas con N64 a fondo te das cuenta de que iba muy sobrada.

EMaDeLoC escribió:Yo llegué a la conclusión de que el cuello de botella principal esta en la RAM. No porque sea lenta, que es de las más veloces de la época, sino por ser única e ir saturada.
Solucionar eso es practicamente imposible.
Bueno, se podría solucionar ampliando el ancho de banda de la memoria de los 8 o 9 bits al doble, o mejor aún, dandole memoria dedicada al framebuffer para aliviar a la RAM unificada, aunque necesitaría que se pudiera manipular por la CPU. Pero para hacer cualquiera de estas cosas habría que modificar el controlador de memoria, y este va embebido en el RCP. Así que o a alguien se gasta la millonada en desarrollar un RCP v2.0, o es imposible.

Y el controlador de memoria está grabado en silicio, claro, no es un volcado desde la bios con valores editados por software...

Para una cosa que la naturaleza de los microcódigos podría haber ayudado a resolver... (si es que hubiesen registros para acceder a ese área de memoria a tocar cosas).

dirtymagic escribió:

ziu escribió:Hola1 dos preguntas,
el 64dd aparte del almacenamiento teniaa algún extra de hardware?(Más RAM, algún chip extra)

Es posible y facil overclockear la N64? Hasta cuántos MHz es la media? (Entiendo que se tendría q poner algún disipador) Ganas unos cuantos FPS en los juegos que más cuestan mover?

Saludos!

El 64DD venía con Expansion Pak como buffer de datos y una biblioteca de instrumentos para la música.

El overclock en N64 a no ser que programes con ese overclock en mente, suele acelerar el juego en sí, vamos que modifica el timming del juego, por lo que va todo más acelerado-

Salud.

Ok gracias, por lo que he leido tambien el 64DD tiene un copro que se dedica a gestionar la RAM, pero no creo que se pueda utilizar para mejorar la potencia..

A 32-bit coprocessor operates disks and transfers data to the console, where the RCP and CPU process data

lastima que no enfocaron el puerto de expansion del 64DD para hacer la consola mas potente¿hubiera sido posible por este bus?
Seria posible aprobechar para homebrew o demos el 64DD o solo se limita a tener mas almacenamiento?

Saludos!

ziu escribió:Ok gracias, por lo que he leido tambien el 64DD tiene un copro que se dedica a gestionar la RAM, pero no creo que se pueda utilizar para mejorar la potencia..

A 32-bit coprocessor operates disks and transfers data to the console, where the RCP and CPU process data

lastima que no enfocaron el puerto de expansion del 64DD para hacer la consola mas potente¿hubiera sido posible por este bus?
Seria posible aprobechar para homebrew o demos el 64DD o solo se limita a tener mas almacenamiento?

Ese coprocesador no gestiona la RAM. Tal y como dice la cita, se encarga de controlar la disquetera, leer los datos del diskette y pasarselos a la consola. No hace nada más.

El puerto de expansión se conecta directamente al puerto de cartuchos, por no decir que son lo mismo pero con el pinout cambiado. Así que todo lo que se pueda hacer con un cartucho y más, se puede hacer con el puerto de expansión. Y hay cartuchos con modems y capturadoras de vídeo. Y dentro de la scene, una persona creó su propio cartucho con wifi y llegó a programar un sistema de streming con el que pasaba los comandos del mando de la consola a un PC y este le enviaba la señal de vídeo al cartucho que luego la consola era capaz de emitirlo por la TV. No sé qué fue de ese vídeo porque ya no lo encuentro, quizá era falso, pero era teóricamente posible.

@ziu @EMaDeLoC de hecho los flashcards ya cargan juegos de 64DD sin usar el puerto expansión. Lo único que se tiene que tener la expansión de RAM para igualarla con la de 64DD y no recuerdo si se modificaron las ROM para hacerlas compatible, pero vamos que funcionan en modo cartucho sin más.

Al final el DD sólo ofrecía algo que el cartucho no podía económicamente: más espacio para datos aunque a menor velocidad (creo), que no deja de ser el motivo de su creación al no querer CD. Ahora molaría que calzase un Pentium III, etc. Pero en la época N64 con todos sus recortes era muy superior en potencia a su competencia y si Saturn no fuese semejante fracaso forzando la Dreamcast en el 98, la N64 hubiese sido la consola más potente durante 4-5 años. Sólo el PC y los arcades ofrecerían cosas mejores, pero eso pasa siempre.

@SuperPadLand

Si , fue la más potente, pero una lastima que se limitaron el 90% de juegos a 3d de mundo abierto o tipo goldeneye, me hubiera gustado ver mucho 2d de neogeo, Capcom y más arcades,shooters.. luego no sé si tenía un catálogo mas reducido debido a q las compañías se tenian q costear el precio del cartucho y Nintendo aun era inflexible con los juegos de violencia/sangrientos..(creo q con resident evil 2 empezaron a ser menos talibanes con estos generos)

Un lector de CD simple por la expansión con el expansión pak y hubiéramos visto juegazos increíbles(si tenían miedo a la piratería de CD siempre se hubiera podido acompañar el CD con un cartucho con el mínimo de almacenamiento y 4 texturas/audios en el)

Saludos!