Hilo de detalles y curiosidades de N64

Hace un tiempo hice esto:




Se trata de los restos mortales de un Passport 3 que decidió suicidarse mediante los tipicos bugs del software, convertido, despues de preparaciones por adelantado poco acertadas, en un conector en T cableado de tal manera que solo pasan al cartucho de atras las patillas necesarias para el CIC. Actualmente lo uso para poder usar mi 64drive con CIC PAL en mi consola NTSC.

Como podréis ver es todo bastante chapucero. mas que nada por que empece a hacerle cortes y lijados no demasiado acertados hace años cuando no sabia lo que estaba haciendo y luego quedó guardado hasta que me decidí a acabarlo.
¡Pero funciona!

Pues esta guapo. A su estilo de MacGyver, pero mola.

@EMaDeLoC muchas gracias por molestarte, me parecen muy interesantes estos experimentos, ya que en los 90 yo no tacaba un Pc ni con un palo más allá de casos contextuales.

Más adelante, cuando tenga tiempo, reflotaré el tema y el post para emitir una opinión al respecto.

https://assemblergames.com/threads/unre ... ent.63022/

Siguen saliendo hardware para la 64, ¿en serio vendia mal?

@Flash-Original
Bueno, quedó de segunda a mucha distancia de PS1. A Nintendo desde luego le hubiese gustado vender mucho mas. Ni fracaso estrepitoso ni exito de masas. Claro que si relativizamos, viniendo de una posicion dominante, el quedar segunda a tanta distancia podría considerarse un fracaso estrepitoso.

Respeto al prototipo que muestras, me recuerda a algo que aparecia en las revistas de la epoca, que decian que era el 64DD.
Era como esto, pero con una sola luz y una ranura ligeramente ovalada donde estan las 3 pequeñas en este prototipo.
La verdad es que ya no se si no lo habría visto con anterioridad, erroneamente identificado como 64DD en las revistas.
Desde luego, puedo decir que no me suena nada de la funcinoalidad que mencionan.
N64 Media Center? xD

@radorn
Segun parece llevaba varias cosas incorporadas entre esas un puerto ethernet en la web qeupase se ve en la pagina 2 creo

Flash-Original escribió:@radorn
Segun parece llevaba varias cosas incorporadas entre esas un puerto ethernet en la web qeupase se ve en la pagina 2 creo

Ese conector que ves es un RJ-11 y es una conexión telefónica normal y corriente. Por lo visto ese prototipo esta pensado para conectarse a algún servidor de datos como lo hacia el 64DD, solo que en vez de usar un cartucho con un modem, el prototipo ya lo tiene integrado. La pista, un pequeño transformador que tiene la placa que suele ser habitual en modems.
Desde luego si hubiesen seguido adelante con el prototipo y hubiese salido con un disco duro de 512MB (algo razonable en coste para la época) y un servicio RANDnet con juegos descargables, podría haber ayudado a la consola a mantenerse o ganar más ventas. Incluso los desarrolladores podrian haber mejorado su contenido al no tener que hacer cabriolas para meter juegos en cartuchos baratos de 16MB y haber usado los 64MB máximos, lo que habría bajado los costes de desarrollo y el precio final de los juegos. Vamos, el modelo de negocio de ahora puesto hace 20 años. Por soñar...
Otro aparato más que demuestra el potencial de la consola con su puerto de expansión, bastante desaprovechado. Pero bueno, con PSX y su puerto paralelo pasa lo mismo.

radorn escribió:@Flash-Original
Bueno, quedó de segunda a mucha distancia de PS1. A Nintendo desde luego le hubiese gustado vender mucho mas. Ni fracaso estrepitoso ni exito de masas. Claro que si relativizamos, viniendo de una posicion dominante, el quedar segunda a tanta distancia podría considerarse un fracaso estrepitoso.

Discrepo en el fracaso estrepitoso por dos razones: primera, con un catálogo reducido en la N64 contra una extensa colección de títulos y una popularidad tan alta de la PSX, logró vender casi 33 millones de unidades. No es mejor cifra que la SNES, pero es el doble que lo que sacó GameCube. Segunda, Saturn tiene ese dudoso "honor" del fracaso estrepitoso con sus 8 millones de ventas. Es verdad que palidecen ante las 100 millones de PSX, pero por eso mismo ante un mercado casi en el monopolio de Sony, 33 millones no es mala cifra. Aún con esos matices, la N64 no fue la consola de su generación, lo fue PSX sin discusiones.

@EMaDeLoC Pues menos mal que no les dio por usar mucho sus puertos de expansión, porque hubieran seguido los pasos de Sega.

@EMaDeLoC depende, en Japón sí fué un fracaso estrepitoso, y añado vergonzante: estamos hablando que tanto Famicom como Super Famicom gozaban del 88-90% de la cuota del mercado doméstico japonés, y con la N64 no es sólo que perdiese el liderato de ventas, sino que incluso quedó relegada a un embarazoso tercer puesto por detrás de la propia Saturn, la cual ventas al margen fué mucho más popular y querida a nivel de calle que la N64, que salvo por los chispazos que le dieron los juegos de Pokemon por aquellas tierras, por lo demás no fué más que una caída en picado sin paracaídas en ese país. Si a ello le sumamos las ganas que le tenían en NAMCO, CAPCOM, y sobre todo en Square a Hiroshi Yamauchi por sus años de abusos y arrogancia con sus propios socios, golpes como el de Hironobu Sakaguchi tirándole puyas públicamente a Nintendo mudando la gallina de los huevos de oro (FF) a su más directa rival, la cual previamente Nintendo había despreciado en un E3, que encima esa misma es la que le arrebató la hegemonía delante de todas las otras, provocando el abandono de thirds cual leproso a modo de venganza casi personal, es hasta la fecha el counter más humillante hacia una compañía que se ha visto en la historia de esta industria.

En Japón el hostión fué de romperse la dentadura contra el bordillo de la acera, y que encima la gente en lugar de ayudarte se te mease encima, un giro radical de 180 grados que no logró revertirse en una consola doméstica de la misma marca hasta la Wii. Poca broma.

En USA por supuesto no fué en absoluto ni la mitad de dramático, siendo allí una máquina de éxito muy popular, que "simplemente" estaba a la sombra de esa apisonadora que era PlayStation.

A nivel mundial al final hasta ganaron algo de dinero, pero joder la cura de humildad recibida en Japón.

coyote-san escribió:@EMaDeLoC Pues menos mal que no les dio por usar mucho sus puertos de expansión, porque hubieran seguido los pasos de Sega.

No, hombre no, no lo decía con esa intención. Pero si en vez de sacar el 64DD casi al final de su tiempo de vida hubieran sacado esa expansión con disco duro y servicio RANDnet en EEUU (que habría sido lo lógico), se habrían conseguido cosas interesantes.

@Sexy MotherFucker Yo lo resumía en cifras globales, pero es verdad, a nivel de Japón el sopapo fue gordo. A la hora de diseñar juegos los de Nintendo lo han hecho muy bien pero en el tema de relaciones de empresa y subestimar a la competencia... De hecho, ironias de la vida, quisieron juntarse con Philips para darle una lección de humildad a Sony (que les acaparaba muchos ingresos por el CD) y acabaron creando al monstruo que se los comió durante 10 años.
Erraron al pasar del CD con la N64 cuando era la tendencia y erraron al pasar del DVD-video con la Gamecube cuando era la tendencia, solo por simple ego y querer tener razón.
Aún así, no considero la N64 ese fracaso estrepitoso, vistas las circunstancias del momento, y menos con el castañazo posterior de la GC.

