Hilo de detalles y curiosidades de N64

19 may 2018 23:14

Enlace permanente

Jolin que pedazo de hilo, llevo solo las dos primeras páginas y estoy enganchadisimo, lo dejo para seguir mañana porque ya me estoy quedando dormido miiiiiiiil gracias por toda la info.

20 may 2018 01:12

Enlace permanente

Yo siempre las verdades, aunque me cosan a hilos, la verdad prevalecerá xD

* 20 may 2018 01:31

Enlace permanente

@AES a ver, si bien está que no te gusten Ocarina of Time ni SM 64 y digas que te producen bostezos.

Pero tacharlos de "basura", sobre todo en la época cuando eran el pináculo de sus respectivos géneros y no tenían igual en otro sistema... xD. A mí no me gusta La Mona Lisa, y si mañana alguien quema el cuadro original y de paso prende fuego al museo me la va a sudar bastante, pero nunca diré que es una mierda simplemente porque personalmente no conecto con esa obra de arte atemporal.

Que conste que yo no soy de la pandillita 64 del subforo (docobo, Oynstein, ese del avatar del pitbull) que vivieron esa generación felizmente aislados del BOOM PlayStation y de la sociedad si me apuras, pero hay cosas que me duele leerlas hasta a mí, como que The Legend of Zelda: Ocarina of Time es una basura de juego.

20 may 2018 01:42

Enlace permanente

@EMaDeLoC todo lo que dice el chaval son hipótesis y teorías para terminar con un juego que recicla contenidos de los tres CD (es lo único que le compro de todo lo que teoriza) y comprime, recorta, tendría que rehacer partes para programarlas pensando en N64, etc. Por no decir que habría que ver hasta que punto en 1994-1996 cuando se está desarrollando el juego era conocido todo lo que comenta el usuario. La mayoría no sabía programar un juego normal para N64 optimizando lo mínimo como para esperar un full-optimización de FFVII a los 6 meses de salir la consola.

Podríamos incluso teorizar como hace él y seguro que conseguimos que FFVII para PSX entre en un sólo CD a base de datos compartidos, reducir calidad a los fondos, comprimir, rehacer modelos, etc. Pero al final la realidad es que el juego en enero de 1997 necesitaba tres CD y N64 ofrecía cartuchos de 8-16mb.

Y sobre lo del FFVII en 94mb, no termino de creerlo, pero aceptemos que es verdad; no veo en que me he equivocado. El resultado final sería un juego recortado, con fondos con peor calidad, datos comprimidos, etc y aun con todo esto seguiría sin entrar en un cartucho de 16mb quedando a años luz. Más abajo el chaval habla de usar un método de compresión que permite reducirlo a 66mb, sigue sin entrar en un cartucho de 16mb; pero haría posible que el juego pudiese venderse en cartucho+disco 64DD.

O sea para conseguir lo mismo que en PSX costo 9000 pesetas haría falta que en Square hubiese genios que conociesen a fondo la máquina, la aprovechasen mejor de lo que hizo RARE en 5 años, que el usuario se comprase un addon y lanzar el juego en dos formatos físicos distintos que seguramente juntos superen las 12000 pesetas (addon aparte claro) ¿Factible?

20 may 2018 07:28

Enlace permanente

Venir a un hilo de N64 a decir que Mario 64 y OoT son basura debería suponer expulsión por troll y, si de verdad piensa que tiene razón, por estúpido e ignorante:

Para gran parte de la industria y de los amantes de los videojuegos siguen siendo considerados, en sus respectivos géneros, como mejores juegos de la historia. Pueden haber sido superados en potencia visual, calidad de sonido, etc. pero no en jugabilidad... creadores de juegos AAA actuales siguen aceptando que se han inspirado en ellos...

* 20 may 2018 12:05

Enlace permanente

Yo no me haría ilusiones pensando en que los juegos multidisco de PS1 serían posibles en N64. Sobre todo RPG's. El mismo Final Fantasy VII que se está comentando que comparte datos entre los CD's y que comprimiendo a lo bruto podría caber en 64 MB se está olvidando que es el chip de sonido de la consola de SONY el que genera la música y que en N64 habría que guardar los samples, con todo el espacio que eso conlleva.

Resident Evil 2 fue una proeza, pero no cabía literalmente un dato más en el cartucho, y comprimieron los vídeos y los fondos al límite hasta el punto en que si lo comprimían un poco más se veían que daba asco. Además, como bien señala Calculinho, llegó varios años después. Los cartuchos limitaron enormemente la consola para tener experiencias "cinematográficas" al nivel de la competencia. Sólo al final de la vida de N64 con los cartuchos de 64MB y las técnicas de compresión de Factor 5 se podría haber conseguido, como así tenermos RE2, Conker's Bad Fur Day y los cancelados Dinosaur Planet, Resident Evil Zero y Eternal Darkness que ya vieron la luz en GameCube.

Un juego como Gran Turismo sería perfectamente posible y sólo saldría malparado en el número de coches (que es mucho, ya que era uno de sus puntos fuertes) y dependería mucho del tamaño del cartucho. El número de circuitos no sería ningún problema. 32 MB darían para un juego muy completo. World Driver Championship son sólo 16 MB. ¿Hay algún juego de carreras de mayor capacidad?

Juegos de lucha en 3D estoy seguro de que se podría haber hecho mucho mejor de lo que vimos, pero ninguno de los estudios punteros estaba interesado o centrado en Nintendo 64. Me hubiera encantado ver un Tekken 3 aunque perdiésemos las cinemáticas. :'(

Sería interesante ver cuánto habría que sacrificar para ver Metal Gear Solid en Nintendo 64, aunque fuese en el año 2000/2001 en cartucho de 64 MB a 15000 ptas. ¿Cuántas horas y minutos de diálogos doblados tiene el juego? Seguramente evitando doblar las conversaciones del códec sería suficiente, pero estaría bien comparar con Conker y RE2 para hacernos una idea.

Del mismo modo, Super Mario 64 y Ocarina of Time son inviables técnicamente en PS1 por el tamaño de los escenarios. Añadiría que cualquier mazmorra de un Zelda tendría cargas en la consola gris, pero ahí está Soul Reaver para demostrar que con ingenio sí se podría. Lo que ocurre es que si todos los juegoshiciesen streaming del CD todo el tiempo las consolas durarían un suspiro.

Offtopic: Fuera coñas, una de las cosas por las que la Mona Lisa es tan importante es por lo mismo por lo que destaca la Nintendo 64: fue la primera representación de la realidad en incorporar niebla.

* 20 may 2018 12:36

Enlace permanente

@Sogun de hecho en la época se rumoreó una posible versión de Tekken 3 para N64, pero se quedó en eso, rumores.

En un entorno tan controlable como el de un Tekken de momento el Z-Buffer sobra en mi opinión, con lo que ya ganamos ancho de banda/fillrate. Corrección perspectiva también a tomar vientos, total salvo para los replays poco uso notorio tendrá, así que algo de capacidad de proceso ganamos por acá. Algunos filtros se supone que salen "gratis", pero en cualquier caso yo el Bilineal lo mandaba también AL CARAJO en entornos de 240p, y ni hablar de Mip Mappings TLFMMI, unos pocos pixels no hacen daño, al igual que el AA, que saldrá gratis, pero ocupa espacio en memoria, pasando olímpicamente de él.

¿Es mucho pedir que en esas circunstancias, a 320x240, podamos aspirar a algo cómo esto?:



System 12, con fondos 3D, y un último plano 2D en ultradetalle. Que no es un monstruo como la Model 2.

Pero es que yo soy pobre hasta para pedir, y me conformo con unos fondos de postal 2D como los del Tekken 3 de PlayStation, que a 368x480i se ve glorioso:


(Edit: lleva filtro ahora que me fijo, debe ser emulador, o una Ps2 con el bilineal activado).

¿Es mucho pedir que la N64 A PELO supere esto un poco por encima? Yo aspiraría a más polycount a 60 fps, y algo más de detalle en las texturas si emplea expansion-pak, nada más, comprobar que en su misma liga la N64 saca diferencia a la PS.

20 may 2018 13:45

Enlace permanente

@Sexy MotherFucker y no te extrañe que en esas condiciones puedas meter 250k polígonos por personaje, mas los fondos.

20 may 2018 15:12

Enlace permanente

Y sobre lo del FFVII en 94mb, no termino de creerlo, pero aceptemos que es verdad; no veo en que me he equivocado. El resultado final sería un juego recortado, con fondos con peor calidad, datos comprimidos, etc y aun con todo esto seguiría sin entrar en un cartucho de 16mb quedando a años luz. Más abajo el chaval habla de usar un método de compresión que permite reducirlo a 66mb, sigue sin entrar en un cartucho de 16mb; pero haría posible que el juego pudiese venderse en cartucho+disco 64DD.

Vamos a ver...
¿Te crees tú que Sakaguchi estaba pensando en 1800MB cuando planeaba el FFVII para SNES? ¿O cuando estaban diseñando la N64 y hacían una demo técnica del FF en 3D, a ver que tal quedaba?
Teniendo en cuenta que los datos del juego ocupan 1/3 de CD y las fechas en las que salió el juego y la consola, me huelo que Sony apretó a Square soft un año antes para inflar la duración de los videos y mostrar la debilidad de la N64 y sus limitados cartuchos (ojo, no lo critico porque es buena estrategia empresarial y complementa el juego).
De todas formas te has anclado en el 97 y los 16MB y lo del FFVII es tan solo un ejercicio teórico de ahora con los conocimientos de 20 años que se tiene de la consola y la posibilidad de usar 64MB sin problemas. Nadie ha dicho en ningún momento que se podía lanzar FFVII con el estreno de la N64, con FMV y de todo troceado en 40 cartuchos, eso lo has sacado tú por tu cuenta sin venir a cuento...
Como he dicho antes, calma tu hervor "sonyer" que por hipotetizar en un posible port de GT o FF en la N64, nadie esta diciendo que la PSX es una puta mierda o la N64 una maravilla. Es más, yo he elogiado el buen diseño de la PSX y añado ahora lo capada que está la N64 porque el RCP esta mal diseñado (en mi opinión de informático, como un zurullo).
Pero un buen programador no coge y tira a la basura una consola por sus tiempos de carga o sus 4KB de cache. Coge lo que tiene y lo exprime al máximo para solucionar esas limitaciones. Así llega Factor 5 y pone 3 cosas sobre la mesa: RE2 para la N64, y sus dos cojones.
Así que tranqui, que por teorizar en 2018 no vamos a cambiar la línea temporal del 96...

Resident Evil 2 fue una proeza, pero no cabía literalmente un dato más en el cartucho, y comprimieron los vídeos y los fondos al límite hasta el punto en que si lo comprimían un poco más se veían que daba asco. Además, como bien señala Calculinho, llegó varios años después.

Como digo, eso de los cartuchos lo saca Calculinho para el 97. Yo siempre hablo de exprimir la consola con los recursos de ahora.

World Driver Championship son sólo 16 MB. ¿Hay algún juego de carreras de mayor capacidad?

Star Wars Racer, Mickey's speedway, Ridge Racer y Road Rash son de 32MB (no cuento F-Zero para 64DD porque es hacer trampa ). No se como van de contenido pero creo que apostaran más en hacer los circuitos distintos de texturas.

Juegos de lucha en 3D estoy seguro de que se podría haber hecho mucho mejor de lo que vimos,

A mi el MK 4 me parece decente. ¿Qué tal un Tekken con ese motor?
Pero la verdad es que los juegos de lucha nunca me han llamado y no sé que tal son ambos graficamente.

Sería interesante ver cuánto habría que sacrificar para ver Metal Gear Solid en Nintendo 64, aunque fuese en el año 2000/2001 en cartucho de 64 MB a 15000 ptas. ¿Cuántas horas y minutos de diálogos doblados tiene el juego?

¿A que pica la curiosidad?
Hay un video por YouTube del MGS que dura 6 horas. Entre la cantidad de texturas de escenarios y el audio, este si que lo veo jodido para meter en 64MB. Pero bueno, si caben 80 minutos de video del RE más fondos, pues puede que si.

Del mismo modo, Super Mario 64 y Ocarina of Time son inviables técnicamente en PS1 por el tamaño de los escenarios.

Yo no lo veo tan difícil. Usando Gouraud en vez de texturizado y con el LOD adecuado, podría añadirse cosas de lejos. Los efectos de luz de OOT si que lo veo chungo...

Offtopic: Fuera coñas, una de las cosas por las que la Mona Lisa es tan importante es por lo mismo por lo que destaca la Nintendo 64: fue la primera representación de la realidad en incorporar niebla.

Por esa regla de tres: PSX y cubismo.

¿Es mucho pedir que la N64 A PELO supere esto un poco por encima? Yo aspiraría a más polycount a 60 fps, y algo más de detalle en las texturas si emplea expansion-pak, nada más, comprobar que en su misma liga la N64 saca diferencia a la PS.

Pues a mi que la N64 tenga juegos con una complejidad poligonal parecida a PSX pero con muchos filtros aplicados y al precio de bajar a 20-30FPS ya me parece suficiente. Pero si, tener datos reales con los que comparar estaría bien...
Para ver arder al mundo, visto lo visto...

20 may 2018 15:54

Enlace permanente

@EMaDeLoC yo lo que digo es que los juegos antes se desarrollaban teniendo en mente el espacio del formato físico porque no quedaba otra si querías venderlo en un sistema bien instalado. Una vez hay una consola bien instalada que ofrece un formato físico casi infinito para el momento cualquier desarrollador se quitará ese problema de en medio y se centrará en hacer el juego. Esto es lo que ha pasado con PSX y N64 y no es que me haya anclado en 1997 es que yo he dicho que en su época el formato físico fue una de las mayores barreras para portear juegos entre ambos sistemas, puse de ejemplo FFVII y sacaste eso de que entra en 94 megas lo cual y pese a usar toda la ventaja de la técnica de 20 años sigue sin poder romper esa barrera de vender FFVII en 1997 en N64 porque en ese año se usaban roms de 16mb.

Por lo demás, me parece muy bien el punto de vista que planteas de ver que se puede hacer con la técnica actual en esta consola, yo mismo he dicho aquí ya que ahora con los everdrive estaría genial intentar superar esa barrera de los 64 megas por rom. Y yo también veo interesante eso de ver como sería GT en N64, pero mi comentario no iba con que fuera imposible en 2018 sino que GT tal cual lo conocimos en 1997 no era un juego posible en N64. Es como el chip MSU1 de Snes, me parece una maravilla y demuestra que tecnológicamente no era necesario un addon para tener juegos con cinemáticas y sonido CD, pero lo han desarrollado 25 años tarde usando todo el avance tecnológico posterior y por tanto imposible en su momento.

* 20 may 2018 16:49

Enlace permanente

No sé si lo han dicho ya, pero el problema de la baja capacidad de los cartuchos de N64 no era tanto que habría que usar como 20 cartuchos para juegos como FF7, sino que no se pueden hacer juegos de varios cartuchos. Lo que se hace con los juegos en CD de sacar el disco, luego meter el siguiente y seguir jugando es irrealizable con una tecnología de cartuchos.

Se podría hacer con juegos que guarden el progreso en el Controller Pak, se apaga la consola, se cambian los cartuchos, luego se vuelve a encender y el nuevo cartucho cargaría los datos guardados en el Controller Pak, pero los cambios en caliente son imposibles. Además que añadir un segundo cartucho al juego lo habría encarecido un montón, mientras que los CDs son baratos.

Luego, en juegos multidisco como el citado FF7 había que repetir partes del código en todos los discos, las mismas ciudades y escenarios del principio del juego podías visitarlas en el CD3, el mismo sistema de combate, los sprites, etc. Lo que más ocupa del juego son las FMV, si hubieran hecho las escenas con el motor del juego estoy seguro de que habría cabido en un solo CD, aunque no creo que se hubiera podido meter en un cartucho de N64.

20 may 2018 17:11

Enlace permanente

@EMaDeLoC

Pues a mi que la N64 tenga juegos con una complejidad poligonal parecida a PSX pero con muchos filtros aplicados y al precio de bajar a 20-30FPS ya me parece suficiente

De hecho según ha comentado ya BMBx64 ese es el objetivo con las nuevas librerías; aumentar algo el polycount, pero con todos los efectos activados, y manteniendo una tasa de fotogramas decente. Yo lo único que propongo es que ya que estamos se exploren todos los frentes: 2D, la N64 en "bare-bones" a ver cuanto rinde, entornos de más detalle con tasas de fps aceptables, EXPANSION PAK MADNESS!, etc.

Vamos, lo dicho arriba se resumen en: un Cadillac & Dinosaurs, un Tekken 3 que compita con el System 12, un Conquer's Bad Fur Day todavía más recargado en detalle a 25-30 fps, y un FPS que haga ruborizar a Perfect Dark.

Es la única forma en que Nintendo 64 va a poder callar bocas para siempre.

20 may 2018 17:25

Enlace permanente

Esto es lo que ha pasado con PSX y N64 y no es que me haya anclado en 1997 es que yo he dicho que en su época el formato físico fue una de las mayores barreras para portear juegos entre ambos sistemas, puse de ejemplo FFVII y sacaste eso de que entra en 94 megas lo cual y pese a usar toda la ventaja de la técnica de 20 años sigue sin poder romper esa barrera de vender FFVII en 1997 en N64 porque en ese año se usaban roms de 16mb.

En eso coincidimos. Es decir, claro que no se puede diseñar un juego de 64MB en el 97 cuando esas ROMs no existían o serian prohibitivas de precio.
Aclarado ese punto, creo que podemos dejarlo aparcado del debate.

Por lo demás, me parece muy bien el punto de vista que planteas de ver que se puede hacer con la técnica actual en esta consola, yo mismo he dicho aquí ya que ahora con los everdrive estaría genial intentar superar esa barrera de los 64 megas por rom.