@EMaDeLoC yo estuve en el año 2000 viviendo en Estados Unidos unos meses, justo antes del lanzamiento de Ps2, en San Diego, California, y si bien PlayStation era el standard, me sorprendió ver en los Malls/centros comerciales una campaña masiva de Nintendo 64 promocionando el Banjo Tooie con hileras de N64 en modelos de colores, y colas de chavales esperando por jugar, dándome cuenta de la fuerza que todavía Nintendo tenía en el mercado yankee, y lo popular que había sido el sistema por esas tierras, que es de hecho el continente donde más vendió con diferencia.

Por supuesto mucha otra gente se acabó matando por conseguir una Ps2 cuando salió, tanto que se quedaron sin stock para el periodo navideño dentro del estado, pero aun así insisto en que quedé sorprendido con la importante cuota de mercado que tenía allí la 64 bits de Nintendo, y según dicen foreros de por aquí es algo que también se extendió a países vecinos como México.

Menuda diferencia con Europa, no digamos ya con Japón.

Yo vuelvo a recalcar, n64 y gamecube no se movian del almacen, perfectamente habia stock del año anterior, en cambio pediamos 100 ps2, y las vendiamos en un dia, de hecho novendiamos mas ps2 porque no habia stock de la propia sony, y a veces haciendo chanchus, comprabamos del corte ingles yblas revendiamos, ganando menos, pero tp penseis quete hacias millonario vendiendo ps2, creo que le ganabamos entorno a 5€ por consola, 10€ máximo, pero me da que era mas sobre los 5€

Gamecube era adorno del almacén y n64 al fondo del armario con Dreamcast

No me convence mucho eso de que el aparato ese con modem y disco duro fuera a solucionar los problemas de espacio de los cartuchos, por muchos 512 MB o gigas que pudiera tener el disco.
Recordemos que de aquella ni siquiera el modem de 56k era universal, mucha gente iba incluso a 33.6 o 28.
Calcula lo que tarda un juego de 64MB en bajar a esa velocidad... y la resultante factura telefonica.
Con un modem de 56k, en un buen dia, cojias unos 5K de bajada, eso son unos 220 minutos de telefono si se mantienen los 5k todo el tiempo. Mas de 3 horas y media!
Los juegos que se pudiesen bajar con esto tendrían que ser bastante pequeños, o "DLC" para juegos existentes.

@AES Aqui tampoco te quiere comprar nadie, asi que ya es algo que teneis en común, claro que a ti, en vez guardarte, lo suyo era devolverte al fabricante, o directamente a la basura.

@radorn no te calientes que te reportan y acabas cayendo tú. El chaval tiene un trauma con N64 y ya está, si no le respondes se acabará aburriendo.

Sexy MotherFucker escribió:Menuda diferencia con Europa, no digamos ya con Japón.

Bien cierto. La marca Nintendo tiene muy buena fama en EEUU, seguramente por su enfoque familiar. Desde luego si no fuera por EEUU la N64 habría sido el fracaso rotundo del que se habla.
Que por si no ha quedado claro, no digo tampoco que tuviese un buen resultado. En la parte comercial se queda algo por encima del aprobado, una segundona bastante por detrás de la de Sony. Y si bien fue una hostia con la mano abierta para Nintendo, lo fue más por el éxito de PSX que por el fracaso de N64. Calificarla de fracaso rotundo me parecen palabras mayores.

radorn escribió:No me convence mucho eso de que el aparato ese con modem y disco duro fuera a solucionar los problemas de espacio de los cartuchos, por muchos 512 MB o gigas que pudiera tener el disco.
Recordemos que de aquella ni siquiera el modem de 56k era universal, mucha gente iba incluso a 33.6 o 28.
Calcula lo que tarda un juego de 64MB en bajar a esa velocidad... y la resultante factura telefonica.
Con un modem de 56k, en un buen dia, cojias unos 5K de bajada, eso son unos 220 minutos de telefono si se mantienen los 5k todo el tiempo. Mas de 3 horas y media!
Los juegos que se pudiesen bajar con esto tendrían que ser bastante pequeños, o "DLC" para juegos existentes.

Pero tú estás pensando en lo que había aquí en aquella época y era casi la edad de piedra. Yo pensaba en EEUU, que el internet era bastante popular y las tarifas de conexión bastante mejores. Para el 98 los 56k ya estaban bien implantados (allí). Además no se trata tanto del espacio de los cartuchos como de los costes de su fabricación. Vender un juego de 16MB saldría más barato descargarlo que comprarlo porque te ahorras el cartucho. Pero su función más interesante sería la de descargar demos, que podrían ser tranquilamente de 4MB (solo 15 minutos de descarga) y ayudarían a promocionar la venta de los juegos. Los juegos de 64MB lo pensaba más para algo tipo exclusivos o como una forma de dar facilidades a los desarrolladores en 99/2000, obligados continuamente a gastar tiempo de programación en meter los datos en el cartucho más pequeño posible, una vez el 64 con disco duro tuviese buena aceptación.
Pero claro, estoy hablando de políticas empresariales que ahora asumimos como normales en un momento que lo de las tiendas virtuales ni se concebía.
Lo dicho, por soñar...

EMaDeLoC escribió:Pero tú estás pensando en lo que había aquí en aquella época y era casi la edad de piedra. Yo pensaba en EEUU, que el internet era bastante popular y las tarifas de conexión bastante mejores. Para el 98 los 56k ya estaban bien implantados (allí).

Pues la Dreamcast originalmente salió con 33.6 y no fue hasta finales del 99 (segun wikipedia) que sacaron el modem de 56k. Y, aun con eso, una gran cantidad de gente en USA siguió con modem telefonico hasta bien entrados los años 20XX. Si, habia cosas como ISDN (RDSI en españolo) y T1, pero poca gente lo tenia. Y en todo caso, las tarifas de internet baratas de muchos eran a traves de servicios integrados en la red de la operadora telefonica. Si llamabas a otro servicio con el modem lo pagabas como llamada de voz, y a saber donde estaba ese servidor.
La cuestion es que incluso con 56k, una descarga de 1 hora o mas ocupando la linea telefonica iba a ser dificilmente aceptable por el gran publico.

radorn escribió:Pues la Dreamcast originalmente salió con 33.6 y no fue hasta finales del 99 (segun wikipedia) que sacaron el modem de 56k.

A ver, eso la Dreamcast y eso en Japón al principio, y en Europa. En EEUU y Japón más tarde ya venía a 56k. Pero eso en la consola, para que fuese más barata. Para finales del 97 la mitad de los proveedores de internet de EEUU ya ofrecían velocidad compatible con 56K. Claro que un modem de 56 no sería barato en el 98 para una consola y seguro que Nintendo hubiese optado por el de 33.6 por los costes.

radorn escribió:La cuestion es que incluso con 56k, una descarga de 1 hora o mas ocupando la linea telefonica iba a ser dificilmente aceptable por el gran publico.

Los que se conectaban a internet se tiraban tranquilamente una hora o dos solo navegando. Es verdad que no estarían todo el rato descargando, pero el modem seguiría activo y ocupando la línea. Luego ese argumento de que se ocupa la línea es muy endeble...
Creo que tu error es comparar el internet de aquí con el de allí. En España apenas el 10% se conectaba a internet, mientras que en EEUU para mediados del 98 lo hacía el 30%, y eso es mucha gente. Ese periférico bien vendido y bien apoyado con demos, juegos, etc en EEUU no lo habría hecho mal del todo. Demonios, el 64DD debería haber salido en EEUU y no en Japón, vista la cantidad de consolas vendidas en cada país. Pero eso lo digo con el conocimiento de 20 años por delante en temas de servicios de internet, no con la mentalidad de entonces...
Claro que todo hay que decirlo y seguramente entre placa, modem, disco duro, etc no bajaría de los 300$ y eso tiraría para atrás a la mayoría de padres, y posiblemente eso es lo que llevaría a cancelar el prototipo, los costes de producción.