Uf... Me temo que 64MB es el máximo porque el RCP tiene un bus de direcciones de 16bits y ese es el máximo espacio de ROM al que puede acceder.
Aunque...
Si se aprovechara algún otro acceso al cartucho como el guardado de partidas para crear una combinación única, dividir el ROM en dos bloques (por ejemplo 16+16MB) y cada vez que se accediera al segundo bloque con la combinación única cambiaramos en el cartucho a un bloque nuevo distinto, en teoría se podría hacer un cartucho con tamaño ilimitado. O de al menos 512MB que ya es algo respetable.
Pero esto es una mezcla de electrónica y programación a bajo nivel, que vete a saber si es posible. De como accede la consola al cartucho no tengo ni idea.
Pero de ser posible, un cartucho de 96MB seria sexy...

Vamos, lo dicho arriba se resumen en: un Cadillac & Dinosaurs, un Tekken 3 que compita con el System 12, un Conquer's Bad Fur Day todavía más recargado en detalle a 25-30 fps, y un FPS que haga ruborizar a Perfect Dark.

Es la única forma en que Nintendo 64 va a poder callar bocas para siempre.

El C&D lo veo más que seguro, y en apenas 4MB de ROM.
A lo demás, igual se te ha ido un poco la olla...

* 20 may 2018 17:36

Enlace permanente

@EMaDeLoC creo BMBx64 ya me explicó por aquí que el limite que puede gestionar la consola es de 64mb sí. Pero vamos yo hablo de lo de siempre, trucos y artimañas para engañar a la consola (como lo que tu comentas), por ejemplo y hablando en cartucho físico (costes aparte claro) no sería posible fabricar un cartucho con dos roms de 64mb y algo intermedio que gestionase que datos transmitir a la consola o simplemente que la consola empiece cargando la rom 1 y llegados a un punto por ejemplo te salte una pantalla de salvar partida (a lo FF al cambiar disco) y tras eso si decides continuar que cargue directamente la rom 2?

Cosas así vamos Por otro lado no sé como lo hace, pero los everdrive permiten cargar juegos 64DD no sería viable con esa función cargar 64+64? Por ejemplo si el flascard "emulase" a 64DD e hiciese creer a la consola que está enchufado?


@Sexy MotherFucker para hacer callar bocas basta con pulir el Perfect Dark para que vaya a 20-25fps. Aunque creo que fue en este hilo que se teorizaba sobre un posible port-demo del motor de Half-Life.

* 20 may 2018 17:40

Enlace permanente

@EMaDeLoC no lo tomes como algo literal; un equivalente a Tekken 3 en demo para ver el rendimiento, un equivalente a Conker pero con las nuevas librerías, etc.

20 may 2018 18:21

Enlace permanente

Por otro lado no sé como lo hace, pero los everdrive permiten cargar juegos 64DD no sería viable con esa función cargar 64+64? Por ejemplo si el flascard "emulase" a 64DD e hiciese creer a la consola que está enchufado?

Para que funcionara en la consola original hay que ceñirse a lo que puede hacer el hardware. La cuestión es que no se si se puede usar 64MB de DD y 64MB de cartucho simultáneamente. Ambos usan el mismo bus, así que debe haber un switch que cambie de uno a otro, pero igual de esta manera solo conseguimos un 32+32.
El RE2 (joder, como trillamos este juego) y el Conker usan dos chips de 32MB en el cartucho, así que un controlador interno esta cambiando de un chip a otro. Si hubiese algo que nos permitiera controlar este intercambio, se podría acceder a tantos 32MB adicionales como se pudiera. Por ejemplo, con un bit más tendriamos 32+32+32=96MB y con dos bits 32+32+32+32+32=160MB.
Pero eso depende del bus del cartucho. Según leo, hay 4 pins de de CIC e interfaz serie, 3 de señales de control y 2 que no se usan o no se sabe. Quizá si se pueden controlar estos pins mediante software, podríamos hacer esos cambios de chip de forma transparente para la consola.
Pero eso en la parte de un cartucho físico. Para el everdrive64 Krikzz tendría que currarse un parche para que cargue 32MB adicionales en la SDRAM y tendríamos una bonita pantalla de carga aunque con las SD de ahora sería solo de 2-3 segundos.

EMaDeLoC no lo tomes como algo literal; un equivalente a Tekken 3 en demo para ver el rendimiento, un equivalente a Conker pero con las nuevas librerías, etc.

No, si yo lo decía porque Tekken 3 es una bestia como el Daytona USA y el Conker esta muy trabajado de código. Tal vez se pueda arañar algo pero no mucho.
Es una pena que el modelo de negocio de crear un engine gráfico bueno y venderlo entre desarrolladores no estuviese implementado aún por esa época. Habríamos visto más cosas interesantes.

* 20 may 2018 19:18

Enlace permanente

No conozco todos los detalles, pero creo que puedo decir con bastante seguridad que la N64 puede soportar bastante mas memoria en los cartuchos que solo 64MB.
Para empezar, el el mapa de memoria de la consola es de 32bit. Creo que si que es verdad que el bus tiene un ancho de 16bit, o sea, 16 lineas, pero eso no quiere decir que solo soporte direcciones de 16bit. Si solo soportase direccionamiento de 16 bit no soportaria 64MB, si no 64KB (2^16) como los microordenadores de los 80. Segun tengo entendido el bus de cartucho usa intercalamiento (interleaving), usando las mismas lineas para direcciones y datos, en vez de lineas separadas (a causa de lo cual no usa chips ROM standard).
Ademas, la ultima version del 64drive HW2, lleva 256MB de RAM dedicada al espacio para emular las ROMs, totalmente accesible de forma normal a la CPU de la N64. http://64drive.retroactive.be/features.php.
En la pagina 10 del documento "Hardware Specification" de la seccion de soporte, se explica lo siguiente

SDRAM SIZE
The total numer in bytes of SDRAM on the device.
HW1, Rev A 67108864 bytes (64Mbyte).
HW2, Rev B 268435456 bytes (256Mbyte)
NOTE: Only 240MB is mapped into cartridge space due to addressing limitations of the N64 PI bus.

Imagino que los 16MB restantes, irán destinados, supongo que con mucho sobrante, a ser almacenamiento temporal para la emulacion de los chips de guardado, cosas internas del 64drive.

Así que, por lo visto, la cifra magica es 240MB, no 64.

Y para que sirve tanto "cartridge space"? Pues para emular el 64dd con alguna revision futura del hardware, con sus disquitos, su bios... para desarrollo homebrew si algun dia despega... cosas....

* 20 may 2018 19:19

Enlace permanente

La n64 tenía entre muchos otros, 3 grandes problemas y fueron devastadores;

Super Mario64
Goldeneye
Zelda oot

Juegos que hacen que la competencia palidezca totalmente y siga generando lo que genera, vender mucho y quedarte sin LO MEJOR

Y no se pudieron superar.

* 20 may 2018 19:22

Enlace permanente

@EMaDeLoC @erbarbas

Y a todo esto, una pregunta para BMBx64: ¿Cuál es el fillrate de cada consola? No encuentro datos concretos en ninguna parte y sospecho que no son tan diferentes como creemos.

El real? Depende de muchas cosas, en éste hilo puse fillrates que se consiguen en 2D con libdragon, pero están muy por debajo del fillrate teórico de la consola y de libn64 (que ahora se compila con GCC 8 y es todavía más rápida, la librería es de Marathon, el autor de CEN64 )

@BMBx64 Hace muchos años, a raiz de unas dudas tecnicas sobre las frecuencias de video de la N64, me metí a investigar sobre las diferentes frecuencias de reloj presentes en el sistema.

Creo que en las primeras versiones de la consola parece ser que habia 2 generadores de reloj, cada uno con un cristal, pero en erevisiones posteriores usaron un unico generador de reloj, diferente al anterior, al que se conectaban los dos cristales.

Inicialmente, muchas fuentes, incluido marshallh, decian que de un mismo cristal de diferente frecuencia segun region/formato y un multiplicador 17X se obtenian, aproximados, los 250MHz de la RAMBUS, y de ahi, el RCP dividia entre /4 para obtener sus 62.5 nominales, que tambien pasaba a ser la velocidad del bus entre el RCP y la CPU, que con su multiplicador 1.5x de fabrica pasaba a los conocidos 93.75MHz.
Por otro lado, con un segundo multiplicador producian tanto los ~50MHz del bus de video como la frecuencia del la portadora de color de video.
Pero esta teoria, por muy elegante que sea, ahora parece ser que no era correcta: Ignora el segundo cristal presente en la placa y no concuerda con muchas de las fichas tecnicas, como esquemas de circuitos de la consola, las especificaciones del chip multiplicador, y algunos otros.

Ahora dicen, y las fichas tecnicas parecen respaldarlo, que la velocidad de la RAMBUS y el cristal del que se deriva, son iguales misma en todas las consolas independientemente del formato, y que la velocidad del RCP y la CPU y todo lo que esta sincronizado con ellas no se deriva de la RAM, si no del bus de video. Y que la explicacion que se solia dar para fenomenos producidos por usar ROMs de diferente region, como la desincronizacion de audio en las escenas del Turok3 o la velocidad cambiante de los cronometros de DK64 no es por culpa de estar sincronizados con la RAM si no que es la propia CPU la que va a velocidad diferente. siendo la consola PAL mas rapida.

¿Tu te sabes bien este tema? porque a mi ya me empieza a mosquear xD

En cuestiones de vídeo puedo preguntar a Marshall que es el más entendido (mod HDMI).

Pero sí, la consola PAL (o mi modelo concreto, que es de los primeros franceses) tiene un problema cuando ejecuta en NTSC, en mis tests que grabo directamente el contador de fps marca 61 fps y no es un fallo de precisión, tengo un molesto tearing en pantalla.



Recuerdo que en una tele distinta no tenía tearing con NTSC, pero tampoco analice otros datos como los fps en su momento.

20 may 2018 20:48

Enlace permanente

Una N64 con 240mb de tamaño máximo para sus juegos sería una gozada Junto con las herramientas de comprensión abarcaría prácticamente todo lo importante third de su generación y lo que no, tampoco exigiría unos sacrificios tan bestias a nivel recortes. Que pena que no fuese lo estandar en su época

Por cierto existe algún análisis teorizando de cuanto podría reducirse otros juegos de la época? Me ha entrado curiosidad tras ese posible FFVII en 66 megas saber cuanto podrían ocupar otros como MGS, FFVIII, FFIX, X-Files, D, RE3, etc

* 20 may 2018 21:19

Enlace permanente

@EMaDeLoC no lo tomes como algo literal; un equivalente a Tekken 3 en demo para ver el rendimiento, un equivalente a Conker pero con las nuevas librerías, etc.

Se refiere a que sería ultra jodido de hacer.

20 may 2018 21:28

Enlace permanente

La n64 tenía entre muchos otros, 3 grandes problemas y fueron devastadores;

Super Mario64
Goldeneye
Zelda oot

Juegos que hacen que la competencia palidezca totalmente y siga generando lo que genera, vender mucho y quedarte sin LO MEJOR

Y no se pudieron superar.

Crash y Spyro superaron a Mario.

20 may 2018 21:38

1 valoración positiva

Enlace permanente

La n64 tenía entre muchos otros, 3 grandes problemas y fueron devastadores;

Super Mario64
Goldeneye
Zelda oot

Juegos que hacen que la competencia palidezca totalmente y siga generando lo que genera, vender mucho y quedarte sin LO MEJOR

Y no se pudieron superar.

Crash y Spyro superaron a Mario.

en que cuando y como ?

20 may 2018 21:39

Enlace permanente

He estado haciendo algunos calculos para intentar solucionar mis dudas sobre video a mi manera, claro que no tengo ningun aparato con el que medir mi acierto o error

En la N64 la parte de video funciona asi:
Del RCP sale un bus de 7 bits que comunica el VI (Video Interface) dentro del RCP con el DAC de video.
A traves de el son enviados de forma secuencias 4 bytes: R G B y un byte de control.
Por tanto la profundidad de color maxima de la N64 son 21bit RGB, 7bit por componente, incluso si el software renderiza a 24bit, el ultimo bit se pierde. Pero normalmente renderiza a 16 con dithering, asi que con 21bit sobran.
El byte de control, entre otras cosas, le señalan al DAC que debe generar pulsos de sincronizacion.
Por tanto, la temporizacion de video analogico de la consola está medido en pixels.
A traves de la documentacion de los componentes de la consola se puede derivar la velocidad exacta de este bus, y por tanto, del numero de pixels que salen por el. Esta velocidad es fija puesto que viene derivada por la frecuencia de color del formato de video de cada region. Lo que hace la consola para poder especificar un modo de video por software, es establecer cuandos pixels dura una linea y cuantas lineas dura un refresco de pantalla.
Probablemente la interfaz de video no la programe cada desarrolladora si no que vengan incluidos en la libultra (la libreria oficial de desarrollo), con modos predefinidos por NIntendo ya ajustados para cada region. La cuestion es que yo no se cuales son los parametros, asi que se me ha dado por hacer numeros y ver valores plausibles, intentando aproximar las velocidades oficiales de los formatos de video analogicos usando los parametros posibles en N64.

Está inacabado, pero muchas cosas ya las he calculado.
Una vez obtenido el pixel clock del sistema, lo divido para obtener una aproximacion de la longitud de linea en pixels, que necesariamente me dará decimales. Asi que, cojo ese numero, le quito los decimales, y pruebo algunos enteros proximos.
Por ejemplo, dividiendo el pixelclock de la consola PAL entre el refresco horizontal oficial de PAL (15625Hz) obtengo 794.50448 pixeles por linea, asi que redondeo a 794 y de paso pruebo tambien 795, pero como 795 es impar y podría haber razones para no usarlo, pruebo tambien 796.
Luego, para el numero de lineas por cuadro, para 288p cojo la especificacion oficial, que son 625 lineas y lo divido entre 2, lo que da 312.5. Como dejar la "media linea" provocaria una imagen entrelazada, hay que redondear a numero entero. Como no se si redondean al alta o a la baja, pruebo 312 y 313. Para entrelazado dejo la 625, obviamente.

-------------------PAL N64--------------------

PAL carrier = 283.75 x 15625 = 4433593.75 -> +25 = 4433618.75
PAL color cycles per line = 283.75 or 283.7516

N64 PAL crystal      = 17734475.00 Hz
       |->  1/4 (0.25x) =  4433618.75 Hz (PAL color)
       |-> 14/5 (2.80x) = 49656530.00 Hz (video bus)
   
pixel clock = videobus / 4 (1 clock per RGB byte + 1 clock for signaling byte)
49656530 / 4 = 12414132.5 pixels per second

---50Hz native---

line lenght = pixel clock / horizontal sync
PAL  12414132.5 / 15625 = 794.50448 pixels

794 pix lines = 15634.927581863979848866498740554 Hsync
                             +9.927581863979848866498740554 Hz vs standard PAL
line duration =  63.959362444375392320003028806080 microsec
                         283.57142857142857142857142857143 chroma cycles
312 line 288p = 50.111947377769166182264419040238 Vsync
313 line 288p = 49.951845309469584181682104602409 Vsync
625 line 576i = 50.031768261964735516372795969773 Vsync
           \ 25.015884130982367758186397984887 fps

795 pix lines = 15615.261006289308176100628930818 Hsync   
               -9.738993710691823899371069182 Hz vs STD
line duration =  64.039915797579895333000513729008 microsec
            283.92857142857142857142857142857 chroma cycles
312 line 288p = 50.048913481696500564425092726980 Vsync
313 line 288p = 49.889012799646352000321498181527 Vsync
625 line 576i = 49.968835220125786163522012578616 Vsync
           \ 24.984417610062893081761006289308 fps

          
796 pix lines = 15595.643844221105527638190954774 Hsync
              -29.356155778894472361809045226 Hz vs STD
line duration =  64.120469150784398345997998651939 microsec
            284.28571428571428571428571428571 chroma cycles
312 line 288p = 49.986037962247133101404458188378 Vsync
313 line 288p = 49.826338160450816382230642028032 Vsync
625 line 576i = 49.906060301507537688442211055276 Vsync
           \ 24.953030150753768844221105527638 fps

-------------------NTSC N64----------------------

NTSC chroma carrier = 315000000/88 = 3579545.4545454545454545454545455
NTSC 227.5 chroma cycles per line

N64 NTSC crystal    = 14318181.8181818181818181818181818 Hz
   |->   1/4 (0.25x) =   3579545.4545454545454545454545455 Hz   (NTSC color)
   |-> 17/5 (3.40x) = 48681818.1818181818181818181818182 Hz   (video bus)

pixel clock = ((315000000/88)*(17/5)) = 12170454.545454545454545454545455

---60Hz native---

nominal line lenght = pixel clock / horizontal sync
NTSC   ((315000000/88)*(17/5))/(15750/1.001)   = 773.5
SysM   ((315000000/88)*(17/5))/(15750)      = 772.72727272727272727272727272727

testing 772 773 774

( ( (315000000/88) * (17/5) ) / 772 )
772 pix lines = 15764.837494112105511069241639190
              +30.571759846371245334975904924091 Hz vs STD
line duration = 63.432306255835667600373482726423
262 line 240p = 60.171135473710326378126876485457
263 line 240p = 59.942347886357815631441983418973
525 line 480i = 60.056523787093735280263777673105
           \ 30.028261893546867640131888836552

(((315000000/88)*(17/5))/773)
773 pix lines = 15744.443137716100199929436669411

line duration = 63.432306255835667600373482726423
262 line 240p = 60.093294418763741221104720112255
263 line 240p = 59.864802805004183269693675549090
525 line 480i = 59.978831000823238856874044454898
           \ 29.989415500411619428437022227449

(((315000000/88)*(17/5))/774)
774 pix lines = 15724.101479915433403805496828753

line duration = 63.596638655462184873949579831931
262 line 240p = 60.015654503494020625211819957071
263 line 240p = 59.787458098537769596218619120732
525 line 480i = 59.901338971106412966878083157153
           \ 29.950669485553206483439041578576