De todas formas lo interesante del prototipo es que si es posible conectar un disco duro casi podríamos descartar que 64MB sea el límite de la consola y lo sean realmente esos 240MB que tiene implantado el 64drive. Lo cual me hace pensar... ¿Y si Nintendo no implantó el CD porque el RCP tiene ese límite de acceso y adaptar un lector fuese más costoso aún que lo que costaba en PSX?

@radorn @EMaDeLoC en USA la Dreamcast salió directamente con un modem de 56 kb, mientras que aquí nos llegó el de 33. Estuve en Estados Unidos por esa época, y además me compré la Dc PAL de salida y leía mucha información internacional sobre ella.

No es lo mismo tener el PC conectado para navegar o lo que sea y convencer a los adultos que pagaban la factura de hacer lo mismo por un solo juego de consola. Esa es mi percepcion. Puedo equivocarme.

Respecto a lo de usar CDs, Nintendo no lo hizo sencillamente porque no se ajustaba a su modelo de negocio el tener un formato que no pudiesen controlar ellos mismos. Nintendo quiso probar con CDs con la Super y luego se echaron atrás dandole una puñalada trapera a SONY como ataque preventivo de lo que muy seguramente Yamauchi percibió, y no con pocas razones, como un intento de SONY de comerle las papas. Claro que luego el asunto no les salió como esperaban...
Despues de eso, por una parte se reafirmarían en su posicion de seguir con lo que conocian, cartuchos con CIC, y por otra, es posible que otras empresas del sector mirasen a Nintendo de reojo pensando que igual tambien les traicionaban. Por lo que dicen muchos, no se vio con buenos ojos entre la industria japonesa que Nintendo rompiese el acuerdo con SONY para irse con una empresa extranjera, trato que, nuevamente, acabó en la nada.
O sea, que Nintendo hizo dos tratos seguidos con dos empresas con tecnologia CD y ambos tratos acabaron en nada... Quien quiere ser la tercera? xD Es mas, a cuantas mas podría haber acudido Nintendo si realmente hubiese querido usar CDs? Acabaron acudiendo a Panasonic para la GC y sucesoras, pero eso ya es otra historia. Con el drama calentito dudo que hubiese muchas empresas interesadas.
Además, no olvidemos, que de aquella, incluso las unidades opticas mas basicas eran caras y hubiesen subido mucho el precio de la consola, cosa que no encajaba en la estrategia de Nintendo... no estoy diciendo que fuera buena, solo señalo que tenian una y en ella no entraba lo de usar CDs por una serie de razones.

En fin, no creo que haya nada en la arquitectura de la N64 que fuese a impedir implementar un lector de CD. A traves del PI se puede implementar perfectamente una interfaz que no requiera de mapear el disco como memoria. El propio 64drive tiene la capacidad de transmitir datos directamente por USB, e incluso tiene una interfaz wifi en la ultima revision de hardware.
Piensa tambien el los modems de la consola, tanto el del 64DD como el incorporado en el Morita Shogi. Tambien esta el cartucho de captura e incluso el Mario no photopie, con dos ranuras de tarjeta smartmedia. A traves del PI se puede conectar todo tipo de hardware y no tienes que limitarte a mapearlo como memoria.
Como recordarás de nuestra anterior conversacion, no creo que ni el 64DD use direcciones de memoria como metodo de acceso al disco, aunque tu creo que si proponias esa implementacion.

Bueno, en resumen. Que estoy convencido de que la N64 no tiene ninguna limitacion tecnica que le impidiese usar CDs si no que las decisiones se tomaron en base a consideraciones politicas y de mercado.

Considera esto: ¿Si la N64 no era suficiente para implementar un CD, como lo hicieron la MegaDrive y la SNES?

Cuando dije lo de la limitación en el acceso al CD no queria eliminar el resto de motivos, que desde luego son más importantes en esa decisión como la ruptura con Sony y Philips, la piratería, etc.
Tampoco quería decir que no fuese posible adaptarlo a la N64, hay todos esos ejemplos de muchas funciones añadidas a la consola como el 64DD, el modem, el capturador de video, etc. Pero hay cosas que aclarar.
El PI de la consola tiene tres partes principales de comunicación: el bus paralelo, el bus serie y los datos CIC.
Los datos CIC ya sabemos qué es.
El bus paralelo es la forma que se comunica al cartucho y al 64DD. El manual de programación especifica que es un acceso por DMA (acceso directo a memoria) por lo que solo se comunica a traves de instrucciones tipo "pasame el bloque de tamaño X en la dirección Y". Un par de pines extra indican si la operación es de lectura o escritura, para guardar partidas en cartucho o disco.
Por último el bus serie es lo que permite conectar el modem de Morita shogi, y seguramente cualquier otro modem similar. Por su velocidad, muy lenta, parece que su uso se limite a modems.
Hay unos pines dedicados a audio, video... Esos para otro momento...
Volviendo a la comunicación paralela, son direcciones de memoria puras y duras, no son archivos, ni pistas de audio... son bloques de datos. El RCP, que es quien hace practicamente todo, solo funciona por DMA, así que si o si para trabajar con discos como el 64DD debe haber una interfaz que haga las traducciones debidas a los sectores del disco. De hecho ya comentamos que había dos direcciones de memoria principales, una dedicada a los cartuchos y otra al 64DD.
El caso es que esto viene por el diseño del RCP, que como digo se ocupa practicamente de todo, e incluye la interfaz PI. No hay más que ver como el RCP se conecta al cartucho directamente, a pelo, sin intermediarios, de patilla de cartucho a patilla del chip. Cuando Silicon Graphics les ofreció este chip todo-en-uno a Nintendo que les permitía ahorrarse controladores DMA, de perifericos, audio, etc, les faltó tiempo para firmar la compra.
Pero el RCP tiene una carencia y es que no dispone de interrupciones de sistema, imprescindible para el uso de CDs. En PSX cuando una pista de audio se acaba, el controlador de CD manda una interrupción a la CPU para que lo sepa y esta decide, según el juego, repetir pista, continuar con otra o parar. Esto el RCP no lo incluye, y aún menos el puerto de cartucho/expansion de la consola (recordemos que técnicamente es el mismo).
Entonces, ¿no se puede poner un CD en la N64 tipo 64DD? Claro que si, solo has de dotar al periferico de controlador de CD, cache, interfaz entre DMA y CDRFS (sistema de archivos del CD). Es decir, te sale algo más caro de implementar el CD por tener un chip que te hace de todo en vez de tener chips separados y dedicados.
Entonces si se puede poner un CD (no dije que no se pudiera), pero sale algo más caro de implementar que lo que salía en PSX por el RCP. Y además tengo serias dudas de que se pudiera reproducir audio mientras se ejecuta un juego. No podría usar el bus paralelo porque se sobrecargaría el RCP, pero como hay unos pines dedicados al audio en el cartucho, puede que por ahí si. Pero tenemos el problema de que no hay interrupciones, así que habría que exprimirse los sesos para saber cuando se ha llegado al fin de una pista, porque exceptuando el bus serie la comunicación del PI no es bidireccional. El cartucho/64DD/CD solo puede responder a peticiones de datos del RCP, pero no puede, por sí mismo, mandarle datos al RCP que no han sido solicitados.
En cuanto a tu pregunta sobre MegaDrive y SNES, es muy sencilla: MegaDrive tiene un puerto distinto al del cartucho, seguramente sin tantos límites de diseño, y la Nintendo Playstation era una modificación completa de hardware, casi una consola nueva. Pero bueno, como he dicho yo no planteaba que no se pudiese, sino que en la N64 salía más caro de implementar el CD que en la PSX. Al menos con el hardware de consola tal y como lo conocemos.
Sería un motivo a añadir a la lista de Nintendo de argumentos contra el CD.