-----------------CROSS REGION----------------------

---60Hz from NTSC used on PAL N64---

772 pix lines = 16080.482512953367875647668393782 Hsync
262 line 240p = 61.375887454020488074991100739627 Vsync
263 line 240p = 61.142519060659193443527256250123 Vsync
525 line 480i =  61.258981001727115716753022452504 Vsync


---60Hz modes custom made for PAL N64---

System-M  12414132.5 / 15750         = 788.19888888888888888888888888889
NTSC        12414132.5 / (15750 / 1.001)       = 788.98708777777777777777777777778
trying 788 789 790

788 pix lines = 15753.975253807106598984771573604 Hsync
                           +19.709519541372333250505839338327 Hz vs STD
line duration =  63.476042325148374242018119268503 microsec
262 line 240p = 60.129676541248498469407525090092 Vsync
263 line 240p = 59.901046592422458551272895717125 Vsync
525 line 480i = 60.015143824027072758037225042301 Vsync
           \ 30.007571912013536379018612521150 fps

789 pix lines = 15734.008238276299112801013941698 Hsync
                              -0.25749598943515293325179256738192 Hz vs STD
line duration =  63.555555555555555555555555555554 microsec
262 line 240p = 60.053466558306485163362648632435 Vsync
263 line 240p = 59.825126381278703850954425633833 Vsync
525 line 480i = 59.939079002957329953527672158850 Vsync
           \ 29.969539501478664976763836079425 fps

790 pix lines = 15714.091772151898734177215189873 Hsync
                            -20.173962113835531557050544392317 Hz vs STD
line duration =  63.637149031557380268013089114364 microsec
262 line 240p = 59.977449512030147840371050343028 Hsync
263 line 240p = 59.749398373201135871396255474804 Hsync
525 line 480i = 59.863206751054852320675105485230 Hsync
           \ 29.931603375527426160337552742615 fps




20 may 2018 21:45

Enlace permanente

Lanzo una pregunta al aire

si en los 90 hubieran existisdo "cartuchos SD " con pongamos 800 Megas de capacidad de verdad pensais que aun asi habria juegos de psx imposibles de hacer correr en una n64 ?

* 20 may 2018 21:46

Enlace permanente

La n64 tenía entre muchos otros, 3 grandes problemas y fueron devastadores;

Super Mario64
Goldeneye
Zelda oot

Juegos que hacen que la competencia palidezca totalmente y siga generando lo que genera, vender mucho y quedarte sin LO MEJOR

Y no se pudieron superar.

Crash y Spyro superaron a Mario.

Y superman64 a metal gear solid. (tú empezaste )

20 may 2018 22:01

Enlace permanente

Crash y Spyro superaron a Mario.

En una realidad alternativa, es posible xD
En la nuestra, Super Mario 64, B-K, B-T y DK64 son los mejores plataformas de su gen.

20 may 2018 22:35

Enlace permanente

No obstante Crash Bandicoot 3 Warped es mejor que otros plataformas tanto de N64 como de PlayStation, entre ellos Rayman 2. No soy fan de la saga, pero ese juego está muy por encima de la media, un serio candidato al mejor plataformas en la máquina de Sony, aunque habría que ver los Spyro qué tal, no los conozco más allá de las demos, y de jugar borracho en casas de colegas a una copia pirata.

Pero sí, Super Mario 64 es el pináculo del género en aquella generación.

21 may 2018 01:04

Enlace permanente

Nadie duda de la calidad de los Crash o Spyro (aunque a mi este ultimo nunca me gusto ) pero de ai a decir que superaron a mario pues ...

21 may 2018 02:18

Enlace permanente

Yo a Super Mario 64 le tengo como a Espinete en Barrio Sesamo, y yo cuando salió el juego ya era adolescente, por eso ni me fijé en ello

Me perdi eso si, verle hacer el pino en la copa del arbol, apoteósico, yo entonces estaba jugando al In The Hunt o Panzer Dragoon Zwei, por recordar algo de la época.

Como iba a saltar tras Resident Evil, Sega Rally, Tekken 2, a hacer el pino y bucear!!

* 21 may 2018 05:01

Enlace permanente

Yo a Super Mario 64 le tengo como a Espinete en Barrio Sesamo, y yo cuando salió el juego ya era adolescente, por eso ni me fijé en ello

Me perdi eso si, verle hacer el pino en la copa del arbol, apoteósico, yo entonces estaba jugando al In The Hunt o Panzer Dragoon Zwei, por recordar algo de la época.

Como iba a saltar tras Resident Evil, Sega Rally, Tekken 2, a hacer el pino y bucear!!

Oh sielos! Apartaos todos, que ha llegado Don Maduro Machoman! WARNING +18 Niños a la cama!
Si por entonces eras adolescente, ahora tendrás mas de treinta, o puede que, incluso, estés cerca de los cuarenta (lo de "adolescente" es muy ambiguo).
Siguiendo tu retorcida logica sobre madurez, no se que haces en un foro de videojuegos a estas alturas, colega.
Vete a, no se... fumar puros, esnifar coca, violar putas, pelearte en bares, o lo que sea que corresponda a tu nivel de "madurez" en tu mente tan... "madura", y deja de tocar los cojones por aqui.

21 may 2018 11:43

Enlace permanente

Señores, dejen el tema de madurez y demás.

Si a alguien no le importa el tema, o no le gusta la N64, no hace falta que entre en el hilo de "detalles y curiosidades de N64" y tampoco hace falta seguirle la corriente.

A ver si podemos mantener esto en orden sin piques innecesarios.

21 may 2018 12:02

Enlace permanente

Que yo sepa el cartucho con más capacidad fue el que hicieron para el RE2 que era de 64MB, ¿lo usaron para algún otro juego?

21 may 2018 12:21

Enlace permanente

Que yo sepa el cartucho con más capacidad fue el que hicieron para el RE2 que era de 64MB, ¿lo usaron para algún otro juego?

Conker y pokémon stadium 2. Creo que sólo esos 3

21 may 2018 12:32

Enlace permanente

Para empezar, el el mapa de memoria de la consola es de 32bit. Creo que si que es verdad que el bus tiene un ancho de 16bit, o sea, 16 lineas, pero eso no quiere decir que solo soporte direcciones de 16bit. Si solo soportase direccionamiento de 16 bit no soportaria 64MB, si no 64KB (2^16) como los microordenadores de los 80.

Cierto, vaya fallo más tonto
Bueno, me he estado ojeando el N64 Development Kit Manual para aclarar cosas y me he quedado más confuso aún.
La dirección de memoria es de 32bits y se usa memoria virtual que se traduce a memoria física. La virtual está dividida en varias partes tal que así:

Beginning  Ending      Name    Behavior
0x00000000 0x7fffffff  KUSEG   TLB mapped
0x80000000 0x9fffffff  KSEG0   Direct mapped, cached
0xa0000000 0xbfffffff  KSEG1   Direct mapped, uncached
0xc0000000 0xdfffffff  KSSEG   TLB mapped
0xe0000000 0xffffffff  KSEG3   TLB mapped


Las TBL son direccionamientos que no nos cuentan como espacio. Nos queda KSEG0 y KSEG1, y de KSEG0 dice literalemten que "sea el espacio de direcciones más popular, si no el único, utilizado".
Haciendo cuentas nos sale que KSEG0 tiene un tamaño máximo de 512MB
Pero según leo, a la hora leer los cartuchos las direcciones empezarían por 0x90000000, lo que nos dejaría con 256MB. Las direcciones entre 0x80000000 y 0x8fffffff quizá correspondan al 64DD.
Y eso nos lleva a la información que añades:

la ultima version del 64drive HW2, lleva 256MB de RAM dedicada al espacio para emular las ROMs, totalmente accesible de forma normal a la CPU de la N64. http://64drive.retroactive.be/features.php.
En la pagina 10 del documento "Hardware Specification" de la seccion de soporte, se explica lo siguiente

SDRAM SIZE
The total numer in bytes of SDRAM on the device.
HW1, Rev A 67108864 bytes (64Mbyte).
HW2, Rev B 268435456 bytes (256Mbyte)
NOTE: Only 240MB is mapped into cartridge space due to addressing limitations of the N64 PI bus.

Imagino que los 16MB restantes, irán destinados, supongo que con mucho sobrante, a ser almacenamiento temporal para la emulacion de los chips de guardado, cosas internas del 64drive.

Creo que esos 16MB corresponden a direcciones reservadas de la N64 (comandos para el cartucho, el boot, CIC, cosas así) y no del 64drive.
Así que si, podría ser 240MB el tamaño máximo del cartucho.

PERO
Teniendo en cuenta la agresividad del marketing que dio Nintendo para vender la consola en el 96, el tamaño máximo de cartucho que vendían era de 32MB. Si podía ser de 240MB, ¿Por qué no abofetearon a Sony con 240MB de acceso instantáneo? ¿Por qué dejaron escapar a Sakaguchi diciéndole que su FF se quedaba en 16MB? ¿Por qué no vendieron al menos los 64MB, si el problema era que tenían dudas?
O bien teniendo en cuenta el precio de las ROMs de entonces y el largo plazo que quedaba hasta los 32MB los de Nintendo fueron muy prudentes, o a tenor de como funciona el 64DD (32MB por cara) y como están hechos RE2 y Conker (dos chips de 32MB), el tamaño máximo del cartucho sea de 32MB + 32MB adicionales usando un direccionamiento extra al estilo de la segunda cara del 64DD.
Ojo, eso no quita que haya direcciones libres para teóricamente acceder a 240MB. Pero en lo practico, quizá el hardware de la N64 te diga
Hasta que algún gurú de la N64 con una 64drive de 256MB haga pruebas, nos vamos a quedar con las ganas de saberlo.

Que yo sepa el cartucho con más capacidad fue el que hicieron para el RE2 que era de 64MB, ¿lo usaron para algún otro juego?

Ese, Conker's Bad Fur Day, Pokemon Stadium 2 y Paper Mario europeo (por ser multi-idoma).
En 64DD la mayoría son de 64MB, pero en realidad buena parte de ese espacio no lo usan.

* 21 may 2018 14:01

Enlace permanente

@hyrulen @iamdevil
Como dice EMaDeLoC, tambien está Paper Mario. Las versiones Japonesa y Americana son de 40MB (320Mbit), pero la Europea, sin duda a causa de los idiomas extra, acabó usando un cartucho de 64MB (512Mbit). Claro que les sobró un monton de espacio, cosa que demuestra la version de Virtual Console, con 50MB con decimales, resultante de recortar todos los ceros del final xD

@EMaDeLoC
Cuando hablaba de los 16MB "sobrantes" no me referia al mapa de memoria de la consola, si no a que en el 64drive nuevo hay 256MB reales de RAM, de los cuales 240 están mapeados al bus PI (cartucho) de la consola para ser accedidos como ROM, y los otros 16 los usará internamente para emular los chips de guardado (que el mas grande son 128KB asi que sobra un monton xD). Y digo esto porque se que el 64dive HW1, que poseo, teniendo 64MB de SDRAM, para emular los "saves" mas pequeños (eeprom de 4 y 16 kbit) usa la memoria interna del FPGA, pero para las SRAM de 32KB y 96KB, y la FlashRAM de 128KB, usa la "cola" de la SDRAM, porque no hay tanta memoria en el FPGA. Afortunadamente, todos los juegos de 64MB graban en EEPROM excepto Pokemon Stadium 2, que creo que usa SRAM. En la cola de la ROM no hay 32KB libres, pero si hay una zona suficientemente grande libre en medio de la ROM, y el menu incluye un modo especial especifico para ese juego por el cual, la SRAM en vez de mapearse al final de la SDRAM, se mapea a ese hueco vacio de la ROM, donde no molesta.
En el nuevo 64drive, con 16MB de SDRAM sobrantes, no hacen falta hackeos de ningun tipo y hasta se puede pasar las EEPROM a SDRAM y no ocupar la RAM del FPGA. Ademas, el HW2 tiene caracteristicas como un modulo wifi (aun no implementado del todo en el firmware) y otras cosas que ahora no recuerdo, asi que no me sorprenderia que usase toda esa ram "sobrante" para cosas internas del cartucho.

Respecto a tus dudas sobre la accesibilidad de los 240MB, yo no puedo confirmartelo, pero trato con marshallh con cierta frecuencia y dudo mucho que haya puesto esa caracteristica ahi sin haber probado que se puede acceder a ellos sin problema.

Lo de que si Nintendo pudo haber anunciado los 64MB desde el principio y asi no perder tantas third parties?
Pues aparte de que, como ya comentas, el precio hubiese sido prohibitivo en aquel momento, tampoco creo que hubiese cambiado nada, ni hubiese frenado a Square de irse con SONY. No solo los costes de produccion eran mas baratos, si no que las condiciones de la licencia tambien eran mas ventajosas y sin un control tan ferreo como el de Yamauchi.
Incluso si Nintendo se hubiese vuelto mansa como un corderito y les hubiese puesto ojitos tiernos, relajase el control y todo lo necesario para que no se le fueran las desarrolladoras, 64MB siguen siendo una decima parte de un CD de entonces.
Pongamos incluso que en 1996 hubiesen podido sacar cartuchos de 64MB y a precios del 2000... aun con esas la mayoria de las desarrolladoras hubiesen dado el salto a SONY, quiza no tantas, pero tampoco habría tanta diferencia.
Tengo que reconocer que la PS1 ofrecia muchisimas ventajas sobre Nintendo. Mas espacio, mas barato, licencia menos restrictiva, control menos ferreo. SONY se lo montó muy bien en aquel momento, hay que reconocerselo, y dio un ordago de mil pares.

Respecto al 64DD, TODOs los discos son de 64MB, aunque no estoy seguro de si la cifra es exacta como en un chip ROM o aproximada. Simplemente que pueden venir formateados, segun recuerdo haber leido, de 7 formas diferentes, que varian desde "Todo el disco es escribible" a "todo el disco es de solo lectura", y otros 5 modos que reparten el disco en distintos porcentajes de zonas RW y RO.
Lo que mencionas de las 2 caras... es cierto que el disco se puede escribir por ambas caras, pero no es como disquettes antiguos a los que dabas la vuelta porque el lector solo tenia un cabezal para una de las caras. El 64DD es como los disquetes posteriores, o discos ZIP, con una sola orientacion y ya el lector tiene 2 cabezales, cada uno para un lado del disco, y se leen ambas caras al mismo tiempo, repartiendo los datos entre ellas.

21 may 2018 15:04

Enlace permanente

Cuando hablaba de los 16MB "sobrantes" no me referia al mapa de memoria de la consola, si no a que en el 64drive nuevo hay 256MB reales de RAM, de los cuales 240 están mapeados al bus PI (cartucho) de la consola para ser accedidos como ROM, y los otros 16 los usará internamente para emular los chips de guardado (que el mas grande son 128KB asi que sobra un monton xD).

No, precisamente las parte que has citado de las especificaciones del 64drive ya dice que es una limitación de direccionamiento de la N64. Que luego se aproveche el sobrante para guardar partidas es otra cosa.

Respecto a tus dudas sobre la accesibilidad de los 240MB, yo no puedo confirmartelo, pero trato con marshallh con cierta frecuencia y dudo mucho que haya puesto esa caracteristica ahi sin haber probado que se puede acceder a ellos sin problema.

Pues si tienes ocasión preguntale porque él sabrá mejor que nadie los límite de espacio direccionado de la consola.
Me extraña mucho que ese tipo de información no sea más fácil de encontrar después de 20 años.

Tengo que reconocer que la PS1 ofrecia muchisimas ventajas sobre Nintendo. Mas espacio, mas barato, licencia menos restrictiva, control menos ferreo. SONY se lo montó muy bien en aquel momento, hay que reconocerselo, y dio un ordago de mil pares.

Totalmente de acuerdo. Nintendo debería haber hecho tan buen marketing a los desarrolladores como a los jugadores.

Lo que mencionas de las 2 caras... es cierto que el disco se puede escribir por ambas caras, pero no es como disquettes antiguos a los que dabas la vuelta porque el lector solo tenia un cabezal para una de las caras.

Yo no he dicho que hubiera que darles la vuelta... Yo me refería a que la consola accede a una cara y luego a la otra, y para hacer el cambio se hace un direccionamiento extra. Lo digo porque tengo entendido que en juegos comerciales una cara era de solo lectura y la otra podía ser solo lectura, escritura, o mixta. Creo los Mario Artist y F-Zero hacían eso para guardar los datos.

21 may 2018 17:26

Enlace permanente

Oyidme otra cosa, el 64DD salía de fábrica pensado para discos de 64 megas; pero intuyo que no habrían diseñado el cacharro a modo de paliativo de los CD de la época para que ese fuese lo máximo que pudiese cargar en un disco no? Esto lo digo porque hablábamos antes de como hacer un "cartucho" de más de 64 megas; pero igual usando el formato 64DD ya se podría superar ese límite sin más no? Evidentemente habría que engañar a la consola con el flashcard para que crea que está usando el 64DD cosa que no sé si es posible sin enchufarle algo en el puerto de expansión.

21 may 2018 17:35

Enlace permanente

Pues eso depende del cabezal del 64DD, si es capaz de leer datos de más densidad que un disco de 64MB normal. Pero dudo mucho que pudiera tener más capacidad.
De todas formas si creo que pudiera ser posible superar ese límite, bien de forma nativa por la N64 por las direcciones de memoria, bien creando y programando un cartucho apropósito y controlándolo a través del interfaz serie.

21 may 2018 17:41

Enlace permanente

@EMaDeLoC ok, pero el caso no es si era capaz físicamente sino de que si por ejemplo hubiesen diseñado el 64DD a turboreacción para leer discos de lo que le diese la gana ¿Habría algún que otro impedimento a nivel hardware interno que limitase el tamaño? De todas formas supongo que la idea del 64DD sería poder hacer swap-disc así que en caso de necesitarse irían 64+64+64... hasta donde hiciera falta, tengo entendido que era un formato físico barato así que no era un problema.