EMaDeLoC escribió:El bus paralelo es la forma que se comunica al cartucho y al 64DD. El manual de programación especifica que es un acceso por DMA (acceso directo a memoria) por lo que solo se comunica a traves de instrucciones tipo "pasame el bloque de tamaño X en la dirección Y"

Esto es incorrecto. El uso del DMA es el sistema RECOMENDADO para transferir grandes cantidades de datos del cartucho a la RDRAM, que es lo ideal para cosas como codigo ejecutable, graficos y otros datos de juego por la mayor velocidad de la RDRAM comparada con el cartucho. Sin embargo, otros tipos de datos normalmente se acceden directamente desde el cartucho en tiempo real, sin DMA ninguno, como, por ejemplo, samples de audio para musica y efectos y datos de animacion. Si alguna vez has hecho los famosos trucos de inclinar el cartucho, en zelda o goldeneye, por ejemplo, habrás podido observar los efectos de esto: El sonido se vuelve un ruido infernal y los personajes parece como si se hubiesen chutao todo el extasis y las anfetas del planeta entero.

EMaDeLoC escribió:Por último el bus serie es lo que permite conectar el modem de Morita shogi, y seguramente cualquier otro modem similar. Por su velocidad, muy lenta, parece que su uso se limite a modems.

Esto lo sabes a ciencia cierta o es una suposicion tuya?
Yo lo que tengo entendido es que el bus de serie está ahi para los chips eeprom de guardado y no se usa para nada mas.
Si, son eeprom en serie. Los "saves" SRAM y FlashRAM van conectados al PI, pero los EEPROM van por el bus en serie.

EMaDeLoC escribió:Hay unos pines dedicados a audio, video... Esos para otro momento...

Audio, si, como en en la Famicom y la Super (En la NES, por desgracia, no)
Video, que yo sepa, no. De donde sacas esto?

EMaDeLoC escribió:De hecho ya comentamos que había dos direcciones de memoria principales, una dedicada a los cartuchos y otra al 64DD.

Y yo sigo pensando que la region de memoria dedicada al 64DD es para el IPL (la ROM e arranque) y no tiene nada que ver con la forma en que se accede al disco.

EMaDeLoC escribió:El RCP, que es quien hace practicamente todo, solo funciona por DMA,

El DMA es simplemente un mecanismo para permitir a la CPU hacer una peticion de copia de datos desde el cartucho a la RDRAM y que mientras el RCP realiza esa transferencia, la CPU quede libre para seguir procesando otras cosas. Sin DMA la CPU tendría que ser la encargada de copiar byte por byte todos los datos desde el cartucho a la RDRAM y no podría hacer nada mas durante ese periodo.
Por otro lado, El RCP puede acceder al cartucho por su cuenta perfectamente, sin DMA (que tampoco tiene sentido pues es el propio RCP quien tiene el control de ese bus, asi que a quien iba a pedirle el DMA?), y lo hace para acceder a los datos de audio, y, por ejemplo, en el Indiana Jones, hicieron microcodigo custom para que cargarse las texturas en la TMEM (cache de texturas) directamente desde el cartucho, en vez de tener que ser copiadas a la RAM primero. Probablemente tambien haga lo mismo habitualmente con los datos de animacion.
Todo esto va definido por las librerias de programacion, y no tanto por el hardware.

Respecto a lo de la implementacion mas cara a causa de las cuestiones logicas del CD... Sinceramente, no es mucho peor que para el 64DD. Lo caro del CD no es la electronica de interfaz con el host, si no los requerimientos del propio CD.
El 64DD tambien tiene que tener electronica para hacer interfaz con la N64.
Mencionas lo de los eventos asociados a las pistas e audio... bueno el 64DD tambien tiene que informar a la N64 de eventos inesperados; Los mas obvios la introduccion y extraccion de discos. Sin lineas IRQ, la N64 tendrá que hacer polling al controlador del 64DD. Pues para el CD lo mismo. El audio del CD se puede pasar a la consola directamente por las patillas de audio analogico, y todo lo demás se implementaría de forma comparable a como se implementaban los controladores de disco en los PCs cuando iban en tarjetas ISA y PCI antes de que se integrase todo en la placa base.
Francamente, en cuanto a consideraciones de coste, la parte logica del hipotetico 64-CD, para poder hacer la interfaz con el PI, me parecen despreciables comparado con la parte de electronica de control, la mecanica, y la optica, el lector de CDs, que era lo mas novedoso por entonces.

EMaDeLoC escribió:En cuanto a tu pregunta sobre MegaDrive y SNES, es muy sencilla: MegaDrive tiene un puerto distinto al del cartucho, seguramente sin tantos límites de diseño, y la Nintendo Playstation era una modificación completa de hardware, casi una consola nueva.

Dudo mucho que el puerto de expansion de la MD tenga menos limitaciones que el las partes disponibles del PI de la N64.
Y respecto a lo del SNES-CD, te equivocas.
Por un lado es cierto que SONY iba a vender su modelo integrado (cuyo prototipo ha salido a la superficie en tiempos recientes, pero tambien se iban a producir expansiones para la SNES, que se conectarían al puerto de expansion inferior de la consola, como el BS-X SatellaView.
http://pressthepsbutton.files.wordpress ... cd-rom.jpg
http://www.nintendoworldreport.com/media/27669/4/1.jpg
http://www.glitterberri.com/content/sne ... cle_1.jpeg
http://nextn-cdn.nextn.netdna-cdn.com/w ... s-CD-7.jpg
Igualico que el MegaCD

De aquella casi todas las consolas tenian puertos de expansion. Hasta la NES (no la famicom) tiene un puerto debajo, aunque hay que cortar un poco de plastico para destaparlo https://duckduckgo.com/?q=NES+expansion ... &ia=images (Si bien la Famicom tiene otro puerto de expansion en el frontal, pero parece mas para accesorios basicos que algo al mismo nivel que el cartucho)
Lo novedoso del diseño del EXT de N64 es que fisicamente es el mismo que el de cartuchos. Asumir que, por que tiene limitaciones, es, de alguna forma, "mas limitado" que los anteriores... me parece un tanto aventurado.

Como dato curioso sobre el CD de SNES, existe un prototipo aun anterior en el que todo iba implementado en un armatroste gigantesco conectado al puerto de cartucho de la consola.
https://www.nextn.es/2015/04/n-files-2- ... ps-y-sony/

radorn escribió:Sin embargo, otros tipos de datos normalmente se acceden directamente desde el cartucho en tiempo real, sin DMA ninguno, como, por ejemplo, samples de audio para musica y efectos y datos de animacion.

Eeem... Eso también es DMA, técnicamente, solo que en vez de ir a la RDRAM va al RCP. La DMA se define por la transferencia de datos entre componentes sin necesidad de involucrar a la CPU.
De todas formas ahora que lo leo me refería al acceso por direcciones de memoria.

radorn escribió:Yo lo que tengo entendido es que el bus de serie está ahi para los chips eeprom de guardado y no se usa para nada mas.
Si, son eeprom en serie. Los "saves" SRAM y FlashRAM van conectados al PI, pero los EEPROM van por el bus en serie.

Pues con el manual de programación de la N64 en la mano he de darte la razón. Vi el pin en uso en el Morita Shogi y deduje que se usaba para el modem, pero va al EEPROM. Me habría gustado verlo en el modem del 64DD pero no he encontrado fotos de esa parte del circuito.
Un poco llamativo que el bus serie no se use para un dispositivo de comunicación en serie y si para una memoria...
No dice el manual nada de módems, así que... ¿acceso por direcciones de memoria reservada?

radorn escribió:Audio, si, como en en la Famicom y la Super (En la NES, por desgracia, no)
Video, que yo sepa, no. De donde sacas esto?

De esta wiki y de este pantallazo, pin 46. No especifican mucho, por no decir nada. Solo es para NTSC, en las PAL por lo visto no esta conectado. ¿Una señal de sincronía de video? Parecería pero el cartucho de captura no lo usa. No parece que se haya usado nunca en un cartucho real.

radorn escribió:Y yo sigo pensando que la region de memoria dedicada al 64DD es para el IPL (la ROM e arranque) y no tiene nada que ver con la forma en que se accede al disco.

No lo discuto, pero si se puede conectar el 64DD y un cartucho a la vez, a la fuerza debe distinguirse uno u otro de alguna manera, o bien rangos de direcciones diferentes o bien una combinación especial de READ y WRITE que no conocemos (y que no me convence). En el manual de programación hay funciones diferenciadas para acceder a cartuchos, discos y registros del 64DD, y se puede establecer el rango de memoria de cada uno, pero no habla de como se diferencia por hardware uno y otro.

radorn escribió:Mencionas lo de los eventos asociados a las pistas e audio... bueno el 64DD tambien tiene que informar a la N64 de eventos inesperados; Los mas obvios la introduccion y extraccion de discos. Sin lineas IRQ, la N64 tendrá que hacer polling al controlador del 64DD. Pues para el CD lo mismo. El audio del CD se puede pasar a la consola directamente por las patillas de audio analogico, y todo lo demás se implementaría de forma comparable a como se implementaban los controladores de disco en los PCs cuando iban en tarjetas ISA y PCI antes de que se integrase todo en la placa base.

Pero el polling es muy ineficiente comparado con las interrupciones, obligaría al RCP a estar de forma constante comprobando el estado de reproducción, otro cuello de botella más...
Tú que conoces más el 64DD, ¿no podría ser que usara el pin 45, NMI_R4300, para indicar los eventos de disco? Aparte de que lo necesita el everdrive64, no veo mucho más información. En el manual mencionan las NMI (Non-maskable Interrupts) que parecen relacionadas a ese pin pero aparte de un escueto "el cartucho ha generado una interrupción", nada más.
¿Y si el 64DD genera la interrupción y luego la consola accede a sus registros para averiguar la causa?

radorn escribió:Francamente, en cuanto a consideraciones de coste, la parte logica del hipotetico 64-CD, para poder hacer la interfaz con el PI, me parecen despreciables comparado con la parte de electronica de control, la mecanica, y la optica, el lector de CDs, que era lo mas novedoso por entonces.

Pues eran mucho más despreciables los componentes que permiten RGB en las consolas francesas y Nintendo los quitó. No subestimes la racanería de la gran N.

radorn escribió:Dudo mucho que el puerto de expansion de la MD tenga menos limitaciones que el las partes disponibles del PI de la N64.

Basta que tenga más pines de comunicación y el MD y el SNES ya lo supera.

radorn escribió:Lo novedoso del diseño del EXT de N64 es que fisicamente es el mismo que el de cartuchos. Asumir que, por que tiene limitaciones, es, de alguna forma, "mas limitado" que los anteriores... me parece un tanto aventurado.

No digo limitado en plan menos posibilidades, pero si diseñado para funcionar de una manera concreta y que hay que adaptar para trabajar fuera de ella. Viendo los pines del EXT, y habiéndose peleado con Sony y Philips, Nintendo no tenía el CD en la cabeza al diseñarlo. Por supuesto eso abarataba costes en la consola.

Estroy de camino a la cama, pero te dejo un par de cosas rapidas, y lo demas, para mañana.

Lo del pin 46, VCLOCK debe ser el reloj del bus de video, concretamente el pixel clock: 50Mhz nominales (aunque en la practica menos, y diferente en PAL, NTSC y MPAL), 4 ciclos por pixel (R G B y control) No se me ocurre para que podría usarse en un cartucho, la verdad. No creo ni que tenga sentido en el cartucho de captura, dado que el aparato tendría que sincronizarse a la señal de video entrante, no imponer un reloj externo, entre otras razones.

Lo del NMI: El chip PIF controla el CIC, los mandos, alguna cosa mas, y el boton reset. Del boton RESET se detecta cuando se pulsa y cuando se suelta, y pasa algo diferente en ambas, pero no me preguntes mas.
Se, por ejemplo, que, con un Action Replay o derivados, si presionas reset durante el menu (o el logotipo, realmente) y lo mantienes, puedes sacar el cartucho y meter otro sin que la consola se resetee. Sirve para importar juegos, siempre y cuando el CIC sea el mismo y el juego no tenga otras protecciones de region (como lo de mirar el Os_Tv_Type y decirte que tu consola no vale para ese juego). Eso deja claro que hay un evento cuando pulsas y otro cuando sueltas.
Tambien están los juegos que hacen algun efecto mientras mantienes el RESET pulsado y no vuelven al juego hasta que sueltas, con el notable caso de Tetrisphere (si no lo conoceis, probad!)
El manual de programacion menciona algo al respecto de que los juegos deben acabar limpiamente todo el procesado y no dejar ciertas cosas sin cerrar en unos milisegundos cuando se pulse o suelte el reset, para evitar no se que problema.

Creo que los cartuchos lo usan para algo, pero no tengo claro que. Se que el 64drive lo usa para detectar el reset y poder implementar (si esta configurado asi en el menu) la funcion de volver al menu cuando se haga reset. En vez de dejar que la consola arranque otra vez la ROM que estabas jugando, como un cartucho normal (que, en realidad no lo hace directamente, si no que primero carga el boot-emulator de nuevo para poder saltarse la proteccion del CIC, y luego va la ROM del juego), puede decidir poner en su lugar el bootloader que, a su vez, carga el menu dese la SD.

En fin, que no pongo la mano en el fuego, pero no creo que el NMI pueda usarse para la funcion que dices. De hecho, hablando con marshallh hace años, yo tambien tuve la curiosidad de preguntar por el NMI, en concreto para saber si era posible resetear la consola desde el 64drive mediante una orden remota por USB, y me explico que no, que el NMI lo genera el PIF y lo reciben la CPU, el cartucho y otras ocsas mas, pero no al reves.

PD: mi concepto de "rapido" como ves, es un tanto extraño xDDD

AES escribió:Yo vuelvo a recalcar, n64 y gamecube no se movian del almacen, perfectamente habia stock del año anterior, en cambio pediamos 100 ps2, y las vendiamos en un dia, de hecho novendiamos mas ps2 porque no habia stock de la propia sony, y a veces haciendo chanchus, comprabamos del corte ingles yblas revendiamos, ganando menos, pero tp penseis quete hacias millonario vendiendo ps2, creo que le ganabamos entorno a 5€ por consola, 10€ máximo, pero me da que era mas sobre los 5€

Gamecube era adorno del almacén y n64 al fondo del armario con Dreamcast

Como dice @Sexy MotherFucker , depende del país, en España quizás no pero en USA y México(supongo que en otros países de America también), se vendía bastante bien, no para rivalizar las ventas de ps1 a nivel mundial, pero por lo menos en este lado del charco no se puede hablar de fracaso estrepitoso.

radorn escribió:Estroy de camino a la cama, pero te dejo un par de cosas rapidas, y lo demas, para mañana.

Hombre, tampoco te quiero quitar horas de sueño. Se agradece, pero la próxima a dormir.

radorn escribió:Lo del pin 46, VCLOCK debe ser el reloj del bus de video, concretamente el pixel clock: 50Mhz nominales (aunque en la practica menos, y diferente en PAL, NTSC y MPAL), 4 ciclos por pixel (R G B y control) No se me ocurre para que podría usarse en un cartucho, la verdad. No creo ni que tenga sentido en el cartucho de captura, dado que el aparato tendría que sincronizarse a la señal de video entrante, no imponer un reloj externo, entre otras razones.

Pues ale, otro misterio para la lista...

radorn escribió:Lo del NMI: El chip PIF controla el CIC, los mandos, alguna cosa mas, y el boton reset. Del boton RESET se detecta cuando se pulsa y cuando se suelta, y pasa algo diferente en ambas, pero no me preguntes mas.

Según el manual, al pulsar el reset se genera un evento OS_EVENT_PRENMI y 0'5 segundos después una interrupción NMI, a menos que el botón siga pulsado que entonces se genera en cuanto se suelte. Esto estará pensado para darle tiempo al juego a cerrarse, guardar datos, etc, y es lo que permite eso que comentas del Tetrisphere.

radorn escribió:El manual de programacion menciona algo al respecto de que los juegos deben acabar limpiamente todo el procesado y no dejar ciertas cosas sin cerrar en unos milisegundos cuando se pulse o suelte el reset, para evitar no se que problema.

En concreto menciona no dejar el RCP en un estado de bloqueo (al ser softreset si se bloquea habría que apagar y encender la consola), parar tareas de audio para que no haya ruidos y parar los DMA al ROM. Por lo visto tras un reset el hardware se reinicia igual que un encendido, pero excepto el primer megabyte, la RAM queda intacta y queda registrado que ha habido un reset. Esto puede ser un problema si empiezas a acceder a la RAM sin haberla limpiado, pero también puede ser útil, por ejemplo para no tener que volver a cargar datos del 64DD.

radorn escribió:Creo que los cartuchos lo usan para algo, pero no tengo claro que.

Pues aventuro a decir que es para reinicializar las memorias del cartucho. ¿Recuerdas que hace unas páginas hablé de un truco para expandir la capacidad del cartucho más allá de 64MB? Se basaba en el funcionamiento de los bancos de memoria. En previsión de que un cartucho se componga de varios chips, por ejemplo 2 chips de 4MB, se le manda un aviso a traves del pin para que reinicialice los bancos de memoria. Si no, en vez de cargarse el primer megabyte de los primeros 4MB, donde estaría el programa, cargaría el megabyte de los segundos 4MB, y se ejecutaria código corrupto y la consola explotaría... Bueno, lo último no, pero podría pasar de todo.
Así que para eso lo usan los cartuchos, para reiniciarse en caso de reset. No todos los necesitan porque hay muchos con solo un chip, y los que tengan más de un chip puede que no trabajen con bancos de memoria si no con su propio gestor de direcciones y no necesite reinicializar nada. Pero le viene que ni pintado a las flashcarts para cargar el menú.

radorn escribió:En fin, que no pongo la mano en el fuego, pero no creo que el NMI pueda usarse para la funcion que dices.

Pues yo si la pongo en el fuego (tu mano, claro ) y entre tus explicaciones y el manual me queda claro que el NMI no funcionaría para eso. Es curioso porque hay otro pin, el 20, dedicado a un cold reset. ¿Qué diferencia habrá entre uno y otro?
En fin, que el pin de NMI no serviría para que el cartucho se comunique, lo cual me deja con la incognita de como avisa el 64DD de una extracción de disco, además de como se genera la interrupción de cartucho definida en el manual. Supongo que lo de 64DD lo hará por polling como dijiste, lo otro ni idea. Quizá solo sirva para detectar que se quita el cartucho a saco.

@EMaDeLoC
Del COLD_RESET no tengo ni idea, pero no creo que haga eso que dices de "detectar" la extraccion de un cartucho en caliente.
Cuando sacas el cartucho, el PIF deja de detectar el CIC del cartucho y provoca que la CPU deje de correr, congelando la consola.
El VI del RCP sigue pasando el ultimo framebuffer al DAC y creo que tambien el ultimo buffer de audio.
Con el truco de los AR/GS que mencioné con anterioridad (que probablemente se deba a que el software que usa no responde al pre-nmi) o con mi super conector en T, si retiras el cartucho que está corriendo, pero mantienes el CIC conectado, el juego no se cuelga a no ser que la CPU requiera datos nuevos y, al no conseguirlos, la ejecucion se va al carajo (crash). Los datos en streaming que usa el RCP (audio, animaciones) no parece que provoquen grandes problemas, y todo vuelve a la normalidad en cuanto reinsertas... a no ser que la ranura de cartuchos esté floja y se pierda la continuidad del CIC, parando la CPU.

En algun momento tendré que grabar algun video demostrando estas tonterias xD

radorn escribió:Del COLD_RESET no tengo ni idea, pero no creo que haga eso que dices de "detectar" la extraccion de un cartucho en caliente.

Huy, no, yo me refería a la interrupción de la CPU asociada al cartucho que viene en el manual de programación. Iba a decir que quizá se generaba cuando desconectas el cartucho y no pasa corriente (no esta cerrado el circuito de los 3.3v). Pero por lo que comentas, tal vez la interrupción este asociada a dejar de detectar el CIC. Al menos tiene sentido, pero el escueto "A peripheral has generated an interrupt" del manual no es muy preciso...

Bueno, COLD_RESET se añade a la lista de misterios...

radorn escribió:En algun momento tendré que grabar algun video demostrando estas tonterias xD

Pues estaría bien, porque ayudaría a ver como funciona los accesos del RCP al cartucho. Por ejemplo, si dices que estando el CIC conectado pero no los datos la consola puede seguir corriendo, eso es que el RCP pasa de los ALE, el reloj y casi de todos los pins del cartucho y se espera lo que quiera a que lleguen

Y pensando en eso...
Un adaptador con el CIC y las conexiones necesarias y una protección adecuada, unos cartuchos que solo vayan con ese adaptador y ¡PAM! @Calculinho, ahí tienes tu sistema multicartucho para el Final Fantasy VII, ¡y por solo 200$!
Es broma, se me ha ocurrido la idea y he pensado en ti. De buen rollo todo.

@EMaDeLoC no he entendido una mierda, pero se empieza por algo aunque sea caro y ya luego se mirará como hacerlo más barato xD

He grabado el video del que hablaba en mi ultimo mensaje.

https://www.youtube.com/watch?v=H56vD13ynto

Copio aquí, por conveniencia, la descripcion de Youtube. La ventaja de verlo en Youtube es que se puede hacer click en los tiempos que marqué para los que no quieran tragerse los 15 minutos enteros.

Calculinho escribió:@EMaDeLoC no he entendido una mierda, pero se empieza por algo aunque sea caro y ya luego se mirará como hacerlo más barato xD

Básicamente que se podría cambiar de cartucho igual que se cambiaba de CD en los FF de PSX, sin reiniciar la consola.

@radorn Lo del pilot wings me ha dejado loquísimo, todo está en la ram de la consola en ese momento xD

Tiene que tener una velocidad de transferencia de la hostia, ¿no?.

@Señor Ventura
Podría probar en alguna isla mas grande con mas objetos, donde las cosas lejanas desaparezcan detras de la distancia de carga, y entonces, igual, resulta que el juego tiene que cargar algo nuevo desde el cartucho durante la partida, no lo se. Pero si, por lo menos en el caso e la pequeñisima "Holiday Island", parece que todo se carga desde el principio... todo excepto los samples de sonido, que como ya dije mas arriba, los usa el RCP (concretamente la parte del RSP) directamente desde el cartucho. El resto, se transfiere mediante DMA a la RDRAM y luego se usa desde ahí.
Tecnicamente la N64 tiene tiempos de carga, pues lo normal es que transfiera muchas cosas desde el cartucho a la RAM, pero habitualmente es tan corto que se hace casi instantaneo, y casi hasta se agradece ese segundo de pantalla negra como transicion.
Tambien hay que tener en cuenta que en los juegos de N64 suele usarse compresion de datos. Primero se hace DMA desde el cartucho a la RAM, y desde ahi se hace descompresion, luego los datos comprimidos se descartan y se usa el espacio que ocupaban como RAM para procesado. Supongo que tambien podría descomprimirse directamente desde el cartucho, dado que la CPU puede perfectamente leer el cartucho byte a byte, pero posiblemente sería demasiado lento. Aunque sospecho que los Quake's hacen eso, visto todo lo que tardan en cargar los niveles.

Respecto a la velocidad, mejor datos que especulaciones
https://www.hcs64.com/dma.html
hcs es un scener desde cuando la N64 era joven. Entre otras cosas, hizo un emulador de NES para N64.

bluedark escribió:

Calculinho escribió:@EMaDeLoC no he entendido una mierda, pero se empieza por algo aunque sea caro y ya luego se mirará como hacerlo más barato xD

Básicamente que se podría cambiar de cartucho igual que se cambiaba de CD en los FF de PSX, sin reiniciar la consola.

Eso sería genial, pero a efectos del 2018 la pregunta es si se podría hacer con un único flashcard. De todas formas yo creo que lo más fácil sería hacerlo del mismo modo que se hizo en PSX, meter un punto de guardado al terminar un cartucho, cambiar cartucho y cargar esa partida. Que en realidad parece que PSX tenía juegos muy grandes, pero a efectos prácticos lo que te vendían en un Final Fantasy eran tres o cuatro juegos que importaban partida del anterior.

radorn escribió:Respecto a la velocidad, mejor datos que especulaciones
https://www.hcs64.com/dma.html
hcs es un scener desde cuando la N64 era joven. Entre otras cosas, hizo un emulador de NES para N64.

Si mi vista de halcón no me falla (desde el movil es complicado ver una letra tan pequeña, y si haces zoom pierdes el renglón), lo que dice es que puedes transferir desde la cpu y el dma simultáneamente, y que transfiere 3.7 bytes por ciclo, pero no se si solo empleando el dma, o de forma conjunta.

La pregunta es, ¿de cuantos ciclos dispones para transferir?.

@Señor Ventura
Yo lo que he entendido es que la CPU puede hacerle al RCP una peticion de transferencia DMA desde A a B de longitud X, y hasta puede tener una segunda peticion a la espera mientras se hace la primera y que, mientras tanto, puede tambien acceder la CPU a lo que quiera. Dicho eso, las pruebas hechas ahi estan diseñadas para minimizar las lecturas hechas por la CPU para asi dejar via libre al RCP para poder medir la velocidad punta que pueda alcanzar. Parece logico pensar que las lecturas paralelas que añadas afectarán al rendimiento del DMA, pues, a fin de cuentas, ambas operaciones competirían por los mismos recursos y transitarian por los mismos buses. Ahora bien, aparte de la ventaja de dejar a la cpu, y su bus hacia el rcp, libre para otras cosas, y dado que la CPU solo puede acceder al resto del sistema a traves del RCP, esconveniebte que, cuando la tarea lo permita, se use DMA para mover datos, pues siempre va a ser mas rapido que hacerlo con la CPU, porque asi eliminas muchos pasos intermedios.

Los ciclos que se mencionan ahi parecen ser los de la cpu, que a una velocidad nominal de 93.75MHz, esos 3.7bytes por ciclo se convierten en 330.8 Megabytes por segundo. Pero tambien dice algo que no me queda claro sobre "la mitad" y/o "el doble" con respecto a los ciclos, asi que multiplica o divide eso por 2 y una de las 3 cifras es la correcta xDDDD O sea 165.4 - 330.8 - 661.6
En todo caso, si lo unico que la consola tuviese que hacer para arrancar un nivel fuese pasar los datos del cartucho a la ram por dma, y no tuvuiese que computar nada, ni hacer descompresion, etc... podría transferir 2 conkers por segundo, como minimo.

@radorn así que estaríamos hablando de un mínimo de 22 mega bits por frame, y un posible máximo de 88 mega bits por frame.

Menuda locura.

Cobarde

@Señor Ventura no, es que me empiezas a hacer gracia 0 en todo lo que sea debatir contigo sobre Nintendo.

@Señor Ventura @Sexy MotherFucker
No se de que va ese intercambio que estais teniendo, pero, por favor, tratad de evitar las flame-wars, que con el troll habitual obsesionado por la cuota de mercado, yo, por lo menos, ya tengo mas que suficiente.

@radorn volviendo al asunto del hilo, y hablando de Pilotwings 64, ¿alguien podría confirmar si la versión final lleva activado el T.L.F.M.M.I?. Es que recuerdo que en una de las múltiples entrevistas a Miyamoto durante el Space World presentación de la consola, le preguntaron que si ese juego usaba tal técnica, a lo que Shigeru respondió que Super Mario 64 sí empleaba esa técnica (se nota bastante de hecho), mientras que el resto de los juegos expuestos en vídeo no, pero que sería fácil aplicarlo durante las últimas etapas de desarrollo.

Lo pregunto porque me lo alquilé en la época, y juraría que cuando menos que algunos mip mappings se ven durante la partida.

radorn escribió:@Señor Ventura @Sexy MotherFucker
No se de que va ese intercambio que estais teniendo, pero, por favor, tratad de evitar las flame-wars, que con el troll habitual obsesionado por la cuota de mercado, yo, por lo menos, ya tengo mas que suficiente.

Yo tampoco lo se, solo he comentado el dato del enlace que has compartido mas atrás.

Es Tri-Linear Mip-Map Interpolation, no Tri-Linear Fucking Mip-Map Interpolation, @Sexy MotherFucker, no me seas tan intenso, que esto no es una peli de Tarantino ni tu eres Samuel L Jackson xDDDDDDDDDD

Y yo diría que si que usa TLMMI, vamos. Sería una entrevista durante la fase de desarrollo y aun no lo pusieron por aquello de ahorrar ciclos, supongo.

El TLMMI, como tantas otras tecnicas, no es un "modo" en que tengas que poner el RDP y se aplique en general, si no que cada comando de dibujo enviado al microcodigo tiene que decir que tecnicas aplicar y con que argumentos. Luego ya depende del motor del juego el como encajar eso en el motor grafico.
Habitualmente los efectos los aplican en los modelos 3D almacenados en el cartucho, pero tambien podrían ser modificados en tiempo real por la CPU, para hacer efectos dinamicos.

En fin, en resumiento (y repitiendo), yo si que veo claramente interpolacion trilinear de mipmaps en el PW64. Incluso en mi borroso video se ve como el suelo con textura de losas de piedra donde empieza el juego, en la distancia se vuelve super borroso, tipico del TLMMI excesivo de la epoca.

@radorn TLF, de filtrar/filtering, mip mapping interpolation. Así era como Nintendo lo publicitaba en las specs de la época.

Gracias por responder, porque necesito apoyo "biónico" para confirmarlo xD

Sexy MotherFucker escribió:@radorn TLF, de filtrar/filtering, mip mapping interpolation. Así era como Nintendo lo publicitaba en las specs de la época.

Gracias por responder, porque necesito apoyo "biónico" para confirmarlo xD

mmmm, sería Tri-Linear Filtered Mip-Map Interpolation, tiene sentido, pero nunca lo habia visto puesto asi.

AÑADO: De hecho esta es una de las cosas que me decepcionaban bastante de la N64. En las revistas, con todas aquellas imagenes de desarrollo, siempre tenian los juegos mejor aspecto que cuando salian. Pero de aquella no sabia por que.
Un aspecto del problema es que, durante el desarrollo se ahorraban muchas efectos e iban mas a pelo, pero para la version final aplicaban todo el maquillaje, parece ser que, principalmente, porque Nintendo lo exigia, o algo asi.
Luego tambien está la cuestion de que, el antialiasing de N64 se aplica en 2 partes. Una parte del antialiasing, en las aristas "interiores" (donde hay union "fisica" dentre los poligonos) la calcula el RDP y la dibuja directamente al framebuffer, y la segunda "capa", la hace el el VI, que es el componente del RCP que lee el framebuffer y escupe pixeles por el bus de video al DAC. Esta segunda capa se aplica sobre las aristas flotantes (como, por ejemplo, una farola delante de una pared) interpolando los pixeles adyacentes del framebuffer usando "pistas" que deja el RDP en el bit extra de la memoria de 9 bit. Porque la RDRAM de N64 es de 9 bit, y para datos normales el bit extra no se usa para nada, pero en datos de framebuffer se usa para esta segunda capa de AA) Lo cual queda un tanto cutre si no se modula bien, y es tambien responsable de esos puntitos raros que a veces se ven en bordes donde ocurre superposicion.