21 may 2018 17:58

Enlace permanente

Buf, pues eso depende de como este hecho el 64DD... Si en el momento en que se saca un disco se interrumpe la ejecución del programa, pues olvídate del swap disc...
Parace que el 64DD tiene un ejecutable en caso de no haber disco, para realizar configuraciones. Tiene pinta de que salte en cuanto el disco se saque. En ese caso, swap disc imposible.

21 may 2018 20:58

Enlace permanente

a ver que de pequeño veia Fraggel Rock y no me pasa nada aquí estoy, pero que en esa época a los juegos de n64, casi todos, eran para un publico mas infantil, hoy es dia que tengo aun una n64, y fzero y algunos mas, pero no soy ningun enfermo de defender ninguna mierda, la n64 era es y será una basura con 4 juegos que me gustan, pero hasta ahí, mal montada, malos graficos en conjunto global, malos juegos, poco catálogo, ausencia de thirds, bueno que voy a contar que no sepamos todos en porque ese numero de ventas o porque yo trabajando en distribución de videojuegos teniamos echada la X a la n64 y posteriormente gamecube, no vendia ni el churro recien salido caliente de la feria, nadie pedía ni nos compraba

Y no pasa nada, se reconoce y punto, que no te van a pagar o cagarte palomas por decir que es mala o buena, aun creo que muchos pensais que estais en el recreo de EGB y cuando se dice algo que no gusta ahí estais pa atacar xD

N64 esta muyyyyy lejos de Saturn y a otra liga de PSX

21 may 2018 21:24

Enlace permanente

N64 está lejos de saturn y playstation, ¿en gráficos?.

21 may 2018 22:12

1 valoración positiva

Enlace permanente

@AES
Parece que eres algún año mayor que yo así que debes superar holgadamente los 30 años, lo que hace más lamentable tu actitud. Lo voy a decir muy claro: tus mensajes en este hilo no son opiniones ni buscan iniciar un debate: son pura basura que lo único para lo que sirven es para ensuciar uno de los mejores hilos no ya de este subforo, si no de cualquier foro de videojuegos en cualquier idioma.

Mira que se han abierto hilos los últimos meses en los que se ha puesto a parir la Nintendo 64 y en los que tus textos habrían tenido cabida, pero has venido a soltar tus estupideces en un hilo que es casi casi educativo. Un hilo que BMBx64 alimenta constantemente con numerosos aportes repletos de datos y que muchos usuarios, aún no teniendo simpatía hacia la consola y sus juegos o que no tenían nada que aportar, se han tomado la molestia de felicitar al autor y animarle a seguir publicando cosas.

Luego vas riéndote de la gente hablando de madurez mientras las insultas sin ningún pudor, soltando puyitas para seguir manchando el hilo como la tontería de las ventas. Se ve que te gusta ser el centro de atención y en los otros hilos la gente pasó de ti. Pido al resto de usuarios que no te respondan más. Y a moderación le pido que actúe y si es posible que te inabilite la capacidad de publicar más mensajes en este hilo.

21 may 2018 22:23

Enlace permanente

N64 está lejos de saturn y playstation, ¿en gráficos?.

* 21 may 2018 22:25

Enlace permanente

@AES

Ya he avisado antes en general y ahora te aviso directamente.

Cada uno es libre de tener la opinión que quiera, ahi no pasa nada.
Pero si piensas eso de esa consola ¿que haces en un hilo que trata exclusivamente de ella con la unica intencion de caldear el ambiente?

Si no te interesa el tema, ni la consola, ¿no es mejor ignorarlo y centrarte en los que si te importan y puedas aportar algo?

Y esa misma pregunta va para todos los que quieran seguir con ese tono independientemente de si les gusta o no la consola del hilo.

21 may 2018 23:15

Enlace permanente

N64 está lejos de saturn y playstation, ¿en gráficos?.

¿En que estás pensando?.

* 22 may 2018 02:31

1 valoración positiva

Enlace permanente

@EMaDeLoC
En la primera respuesta que me diste sobre lo de los "16MB sobrantes" parecias haber entendido que yo decia que eran algo que sobraba EN el mapeado de la N64, por eso hice la aclaracion de que me referia al 64drive. Pero parece que esa aclaracion causó otra confusion, y ahora parece que crees que dije que el 64drive se guardaba esos 16MB en vez de ponerlos disponibles para el PI.

He vuelto a revisar la especificacion tecnica de la N64 y he visto que puede que haya algunos pocos KB del rango de direcciones del PI en donde el 64drive da acceso a la N64 a algunos registros internos para que la N64 pueda controlar ciertas cosas especificas del 64drive, como el puerto USB, el wifi, registros internos, como uno para activar acceso RW, y mas. Asi que puede que el PI acepte algo mas espacio ROM que los 240MB que el 64drive ofrece y simplemente lo haya redondeado a 240MB por conveniencia.

En todo caso, lo que digo es que la memoria interna que el 64drive mapea al PI debe ser (quitando las excepciones mencionadas) la misma que la consola soporta.
Desde el lado de la N64, si la CPU intenta acceder a direcciones fuera del rango mapeado al PI, la peticion o bien acabará en alguna otra parte del sistema o bien causará una excepcion o algun otro error. Desde el lado del 64drive, el FPGA tiene que mapear explicitamente esa porcion de 240MB de su RAM interna al rango de direcciones del PI que llegan por el conector del cartucho.
Ambos elementos estan de acuerdo en donde estan los limites.

Lo del 64DD, no dije que tu hubieras dicho que habia que darle vueltas al disco, pero, por alguna razon, insistes en que la maquina escribe a las dos caras de manera independiente, y ni es cierto ni sería practico.
Dado que no vas a darle vuelta al disco, como pasaba en disqueteras muy antiguas de un solo cabezal, montas 2 cabezales en el lector, y teniendo 2 cabezales la forma mas practica de montarlos es en un mismo brazo con los dos cabezales mirando al mismo punto del disco pero en caras opuestas. Por que si tienen que moverse independientemente, ya sea de forma simultanea o uno de cada vez, complicas innecesariamente la mecanica del lector, con brazos independientes mas motores y/o mecanismos para cambiar de un brazo a otro... Y total para que? Si lees de las dos caras al mismo tiempo duplicas la velocidad de lectura, asi que porque separar los datos en 2 caras independientes cuando puedes leer las 2 en una misma continuidad de datos y al doble de velocidad?

Como ya he dicho antes, el reparto de partes reescribibles y de solo lectora no se hace por caras, si no que los discos de 64DD vienen formateados con una especificacion de hasta donde llega la zona de solo lectura y donde empieza la parte reescribible. Segun leí en su momento, hay 7 "tipos" de disco que van desde "todo el disco es de solo lectura" a "todo el disco es reescribible" y diversos porcentajes de reparto entre esos dos. No es que los discos sean diferentes fisicamente, si no que vienen formateados diciendo "soy de tipo #", y el hardware de control del 64DD se encarga de permitir o denegar a la N64 escribir en determinadas zonas. Cuando una desarrolladora hace un juego, ya se encarga de especificar que tipo de formato quiere, y pone los datos del juego en la zona RO, dejando la zona RW para datos de usuario (aunque tambien puede traer datos de fabrica en la zona RW, como Mario Artis Talent Studio, que trae una animacion de Hiroshi Yamauchi que puedes borrar para siempre si no te interesa).

@Calculinho
No puedo jurarlo, pero dudo mucho que el 64DD esté preparado para leer discos de mayor capacidad. Estas cosas se diseñan para ser lo mas baratas posible. Desde luego, es seguro que la electronica incluida y el software que lo controla no van a permitir leer un formato mas denso que el oficial, y con respecto a los cabezales, probablemente estén diseñados para leer correctamente el formato oficial y si intenta uno hackear el aparato para leer algo mas denso probablemente de muchos problemas. Asi que de eso olvidate.

Respecto a lo de los multiples discos, estás absolutamente en lo cierto. Si fuera necesario, se podría hacer un juego en multiples discos, a lo RPG de PS1, y pedir al usuario que lo cambie en puntos de inflexion de la historia. Dicen incluso que el MOTHER 3 iba a venir en 4 discos, aunque puede ser un rumor.
EMaDeLoC, lo siento, macho, pero aqui te has equivocado. Si que se puede hacer hot-swap perfectamente, y de hecho hay juegos que lo hacen. Primeramente y mas importante que cualquier otro, está la serie Mario Artist, que son 4 titulos que intercambian datos entre ellos.
Paint Studio (para hacer dibujos 2D), Polygon Studio (modelados 3D y algunos juegos donde usar los modelos que haces), Talent Studio (para crear personajes que luego puedes usar en pases de modelos, peliculas animadas y alguna chorrada mas) y Communications Kit. El Communications Kit está especificamente diseñado para poder intercambiar datos entre los diferentes discos, de forma que puedas usar renderizados de tus modelos de Talent y Polygon en el Paint, o usar dibujos de Paint como texturas en Polygon y Talent, y alguna otra combinacion asi. Incluso los 3 discos de actividades tienen menus para administrar archivos y creo que se puede cambiar el disco para intercambiar archivos, pero no estoy seguro de esto ultimo e igual solo se puede hacer con el CommKit. El Communications Kit, ademas, permitia usar el modem (conectado al puerto de cartuchos) para enviar tus artistadas a los servidores de Nintendo y no se si habia competiciones o una galeria en la web y se podian bajar cosas que hacian otros, o algo asi... solo duró 2 años o año y medio.
Luego está Doshin the Giant, del cual sacaron una especie de "secuela" en la que controlas la presencia onirica de un niño en sus sueños, paseando por una especie de parque tematico y haciendo que se yo que cosas bizarras. En ciertos puntos del juego se supone que tienes que saca el disco y meter el doshin normal para pasarle datos para desbloquear alguna historia o algo asi...