Total, que, tanto en los SDK oficiales como con cacharrejos como el AR/GS, hay funciones para hacer "screenshots" copiando directamente los datos del framebuffer antes de que el VI los pase al DAC, perdiendo esta segunda capa de filtrado, y, por tanto, ofreciendo un aspecto mas nitido, con pixeles mas acentuados.
Esto es mas o menos lo mismo que se consigue con el parcheado anti-AA que surgio hace un par de años o 3.

@radorn sobre todo en las specs del principio en las revistas, y de hecho yo en muchas N64 magazines, Hobbys, etc, lo he visto siempre escrito así en sus inicios. (Filtered). Luego ya en la publicidad posterior en qué comparaban las specs con PlayStation creo que omitieron la F, aunque tampoco me acuerdo muy bien.

En cualquier caso da igual, porque ambas entiendo son válidas.

Sexy MotherFucker escribió:@radorn volviendo al asunto del hilo, y hablando de Pilotwings 64, ¿alguien podría confirmar si la versión final lleva activado el T.L.F.M.M.I?. Es que recuerdo que en una de las múltiples entrevistas a Miyamoto durante el Space World presentación de la consola, le preguntaron que si ese juego usaba tal técnica, a lo que Shigeru respondió que Super Mario 64 sí empleaba esa técnica (se nota bastante de hecho), mientras que el resto de los juegos expuestos en vídeo no, pero que sería fácil aplicarlo durante las últimas etapas de desarrollo.

Lo pregunto porque me lo alquilé en la época, y juraría que cuando menos que algunos mip mappings se ven durante la partida.

Si te refieres al trilinear mipmapped intepolation (TLMMI),yo diría que es al revés el Pilotwings 64 lo lleva activado y el Super Mario 64 ,no.

Hace un tiempo @BMBx64 comento que se necesitaba poner en modo 2 cycles el RDP para hacer TLMMI,mi duda es si una vez activado este efecto, ¿usar 2 texturas que también necesita este modo repercutía mucho en el rendimiento?.

Salud.

@dirtymagic estoy 100% por seguro de que Miyamoto dijo que SM64 lo usaba sí o sí en las entrevistas de presentación del sistema, lo único que no tengo aquí la Hobby/SuperJuegos de turno para confirmarlo, pero sé lo que leí, es un recuerdo nítido. Quizás lo que no hace es tenerlo activado el 100% del tiempo, porque yo también percibo en ocasiones texturas en exceso "bailarinas" en los fondos de algunos suelos, del mismo estilo que las vistas en Shenmue, otro juego que no emplea Mip Mappings.

@radorn

En las revistas, con todas aquellas imagenes de desarrollo, siempre tenian los juegos mejor aspecto que cuando salian. Pero de aquella no sabia por que.