Si en el momento en que se saca un disco se interrumpe la ejecución del programa, pues olvídate del swap disc...
Parace que el 64DD tiene un ejecutable en caso de no haber disco, para realizar configuraciones. Tiene pinta de que salte en cuanto el disco se saque. En ese caso, swap disc imposible.

El 64DD tiene tanto su firmware interno para controlar los mecanismos, como una boot-rom/BIOS que la N64 carga si no hay un cartucho insertado en la consola. Si hay cartucho, por mucho que haya un 64DD con o sin disco, se carga el cartucho, y ya sabrá el cartucho si quiere usar el 64DD y le vale el disco que haya dentro o no. Si no hay cartucho, la N64 carga la BIOS del 64DD, que es como una ROM de N64, y la propia BIOS se encarga de inicializar el 64 y ver si hay un disco dentro y cargarlo si lo hay. Si no hay disco, la BIOS tiene menus para cambiar la hora del reloj interno y alguna otra cosilla. El disco no puede arrancar por si mismo. Primero carga la BIOS y la esta busca el disco y lo intenta arrancar si lo encuentra.

Hay 2 cartuchos especiales pensados para usar con el 64DD que no arracan la N64 como un cartucho de juego normal, si no que dejan que arranque el 64DD: el modem y la tarjeta de captura de video. El modem lo puedes usar con el disco RandNET (basicamente un navegador web) y el Mario Artist Communications Kit. El cartucho de captura de video sirve para conectar una camara, un video o alguna otra fuente de video compuesto y capturar imagenes para hacer cosas en el mario artist.

Asi que, si, una vez mas, se puede hacer hotswap sin problemas. El software de 64DD está pensado para usar el expansion pak como caché y el disco solo se accede cuando es necesario. La mayoria de programas están diseñados para avisarte cuando sacas el disco en un momento indebido. Me imagino que si sacas el disco durante una pantalla de carga podría ser mas problematico y hasta causar un error, pero tambien es posible que tenga codigo para aguantar en esos casos y simplemente pedirte que vuelvas a meter el disco.

Otra cosa, para los que aun duden: El conector EXT de debajo de la consola es, electricamente, el mismo conector que el de cartuchos en la parte de arriba. Son las mismas patillas. De hecho, si abres la consola, es el conector EXT el que está soldado a la PCB, y el conector de cartuchos va insertado en el conextor EXT mecanicamente y sin soldadura. La diferencia, logicamente, es que, desde abajo, el orden de las patillas es a la inversa. Tambien está la diferencia de que en el conector de cartuchos hay 2 patillas que no están conectadas y que en el conector EXT si. No estoy seguro ahora mismo, pero creo que es un rail de 12voltios para los motores del 64DD y que ningun componente de los cartuchos necesita.
La separacion entre cartucho y 64DD se hace por direcciones de memoria. Ahora bien. La BIOS del 64DD obviamente se carga como si fuera un cartucho, pero en un rango de direcciones diferente. Lo que ya no se es cual es el modo de acceso a los datos del disco. No se si se accede como un cartucho, leyendo direcciones de memoria, o se mandan comandos de lectura a un "puerto" y se espera a que el 64DD lea el disco y devuelva una respuesta. Me inclino por la segunda opcion, que es lo que se suele hacer en estos casos. El acceso por direcciones de memoria es mas para memoria en estado solido, que no tiene que hacer lentas operaciones mecanicas y puede responder de forma inmediata. Se cargan los datos en el Expansion Pak y a ejecutar.
El 64DD hasta tiene su propio CIC, o chip de seguridad, diferente a todos los usados en cartuchos (o la placa de arcade Aleck64), que autentifica la ROM de la BIOS. Me imagino que está diseñado para tardar algun que otro milisegundo mas en activarse para dar preferencia al de cartucho e inhibirse si ve que el cartucho ya está activo, y asi conseguir ese efecto de que si hay cartucho cargue el cartucho aun cuando haya 64DD conectado. Tambien podría ser otro proceso, no lo se...

22 may 2018 09:12

Enlace permanente

@radorn entonces si no te he entendido mal con un everdrive (diseñado para ello que supongo que los de ahora no) podría engañar a la consola para hacerse pasar tanto por un cartucho como un 64DD enchufado, aunque no se consiga nada más que esto ya son 64+64 megas para juegos que daría para mucho. Si ya se consigue lo de poder ir cambiando discos de 64DD desde el flashcard el tamaño de los juegos ya no sería un problema.

* 22 may 2018 10:02

Enlace permanente

@Calculinho
Si, se puede simular el 64DD desde un cartucho.
Uno de los propositos de aumentar la RAM en el 64drive es precisamente poder cargar una ROM de cartucho y una imagen de disco 64DD al mismo tiempo (F-ZERO X Expansion Kit, por ejemplo). Probablemente tambien sería necesario cargar la BIOS del 64DD, pues, aunque el codigo que esta contiene para arrancar los discos de forma independiente del cartucho y las funciones para cambiar la hora (y otras que pueda tener, que desconozco) no son vitales dentro del contexto de un cartucho flash que perfectamente puede tener su propio codigo para esas cosas, tengo entendido que la BIOS del 64DD tambien contiene codigo extra como fuentes de texto y algunos otros recursos que pueden ser usados por los juegos en disco.

Ahora bien... la implementacion de todo esto lleva bastante retraso, y lo cierto es que tampoco es prioritario, puesto que ya se han encargado de convertir todos los discos comerciales a formato cartucho y tanto el 64drive como el Everdrive64 aceptan estas conversiones con capacidad de guardar incluida. Si bien en el 64drive, por ahora, no se pueden guardar los cambios en juegos de 64DD a la tarjeta SD cargando desde el menu (cosa que el Everdrive, por lo que me han dicho, si implementa), si no que es necesario usar la conexion USB para volcar la imagen de disco con los cambios de vuelta al PC. Por otro lado, creo que en el Everdrive tiene un soporte USB inferior al 64drive, mas lento y con menos capacidades. En el 64drive se puede simular un cambio de disco en caliente simplemente volcando la imagen actual al disco duro del PC por USB y subiendo la imagen de disco del juego deseado. El acto de subir una imagen nueva activa un registro de memoria que estas conversiones a cartucho estan preparadas para leer e interpretar como un cambio de disco. No estoy 100% seguro, pero CREO que el Everdrive no implementa esta funcionalidad. Asi que, con everdrive, puedes guardar datos de 64DD directamente a la SD (y creo que es automatico), pero no puedes hacer hotswap. Con 64drive, puedes hacer hotswap, pero solo puedes guardar a traves de USB (por ahora).
Adicionalmente, implementar cambios de disco en caliente desde la propia SD del cartucho se me antoja complicado. El 64drive tiene un boton integrado (sin pulsador exterior instalado por defecto en el HW1, pero creo que el HW2 si lo tiene), al estilo del ActionReplay/GameShark, y con el se podría indicar un cambio de disco... pero... ¿que accion deberia tomar el cartucho cuando pulses el boton? cambiar un disco, vale, pero ¿cual? ¿donde está? en el mismodirectorio por orden alfabetico?, vale... pero... el 64drive de por si no lee FAT32, lo lee el menu o el software que sea corriendo en al N64; el cartucho solo ofrece acceso a la tarjeta, no ejecuta un sistema de archivos para leer los ficheros, y, hasta donde yo se, el everdrive hace exactamente lo mismo a ese respecto (que es lo logico). En ambos cartuchos, el guardado de datos en tiempo real se hace guardando una lista de sectores de la tarjeta donde reside el fichero de guardado y simplemente mete ahi los datos sin mas. Una vez cargado un juego, ni la N64 o el cartucho flash saben ya nada del ficheros ni de FAT32 ni nada de nada. Asi que, como leches se supone que se implementa el cambio de discos en caliente desde la propia consola? xD

En cualquier caso. la existencia de las conversiones a ROM de cartucho de los juegos de 64DD, algunas de las cuales, ademas, ya han sido traducidas al ingles (http://www.64dd.org), hace que la implementacion de soporte 64DD "real" pase a ser una prioridad secundaria. Asi que no se... llegará cuando llegue, supongo xD .... o quiza nunca.