Esto a mí también me ocurría mucho, y con los años releyendo todos esos números me he dado cuenta de que era porque en muchos casos mostraban imágenes en altísima resolución de los juegos en estaciones de trabajo moviéndose en realidad 1 fps a cambio de ese lustre, con calidad RGBHV, o directamente pantallazos que no representaban a una Nintendo 64.

Por ejemplo del The Flying Dragon recuerdo que te colgaban imágenes así:



Pero todavía más bestias, como a 1024x768, y con un AA inmaculado. Y luego en los análisis veías esto:



Vídeo compuesto degradado, 240p, con unos filtros de "segunda", etc.

Sexy MotherFucker escribió:@dirtymagic estoy 100% por seguro de que Miyamoto dijo que SM64 lo usaba sí o sí en las entrevistas de presentación del sistema, lo único que no tengo aquí la Hobby/SuperJuegos de turno para confirmarlo, pero sé lo que leí, es un recuerdo nítido. Quizás lo que no hace es tenerlo activado el 100% del tiempo, porque yo también percibo en ocasiones texturas en exceso "bailarinas" en los fondos de algunos suelos, del mismo estilo que las vistas en Shenmue, otro juego que no emplea Mip Mappings.

Creo que se comento en este mismo hilo,que tenían pensado activarle TLMMI al SM64 y así lo decían en las entrevistas donde presentaban el juego,pero ni en las ferias lo tenia activado ,ni tampoco en el juego final.El por qué, ni idea,aunque para mi mejor,no me gusta nada como se ve ese filtrado en N64 ni en DC.

Salud.

@dirtymagic @Sexy MotherFucker
Como vuela esta conversacion de repente xD.

El Mario 64 en general no parece que use TLMMI, pero si que lo aplica en algunas partes. Por ejemplo, en el pasillo del primer nivel de Bowser, el cuadro de la princesa que se vuelve en Bowser a medida que te acercas es un efecto logrado mediante la aplicacion de TLMMI. Generan un set de mipmaps especial a partir de 2 texturas diferentes, en vez de derivar todos los mipmaps del set a partir de una unica textura, que es lo habitual.

Lo de usar 2 texturas no es como funciona el TLMMI en N64 habitualmente. El caso del cuadro de mario64 es un caso especial, e, incluso ahí, una vez generado el set, el rendimiento es el mismo, porque el modo en el funciona la tecnica es que la primera vez que se carga la textura, se generan ya todos los mipmaps y se cargan en la TMEM, y ya el RDP lo usa desde ahi. Lo de 2-cycle, hasta hoy no sabian muy bien que era, pero tiene sentido que algo llamado asi haga falta para hacer TLMMI, dado que la idea basica es interpolar entre 2 mipmaps de una textura, lo cual necesariamente ha de tomar al menos 2 pasos o ciclos. Lo que si que te confirmo es que no se usan "2 texturas" durante el renderizado para hacer TLMMI

Y si, totalmente de acuerdo. Generalmente el mipmapping de N64 se aplica con demasiada generosidad y sería preferible tener los pixeles a pelo, y, por lo que he visto, el de DC puede ser incluso peor, con una transicion muy brusca entre mipmaps, aparte de la borrosidad propia de la tecnica mal aplicada.

Sexy MotherFucker escribió:Esto a mí también me ocurría mucho, y con los años releyendo todos esos números me he dado cuenta de que era porque en muchos casos mostraban imágenes en altísima resolución de los juegos en estaciones de trabajo moviéndose en realidad 1 fps a cambio de ese lustre, con calidad RGBHV, o directamente pantallazos que no representaban a una Nintendo 64.

Por ejemplo del The Flying Dragon recuerdo que te colgaban imágenes así:

Había mucho prerender hecho en estacion grafica, pero con los años me di cuenta de ese truco rastrero, y no es que hoy en dia no hagan lo mismo xD. Recuerdo especialmente un juego de Rally, el Top Gear, creo, con unas imagenes brutales super "realistas" (o sea, muy detalladas) y me subia todo el hype a la punta del nabo, y luego nunca salia nada con ese aspecto.
Pero yo me refiero mas bien a cosas tipo los screenshots de Rare, que ahí si que sucedia lo que yo te digo. Era el juego, era la consola, pero sin la vaselina en el objetivo. Alguna vez tuvieron la audacia de renderizar a super resoluciones, pero habitualmente solo era una cuestion de diferencia de efectos.

Y cosas como esta es que era pura crueldad: "Doraemon 64"
PUEDO PROMETER Y PROMETO QUE ESTOS MARAVILLOSOS GRAFICOS...


...no tendrán nada que ver con lo que tendrá el juego final, pringaos!