Hilo de detalles y curiosidades de N64

radorn escribió:@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.

Con lo de 2 texturas me refiero al efecto por ejemplo del suelo de la campiña de los Zelda,o los reflejos lumínicos en las paredes del templo del agua del Zelda 64.

Salud.

dirtymagic escribió:Con lo de 2 texturas me refiero al efecto por ejemplo del suelo de la campiña de los Zelda,o los reflejos lumínicos en las paredes del templo del agua del Zelda 64.

Ah, pero eso me parece que no es un renderizado de dos texturas en un mismo poligono, si no que lo hacen superponiendo 2 poligonos, cada uno con su textura, con algun tipo de Z-bias para evitar el Z-fighting.
Quizá algun juego use alguna otra tecnica, pero lo habitual para usar dos texturas es usar dos poligonos.

¿Esto?:

No,usa multitextura.
Y el camión del blast corps es una textura animada,que depende de la posición del camión ,mueve la coordenada X-Y de las texturas de la animación.

Salud.

@Señor Ventura
Ah, el falso "bump-mapping" del Backlash de BlastCorps. Buen ejemplo.
Se que el programador que lo hizo explicó en alguna entrevista que todos los angulos estaban prerenderizados. Lo que no tengo claro es si hay interpolacion entre un angulo y el siguiente o simplemente cambia uno por otro cuando toca.

Y siguiendo lo del Top Gear Rally... https://www.unseen64.net/2008/04/04/top ... emo-proto/ criminal!

AÑADO: He cargado el juego y girando despacio el camion se ve claramente que la transicion entre los "angulos" es instantanea, sin ninguna interpolacion. Simplemente prerenderizaron muchos angulos para lograr un efecto suavizado en condiciones normales.

Recuerdo todo el revuelo por el bump-mapping en la 6ª generacion, y yo pensando, inocente e mi, "pero si eso ya lo hacia la N64 en el BlastCorps".

Acabo de comprobar que para el efecto del camión del Blast Corps cambia de una textura a otra sin transición. Lo que ocurre es que hay bastantes pasos y si el camión gira medianamente rápido no se nota. Un lujazo de efecto, se ve que les sobraba espacio para las texturas, pero luego dicen que hay un robot al que le falta un brazo porque no tenían espacio suficiente.

Añadiendo a lo que acertadamente habéis comentado del TLMMI y su uso en algunos juegos, es posible emplear mipmaps sin el filtrado trilinear y por eso se crean esas transiciones tan burras que se ven en algunos juegos ajenos a Nintendo 64 (vamos, yo no me sé ningún ejemplo).

Sogun escribió:Añadiendo a lo que acertadamente habéis comentado del TLMMI y su uso en algunos juegos, es posible emplear mipmaps sin el filtrado trilinear y por eso se crean esas transiciones tan burras que se ven en algunos juegos ajenos a Nintendo 64 (vamos, yo no me sé ningún ejemplo).

Pues aqui tienes uno bien sangrante

https://www.youtube.com/watch?v=eV8enCp651c&t=6m05s

BANDING OVERLOAD!

@radorn
Me refería a que no recuerdo ejemplos de banding en Nintendo 64. Sé que en otras plataformas hay bastantes casos.

Otra cosa sobre el TLMMI es que no se puede aplicar si la textura supera cierto tamaño, ya que los mipmaps ocupan espacio en la caché.

Sogun escribió:@radorn
Me refería a que no recuerdo ejemplos de banding en Nintendo 64. Sé que en otras plataformas hay bastantes casos.

Otra cosa sobre el TLMMI es que no se puede aplicar si la textura supera cierto tamaño, ya que los mipmaps ocupan espacio en la caché.

La verdad es que a mi tampoco me suena en N64 juegos que usen el TLMMI y se vean como el Unreal tournament de DC,pero la baja resolución hacía que todas las texturas que tuviesen lineas pareciesen que se estaban derritiendo,ya que como comentas,creo que la resolución máxima de la textura con el TLMMI activado era ¿128x48px en escala de grises? y estas al no ser cuadradas creo que tiene problemas al repetirse para llenar un polígono y ¿32x32px en 8 bits con paleta y la misma resolución pero en 16 bits?

Salud.

radorn escribió:He grabado el video del que hablaba en mi ultimo mensaje.

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

Muy interesantes las pruebas.
Mi opinión es que los errores de sonido no son producidos por no poder cargar los samples del cartucho. Creo seguir oyendo los samples de fondo entre el ruido. Me parece que el problema es que al no recibir el RCP respuesta del cartucho se generan microparones en el procesado del RCP y al estar todos sus elementos conectados internamente por el mismo bus, todos lo sufren, pero como el sonido por su frecuencia (44khz) es el más sensible a estos microparones es donde se produce la distorsión más evidente. La imagen no se ve afectada porque al ser 30Hz como mucho, los microparones no se perciben entre frame y frame. Dicho de otro modo, si los microparones son de 1 milisegundo, no lo notaras en la imagen porque es tan solo 0'03fps, mientras que en el sonido te has comido 44 muestras de sonido.

radorn escribió: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

Se refiere ahí a la velocidad de frecuencia de actualización del registro que usa para contar cada vez que una operación DMA finaliza. Esta velocidad es la mitad del reloj del CPU, es decir, 46'875MHz, y para compensar eso dice que "dobló el valor".
No sé si así el cálculo es correcto, la verdad, porque ver fracciones de byte por ciclo me chirría con mis conocimientos de informática. Además el RCP va a 2/3 de la velocidad del reloj y es con esa frecuencia con la que debería medirse la transferencia de datos. Y por último, 330MB/s me parece muy exagerado si tenemos en cuenta que por el 97 apareció el bus AGP para tarjetas de video a una velocidad inicial de 266MB/s. ¿Una consola para niños con mayor velocidad de transferencia que el bus desarrollado por la mismísima Intel?
No hay que olvidar que la velocidad estaría limitada por los chips ROM del cartucho, y estos a su vez se elegirían según las necesidades del juego. ¿Para qué instalar chips de 50MB/s en Super Mario64? Sería un desperdicio de ancho de banda y de dinero.
El manual de programación cita concretamente 5MB/s como mínimo y 50MB/s de pico. Siendo generosos, tal vez 100MB/s en los últimos cartuchos y más potentes, simplemente por usar chips más modernos.
En esta wiki se muestra el diagrama de señales del PI de la N64. En uno de los gráficos puede verse como transmite 256 words (512bytes) en 97 microsegundos, lo que equivale a justamente 5MB/s.
Siento quitaros la ilusión, pero la transferencia de datos desde el cartucho no puede ser de 330MB/s.

MIPMAPPING
Lo vendieron a bombo y platillo para la N64 pero para su resolución y su tamaño de texturas habitual, no se nota mucho la diferencia de estar o no estar. Menos aún en TV CRT y aún menos si la TV era de 19" o menos.
En cuanto a rendimiento, el manual dice:

To implement tri-linear MIP mapping, the RDP must be in two-cycle mode.

Así que meter mip-map trilineal te come el rendimiento del RDP.

Prerenders en las revistas
Yo no me di cuenta de que hubiera capturas de juegos con efectos o pulidas, dejando los cantosos prerenders aparte. La única revista que seguía por entonces era la Nintendo Acción y he desempolvado un número, el de marzo del 99 creo, por curiosidad para ver qué material usaban y son todo capturas cutres por video compuesto que dan dolor de cabeza.
Si estas capturas venían de estaciones SGi con más filtrado ya no lo sé. Desde luego no era el timo claro del Doraemon 64, pero es que en Japón es muy habitual los timos así.

@EMaDeLoC Alrededor de 700KB por frame ya si me parece factible, y además muy competente si de verdad es la cifra mínima.

Muy interesante el vídeo

@EMaDeLoC
El audio lo gestionan los juegos como puede ser con un hilo independiente que sigue leyendo de la fuente (aún cuando el programa principal ha recibido una excepción), si falla la fuente y no se comprueba el buffer al final debe llenarse de basura, si el tracker sigue activo es probable que las notas de la canción sigan funcionando y aplicándose sobre esa información.

Es una teoría vaya, por tamaño de hecho podrían cargarse los distintos samples en la RAM y hablaríamos de un problema distinto, la verdad es que aún no he reproducido música procesando desde el RSP pero el resultado debería ser el mismo, enviarlo a audio.

En la libogg que porté a N64 voy leyendo pequeños bloques de menos de 1 segundo, compruebo la integridad de lo que llega y de hecho tengo una función que inserta "silencio", los sectores tienen que cuadrar siempre, entre el cambio de canciones o cuando llega al final de la misma por ejemplo, es a grandes rasgos un buffer controlado manualmente.

En cuanto a la velocidad de transferencia del cartucho, con libdragon conseguía cifras muy bajas, libn64 es como poco unas 17 veces más rápida leyendo datos, pero esos datos tan elevados no los veo, creo que 5MB/s si que es más realista, a falta de tests.

Hey @BMBx64, se te echa de menos por aquí.
Para ahondar un poquito, los microparones lo dije porque el RCP debe recibir siempre una respuesta cuando hace una operación DMA, incluso un "ahora no puedo", y si no esta conectado el cartucho el bus interno del RCP se queda esperando una respuesta hasta que decide pasar. Y claro, todo lo que dependa del bus sufre de ese parón y lo más sensible es la unidad de procesamiento de audio.
Hay que pensar que el que el cartucho no responda a peticiones DMA no esta previsto, puesto que al desconectar el CIC el PIF para la consola. El trampeo de @radorn va más allá del nivel de "puteo" que los diseñadores preveían en una consola para críos.
Ciertamente dependerá de cada programa, pero creo que es más eficiente guardar en RAM datos grandes y de uso repetitivo como texturas, modelos, animaciones frecuentes y samples. Para el cartucho es mejor cosas más esporádicas y pequeñas, como animaciones cortas poco frecuentes. Todo dependerá del uso y necesidad, siendo el factor más importante los 5MB/s del cartucho frente a los 500MB/s de la RAM.

Pero vamos, si dices que no es así tu palabra va a misa.

@EMaDeLoC
Es una buena teoría también, aunque me preocupa qué le debe llegar al buffer, yo desde luego no accedería al cartucho para cargar samples de algún tracker, tengo compilada una librería de MOD, XM, etc y en ese caso va todo a RAM, sin streaming.

En unos 20 días o así ya estaré más libre para poder hacer nuevos aportes

@BMBx64 Genial se echa en falta. Por cierto la documentación sera solo ingles (lo mas seguro que si pero por preguntar, ya que toqueteare )

Lo del mipmapping (si no lo he mal leido) hace una superposicion de una textura encima de otra y creo que no consume mucho.Pero tiene que encajar tanto como la textura como el poligono, el project 64 tenia problemas de esto, no se si arreglaron

Intento hacerlo en el editor pero al no saber como funciona malo

@Sogun @dirtymagic
Pues fijate que a poco de tener el 64drive, hace años, se me dio por cargar todos los juegos al menos una vez y jugar un par de minutos, o algo asi, pero solo a una version de cada juego (excluyendo regiones y versiones de la ROM, con excepciones), y tengo cierto recuerdo de que en algun que otro juego, especialmente los "cutres" de de muchas terceras, en alguno vi efectos de banding bastante estridentes.
Por desgracia es un recuerdo vago y no podría decir que juego era, pero si, se notaba bastante. No tan brutal como en la comparativa esa del Unreal, pero si, podías ver claramente el limite, sin apenas suavizado.
Igual algun dia lo vuelvo a encontrar.

EMaDeLoC escribió:La única revista que seguía por entonces era la Nintendo Acción y he desempolvado un número, el de marzo del 99 creo, por curiosidad para ver qué material usaban y son todo capturas cutres por video compuesto que dan dolor de cabeza.

Para el 99, la consola ya estaba con medio pie en la tumba, muchas third parties ya habian abandonado el barco y ciertamente recuerdo que hubo un descenso en la calidad de las imagenes de las "previews" de juegos en desarrollo. Pero antes de eso, habia muchos ejemplos de lo que digo. Date un paseo por Unseen64 y rebusca juegos anteriores y ya verás como se ven imagenes muy nitidas. Sin ir mas lejos, GoldenEye, Perfect Dark, incluso los Zeldas, y otros tambien.
Yo insisto en que la mayoria de ellos salian de hardware N64, pero en esa etapa aplicaban menos filtrados y sacaban las imagenes directamente del framebuffer, en vez de capturar la salida analogica, ahorrandose la segunda capa de filtrado del VI y la degradacion analogica. Además de que, en muchos casos, tambien aprovechaban para renderizar a mayor resolucion que la que usaban en el producto final.

EMaDeLoC escribió:No sé si así el cálculo es correcto, la verdad, porque ver fracciones de byte por ciclo me chirría con mis conocimientos de informática. Además el RCP va a 2/3 de la velocidad del reloj y es con esa frecuencia con la que debería medirse la transferencia de datos.

La velocidad que interesa al programador es la de la CPU, que es donde se ejecuta el bucle principal de su programa, asi que lo que interesa a un programador es saber cuantos ciclos de CPU va a tardar en acabar la transferencia. Sabiendo que el RCP corre a una velocidad distinta a la CPU y que lo unico que la CPU puede saber del proceso de DMA es en que momento lo pidió y en que momento el RCP le dice "ya está", lo unico que puedes es hacer son muchas mediciones y luego aplicar tecnicas de estadistica, y con eso te va a salir decimales si o si xD. Fijate tambien en el grafico, que incluso haciendo varias peticiones de DMA de la misma longitud, no todas tardan lo mismo. Debe haber muchos factores coyunturales que influyen en el proceso. Pero a nivel estadistico, hay consistencia. En cada una de las longitudes hcs dice que le sale una media de 3.7, y concluye que hay una relacion lineal entre la longitud de la transferencia y el tiempo que tarda.

Supongo que se podría intentar hacer un programa en codigo del RSP que midiese la velocidad de transferencia de las distintas areas, al margen de la CPU, pero incluso si se pudiese hacer, no tendría mucha relevancia desde el punto de vista de la CPU.

Respecto a la velocidad final, yo me lavo las manos xD. Ni me hace ilusion ni me la deja de hacer que sean 165, 330, 660, o solo 5, la verdad. Son un hippie porrero y todo me resvala xDDDDDDDDD simplifica tioooo

EMaDeLoC escribió:Mi opinión es que los errores de sonido no son producidos por no poder cargar los samples del cartucho. Creo seguir oyendo los samples de fondo entre el ruido. Me parece que el problema es que al no recibir el RCP respuesta del cartucho se generan microparones en el procesado del RCP y al estar todos sus elementos conectados internamente por el mismo bus, todos lo sufren, pero como el sonido por su frecuencia (44khz) es el más sensible a estos microparones es donde se produce la distorsión más evidente. La imagen no se ve afectada porque al ser 30Hz como mucho, los microparones no se perciben entre frame y frame. Dicho de otro modo, si los microparones son de 1 milisegundo, no lo notaras en la imagen porque es tan solo 0'03fps, mientras que en el sonido te has comido 44 muestras de sonido.

Os puedo decir con confianza que la mayoria de juegos comerciales usan soundbanks (la terminologia oficial del SDK, funcionalmente equivalente a los SoundFonts habituales en PC) y estos son leidos por el RCP directamente desde la ROM, sin cargarlos en RAM. La rutina de reproduccion MIDI se carga en RAM, obviamente, y por lo que se ve, tambien las secuencias/partituras, pero el soundbank con los samples, normalmente codificados en vADPCM, se leen directamente desde el cartucho a medida que se reproduce la musica. Eso es lo habitual, y es algo que he visto confirmado por diferentes fuentes a lo largo de los años de leer cosillas tecnicas de la consola, incluida una charla por IRC con marshallh. Sumando eso y la experiencia practica de lo que se ve en mi video, tengo bastante confianza de que es como he dicho. Yo en este momento no tengo la documentacion del SDK a mano, pero, estoy bastante seguro de que tambien ahi se dice algo similar. Si lo encuentras, ponlo aqui tambien

Ahora un poco de especulacion: Viendo lo que está en el video, y otras pruebas que hice que no están incluidas ahi, creo que, si bien casi/todos los juegos leen los soundbanks directamente de la ROM, ahorrandose ocupar la RAM con ellos, no todos lo leen de la misma manera. En pruebas que hice fuera del video, por ejemplo una del Zelda OoT en la casa de link, despues de volver a meter el cartucho, algunos samples tardaron en volver a la normalidad. En el momento que introduje el cartucho, habia notas que estaban aun sonando dese antes de meterlo, y esas notas siguieron sonando corruptas hasta que se volvio a cargar el mismo sample para volverlo a tocar. Otros juegos, sin embargo, como el pilotwings, el sonido se arreglaba instantaneamente en el momento de meter el cartucho de nuevo, aunque estuviese esa nota a la mitad de su duracion.
Esto me sugiere que algunos juegos leen los samples a pelo desde el cartucho y otros hacen cache temporal durante la duracion de la nota. Pero casi/todos se abstienen de cargar el soundbank entero en RAM.

Respecto a tu teoria de los micro-parones, creo que estas totalmente desencaminado:
Lo que dices que te parecen los samples "entre el ruido" es simplemente ruido "tocado" al son de la partitura.
Aqui meto otra micro-especulacion <<< Si bien antes he dicho que el soundbank se queda en la ROM, esto es verdad a medias. El soundbank tiene a groso modo dos partes: Un "indice" donde estan las definiciones de los instrumentos, con su ADSR y los indices de donde están los samples, y despues el bloque de samples. La tabla/indice probablemente se cargue en RAM, pero los samples definitivamente se quean en la ROM y se leen desde ahi, con o sin el cacheado que mencioné antes. >>>
Te puedo asegurar que si escuchases el sonido en vivo no tendrías dudas de que no hay nada del sample original ahi. De hecho, incluso sin mi conector en T, puedes hacer algo similar con el truco de inclinar el cartucho, que basicamente consigue lo mismo, mantener las patillas del CIC conectadas pero cortar, al menos, buena parte de las pistas de datos, impidiendo, al menos en parte, la lectura de la ROM.

Tambien con respecto a lo del sonido te tengo que corregir, y ya te adelanto que en esto tambien tengo confirmacion de marshallh, que algo sabría habiendo hecho el UltraHDMI, que se conecta al bus digital de audio que sale del RCP.
La N64 no tiene un sample rate fijo. De hecho, solo algunos juegos de Konami usan un samplerate de 44.1Khz, e incluso este ni siquiera es exacto, si no que, en NTSC al menos, son 44095Hz.
Cada juego tiene un samplerate diferente, y ninguno es exacto con respecto a ningun estandard, especialmente gracias a las frecuencias de reloj que maneja la consola. Como ejercicio te sugiero bajarte los sets USF y reproducirlos con foobar2000 y su componente USF, y verás lo que te encuentras. Y si, los samplerates que salen de ahi son representativos de lo que hace la consola real. Si bien el bus de video de la consola tiene una frecuecnia fija, el de audio no, si no que el RCP puede sacar la frecuencia que quiera y el DAC de audio la acepta sin problemas, claro que la calidad de la conversion no es precisamente como para echar cohetes, con un folding brutal cuando el samplerate es bajo. Si puedes, prueba a grabar audio de la consola al PC, por analogico, y mira el resultado en un espectrometro, y verás el folding/mirroring que se produce donde acaba la banda real y se produce el reflejo en las frecuencias altas.

Otra cosa que me chirria con tu teoria de los microparones es que, si realmente sucediese eso, si afectaria a la imagen aunque el microparon sea inferior a un refresco de pantalla. Como minimo tendría que verse basura a mitad de la pantalla, pero yo diría que hasta se perdería la sincronizacion de la imagen, dado que es el RCP el que le señaliza en tiempo real al al DAC donde meter los pulsos de sincronizacion. Esto lo puedes ver en la documentacion del mod RGB analogico de Tim Worthington.
http://etim.net.au/n64rgb/ http://members.optusnet.com.au/eviltim/ ... 64rgb.html
Dado que una linea dura unos 64microsegundos, un microparon de esos que teorizas de 1 ms se cargaria varias lineas con sus respectivos pulsos de sincronizacion, y a saber si no cae tambien en un pulso vertical. En fin, que de ser cierto lo que teorizas, el video se iria a la mierda. Y daría igual si el RCP continuase donde lo dejó antes del paron o se adelantase al momento en que deberia estar si no hubiese parón. En ambos casos la sincronia y la estabilidad del bus de video se irían a tomar por saco xD.

BMBx64 escribió:El audio lo gestionan los juegos como puede ser con un hilo independiente que sigue leyendo de la fuente (aún cuando el programa principal ha recibido una excepción), si falla la fuente y no se comprueba el buffer al final debe llenarse de basura, si el tracker sigue activo es probable que las notas de la canción sigan funcionando y aplicándose sobre esa información.

Yo avogo tambien por la teoria de la "basura", No se si es que hay un buffer que se llene de ella o como pasa todo eso, pero no me cabe duda de que el juego trata de leer los samples de la ROM y obtiene basura. Mas allá de eso no se decir si esa basura se almacena en algun sitio despues de su obtencion inicial o se obtiene basura nueva con cada nota que el secuenciador intenta reproducir. Pero tiene un inconfundible aroma que me dice, sin lugar a dudas, que es basura

Flash-Original escribió:Lo del mipmapping (si no lo he mal leido) hace una superposicion de una textura encima de otra

Cuando un juego aplica mipmapping sobre un poligono, se derivan de la textura original versiones de resolucion reducida (la mitad en cada dimension, resultando en una version que ocupa una cuarta parte de la original). Cada una de estas versiones, incluida la original, se denominan mip-maps, y tienen que caber todas de una vez dentro de la cache de texturas o TMEM del RCP para que el proceso las pueda usar. En casos especiales, como el cuadro de mario 64, se pueden generar los mipmaps a partir de varias texturas diferentes (en este caso 2), pero una vez finalizada la conversion, se opera de la misma manera. Todo el set de mipmaps aplicado a un poligono tiene que caber en los 4K de la TMEM, incluido el indice de colores si usas texturas paletizadas.

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

En otro orden de cosas, y sin animo de desviar la conversacion actual, ciertas cosas que se han tocado me han recordado mi carpetilla de "investigaciones" de N64, donde almaceno diversas chorradas y datos que he sacado a lo largo de los años.
Aun no me he leido el hilo entero, asi que es posible que duplique algunas cosas de las que se han comentado ya. Pido disculpas por adelantado.

Empiezo con un hilo al que contribuí hace un tiempo en el foro de retroactive.be, la empresa de marshallh (64drive / UltraHDMI), donde se hablaba de juegos PAL a resolucion nativa. https://retroactive.be/forum/viewtopic.php?f=9&t=36
Resumiendo: Casi todos los juegos NTSC renderizan a una resolucion determinada y mapean 1:1 la resolucion vertical del framebuffer a las lineas de video NTSC correspondientes. Como es sabido, muchos juegos PAL, siguiendo la tradicion, se limitan a compensar la mayor resolucion vertical de PAL añadiendo barras negras arriba y abajo. Otras conversiones PAL con video a pantalla completa renderizan a un framebuffer de identicas dimensiones a la version NTSC del juego, y leugo el VI se encarga de escalar la imagen a la resolucion PAL. Esto suele introducir aun mas borrosidad de la que es habitual en N64.

Sin embargo, no todos los juegos encajan en este patron. Empiezo con lo mas interesante:

Confirmo personalmente, en contra de la creencia popular, que SI hay conversiones PAL con resolucion nativa y mapeado 1:1, pero yo solo he encontrado 4 y dudo mucho que haya mas, aunque no he probado todos los juegos PAL para poder asegurarlo con certeza:
GoldenEye 007, Perfect Dark, Diddy Kong Racing, y, para rematar, el prototipo de 40 Winks.
Estos 4 juegos en sus versiones PAL (o en el caso de 40 Winks, la unica version disponible, que es PAL) funcionan a 288p y mapean las lineas del framebuffer a lineas de video PAL a una ratio de 1:1. O sea, que es resolucion 288p real, sin reescalado.

Tengo algunas "pruebas fotograficas" para quien le interese, pero no cubren todos los juegos (aunque la comunidad de modding de GE y PD tiene esos dos bien cubiertos), pero cualquiera con un poco de ojo puede comprobar, especialmente con ayuda de una capturadora y un poco de inspeccion manual haciendo zoom sin resampleado.

Ademas de estas joyitas con 288p real, lo cierto es que el asunto de las resoluciones en N64 es muy curioso y hay todo tipo de variaciones salpicadas por ahi.

En GoldenEye, por ejemplo, a pesar de que todo el juego va a 240p y 288p en NTSC y PAL respectivamente, La introduccion con los logos y la galeria de personajes, y el menu principal son renderizados a un framebuffer de mucha mayor resolucion que el juego.

El primer juego de Goemon, la aventura 3D, es un caso bastante curioso tambien. La version USA, obviamente, va a 240p, mapeado 1:1 sin reescalado. La version PAL es a pantalla completa reescalando la resolucion original NTSC... Pero la version original Japonesa hace algo que solo he visto en algun que otro juego mas. El framebuffer está pensado para 240p, pero el modo de video de salida es 480i, y con interpolacion, produciendo un aspecto borroso totalmente innecesario. Para mi es un misterio por qué decidieron hacer algo asi.
La prueba del delito: Goemon videomode.zip

Otro caso interesante es Turok 2.
Como es sabido, este juego es compatible con el Expansion Pak y con el se puede activar un modo de alta resolucion en modo 480i o 576i. Sin embargo, ni la version PAL ni la version NTSC renderizan a un framebuffer de esas resoluciones. AMBAS VERSIONES del juego renderizan por debajo de la resolucion nativa de video y hacen reescalado. Esto es habitual en los juegos que hacen alta resolucion en modo entrelazado, tanto en PAL como NTSC. Para verlo hacen falta capturas de video, para ver como, a pesar de que en esos modos el juego no hace antialiasing ninguno, las lineas no son limpias, y cada cierta periodicidad hay patrones moire sutiles
El modo "Lo-Rez" del juego, tanto en su version NTSC como PAL, hace mapeado 1:1 de lineas, y en PAL, añade las infames barras negras.
Capturas por S-Video para demostracion: Turok2 videomode.zip

Dejo aqui unso archivos con imagenes, que creo que es mejor darlas asi para facilitar que cada uno las inspeccione con un editor o visualizador de imagenes y poder hacer zoom, activar y desactivar filtros, etc, que si los pongo en una galeria web, no es lo mismo.

El primero son dumps del framebuffer de N64 que hice con un action replay conectado al PC por puerto paralelo, en consola PAL y con juegos mayormente PAL, excepto el Extreme G 2, que es una copia NTSC que heredé con la coleccion de un amigo que ya no queria la consola y de alguna manera compro eso de segunda mano en un rastrillo o algo asi...
N64 framebuffer AR captures.7z
(NOTA: Las capturas del FB de Perfect Dark son de la version del juego sin EP, porque para hacer capturas hay que arrancar el juego con el "code generator", y este ocupa todo el EP, asi que el juego arranca como si no lo tuvieras. Aunque la version completa del juego tiene resolucion 288p real, la version reducida no, y va con barras negras)

El segundo son unas imagenes beta de GoldenEye, distribuidas por RARE en su momento, y que a mi me tienen todo el aspecto de ser dumps de framebuffer dadas las muchas aristas sin AA que se pueden ver en muchas de las imagenes. Como explique antes, las aristas "interiores" (las que conectan "fisicamente" con otro triangulo) generalmente las puede "AAizar" el RDP sin problema, pero las externas (las que son por superposicion, sin conectar con otro triangulo en la escena), mayormente las aplica AA (o no) cuando el VI las procesa junto con las pistas en el bit extra de la RDRAM.
Ademas de eso, viendo que la resolucion del framebuffer del juego final NTSC no son 240p completos y en las imagenes estas si, tengo que sospechar que haya reescalado final, aunque tambien podría no ser asi.
Para redondear la jugada, estan en JPEG, pero eso ya no depende de mi.
mundorare_ge_beta_ss

Añado tambien una lista que compilé hace un par de años de las frecuencias de sampleo de los USFs disponibles, para ilustrar lo que decia antes. Hay dos frecuencias muy populares, que intentan aproximar las frecuencias estandard 22.050 y 32.000, y otras dos que aproximan la frecuencia del CD, pero ninguna es exacta... y las demas son de su padre y de su madre.
Y repito la confirmacion que me dio marshallh en su momento: Estas frecuencias son las que corren por el bus que llega al DAC de audio, sin resampleo.


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

Perdon por el post gigantesco xD

Por cierto
¿alguien mas recuerda los nucleos de ferrita originales de los mandos, que venian con un tubo termoretráctil en vez de carcasa de plastico?
https://i.stack.imgur.com/nB5w9.jpg
https://cdn.instructables.com/FNL/436D/ ... .LARGE.jpg

¿Y que me decís de los jumper paks con etiqueta de papel en vez de inscripcion en relieve en el molde?
https://duckduckgo.com/?t=palemoon&q=n6 ... &ia=images

las cutres primeras versiones, oh yeah.

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

Una curiosidad mas surgida de buscar lo del jumper pak con etiqueta de papel.
aacabé viendo informacion sobre rdram > la pagina de wikipedia sobre Rambus dice algo sobre que la n64 usa una version temprana, llamada "base rdram" > se da un enlace a un post de 2004 en "the rare witch project" (ahora TheRWP) donde se explica que por arreglar rambus el problema de la latencia de rdram para limpiar su nombre, como resultado, las nuevas n64 que sacaron con lardram revisada ya no tenian la propiedad que permitia a Banjo Tooie dejar datos en RAM durante 10 segundos despues de apagar la consola (se quedó en 2 segundos) y que Banjo Kazooie los pudiese leer... lo que se conoce como la mitica funcion "stop'n'swop". Así que se supone que la funcion aun existe en BK, pero fue eliminada (o convertida en inaccesible) en BT porque Rare, Ninty o ambas no querian tener crios torpes metiendo y sacando cartuchos a toda velocidad y por la fuerza en la consola.
Yo nunca habia leido esta version tan detallada antes, asi que lo dejo aqui tambien.
https://www.therwp.com/forums/showthread.php?t=881

Hola,mirando esta web Texturas N64,me he encontrado que la textura más grande que cabe en la cache es 90px*90px*4bits pero me parece un numero rarisimo,pensaba que las texturas tenían que ser siempre potencia de 8,¿esto es así o se ha colado el tio de esa web?.

Salud.

@radorn ese mando y ese jumper pak aún los conservo de mi n64 comprada de lanzamiento con el mario 64. Hay alguna cosa mas que diferencie las primeras versiones a las demas?

dirtymagic escribió:Con lo de 2 texturas me refiero al efecto por ejemplo del suelo de la campiña de los Zelda,o los reflejos lumínicos en las paredes del templo del agua del Zelda 64.

radorn escribió:Ah, pero eso me parece que no es un renderizado de dos texturas en un mismo poligono, si no que lo hacen superponiendo 2 poligonos, cada uno con su textura, con algun tipo de Z-bias para evitar el Z-fighting.
Quizá algun juego use alguna otra tecnica, pero lo habitual para usar dos texturas es usar dos poligonos.

dirtymagic escribió:No,usa multitextura.

Estuve leyendo el hilo, y ya veo a que te referías. Parece que si se pueden hacer efectos de doble textura, pero hay juegos que realmente usan poligonos supuerpuestos para estas cosas, y Rareware es lo que solía hacer, especialmente los juegos con el motor "banjo" (BK, BT, DK64). Lo de los reflejos de agua en el Zelda me convence bastante la explicacion de los dos ciclos, pero de la superposicion de los dos patrones de hierba... no se yo... tengo la impresion de haber visto z-fighting entre las dos en ciertas condiciones extremas, aunque es posible que fuera en un emulador qe quizá emule la multitextura generando 2 triangulos superpuestos con alpha... no se.

Murdick escribió:Hay alguna cosa mas que diferencie las primeras versiones a las demas?

Pues no se. Aparte de revisiones menores del hardware, como retrazados de las PCBs, renovacion de los moldes y cosas asi... la verdad es que no se me ocurre. Desde luego, funcionalmente son identicos. No creo que haya ninguna diferencia practica.
Yo tambien tuve mando con termoretractil de ese, pero un dia se me cruzó la idea de que tenia que saber que habia debajo y lo rajé con un cutter... y me quede decepcionado, claro xD.
Tambien tenia jumper con etiqueta, pero no se donde está ahora.

Poco me faltó a mi tambien para tirar de cutter jej

Madre mía, menudo ladrillo @radorn, pero muy interesante todo.

radorn escribió:Os puedo decir con confianza que la mayoria de juegos comerciales usan soundbanks (la terminologia oficial del SDK, funcionalmente equivalente a los SoundFonts habituales en PC) y estos son leidos por el RCP directamente desde la ROM, sin cargarlos en RAM. La rutina de reproduccion MIDI se carga en RAM, obviamente, y por lo que se ve, tambien las secuencias/partituras, pero el soundbank con los samples, normalmente codificados en vADPCM, se leen directamente desde el cartucho a medida que se reproduce la musica.

La verdad que eso de cargar samples desde el ROM suena raro al principio, pero viendo los límites de velocidad de la RAM, la prioridad en alimentar de datos el RSP y el RDP y que por DMA puede ir del cartucho al AI de forma directa, es una forma de optimizar el uso y acceso de la RAM.

radorn escribió: En pruebas que hice fuera del video, por ejemplo una del Zelda OoT en la casa de link, despues de volver a meter el cartucho, algunos samples tardaron en volver a la normalidad. En el momento que introduje el cartucho, habia notas que estaban aun sonando dese antes de meterlo, y esas notas siguieron sonando corruptas hasta que se volvio a cargar el mismo sample para volverlo a tocar. Otros juegos, sin embargo, como el pilotwings, el sonido se arreglaba instantaneamente en el momento de meter el cartucho de nuevo, aunque estuviese esa nota a la mitad de su duracion.

Pues habría sido muy interesante tenerlas en video, pero no hace falta que maltrates otra vez la consola, me da un poco de yuyu.

radorn escribió:Respecto a tu teoria de los micro-parones, creo que estas totalmente desencaminado:
Lo que dices que te parecen los samples "entre el ruido" es simplemente ruido "tocado" al son de la partitura.
Aqui meto otra micro-especulacion <<< Si bien antes he dicho que el soundbank se queda en la ROM, esto es verdad a medias. El soundbank tiene a groso modo dos partes: Un "indice" donde estan las definiciones de los instrumentos, con su ADSR y los indices de donde están los samples, y despues el bloque de samples. La tabla/indice probablemente se cargue en RAM, pero los samples definitivamente se quean en la ROM y se leen desde ahi, con o sin el cacheado que mencioné antes. >>>
Te puedo asegurar que si escuchases el sonido en vivo no tendrías dudas de que no hay nada del sample original ahi. De hecho, incluso sin mi conector en T, puedes hacer algo similar con el truco de inclinar el cartucho, que basicamente consigue lo mismo, mantener las patillas del CIC conectadas pero cortar, al menos, buena parte de las pistas de datos, impidiendo, al menos en parte, la lectura de la ROM.

No me expliqué bien cuando dije lo de los microparones.
No me refería a que el RCP se quedara "parado" sino a que el bus interno del RCP (el que une todas las interfaces, RSP, RDP y RAM) se quedara ocupado más tiempo del debido tratando de cargar unos datos que no llegan, hasta que pasara un límite de tiempo. El RCP mientras recibe frecuencia de reloj no se para nunca, y el manual ya indica que todas sus unidades trabajan en paralelo. Eso significa que aunque una unidad se bloquee, por el ejemplo el PI, las demás seguirán funcionando siempre y cuando no dependan de la unidad bloqueada.
Por tanto, en vez de "microparones" debería haber hablado de "microesperas del bus interno"

radorn escribió:La N64 no tiene un sample rate fijo. De hecho, solo algunos juegos de Konami usan un samplerate de 44.1Khz, e incluso este ni siquiera es exacto, si no que, en NTSC al menos, son 44095Hz.

Hace nada lo he visto en el manual, la gama de frecuencias a las que puede funcionar son estas:

Aunque no pretendía decir que todos los juegos funcionases a 44'1KHz, ha venido bien para sacar otro poco más de información interna de la consola.
Otro detalle interesante es que el audio también va por frames, aunque estos son independientes del video. Puedes poner 60fps al audio y 30 al video, pero ya te avisa el manual que has de buscar un equilibrio pues esto influye en los accesos a buffers y sus tamaños. En el manual hablan de 10 buffers distintos, así que como que los dejamos para otro día...

En cuanto a mi teoría, tus explicaciones son más convincentes que la mía, especialmente si el sonido sigue roto aún después de volver a colocar el cartucho. Aunque habiendo framebuffers de audio, también podría ocurrir una combinación de ambos: los samples se corrompen y el retraso del DMA (mínimo, pero haylo) desincroniza los frames de audio.
Como no puedo aportar mucho más, pues nos quedamos con la corrupción de los samples.

radorn escribió:Otra cosa que me chirria con tu teoria de los microparones es que, si realmente sucediese eso, si afectaria a la imagen aunque el microparon sea inferior a un refresco de pantalla. Como minimo tendría que verse basura a mitad de la pantalla, pero yo diría que hasta se perdería la sincronizacion de la imagen, dado que es el RCP el que le señaliza en tiempo real al al DAC donde meter los pulsos de sincronizacion. Esto lo puedes ver en la documentacion del mod RGB analogico de Tim Worthington.
http://etim.net.au/n64rgb/ http://members.optusnet.com.au/eviltim/ ... 64rgb.html

Bueno, aparte de la aclaración anterior sobre el funcionamiento en paralelo, un apunte: no se vería basura en pantalla puesto que el VI, y en concreto el buffer de video, seguiría funcionando.
Fijate como en el diagrama de la segunda web que has puesto aparece una señal de reloj de 50MHz que une el RCP y el DAC. Esto sincroniza ambos para la información del pixel (de 21bits) que incluye las señales de sincronismos al acabar una línea y un frame.
Cuidado, no confundir el framebuffer con el buffer de video. El framebuffer es el que todos conocemos, cuando el RCP, RSP y CPU terminan de manipularlo, este se vuelca al buffer de video que es el que esta sincronizado con el DAC de video. Por tanto, aunque la consola se cuelgue, al estar el buffer de video sincronizado de forma independiente con el DAC, siempre tenemos imagen en la TV.
Un detalle que apoya esto es como los distintos framerates de los juegos y mods de overclocking de la consola no afectan a la imagen con tearing y cosas así. De hecho, creo que no hay pantallazos de glitches a mitad de frame cuando la consola se cuelga, pues el buffer de video se queda con el último frame bueno.
Así que incluso en microparón, el vídeo seguiría normal con el último frame cargado en el buffer de video.
"Pero EMaDeLoC, BMBx64 puso un gif con tearing".
Si, pero eso era un juego NTSC en consola PAL. Eso puede pasar si el juego fuerza a refrescar el framebuffer mientras se esta volcando al buffer de video. También si el juego esta sincronizando por un reloj distinto al que usa el VI para la señal de video.

dirtymagic escribió:Hola,mirando esta web Texturas N64,me he encontrado que la textura más grande que cabe en la cache es 90px*90px*4bits pero me parece un numero rarisimo,pensaba que las texturas tenían que ser siempre potencia de 8,¿esto es así o se ha colado el tio de esa web?.

Salud.

Pues tendría que comprobarlo pero me parece que se ha colado un poco.
Tengo entendido las texturas se van guardando en "tiras horizontales" de 64 bits, por lo que una textura de 1x1 a 4 bits en realidad está ocupando 1x16 píxeles (15 de los cuales son basura que puede verse si repetimos la textura varias veces en el mismo polígono), las texturas de 8 bits de 1x1 en realidad son de 1x8 (con 7 píxeles de basuera), etc.
Esto significa que estás condicionado en el tamaño horizontal de la textura dependiendo de su profundidad de color (hasta un máximo de 1024 píxeles), mientras que verticalmente puedes tener cualquier tamaño hasta 256 píxeles según he leído.

http://www.shootersforever.com/forums_message_boards/viewtopic.php?t=6802

Una textura de 90x90x4 (y en escala de grises) ocupa 4050 bits del total de los 4096 que permite la caché, por lo que parece posible. Pero si aplicamos lo anterior, la dimensión horizontal debería ser divisible entre 16 y no lo es. La textura se alargaría hasta 96x90 con píxeles basura y en ese caso terminaría ocupando 4320 bits que superarían la capacidad de la caché.
La textura cuadrada más grande que se podría conseguir sería de 80x80x4 en escala de grises. La textura más grande en general es de 128x64x4 en escala de grises y se pueden ver algunos ejemplos en Perfect Dark, como las montañas que limitan el Area 51 que está compuesta por varias de estas texturas.

@radorn
Sí que se pueden hacer efectos de doble textura en un mismo polígono y hay ejemplos en la hierba de los Zelda, los árboles de Surface en GoldenEye (y el suelo de Depot, aunque me parece que no funciona bien) y las columnas del mapa Rejilla de Perfect Dark. Si recuerdas Z-fighting en los Zelda seguramente sea de las texturas que hacen de caminos.

http://fgfc.ddns.net/PerfectGold/SetTile.htm

Los emuladores tienen muchos problemas con este efecto y normalmente descartan la segunda textura, dejando un aspecto un tanto desangelado. La hierba de los Zeldas se ve bien porque será un hack específico de los plugins gráficos igual que la transición del cuadro del Super Mario 64 que no sería posible sin el uso de mipmaps. El único plugin que realmente soporta estas características es el "reciente" (tiene ya unos años) GlideN64.

En mi mapa de Kakariko para el GoldenEye utilicé dos capas de polígonos para la hierba para ahorrarme dolores de cabeza y que se viera bien en emuladores. Además, de este modo podía alterar el tono de transparecia de la segunda textura. Como ahora tengo un parche específico para flashcarts y otro para emuladores intentaré recrear el efecto tal cual para el parche de consola a ver si gano un poco de rendimiento, aunque la funcionalidad está un poco rota en GoldenEye y no sé si funcionará.

EMaDeLoC escribió:La verdad que eso de cargar samples desde el ROM suena raro al principio, pero viendo los límites de velocidad de la RAM, la prioridad en alimentar de datos el RSP y el RDP y que por DMA puede ir del cartucho al AI de forma directa, es una forma de optimizar el uso y acceso de la RAM.

Pues si, para que ocupar la RAM cuando puedes leerlo directamente? Igual algun juego lo hace, por el motivo que sea, pero la practica habitual es dejarlo en la ROM.

EMaDeLoC escribió:Pues habría sido muy interesante tenerlas en video, pero no hace falta que maltrates otra vez la consola, me da un poco de yuyu.

Puedes hacer lo mismo inclinando el cartucho, y no te de tanta aprehension, que llevan haciendolo desde hace decadas ya. Tienes que levantar poco a poco un lado del cartucho,creo que el izquierdo. Quizá en las partidas SRAM o Flash haya algun peligro de que se pierdan datos, aunque me da que incluso las lineas /read y /write quedan desconectadas, asi que tampoco creo que pase eso.
Lo que consigue esto es trastocar el acceso a las lineas de datos pero dejar el CIC conectado. Lo que oirás será la consola reproduciendo la musica como si nada pero usando basura digital en lugar de los samples. Por eso te parecia oir la musica de fondo en mi video. Al fin y al cabo, si reproduces el mismo ruido a diferentes frecuencias, tu oido va a reconocer tonos igualmente.

EMaDeLoC escribió:Hace nada lo he visto en el manual, la gama de frecuencias a las que puede funcionar son estas:
SeleccionarCopiar
•AI - variable, 3000-368000hz on NTSC, 3050-376000 on PAL

JUASSSS para que luego digan esos audiofilos chalaos que la PS1 modelo SCPH-100x es lo mejor que hay.
NINTENDO 64, el nuevo reproductor de audio de super alta frecuencia para audiophools. Puede hacer los 96KHz 192KHz y casi casi toca los 384kHz !!!!!!!!!!!!!!
...
Claro que eso es lo que puede escupir el AI. El pobrecito DAC de audio no creo que de para tanto xD

EMaDeLoC escribió:"Pero EMaDeLoC, BMBx64 puso un gif con tearing".
Si, pero eso era un juego NTSC en consola PAL. Eso puede pasar si el juego fuerza a refrescar el framebuffer mientras se esta volcando al buffer de video. También si el juego esta sincronizando por un reloj distinto al que usa el VI para la señal de video.

Donde esta eso? Cuando empecé a usar flashcarts usaba la N64 PAL con ROMs NTSC, y no recuerdo haber visto tearing nunca, y eso que siempre estoy con este tipo de cosas en la cabeza, e incluso durante una partida normal suelo avistar extrañezas de estas.

HISTORIA PARALELA:
Luego me pasé a la consola NTSC con un Passport3, pero empecé a experimentar fallos en ciertos juegos, como, por ejemplo, que el Shiren se cuelga siempre durante la pantalla de presentacion del juego en cuanto intenta cargar la segunda escena, regalandome una pantalla llena de basura rosacea, y el Aidyn Chronicles tambien casca durante la presentacion, soltandome una pantalla de texto especificando un error indescifrable.
Así que llegó a ocurrirseme que mi consola NTSC estaba mal porque con la PAL todo iba bien, pero luego empecé a mirar al Passport3 con recelo y se me dio por probar lo mismo con la consola PAL, y efectivamente, causaba los mismos problemas.
Así que mi nueva teoria era que el passport3 era el culpable y que necesitaba sacarlo de la ecuacion. Así que probé a usar el truco de cargar un passport o un AR/GS, mantener reset pulsado con un papelito encajado en la rendija, sacar el cartucho de trucos y meter el que quería cargar (siempre que esté firmado para el mismo CIC que estés usando con el cartucho de trucos). Para mi sorpresa, aun así cascaba, creo.
Total, que todo se arregló cuando completé mi conector T

Tambien hay que decir que para poder usar el 64drive con una consola puesta en pre-nmi gracias a cartuchos como esos, es necesario tener una ROM ya cargada en su RAM y mantener la alimentacion electrica por USB, porque si bien el menu del 64drive puede cargarse perfectamente en una consola con el reset mantenido, lo que ya no funciona es cargar una ROM desde el. Asi que hay que cargarla primero (por menu o por USB, da eso da igual), sacarla de la consola si es que has cargado por menu, pero manteniendo el USB enchufado, meter el AR/GS y hacer todo el proceso, y una vez tengas la consola con un menu AR/GS con pre-nmi, metes el 64drive y le dices al menu que cargue el juego.
Bueno, estoy tocando demasiadas locuras de las mias que probablemente nadie mas haya tocado, y ahora mismo no tengo acceso a los materiales necesarios para demostrarlos, asi que mejor lo dejo ahi xDDDD
Algun día tendré que contar y documentar cómo arreglé mi AR/GS corrupto con un Passport3, un NEO Myth 64 (supongo que podría hacer lo mismocon el 64drive, aunque este es un poco susceptible a perder la ROM con lo de sacar y meter el cartucho), y un proceso absurdo de intercambios de cartuchos en caliente xD

las batallitas del abuelo cebolleta

Sogun escribió:@radorn
Sí que se pueden hacer efectos de doble textura en un mismo polígono (...)

Ya veo, ya. Yo habia leido eso muchas veces, pero, luego, al ver lo que hacian los Banjo's, con las multiples capas de poligonos con alpha, deduje que en realidad era así como se hacia realmente y que lo de la multitextura era un mito.

De todas formas, hacer multitextura ayuda al rendimiento o lo empeora? Lo digo porque, con multiples poligonos superpuestos, el juego puede optimizar el dibujado para cargar, idealmente, cada textura una sola vez, aplicarla en todas las partes de la pantalla que corresponda, y luego cargar las que tengan alpha y hacer lo mismo, contando con el blending para lograr el fundido. Pero, con multitextura, e igual me equivoco, el dibujado en dos ciclos parace indicar que hay que cargar en la TMEM la textura 1 y la textura 2 en pasos distintos PARA CADA TRIANGULO, y eso no parece muy saludable para el rendimiento. ¿no?
Claro que igual me equivoco y no funciona asi? Es que se cargan las dos texturas a la vez en la TMEM?
Si es así, entonces supongo que otros efectos quedan descartados, como el TLMMI, no?

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

Acabo de toparme con esto
https://assemblergames.com/threads/n64- ... ost-966477
Y yo que creia que mis montajes de cartuchos eran una locura...

Tambien me he encontrado esto que arroja algo mas de luz (o confusion) sobre el tema de la capacidad maxima de los cartuchos.
https://ultra64.ca/files/tools/DETAILED ... RY_MAP.txt

d2a1 = 1000000 = 16MB
d1a1 = 2000000 = 32MB
d2a2 = 8000000 = 128MB
d1a2 = FC00000 = 252MB
...
d1a3 = 60300000 = 1539MB ???

JUAS... chupate esa, CD de PS1!!!!!!

Por cierto que hay gente por ahi que, usando una N64 de los primeros modelos, que llevaban 2 chips RDRAM de 2MB, los ha reemplazado por 2 chips de 4MB sacados de expansion paks, y, sumado a el tercer chip en un expansion pak insertado en la ranura, tienen una N64 con 12MB de RAM. No se hasta donde puede llegar la cosa, pero parece que incluso se pueden poner 16MB, claro que ahi ya hay que hacer mucha soldadura y saber terminar el circuito RDRAM.
Hablando de esto mismo marshallh una vez me dijo que el controlador de memoria del RCP es bastante flexible, y en ese mismo documento se especifica lo siguiente:

El range0 es el limite imaginario de la RAM interna, el range1 es el EP, y lo demas, pues, hasta donde aguante la consola que le encadenes chips de RDRAM, me imagino xD
En total, el rango logico da para 63MB. No son 64 porque en el ultimo mega están los registros de la RDRAM
Publicidad engañosa? Deberian haberla llamado Nintendo 63? hmmm

radorn escribió:Puedes hacer lo mismo inclinando el cartucho, y no te de tanta aprehension, que llevan haciendolo desde hace decadas ya.

Me da cosilla...
Eso si, luego no tengo reparo en pillar una N64 francesa y soldarle los componentes RGB sin lupa ni nada, sacándome los ojos
Soy así de especial.

radorn escribió:

EMaDeLoC escribió:Hace nada lo he visto en el manual, la gama de frecuencias a las que puede funcionar son estas:
SeleccionarCopiar
•AI - variable, 3000-368000hz on NTSC, 3050-376000 on PAL

JUASSSS para que luego digan esos audiofilos chalaos que la PS1 modelo SCPH-100x es lo mejor que hay.
NINTENDO 64, el nuevo reproductor de audio de super alta frecuencia para audiophools. Puede hacer los 96KHz 192KHz y casi casi toca los 384kHz !!!!!!!!!!!!!!
...
Claro que eso es lo que puede escupir el AI. El pobrecito DAC de audio no creo que de para tanto xD

Igual la idea era sacar audio de 4 canales por sampleo interpolado con un DAC de los buenos, pero luego como que no...

radorn escribió:

EMaDeLoC escribió:"Pero EMaDeLoC, BMBx64 puso un gif con tearing".
Si, pero eso era un juego NTSC en consola PAL. Eso puede pasar si el juego fuerza a refrescar el framebuffer mientras se esta volcando al buffer de video. También si el juego esta sincronizando por un reloj distinto al que usa el VI para la señal de video.

Donde esta eso? Cuando empecé a usar flashcarts usaba la N64 PAL con ROMs NTSC, y no recuerdo haber visto tearing nunca, y eso que siempre estoy con este tipo de cosas en la cabeza, e incluso durante una partida normal suelo avistar extrañezas de estas.

Esta en este post.

radorn escribió:De todas formas, hacer multitextura ayuda al rendimiento o lo empeora?Lo digo porque, con multiples poligonos superpuestos, el juego puede optimizar el dibujado para cargar, idealmente, cada textura una sola vez, aplicarla en todas las partes de la pantalla que corresponda, y luego cargar las que tengan alpha y hacer lo mismo, contando con el blending para lograr el fundido. Pero, con multitextura, e igual me equivoco, el dibujado en dos ciclos parace indicar que hay que cargar en la TMEM la textura 1 y la textura 2 en pasos distintos PARA CADA TRIANGULO, y eso no parece muy saludable para el rendimiento. ¿no?

Lo empeora y mucho. Es tal y como dices y resumiendolo el RDP pasa dos veces por el mismo triángulo. Los polígonos por segundo pasan a ser la mitad de esta manera, así que hay que usarlo con cabeza y para cosas concretas. Aunque en el Zelda se puede ver que el resultado es espectacular (para la época).
Usar dos polígonos separados por alfa es mucho más eficiente, pero si no esta bien colocados te puedes encontrar con Z-fighting o con que queda muy cantoso.

radorn escribió:Tambien me he encontrado esto que arroja algo mas de luz (o confusion) sobre el tema de la capacidad maxima de los cartuchos.
https://ultra64.ca/files/tools/DETAILED ... RY_MAP.txt

0x0500 0000 to 0x05FF FFFF Cartridge Domain 2 Address 1
0x0600 0000 to 0x07FF FFFF Cartridge Domain 1 Address 1
0x0800 0000 to 0x0FFF FFFF Cartridge Domain 2 Address 2
0x1000 0000 to 0x1FBF FFFF Cartridge Domain 1 Address 2
...
0x1FD0 0000 to 0x7FFF FFFF Cartridge Domain 1 Address 3


d2a1 = 1000000 = 16MB
d1a1 = 2000000 = 32MB
d2a2 = 8000000 = 128MB
d1a2 = FC00000 = 252MB
...
d1a3 = 60300000 = 1539MB ???

JUAS... chupate esa, CD de PS1!!!!!!

Siento quitarte la ilusión, pero cada dominio de direcciones viene detallado:
Cartridge Domain 2 Address 1: 16MB, seguramente para los primeros cartuchos.
Cartridge Domain 1 Address 1: 32MB, "seems to be where the n64ddrive would be addressed", es decir, las direcciones para el 64DD y que no se confundan con las direcciones de los cartuchos.
Cartridge Domain 2 Address 2: 127MB, este no se especifica, pero podría tratarse del dominio para los cartuchos de más de 16MB. Ese podría ser el tamaño máximo real de un cartucho.
Cartridge Domain 1 Address 2: aquí no hay capacidad porque corresponde a la cabecera del ROM, registros, etc, aunque si es verdad que hay direcciones sin usar en la que quizá, solo quizá, se puedan almacenar datos.
Cartridge Domain 1 Address 3: 1.538MB, son direcciones tan distintas de las otras que posiblemente estén reservadas para otro periférico.

radorn escribió:Por cierto que hay gente por ahi que, usando una N64 de los primeros modelos, que llevaban 2 chips RDRAM de 2MB, los ha reemplazado por 2 chips de 4MB sacados de expansion paks, y, sumado a el tercer chip en un expansion pak insertado en la ranura, tienen una N64 con 12MB de RAM. No se hasta donde puede llegar la cosa, pero parece que incluso se pueden poner 16MB, claro que ahi ya hay que hacer mucha soldadura y saber terminar el circuito RDRAM.

Sustituir los dos chips de 2MB por 4MB lo he visto en mods de N64 portables, para ahorrar espacio sin sacrificiar el Expansion pak. Meter 12MB es interesante, pero totalmente inútil puesto que ningún juego esta preparado para ello y solo te servirá para fardar ante tus colegas modders de gastarte el dinero en cargarte un Expansion pak sin ningún sentido.
La implementación de RDRAM en un sistema es sencilla, por eso Silicon Grafics la incluyó en su diseño. El problema es la puñetera latencia que tiene, que es la que hace cojear a la consola.

radorn escribió:El range0 es el limite imaginario de la RAM interna, el range1 es el EP, y lo demas, pues, hasta donde aguante la consola que le encadenes chips de RDRAM, me imagino xD
En total, el rango logico da para 63MB. No son 64 porque en el ultimo mega están los registros de la RDRAM
Publicidad engañosa? Deberian haberla llamado Nintendo 63? hmmm

Ya sabes que el 64 viene por las instrucciones de 64bits del procesador. Ya sabes, esas que no se usan tanto...

Tengo entendido que el gran fallo de la N64 fue poner la misma memoria compartida para video, cpu y audio,
Y se aprovecho de esta forma muy poco los 100 mhz ya que habia mucho lag y atasco con el bus de datos,

¿no creéis que si hubiera tenido memoria independiente en Audio/video/CPU los juegos hubieran sido triplemente mejores en velocidad y calidad de graficos?

Saludos!!

EMaDeLoC escribió:Igual la idea era sacar audio de 4 canales por sampleo interpolado con un DAC de los buenos, pero luego como que no...

Juas. No se, con la orientacion low cost de la consola, no los veo yo pensando en audio cuadrafonico en ningun momento del desarrollo, y menos de aquella. Con Dolby Prologic sobraba para la epoca. Yo ni siquiera tenia eso... ni aun lo tengo hoy...
Ah, y no confundas intercalar e interpolar, que no es lo mismo

EMaDeLoC escribió:Esta en este post.

>>>

BMBx64 escribió: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.

En ese ejemplo, sin tener con que comparar, el tearing que haya facilmente se confunde con el propio efecto de distorsion por aire caliente que tiene esa animacion. Si te fijas mucho si se nota algo que PODRIA ser tearing, pero que igualmente podría ser parte del efecto.

En todo caso, si efectivamente es tearing, el culpable probablemente sea la TV usada en el ejemplo, que tiene toda la pinta de no ser CRT. Y es que, mientras las TVs CRT de antes se limitaban a proyectar la señal de video entrante linea a linea, "en tiempo real", con apenas unos microsegundos de retraso como maximo, las TVs nuevas tienen la mala costumbre de hacer pasar por todo tipo de procesos a la señal analogica entrante antes de ponerla en pantalla. Samplean, convierten, almacenan, escalan, transfieren al panel, y todo eso con el agravante de que, si las señales analogicas de las consolas ya suelen ser un poco, digamos que, "particulares" en condiciones normales, en este caso lo es aun mas.

El bus de video de N64 tiene un pixel clock fijo y diferente para cada tipo de consola (PAL, NTSC, MPAL). Cuando los juegos programan el VI (concretamente las librerias), la forma en que se define el "modo de video" es, para simplificar, que establece la longitud de la linea en pixels y la duracion de cada frame/field por el numero de lineas. Cuando se cumple cada uno de esos periodos, el VI da orden al DAC de video de que produzca un pulso de sincronizacion.
Todo el sistema (excepto la RDRAM, que, por lo que parece, corre a los mismos 250Mhz exactos en todas las regiones, no me preguntes por que) está sincronizado con el bus de video (RCP, CPU, PIF). Cada juego está programado con un modo de video con la "geometria" (pixels por linea, lineas por cuadro) adecuada para que, en conjuncion con el pixel clock de la maquina pretendida, se produzca una señal de video analogico con las frecuencias deseadas.
Tal como documenté anteriormente, la consola PAL tiene un bus de video mas rapido que la NTSC. Al correr un juego NTSC en la consola PAL, la longitud de linea que el juego NTSC especifica necesariamente va a durar menos tiempo al pasar por el bus de video de la consola PAL, produciendo lineas de menor duracion, y por tanto, mas lineas por segundo y mas cuadros por segundo, resultando en los ~61Hz de refresco vertical que BMBx64 observa en su prueba.
Haciendo a la inversa, corriendo un juego PAL en una consola NTSC, la "geometria" de video diseñada producir un refresco de 50Hz al salir por el bus de video PAL, acaba produciendo mas bien ~49Hz al salir por el bus de video NTSC.

ESPECU-RIOSIDADES:
Tecnicamente la N64 puede implementar multiregion mediante la deteccion de Os_Tv_Type o seleccion manual, o algun otro esquema. Y tampoco sería imposible ofrecer opcion 60Hz en los juegos PAL. No se en otros sistemas contemporaneos o la generacion posterior (antes de la era HDMI), pero lo que si que es cierto, es que en N64 hacer esto podría traer complicaciones, porque, con la diferencia de frecuencia del bus de video, si quisieran implementar correctamente 60Hz en consolas PAL o (por alguna extraña razon) 50Hz en la consola NTSC, esto requeriria no solo cambiar la configuracion del VI, si no, posiblemente, muchos mas aspectos del juego que van sincronizados tambien, complicando el proceso de conversion. Ya no solo tendrían que implementar los 50Hz, si no un nuevo modo de 60Hz ligeramente diferente al de NTSC.
Además, Nintendo no estaba por la labor, y en el propio SDK dice que la politica oficial de Nintendo es que una misma ROM no debe implementar modo PAL y modo NTSC, si no que debe hacerse cada uno por separado. MPAL es caso aparte, con la admonicion de que todo juego NTSC debe correr correctamente en la consola MPAL tambien. No se si esto requiere de hacer un modo de video MPAL tambien... si alguien lo sabe, que cante.

Claro que eso no impidió a algunos saltarse las normas...
Uno de los casos mas brutalmente cantosos en este sentido es Wetrix. Las ROMS USA y PAL solo se diferencian en el caracter de region de la cabecera de la ROM, E (de English) para USA y P (de PAL) para... bueno, para PAL/EUR. Al margen de eso, el resto de la ROM es exactamente identica bit por bit. Y, en otro alarde de desprecio por "the Nintenedo way" este byte es ademas el responsable de decirle a la ROM en que modo correr. Si el codigo de juego tiene la E, el juego corre a 60Hz, independientemente de la region de la consola o el spoofing que le hagas. Y si el codigo es P, pues 50Hz.

Otro caso interesante es Extreme G, y creo que el 2 tambien. Las ROMs son diferentes, pero corren a 50Hz o 60Hz segun el indicador de region de la consola (o el spoof que le hagas con el bootloader o menu de flashcart), E incluso la ROM NTSC despliega un modo 50Hz a pantalla completa (con escalado, por desgracia) si la corres con Os_Tv_Type 00/PAL

Hay muchas cosas raras y bizarras en N64 xDD

EMaDeLoC escribió:Siento quitarte la ilusión, pero cada dominio de direcciones viene detallado:

Mentira! Se que disfrutas quitandome el caramelo de la boca! xD
Ahora en serio. Ni tengo ni dejo de tener ilusion por ello. Simplemente me encontré eso y me dio la risa floja ver 1.5 gigas asignados a cartucho.

EMaDeLoC escribió:Cartridge Domain 2 Address 1: 16MB, seguramente para los primeros cartuchos.
Cartridge Domain 1 Address 1: 32MB, "seems to be where the n64ddrive would be addressed", es decir, las direcciones para el 64DD y que no se confundan con las direcciones de los cartuchos.
Cartridge Domain 2 Address 2: 127MB, este no se especifica, pero podría tratarse del dominio para los cartuchos de más de 16MB. Ese podría ser el tamaño máximo real de un cartucho.
Cartridge Domain 1 Address 2: aquí no hay capacidad porque corresponde a la cabecera del ROM, registros, etc, aunque si es verdad que hay direcciones sin usar en la que quizá, solo quizá, se puedan almacenar datos.
Cartridge Domain 1 Address 3: 1.538MB, son direcciones tan distintas de las otras que posiblemente estén reservadas para otro periférico.

Pues me temo que voy a tener que estar en desacuerdo, que es lo mio xD
Iba a empezar con mis explicaciones, pero luego me encontré esto y creo que va a ser mas directo empezar por aqui:
Sacado de la documentacion del 64drive

-ENABLE EXTERNDED ADDRESS MODE
Sets cartridge ROM emulation range
(0x1000 0000 - 0x1F7F FFFF) are mapped to SDRAM for a total of 240Mbyte SDRAM exposed to the N64
Sets CI BASE address to 0x1F80 0000
The default is DISABLED.

-DISABLE EXTENDED ADDRESS MODE
Resets cartridge ROM emulation range
(0x1000 0000 - 0x13FF FFFF) are mapped to SDRAM for a total of 64Mbyte SDRAM exposed to the N64
Resets CI BASE address to 0x1800 0000

As default, this mode is functionally identical on HW1 and HW2 units and is for backwards compatibility
with both earlier homebrew and some commercial games that expect to see unmapped space up high.

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

CI (CARTRIDGE INTERFACE)

The "CI" interface is a small range of memory in the upper area of the PI address space that contains
registers and some block memory associated with the 64drive hardware

Fijate donde empiezan esos rangos de direcciones. Eso es el Cartridge Domain 1 Address 2... El que tu dices que solo es para la cabecera de la rom y unos registros. La cabecera de la ROM está ahi porque tambien lo está el resto de la ROM! Ahi es donde lee la ROM del cartucho la N64, y donde los juegos esperan encontrar los datos.
El rango de los 16 MB no se para que estará pensado, pero los cartuchos normales no responden a nada ahi, si no en el D1A2.
El de la pagina esta dice que el de 32 podría ser para el 64DD. Eso cubre la boot ROM que tiene y todos los registros y buffers que necesite implementar. De ser así tambien confirmaría la conversacion anterior de que no parece probable que los discos se lean mediante direcciones de memoria, dado que no habría espacio suficiente para el disco de casi 64MB.
No se muy bien que será todo esto de los Domains, pero tanto el cartucho (252) como lo que aqui se identifica como 64DD (32) están en el Domain 1, y eso tiene sentido para mi, puesto que han de poder accederse al mismo tiempo. Se diría que lo del Domain es algo que ha de seleccionarse y que afecta de manera global al controlador de memoria. De ser así sospecho que ese rango de 32MB del 64DD tambien aloja los chips de guardado SRAM y FlashRAM de los cartuchos
El Domain 2, con su Address 1 de 16MB y el Address 2 de 128MB, no sé para que serán. Igual son alguna caracteristica especial para el hardware de desarrollo. Y ya el Domain 3 de 1.5 GB ni idea.
La cuestion es que, si uno puede poner la N64 a funcionar en esos "Domains", y el mapa de memoria de la consola escupe por el PI lo que la CPU escriba o lea en esas direcciones, siempre vas a poder construir un dispositivo que se conecte al PI y responda a esas peticiones.
Ahora bien, lo mas probable es que las librerias oficiales no permitan nada de eso. Además, quien sabe que como exactamente ha de ser configurado el sistema para acceder a eso.
Se que el PIF se encarga de inicializar la consola y escribir valores en los registros de la CPU y el RCP. Igual es el PIF el responsable de decir a la N64 como arrancar, incluido qué domain usar. Igual para acceder al D3 hay que sustituir el PIF por un microcontrolador custom.
O igual se puede configurar por software y solo hace falta arrancar primero desde el Domain1 y el software cargado desde ahi puede reconfigurar el sistema para activar el Domain3
Se, por ejemplo, que parte del proceso de arranque es que el PIF comprueba el CIC. Bien. No solo los cartuchos tienen CICs, tambien el 64DD tiene un CIC, uno diferente a los de los cartuchos. Igual el propio CIC da instrucciones al PIF acerca de de donde debe cargar. Esto tendría sentido si consideramos que la ROM del cartucho y el IPL ROM del 64DD no ocupan la misma direccion. "Alguien" tiene que decirle al PIF de donde cargar el primer bloque de datos de la ROM.

En fin, el tio de ese documento me parece fiable. Tiene un canal de YouTube donde hace demostraciones de programacion y enseña equipamiento oficial que tiene, y la verdad es que tiene un monton de cacharros de estos y parece que sabe lo que hace.

EMaDeLoC escribió:Meter 12MB es interesante, pero totalmente inútil puesto que ningún juego esta preparado para ello y solo te servirá para fardar ante tus colegas modders de gastarte el dinero en cargarte un Expansion pak sin ningún sentido.

Bueno, utilidad si puede tener. No una que tenga efecto inmediato, claro, pero, echandole curro, hay 2 cosas bastante obvias que se pueden hacer.
Primeramente, a los homebrewers 4 Megas extra no les amargan el dia. Y en segundo lugar, a los hackers tampoco, especialmente los que quieran hackear juegos que usen el expansion pak, pues el ActionReplay/Gameshark usa la RAM tanto para meter codigos en el espacio que calcule que puede estar libre, como usar el EP entero para el generador de codigos (que tambien se usa para el enlace por puerto paralelo con el PC.

@ziu La N64 tiene muchos fallos y recortes porque Ninty queria un producto relativamente "low cost" pero con potencia y trucos bajo la manga. No le salío tan bien como quería, por desgracia.
No estoy muy seguro de los detalles, pero aparte del problema de la latencia de la RDRAM, lo cual le quita mucha efectividad a esos 500MB/s de velocidad del bus. Si tienes que estar esperando la mitad del tiempo, pues... y claro, muchas cosas tenian que pasar por ahi
Si hubieran diseñado la consola con memorias dedicadas, si, habría aumentado el rendimiento, pero tambien el coste y tambien el fraccionamiento de los recursos. (por ejemplo, tener mucho espacio dispobible en la memoria de audio, pero no poder aprovecharla para texturas aunque tu memoria de video esté agotada).
Quizá un problema menor este ultimo caso, pero lo del coste si que es tal cual.

Alucino con todo lo que sabeis de la consola... es increible, no sé a qué os dedicais pero me gustaría saber algo...
¿Sacais todas esas conclusiones por algún tipo de manual técnico oficial de Nintendo y porque conoceis/trabajais en la materia? o es puro vicio/ansia de información consolera recopilada por internet?
Y lo más importante... ¿Estais programando alguna cosilla para la consola?
En serio, con todo esos conocimientos podrias hacer algo grande para la consola, es cuestión de coordinaros!

Y si no, al menos tenemos este hilo con todo tipo de apuntes para el que se atreva a desarrollar y probar algo.
Todo esto junto a la futura librería en la que está (o estaba?) colaborando BMBx64 espero de sus frutos y vayan saliendo cosas muy interesantes para la 64.

ziu escribió:Tengo entendido que el gran fallo de la N64 fue poner la misma memoria compartida para video, cpu y audio,
Y se aprovecho de esta forma muy poco los 100 mhz ya que habia mucho lag y atasco con el bus de datos,

¿no creéis que si hubiera tenido memoria independiente en Audio/video/CPU los juegos hubieran sido triplemente mejores en velocidad y calidad de graficos?

Saludos!!

Pues depende. Realmente el gran cuello de botella lo genera la propia subida en la calidad gráfica. La PSX tenía sus triángulos texturizados iluminados pero sin corrección de perspectiva ni filtrado. De ahí la N64 pasa a triángulos texturizados con corrección de perspectiva, precisión subpixel, iluminación por vértices, filtrado tri-lineal, anti-aliasing y Z-buffer. Empieza a contar todos los cálculos extra que hace la N64 en comparación con la PSX. Para colmo, la GPU de la PSX va a 53'2MHz mientras que el RCP de la N64 va a 62'5MHz. Y encima el RCP lleva audio, lleva el controlador DMA, periféricos... Vamos, ese procesador es una maravilla si lo piensas bien. Lo malo es que lo caparon de velocidad y de cache de texturas por temas de costes, pero a 100MHz y 8Kb de cache, habría barrido en potencia.

Es mi opinión. Si que es verdad que tiene otros problemas y limitaciones pero la gente se queda en "los cuellos de botella" sin valorar el salto de calidad gráfica que supuso. Hablamos que en el 96 aún no existía el anti-aliasing en PC y que una Voodoo te podía costar tanto como la consola, y sin contar el resto del PC. De hecho, si no fuera por la resolución y cierta diferencia de framerate, la N64 sería la única consola en superar en potencia gráfica al PC medio de entonces. Muy pocas o casi ninguna han llegado a eso.

radorn escribió:

-ENABLE EXTERNDED ADDRESS MODE
Sets cartridge ROM emulation range
(0x1000 0000 - 0x1F7F FFFF) are mapped to SDRAM for a total of 240Mbyte SDRAM exposed to the N64
Sets CI BASE address to 0x1F80 0000
The default is DISABLED.

-DISABLE EXTENDED ADDRESS MODE
Resets cartridge ROM emulation range
(0x1000 0000 - 0x13FF FFFF) are mapped to SDRAM for a total of 64Mbyte SDRAM exposed to the N64
Resets CI BASE address to 0x1800 0000

As default, this mode is functionally identical on HW1 and HW2 units and is for backwards compatibility
with both earlier homebrew and some commercial games that expect to see unmapped space up high.

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

CI (CARTRIDGE INTERFACE)

The "CI" interface is a small range of memory in the upper area of the PI address space that contains
registers and some block memory associated with the 64drive hardware

Fijate donde empiezan esos rangos de direcciones. Eso es el Cartridge Domain 1 Address 2... El que tu dices que solo es para la cabecera de la rom y unos registros. La cabecera de la ROM está ahi porque tambien lo está el resto de la ROM! Ahi es donde lee la ROM del cartucho la N64, y donde los juegos esperan encontrar los datos.
El rango de los 16 MB no se para que estará pensado, pero los cartuchos normales no responden a nada ahi, si no en el D1A2.

¿Cómo que no responden? Tienen una parte que podría ser SRAM. D2A1 podría ser la extensión que necesitan los cartuchos de 32MB cuando se quedan cortos con D1A2.

radorn escribió:El de la pagina esta dice que el de 32 podría ser para el 64DD. Eso cubre la boot ROM que tiene y todos los registros y buffers que necesite implementar. De ser así tambien confirmaría la conversacion anterior de que no parece probable que los discos se lean mediante direcciones de memoria, dado que no habría espacio suficiente para el disco de casi 64MB.

Echandole un ojo al manual de desarrollo del 64DD, menciona que los discos se dividen en cabezales (caras del disco), dentro de ahí en zonas y finalmente en bloques de tamaño variable. Los bloques se direccionan por LBA (Logical Block Address, direcciones de bloques lógicos) que van de 0 a 4291. El como transforma el LBA en direcciones de memoria, que es lo que hay en el slot, no lo especifica. Solo indica que se puede usar las librerías MFS, que trata la información como unidades de archivo, y Leo, que esta a más bajo nivel y que podría hacerlo por LBA.
Eso de los bloques ya lo mencioné anteriormente como sectores, solo que en vez de devolver una parte del sector, la 64DD devuelve todo un bloque entero de hasta 19720bytes.

radorn escribió:No se muy bien que será todo esto de los Domains, pero tanto el cartucho (252) como lo que aqui se identifica como 64DD (32) están en el Domain 1, y eso tiene sentido para mi, puesto que han de poder accederse al mismo tiempo.

Ojo, el manual especifica que el PI no puede hacer otras operaciones mientras accede al 64DD. Ni cartucho ni SRAM, ni nada parecido.

radorn escribió:De ser así sospecho que ese rango de 32MB del 64DD tambien aloja los chips de guardado SRAM y FlashRAM de los cartuchos

Hay direcciones específicas para SRAM de cartuchos que nada tienen que ver con el dominio del 64DD.

radorn escribió:La cuestion es que, si uno puede poner la N64 a funcionar en esos "Domains", y el mapa de memoria de la consola escupe por el PI lo que la CPU escriba o lea en esas direcciones, siempre vas a poder construir un dispositivo que se conecte al PI y responda a esas peticiones. Ahora bien, lo mas probable es que las librerias oficiales no permitan nada de eso. Además, quien sabe que como exactamente ha de ser configurado el sistema para acceder a eso.

No ha de configurarse nada, simplemente acceder a las direcciones correspondientes. El autor del archivo las separa en dominios y direcciones solo para poder aclarar las funciones de cada rango.

radorn escribió:Igual el propio CIC da instrucciones al PIF acerca de de donde debe cargar. Esto tendría sentido si consideramos que la ROM del cartucho y el IPL ROM del 64DD no ocupan la misma direccion. "Alguien" tiene que decirle al PIF de donde cargar el primer bloque de datos de la ROM.

Tú mismo lo dices y tú mismo te respondes, seguramente se haga así.

bluedark escribió:¿Sacais todas esas conclusiones por algún tipo de manual técnico oficial de Nintendo y porque conoceis/trabajais en la materia? o es puro vicio/ansia de información consolera recopilada por internet?

En mi caso, un poquito de lo primero y un mucho de lo segundo
Ayuda que se me suelen quedar estas cosas en la cabeza, y luego, cuando me pongo a escribir, a medida que discurro, frecuentemente, me van encajando las piezas.

Lo de convertir toda esa amalgama de "conocimientillos" en algo practico, me temo que, por ahora, se me escapa, pues no se programar.

@ziu @EMaDeLoC Con respecto a lo de los motivos del mal rendimiento de la consola, aparte de lo mencionado, a lo largo de los años he visto un monton de explicaciones, factores que contribuyen a ralentizar las cosas. La consola tiene una arquitectura... peculiar, y, por desgracia, un acercamiento simplista y directo está condenado a dar resultados pobres. Hay que currarselo.
Factores que he visto mencionar con desprecio muchas veces son la TMEM, la latencia de la RDRAM, la sobrecarga del RCP teniendo que ocuparse de todo (como bien indica EMaDeLoC), que usar el Z-buffer se te come el fillrate, y si, tambien que el modelo de memoria unificada daña mucho la paralelizacion de procesos, y junto con la latencia, pues todo se junta para fastidiar xD.
Hay que echarle mucha cabeza para sacar algo bueno del sistema y a pocas les merecia la pena el esfuerzo y el gasto.
Por cierto que la PS1 si que puede hacer iluminacion por vertices, y el juego de karts de Crash, por lo visto, implementa un z-buffer por software para el agua. Incluso leí algo de que ciertos juegos de lucha implementaron por software la correccion de perspectiva para que el suelo no se deformase.
Pero bueno, la N64 tenia esas dos por hardware, y tambien muchas otras que nunca tocaron la PS1 ni por software.

EMaDeLoC escribió:¿Cómo que no responden? Tienen una parte que podría ser SRAM. D2A1 podría ser la extensión que necesitan los cartuchos de 32MB cuando se quedan cortos con D1A2.

¿Como se van a "quedar cortos" con los 252MB del D1A2? ahí está la cabecera de la ROM y el resto de la ROM, y es el rango donde sabemos responde el 64drive, que no podría correr ROMs comerciales si no mapease su SDRAM interna al PI en ese rango.
Sin duda los cartuchos originales, y el resto de copiones y flashcarts (CD64, DrV64, Z64, NeoFLASH MYTH 64, EverDrive64 y cualquier otro que pueda haber habido alguna vez) hacen lo mismo, si no unos funcionarían y otros no.

¿Será que estás pensando en terminos de SNES, con su HiROM y LoROM, que, de cara a la CPU, eran rangos diferentes, pero de cara a la ROM era el mismo, pero con diferente velocidad de acceso? No creo que aqui suceda lo mismo.

Incluso si hiciera falta ajustar velocidades de acceso a ROM en la N64, eso, aparentemente, se hace con los 4 primeros bytes de la ROM, que configuran el BUS PI, segun me han dicho. Aunque no me preguntes como funciona exactamente.
Lo que digo es que no creo que en N64 se dé ese fenomeno de que diferentes rangos de direcciones logicas accedan al la misma memoria fisica, si es que es eso en lo que estabas pensando.

EMaDeLoC escribió:Echandole un ojo al manual de desarrollo del 64DD, menciona que los discos se dividen en cabezales (caras del disco), dentro de ahí en zonas y finalmente en bloques de tamaño variable.

Podrías darme un enlace a eso o pegar aqui el texto? Dice que las caras se accedan independientemente?

EMaDeLoC escribió:Ojo, el manual especifica que el PI no puede hacer otras operaciones mientras accede al 64DD. Ni cartucho ni SRAM, ni nada parecido.

Yo no decia que se pudiesen acceder en paralelo. Obviamente el bus solo puede hacer una cosa de cada vez.
A lo que me referia es que, viendo como está organizado el mapa de memoria, con los Domains estos, observo que el 64drive mapea sus 64-240MB para ROMs en el D1A2 de 252MB, y el documento este añade que el 64DD podría estár en D1A1 de 32MB.
Sabiendo que el IPL ROM del 64DD, la ROM arrancale que tiene el addon (que carga cuando enciendes la consola con 64DD y sin cartucho), son 4MB (32mbit), sobra mucho de esos 32MB, y teorizaba que quizá tambien las SRAM y FlashRAM de los cartuchos podrían responder en una region diferente de ese rango, y, así, localizaba todos los dispositivos conocidos que se conectan al PI dentro del Domain1, lo cual tiene cierto aspecto de tener sentido.
Claro que esta teoria mía de que hay que "configurar" la consola en un Domain concreto bien puede ser una tontería y que FlashRAM y SRAM estén en el Domain2, con sus D2A1 (16MB) y D2A2 (128MB). Por una parte parece mucho desperdicio sabiendo que SRAM son 32KB (o 96KB en un unico cartucho japones) y FlashRAM son 128KB, pero a fin de cuentas el mapa de memoria son 32bit, lo que da para 4GB, y de alguna forma hay que dividirlo, y frecuentemente hay razones practicas para hacer divisiones grandes y no estarse ahorrando hasta el ultimo bit encajandolo todo bien juntito. Para muestra esos misteriosos 1.5GB del Domain3, que no sabemos a donde se dirigen xD.
Sería la leche que ese Domain3 tambien se mapease al PI, que es lo que parece sugerir ese nombre de (Cartridge Domain). Si fuera así, solo sería cuestion de hacer un aparato que respondiese en ese rango (algo que CUALQUIERA puede hacer, verdad? xD). Pero, para recuperar nuestra antigua frase, "esto es todo especulativo" xD
Lo que yo veo claro en este momento es que la ROM del cartucho responde en el rango D1A2, que son 252MB.
De lo demás, la informacion que ha llegado a mis manos no parece concluyente.
De que el 64DD esté en D1A1 (32MB) solo dicen que "puede" o que "parece"... y sobre D2A1 (16MB) y D2A2 (128MB) dicen que "podría" ser para SRAM y FlashRAM... en fin... todo afirmaciones muy hipoteticas.
Podrían ir cada una por separado, o compartir con el rango que "podría" ser del 64DD, o a saber xD

Total que:
D1A2 (252MB) = ROM Cartucho
de lo demás... ya se verá xDDDDDDD

Gracias por las respuestas.

Supongo que si hubieran metido memoria caches a cada Procesador se hubiera minimzado la latencia , aunque costes se hubieran disparado un poco..
Yo alucino como le sacan todo el potencial con Mario 64 y luego se encuentran con todos los problemas en otro tipo de juegos. (en juegos de coches, tampoco entiendo como en 2d no llega a la calidad de Saturn o algunos juegos de PSX)
¿No estaba preparada para unas 2d avanzadas(ej. Neogeo, castllelvania SON, etc..)?

El expansion pack, aparte de aumentar la memoria,¿ hacia de Dual Channel o añadía otro bus de memoria para aumentar el acceso a la memoria?
¿Si hubieran sacado el expansion pack con una memoria muy rapida y poca latencia, se hubieran solucionado los problemas?
¿Si los programadores hubieran obviado usar todos estos nuevos elementos com z-buffer, antiasilasing etc.. ,
¿huiberan sacado los juegos mas parecidos a PSX, mejorando el rendimiento de la consola?

Gracias y Saludos!

@ziu
Bueno, los procesadores tienen sus cachés, como cualquier procesador minimamente moderno. Sin ellos, todo acceso a memoria tendría que ser a la RAM principal y se harían unos cuellos de botella del copon. La CPU tiene sus caches de datos e instrucciones, registros, y cosas tipicas de esas que tienen las CPUs, y el RCP, con sus diferentes sub componentes, tambien tiene caches varias.
La cuestion es que eso no soluciona la latencia de la RDRAM principal, que es muy acentuada.
Para que nos entendamos. La latencia y la velocidad de transferencia son cosas diferentes.
La RAM de la N64 es bastante rapida en cuestion de velocidad del bus y tasa de transferencia, con 500MB/s.
El problema es que tiene una latencia muy alta (no tengo numeros), y desde que la CPU o el RCP solicitan datos a la RDRAM, pasan muchos nanosegundos hasta que la RDRAM empieza a devolverlos.
Es como pedir comida a domicilio: El repartidor igual tarda solo 5 minutos desde el local a tu casa porque va corriendo como un loco con la moto, pero, desde que tu llamas hasta que el repartidor sale del local con tu pedido, pueden tardar de 10 a 25 minutos en preparar la comida.
No digo que los tiempos de este ejemplo sean representativos de la proporcion de latencia-transferencia de la N64. Simplemente pretendo ilustrar el proceso.

La N64 si puede hacer 2D avanzadas. El SDK contiene microcodigos de audio, de graficos 3D y tambien para graficos 2D. El programador debe cargar cada uno con las tareas correspondientes y luego cargar otro segun necesite. Todo eso para cada frame.
En el SDK, recuerdo que hablan del microcodigo 2D calificandolo de "like the Super Nintendo", pero no creo que sea para tomarselo literalmente, si no en un sentido general.
Como apenas hay juegos 2D en la plataforma, no sabría decirte con que comparar su "potencia".

No, el EP no hace dual channel. El bus de RDRAM parece ser mas bien una cadena. Los chips que añadas se van poniendo uno detras del anterior, aunque en esto no tengo muchos datos que darte. Para mas detalles y correcciones que venga otro xD
El problema de la velocidad, es que, primeramente, todos los modulos de RDRAM van a correr a la misma velocidad, incluso si alguno es mas rapido.
Hace unos dias enlacé aqui tambien un antiguo articulo de otro foro donde se especulaba acerca de la cancelación del stop'n'swop de los Banjo's. En el, se mencionaba que a la mitad de la vida de la N64, Rambus, que aparte de la N64 tambien queria que su nueva RAM triunfase en los PCs, sacó un diseño mejorado que solucionaba la altisima latencia, y parece que eso chips mejorados acabaron en los modelos posteriores de la N64 y en el Expansion Pak.
Incluso si esto es cierto, el problema es que si algun juego pretendia aprovecharse de eso, acabaría siendo incompatible con las N64s que ya tenia la gente, o, por lo menos, se vería una diferencia de rendimiento entre ambas. Cuando se trata de consolas, el tema de mejoras o expansiones es muy complicado. No es como en PC.

Igual, alguien que tenga varias versiones de la consola con los diferentes tipos de RAM podría hacer pruebas y ver si todo esto es verdad y afecta al rendimiento de alguna manera.

Probablemente las propias librerías de desarrollo ya trajesen codigo que se encargaba de administrar las lecturas a la RAM y vigilar que no se hiciesen mas peticiones que las que la RDRAM podía satisfacer, o los propios desarrolladores se verían obligados a no exceder esos limites para no causar inestabilidad. Programar para una consola, incluso con librerias, es muy diferente que programar para PC, con un SO que gestiona todo el hardware y ofrece interfaces API de alto nivel al software, si no que es una interaccion mucho mas directa con el hardware, cosa que es posible porque se espera que este hardware sea siempre igual en todas las consolas, no como en PC, donde te puedes encontrar todo tipo de combinaciones de CPU, RAM, chipset, graficos, sonido, cada uno con drivers de su padre y de su madre...

Hipoteticamente, supongo que sería posible que, doblando esfuerzos, tiempo y coste, Nintendo hubiese sacado unas librerías con la funcion de medir la latencia de la RAM (o igual leer la ID del chip, si es que tienen algo asi) y así saber que latencia esperar de la RAM, y, de esa manera funcionar a un modo de mayor rendimiento en los modelos con la RAM nueva. Tambien podrían implementar esta funcion los programadores de cada juego y tener practicamente 2 versiones del motor del juego dentro de una misma ROM.
Pero, por muy posible que pueda ser esto, y lo interesante que sería para gente como la que visita este hilo, no creo que fuese una buena politica a nivel comercial. Solo conseguiria aumentar costes y enfadar a los usuarios de las versiones antiguas.

Respecto a lo de la aplicacion indiscriminada de las tecnicas novedosas de la N64... Pues si, supongo que el rendimiento hubiese mejorado, y habría disminuido la borrosidad, y algunas ventajas mas. Claro que el almacenamiento limitado de los cartuchos seguiría siendo un problema.

radorn escribió:

EMaDeLoC escribió:¿Cómo que no responden? Tienen una parte que podría ser SRAM. D2A1 podría ser la extensión que necesitan los cartuchos de 32MB cuando se quedan cortos con D1A2.

¿Como se van a "quedar cortos" con los 252MB del D1A2? ahí está la cabecera de la ROM y el resto de la ROM, y es el rango donde sabemos responde el 64drive, que no podría correr ROMs comerciales si no mapease su SDRAM interna al PI en ese rango.
Sin duda los cartuchos originales, y el resto de copiones y flashcarts (CD64, DrV64, Z64, NeoFLASH MYTH 64, EverDrive64 y cualquier otro que pueda haber habido alguna vez) hacen lo mismo, si no unos funcionarían y otros no.

Pero tú estas asumiendo que ese rango de 252MB (en realidad llega a 243MB) se puede usar completamente porque el 64drive los tiene, pero en ese documento donde se listan las partes de D1A2 hay bastantes partes que se indican como "unused" de gran capacidad:

Cada uno es de 111MB y 115MB respectivamente, 226MB en total.
La parte documentada que sí se usa:

Que suma 16MB aprox. (se cuelan unos KB que seran para cabecera, EEPROM, SRAM, etc) y sumando con la parte unused nos dan 243MB.

Que esos 226MB esten documentados como unused no significa que se puedan utilizar sin más. Dentro del rango del dominio sobran muchas direcciones y posiblemente por comodidad y claridad para la programación den saltos dentro de esas direcciones para diferenciar aún más un dato de otro. Por ejemplo, tienes esto:


Donde hay 8 bytes perdidos sin motivo alguno aparte de que el "Image name" empiece en 0x1000 0020, que es una dirección clara y fácil y bien separada a nivel de bits, que en 0x1000 0018 que no es tanto ni una cosa ni otra.
Otro motivo puede ser una cuestión de diseño del hardware, ya que según vayan destinadas unas direcciones necesiten alguna ayuda. Por ejemplo como el expansión pak pasa por un conector y puede tener una impedancia extra, el hardware necesite darle un empujón a las direcciones correspondientes para superar ese extra (no tengo ni idea de si realmente hace eso, pero es un ejemplo a nivel de consola para que se entienda lo que digo). Otro ejemplo, este real, es que si al 64DD se accede por bloques, sobran buena parte de los 32MB de direcciones del dominio. Cuanto mayor sea el rango de direcciones para diferenciarlo, más fácil es de implementar todo, tanto en software como en hardware.
Encima para rematar las direcciones lógicas (software) no tienen porqué ser iguales a las físicas(hardware). En la N64 la dirección virtual 0x80000000 que usa la CPU corresponde a la dirección física 0x0000000, que es la dirección del cartucho ROM. Y efectivamente, por si no fuera bastante lío, no coincide con la D1A2 que estamos discutiendo.
¿Que luego esos 226MB Unused se puedan usar realmente? Pues ya veremos. Si Marshall los ha puesto en su 64drive supongo que será porque ha creado una ROM y comprobado que accede, o directamente nos estaría timando...
De todas formas un detalle que no se puede escapar es lo que dice un manual de desarrollo de la consola del año 99 que los Game pak son de 32MB máximo y los discos de 64'45MB. Pero luego en el mismo manual te cascan un mapa de direcciones de memoria física donde el 64DD tiene 47MB y el cartucho 252MB de rango...
Total, ¿que cual es la capacidad máxima del cartucho...? Pues por los mapeados de dominios, 32MB. ¿Y esos cartuchos con 64MB? He visto fotos de la placa del Conker y el RE2 en las que tienen dos chips de 32MB, y entonces usarían el sistema de bancos de memoria (que he mencionado unas cuantas veces) para pasar de un chip a otro. Ahora bien, no cierro la posibilidad de que se pueda forzar la consola a acceder a esos rangos unused y acceder a un total de 243MB, pero eso sin un respaldo oficial ni pruebas contundentes, puede que en realidad la consola te diga o te diga

radorn escribió:

EMaDeLoC escribió:Echandole un ojo al manual de desarrollo del 64DD, menciona que los discos se dividen en cabezales (caras del disco), dentro de ahí en zonas y finalmente en bloques de tamaño variable.

Podrías darme un enlace a eso o pegar aqui el texto? Dice que las caras se accedan independientemente?

Este es el manual introductorio, incluye el 64DD y las especificaciones de los discos.
Este es el manual de programación.

radorn escribió:

EMaDeLoC escribió:Ojo, el manual especifica que el PI no puede hacer otras operaciones mientras accede al 64DD. Ni cartucho ni SRAM, ni nada parecido.

Yo no decia que se pudiesen acceder en paralelo. Obviamente el bus solo puede hacer una cosa de cada vez.

No, lo que especifica es que el PI no puede hacer otras tareas hasta acabar la petición al 64DD. Por ejemplo, no puede mientras están cargando datos del disco, atender una petición de SRAM. Menciona expresamente que los accesos al disco se hagan por monohilo (singlethread) para evitar llamadas al PI en mitad de la operación.

ziu escribió:¿No estaba preparada para unas 2d avanzadas(ej. Neogeo, castllelvania SON, etc..)?

Por el principio del hilo BMBx64 hizo pruebas 2D en la consola y salían datos impresionantes. Simplemente entre la moda 3D y Nintendo poniéndole mala cara al desarrollador que sacara 2D en su flamante consola 3D, sacaron apenas un puñado de juegos.

ziu escribió:¿Si los programadores hubieran obviado usar todos estos nuevos elementos com z-buffer, antiasilasing etc.. ,
¿huiberan sacado los juegos mas parecidos a PSX, mejorando el rendimiento de la consola?

Primero de todo, Nintendo ni de coña les habría dejado. Se dejó una pasta de las gordas promocionando todos esos avances gráficos y no hubiera permitido nunca un juego que se pareciera a la competencia, hubiese sido un buen ridículo.
En cuanto a la mejora de rendimiento, pues tal vez la mejora fuese minúscula. Al ser la caché de texturas pequeña, las llamadas a la RAM son constantes y ya sabemos que ahí hay cuello de botella. Desactivar los efectos haría que el RCP fuese más rápido, pero al llegar al límite de velocidad de la RAM, no pasaría de allí. Seguramente los juegos más avanzados de la consola ya tengan el equilibrio justo entre variedad de texturas, velocidad límite del RCP y velocidad límite de la RAM, y desactivar los efectos no produzca tanta mejora como se suponga.

Me uno a la pregunta del usuario anterior que le habéis contestado basicamente que N64 es más mejor mucho mejor que PSX. Pero la pregunta no es esa sino si la N64 que conocemos sería mucho mejor de haber salido con la RAM no unificada como PSX. Yo he leído por ahí que uno de los problemas de PSX es que se quedó corta de RAM muy rápidamente (de hecho sale al mercado con menos que la propia SS), pero que pudo paliar esta carencia gracias a que estaba dividida en partes dedicadas exclusivamente a cada parte de la máquina mientras que N64 tenía que hacer mil accesos uno a uno para cada cosa que quisiera cargar desde la RAM por estar unificada ¿Esto es así o no?

Que la CPU de N64 tiene tres veces más mhz que la de PSX o la GPU un 20% más de mhz nadie lo discute, de hecho se puede ver en los datos técnicos de cada máquina, pero el diseño y como se reparten las cosas es lo realmente interesante y complicado de entender. Y más de una vez se ha visto que menos es más cuando el diseño es mejor (360, GC, etc), en en análisis de las tripas de Saturn se ve que tiene cosas muy muy burras para esa época y sobre el papel mucho más potentes que PSX, pero cuando se ve como están instaladas empiezan los problemas por culpa del bus elegido de 16bits o que la expansión de ram es la última en la cola de prioridades a la hora de usar el bus de datos, etc.

Es que he leído muchas veces que la RAM unificada de N64 (y en general) fue un gran handicap y ahora lo ha preguntado un usuario y la respuesta me da a entender que no que da igual unificada o dedicada.

Bueno @Calculinho ya que te pasas por aquí, el manual del desarrollador del 64DD confirma que podía haber juegos multidisco. Final Fantasy VII multidisco confirmed!

En cuanto a la cuestión de la memoria unificada o dedicada... es que depende del sistema
A ver, cada caso tendrá sus ventajas e inconvenientes. Para el caso de la N64, al ser el RCP el encargado de casi todo e incluir su controlador de memoria, la memoria unificada podía ser la mejor opción, pues si hubiese una memoria para cada apartado, el chip tardaría mucho en obtener la información de cada memoria.
Luego esta la flexibilidad que han comentado antes. La PSX tenía 1MB de memoria de video, así que si hacia falta más había que usar la memoria de la CPU, pasando los datos... Lento y dificultoso. En la N64 asignabas más y punto.
Si que como desventaja esta el cuello de botella, pero la RAM de la N64 llegaba hasta 500MB/s y con esas velocidades se compensa, pero la alta latencia (640ns) se te comía esa ventaja.
Pero al final los programadores encontraron una forma de optimizar los accesos a RAM haciendo accesos a ROM, como hemos hablado antes con lo de quitar el cartucho a mitad de juego. El ROM no va muy rápido, pero si lo suficiente para cargar pequeños samples, animaciones o datos, liberando así accesos y ancho de banda a la memoria.
El problema realmente gordo de la N64 es que la CPU tenía que pedirle todos los accesos de memoria al RCP, y eso le lastraba mucho pues su cache es ridícula (2KB de instrucciones y 1KB de datos) y tenía que solicitar continuamente accesos para cargar código o procesar datos del juego.
En resumen, y según lo veo yo, la memoria unficada tiene sus pros y sus contras, pero en la N64 no son unos contras tan graves por el RCP. Si hubiese tenido un diseño de procesadores y memoria como la PSX quizá los resultados habrían sido algo mejores, pero el coste de fabricación habría sido muchísmo más alto. Pero no te quedes con que la memoria unificada fue lo que más la lastró, es la suma de varias cosas donde esta el problema.

@EMaDeLoC anda, eso del multidisco está muy bien. Se sabe si se podría usar esa función desde un flashcard? A fin de cuenta los juegos de 64DD los carga casi todos (a mi las betas de juegos que luego migraron a GC no me van xD)

Gracias por el resto de explicación, en PSX se nota un huevo que no hay RAM en juegos 3D abiertos. Estoy jugando ahora el Bugs&Taz La Espiral del Tiempo que es un juegazo con varios mundos abiertos a explorar resolviendo puzzles, eliminando enemigos y encontrando coleccionables. Tiene un rollo muy parecido al Banjo&Tooie aunque controlando dos personajes al mismo tiempo como Resident Zero. El caso es que para PSX luce genial y va muy bien, pero las estructuras de lejos las muestra como polígonos planos y las va texturizando según te vas acercando, de cerca o en fases cerradas luce genial y no se aprecia eso; pero en mapa abierto se nota y supongo que es por la falta de RAM para tener cargadas todas las texturas no?

Calculinho escribió:@EMaDeLoC anda, eso del multidisco está muy bien. Se sabe si se podría usar esa función desde un flashcard? A fin de cuenta los juegos de 64DD los carga casi todos (a mi las betas de juegos que luego migraron a GC no me van xD)

Bueno, primero tendrán que desarrollar juegos multidisco, ¿no?
Como no hay ningún juego así (a no ser que los Mario Artist tengan esa función, pero creo que no) pues creo que no se sabe como funciona exactamente. Por lo que he leído, los discos tienen un identificador y el juego se encargaría de leerla para continuar o pedir que se inserte el disco correcto. Como no se usaría el botón reset, no sé como se podría seleccionar una nueva rom de disco. Vamos, que igual no se puede, con las flashcarts actuales.
Los juegos de 64DD están parcheados para funcionar el flashcarts, así que no tengas esperanzas por esa parte.

Calculinho escribió:Gracias por el resto de explicación, en PSX se nota un huevo que no hay RAM en juegos 3D abiertos. Estoy jugando ahora el Bugs&Taz La Espiral del Tiempo que es un juegazo con varios mundos abiertos a explorar resolviendo puzzles, eliminando enemigos y encontrando coleccionables. Tiene un rollo muy parecido al Banjo&Tooie aunque controlando dos personajes al mismo tiempo como Resident Zero. El caso es que para PSX luce genial y va muy bien, pero las estructuras de lejos las muestra como polígonos planos y las va texturizando según te vas acercando, de cerca o en fases cerradas luce genial y no se aprecia eso; pero en mapa abierto se nota y supongo que es por la falta de RAM para tener cargadas todas las texturas no?

Pues no tengo mucha idea de PSX, pero igual es para ahorrar fillrate dibujando texturas. A fin de cuentas el escenario ya esta cargado en memoria. Si tuviera que dibujar tantos texels de polígonos lejanos habría bajada de framerate, y además sin filtrado se verian pegotes y moaré y cosas raras. Sin texturas a lo lejos se solucionan todos los problemas.

OK, creo que con esto se resuelve uno de los misterios anteriores.

Esto aclara muchas cosas.
En otras secciones del documento se explica sin entrar en detalles, que la forma "ortodoxa" de acceder al 64DD es hacerle peticiones al SO, para que este se encargue de ir a buscar los datos y cachearlos en la RDRAM, y PARECE que esas peticiones se hacen con LBAs y que tambien el OS pasa los LBAs al 64DD y este es el que traduce los LBAs a posiciones del disco, de la manera en que se detalla ahi.
Al final tambien resulta que me equivocaba antes y si que se accede al disco una cara primero y la otra despues (decision extraña, en mi opinion). Pero es que, además, la primera cara se lee de fuera a dentro y la segunda de dentro a fuera, y, para rematar la jugada, los bloques no son homogeneos a lo largo del disco, como en cualquier soporte moderno de PC (discos duros, memorias flash, discos opticos...) si no que cada zona, cuanto mas alejada del centro del disco, tiene bloques mayores.
No se si es peor este sistema de acceso o el CHS de los discos duros de PC antiguos xD madre mia...


Otra cosa que parece que queda zanjada es la velocidad del PI.
Quizá las velocidades de aquellos test fueran solo entre las caches del RCP y/o la RDRAM. Y supongo que da mas significado a que en la pagina dijese RSP y no RCP.

EMaDeLoC escribió:Pero tú estas asumiendo que ese rango de 252MB (en realidad llega a 243MB) se puede usar completamente porque el 64drive los tiene, pero en ese documento donde se listan las partes de D1A2 hay bastantes partes que se indican como "unused" de gran capacidad:

No has hecho bien ese calculo, tio. Son 252MB en el D1A2, lo he vuelto a comprobar.
Y lo de esos rangos "unused", me parece que el tio hizo algo raro en esa tabla. Primero pone los offset del la cabecera de la ROM, que coinciden con los de la tabla mas detallada del ROM HEADER algo mas arriba en el mismo documento. Sin embargo, aqui hay diferencias con la otra tabla y con lo que yo conozco de las ROMs de N64.

En el header, los primeros 32bytes, de 0x0000 a 0x0040, van una serie de valores de configuracion, los CRCs y la informacion identificativa. Despues del GAMECODE, en el ultimo byte de esos 32, el tio pone "unused", pero en realidad es el byte de revision de la ROM. Si de un juego se sacaban varias versiones, por arreglo de bugs, o lo que fuera, iban aumentando ese byte, 00, 01, 02, 03... FF. Tambien usaron numeros de version para diferenciar las ROMs modificadas que usaron en los discos de zelda de GC y en la consola virtual, normalmente FF. Abre ROMs en un editor hexadecimal y lo verás. Pero aqui dice "unused". Tambien hay otros errores menores.
Pero hay uno muy importante. En la primera tabla ROM HEADER, pone correctamente de de 0x0040 a 0x1000 en la ROM, es el bootcode. No se exactamente si lo ejecuta la CPU de N64 o lo ejecuta directamente el PIF, pero es el codigo que compatibiliza la ROM con el CIC de turno (ademas de que los CRCs se calculan de forma diferente dependiendo del CIC, y si no coinciden, tambien se niega la ejecucion). El caso es que mientras que la primera tabla está bien en su identificacion del bootcode, la tabla del D1A2 donde se vuelve a poner esto, pone un monton de cosas que contradicen esa informacion que me conste que es veridica.

Todos esos RAMROM esto y lo otro, no se que pintan ahi, pero creo que no está bien.

INCISO. Ya que hablamos de la cabecera de la ROM, y viendo que en ese documento la lista de codigos de pais en los "GAMECODE"s está incompleta, aprovecho para "sacar pecho" y comparto una lista que hice de codigos de pais hace unos años para que marshallh mejorase la deteccion de region de las ROMs (mira el codigo y lo traduce a PAL-NTSC-MPAL).
Revisé manualmente un monton de ROMs, particularmente entre las PAL, porque encontré que online algunos de ellos no estaban fichados. No he revisado TODAS las ROMs, por desgracia, y sin programar, hacerlo manualmente fue una paliza, pero bueno, saque esto en limpio:



Para quien no esté familiarizado, los ultimos 5bytes de esos 32bytes de la cabecera antes del bootcode, funcionan así:
-Goldeneye 007 NTSC = NGEE<00> Donde N significa que es un juego de cartucho, GE es el codigo del juego (asignado por Nintendo), E significa que es la version USA (E es por English, no por Europe), y el ultimo byte, en hexadecimal, es el numero de version, en este caso 00, o, si quereis, 1.00
-Majora's Mask Debug = NZSP<01> N cartucho, ZS codigo del juego, P de PAL, 01 la versión, supongo que debido a que fue una version expresamente producida para que la contratista que hizo el emulador para GC, así que aumentaron el numero de version. La version de debug interna de ellos no necesitaba de numero de version. (tecnicamente esta tampoco, pero se la pusieron...)
-Zelda Ocarina PAL v1.01 = NZLP<01>
-Zelda Ocarina NTSC 1.00 = CZLE<00> con C de cartucho con enlaces a 64DD, por la expansion Ura que nunca llegó.

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

Calculinho escribió:Me uno a la pregunta del usuario anterior que le habéis contestado basicamente que N64 es más mejor mucho mejor que PSX.

¿Donde he dicho yo eso?
Lo unico que dije es que tiene funciones que la PS1 no. Lo de mejor o peor es una conclusion tuya

Lo de la memoria unificada, lo toqué tambien, que, basicamente, al tener que ir todo a la misma memoria y con la latencia de la RDRAM, todo se veía afectado.

En general las ventajas de la memoria unificada es, primeramente, el coste: lo que cuesta dinero son los chips, no tanto la capacidad de estos. Cuestan mas 2 chips de 1MB que 1 de 2MB, además ocupan mas espacio en placa y hay que hacer mas conexiones, etc. Además, con memoria dedicada para cada procesador, la memoria que instalas para audio, no la puedes usar para video, aunque te sobre de audio y te falte de video, o para la CPU, o lo que sea. Es menos flexible en cuanto a reparto.
Tambien es menos flexible en cuanto a posibilidades de desarrollo. Por ejemplo, en N64, hacer efectos como la pantalla gigante de algunos circuitos de Mario Kart, o las transiciones de pantalla con piezas de puzzle en Banjo Kazooie, son "sencillas" de hacer, porque todos los procesadores y coprocesadores (CPU, RSP, RDP) tienen acceso a la misma memoria, facilitando, sin costosos trasvases entre memorias, que un componente use los datos de otro para hacer manipulaciones varias. Este tipo de efectos son mucho mas complicados y costosos si tienes memoria no unificada, especialmente si no hay ninguna via para que, digamos, la CPU pueda manipular la memoria de video, por ejemplo.

Como desventajas, pues, obviamente, que todos los componentes que acceden a memoria RAM tienen que ponerse a la espera en una misma cola... que, ademas, en el caso de N64, por desgracia, tiene una latencia brutal. Por ejemplo, el procesador grafico de PS1 no tiene que esperar a que el de audio o la CPU acaben de acceder a la memoria para poder hacer su trabajo. Cada procesador tiene su memoria separada y nadie le molesta. Además de que no tiene el problema de la latencia excesiva.

@EMaDeLoC y @Calculiño Lo del multidisco 64DD, los Mario Artist, efectivamente, permiten hotswap de discos, aunque CREO que está limitado a usar el MA Communication Kit, que sirve de centro de intercambio de datos entre discos, además de permitir, en su momento, compartir datos de todos los mario artist a traves del servicio RANDnet que habia entonces.
Creo que funcionaba asi: Arrancas la consola con el disco Communications Kit, vas a los menús de intercambio de datos, sacas el CommKit y metes otro de los discos, digamos que el Paint Studio, y copias alguno de los archivos almacenados en el. Ese archivo queda almacenado temporalmente en la RAM de la consola. Lo que tienes que hacer ahora es sacar el disco Paint Studio y meter otro donde quieras guardar lo que has copiado. El propio CommKit, creo, ofrece almacenamiento temporal, pero tambien puedes copiar directamente a otros discos Mario Artist para combinar cosas, como, por ejemplo, usar renders de tus modelos 3D de Polygon Studio en tus dibujos de Paint Studio.
Tambien hay discos de otros juegos que contienen extras para los Mario Artist. Por ejemplo, creo que el F-ZERO X Expansion Kit tiene ilustraciones que puedes copiar a Mario Artist a traves del CommKit.

Respecto a lo de los cambios de disco. Con el 64drive, si bien el menu puede CARGAR desde el menú las conversiones a formato cartucho que se hicieron, lo que por ahora no puede es guardar los cambios que hagas al guardar datos desde el juego. Me han dicho aqui que el EverDrive64 si puede. Ahora, que, en el 64drive, el metodo recomendado para jugar a las conversiones del 64DD es mediante carga por USB, por dos razones. A traves de USB puedes tanto enviar ROMs a la RAM interna del cartucho, como copiar los datos otra vez al PC. Esto sirve, en este caso, para guardar lo que hagas en los juegos. Además de esto, estas conversiones de cartucho estan hackeadas de tal manera que usan los registros del CI del 64drive de tal manera que el hecho de enviar una ROM nueva por USB mientras corres una de estas conversiones, el juego identifica la finalizacion de esa transferencia como un evento de sacar el disco y meter uno nuevo.
De esta forma, el 64drive permite la funcionalidad de cambiar los discos. Creo que el ED64 no puede hacer esto, ademas de que su puerto USB es mucho mas lento y con menos capacidades. Al menos con las versiones sobre las que yo he leido. Como siempre estan sacando versiones nuevas, igual ha mejorado esa situacion, pero no lo se...

Respecto a lo de cambiar discos desde la consola, sin usar USB y un PC... obviamente ahí la cosa se complica de lo lindo. Para empezar, no estoy seguro de que se pudiesen usar las conversiones de cartucho en este caso, así que habría que implementar emulacion de 64DD en el cartucho, cosa que, por ahora, no se ha hecho, ni creo que tenga prioridad en la lista de marshallh o Krikkz, dado que son solo 9 o 10 discos, y la mayoría sigue en japones, y estando las conversiones a cartucho ya en manos de todos, pues como que hay mucha menos prisa.
El ED64, además, no tendría memoria suficiente para almacenar las imagenes originales de los discos (64.45MB de los discos contra 64.00MB de la RAM interna) y menos aun si se hace necesario incluir el IPL ROM, la "BIOS" del 64DD, con 4MB mas que añadir a la lista. Y si ya requerimos tambien que se pueda cargar un cartucho al mismo tiempo, para usar el F-ZERO X Expansion Kit, version disco, junto con el cartucho... en fin, ya veis que la cosa se pone imposible sin hardware nuevo. El 64drive, por otro lado, con 256 MB de ram interna (240MB maximo, actualmente mapeables como ROM de cartucho), no tendría problemas en repartir 64 para cartucho, 4 para IPL y 64.45 para disco.
Cómo metodo para cambiar discos... ya es mas problematico. Actualmente, el acceso al sistema de ficheros FAT32 de las tarjetas SD se hace a traves de software corriendo en la CPU de la N64. El cartucho no corre un driver FAT32 internamente, solo da acceso a nivel LBA a la SD, y el sistema de ficheros tiene que correr en la N64. Para guardar saves (eeprom y demas), lo que hacen tanto 64drive como ED64 es que,cuando cargas una ROM, el menú guarda en una pequeña memoria del cartucho una lista de los LBAs donde el fichero del "save" está almacenado, y simplemente vuelca los datos a esos LBAs cuando el juego graba nuevos datos en el chip emulado. Por desgracia, esto es a todas luces insuficiente para implementar hotswap de discos de 64DD.
No obstante, al menos en cuanto a versiones actuales del hardware se refiere, el 64drive si podría tener hardware suficiente para realizar esta tarea.
Con sus 256MB de SDRAM interna, se podría hacer lo siguiente: Se añadiría una nueva funcion en el menú por la cual cuando el usuario cargue una imagen de 64DD, no solo se limite a cargar esa imagen, si no que, además crease una lista de todas las demás imagenes, con sus respectivas listas de LBAs, y almacenase todo eso en la RAM interna. He calculado que con direcciones tipo LBA48, que son las comunes hoy en dia, y sectores de de 512bytes, tambien lo habitual, la lista de LBAs para un disco de 64DD ocupa 0.75MB. Incluso si redondeamos los LBA de 48bit y los almacenamos en una palabra de 64bit, la lista ocuparia 1MB. Hay unos 10 discos de 64DD, asi que unos 10 megas en total para almacenar las listas de LBAs de todos los discos de 64DD que alguien pueda tener en su carpeta de 64DD en la SD del 64drive.
Una vez llegados a este punto, tenemos un 64drive que, sin ayuda de ningun sofware extra corriendo en la N64, mientras ejecuta un disco de 64DD, sabe tambien donde están los demás. Y aqui viene otra ventajita que tiene el 64drive, y es que tiene un boton extra, similar al de un AR/GS, y ese boton podría usarse para ir cambiando de disco, uno a uno. Es ir un poco a ciegas, pero podría solucionarse ordenando los discos con numeros en los nombres de archivo en la carpeta, obligar al menu del 64drive a listarlos en orden, y mantener una lista en un papel para saber cuantas veces pulsar el boton para cargar el disco deseado.
No es lo mismo que cargar visualmente desde un menú, pero funcionaría.

@Calculinho
A que te refieres con eso de "betas que luego migraron a GC"?

radorn escribió:Al final tambien resulta que me equivocaba antes y si que se accede al disco una cara primero y la otra despues (decision extraña, en mi opinion). Pero es que, además, la primera cara se lee de fuera a dentro y la segunda de dentro a fuera, y, para rematar la jugada, los bloques no son homogeneos a lo largo del disco, como en cualquier soporte moderno de PC (discos duros, memorias flash, discos opticos...) si no que cada zona, cuanto mas alejada del centro del disco, tiene bloques mayores.
No se si es peor este sistema de acceso o el CHS de los discos duros de PC antiguos xD madre mia...

Ojo cuidado con la lectura de las caras. Lo que dice la documentación es el orden de los bloques en el LBA, pero fisicamente el disco puede estar leyendo las dos caras a la vez y de dentro a afuera de forma normal. No sé porqué tontería se decide un orden distinto de acceso entre software y hardware, quizá para dificultar la ingenieria inversa y el hackeo o clon del sistema. Cuando se desarrolla para 64DD, solo hay que tener en cuenta que si por ejemplo necesitas los dos primeros bloques, para optimizar la velocidad has de asignarlos al primer bloque de la cara 0 y al último de la cara 1, y leerlos también en ese orden.
A menos, claro está, que aparezca una foto del 64DD con los cabezales uno en Cuenca y otro en Vigo.

radorn escribió:

EMaDeLoC escribió:Pero tú estas asumiendo que ese rango de 252MB (en realidad llega a 243MB) se puede usar completamente porque el 64drive los tiene, pero en ese documento donde se listan las partes de D1A2 hay bastantes partes que se indican como "unused" de gran capacidad:

No has hecho bien ese calculo, tio. Son 252MB en el D1A2, lo he vuelto a comprobar.

A mi el rango de direcciones de D1A2 me sale de 255.459.328 direcciones de bytes, que dividiendo en el estandar de 1024 salen 243'625MB. ¿Como hace tú el cálculo?

radorn escribió:Todos esos RAMROM esto y lo otro, no se que pintan ahi, pero creo que no está bien.

En alguna documentación de desarrollo he leido que los cartuchos usados para probar las betas de juego los llaman RAMROM. Eso es porque literalmente son unas placas a las que se puede insertar una memoria RAM para que la consola la use de ROM. Es bastante brutal la imagen.



Es posible que toda esa documentación de direcciones y dominios la sacara de algún equipo de desarrollo que llamara RAMROM todo lo referente al cartucho. También puede ser que todo eso que comentas del byte de revisiones y otros fuesen datos que solo manejaban y editaban el fabricante del cartucho y que los desarrolladores no necesitaban saber.

@radorn tampoco te he mencionado a ti expresamente, estáis escribiendo mucho estos días así que tras leerme varias páginas enormes lo expuse de forma indeterminada porque ya no sabía bien quien había dicho qué. Por lo que cuentas no has sido tú el usuario que le respondió diciendo que la CPU y la GPU de N64 eran de tantos hz y las de PSX de tantos menos, etc. Que vamos que da igual, simplemente remarcaba que esa no era la explicación que buscábamos los profanos sino si la N64 le iba mejor calzar una RAM unificada o dedicada a trozos.

Sobre lo de las betas acabo de mirar y eran juegos, yo creía que el Doshin the Giant no había salido para 64DD; pero veo que sí.

Calculinho escribió:@radorn tampoco te he mencionado a ti expresamente, estáis escribiendo mucho estos días así que tras leerme varias páginas enormes lo expuse de forma indeterminada porque ya no sabía bien quien había dicho qué.

JUAS, OK. La proxima vez sugeriria "se ha dicho" "aqui se ha dicho" "alguien ha dicho". Porque si, en estos ultimos dias es casi un intercambio entre EMaDeLoC y yo, y ese "habeis", contextualmente, parecia referirse a uno de los dos.
Lo siento por los muros de texto xD. Espero que al menos haya sido provechoso y/o interesante.

Lo de si es mejor una u otra o se podría solucionar cambiando la RAM... Pues, como suele pasar en estos casos... "es complicado"

De betas en 64DD, hay una expansion para el Dezaemon, creo, de hace un porron de años, pero no se si llegó a algo la cosa, ni la vi nunca en marcha. Tampoco es que el Dezaemon sea mi tipo de juego, la verdad.

EMaDeLoC escribió:A mi el rango de direcciones de D1A2 me sale de 255.459.328 direcciones de bytes, que dividiendo en el estandar de 1024 salen 243'625MB. ¿Como hace tú el cálculo?

Pues tal que asín:

0x1000 0000 to 0x1FBF FFFF Cartridge Domain 1 Address 2
0x1FC0 0000 to 0x1FC0 07BF PIF Boot ROM

Abro calculadora con modo hexadecimal (en mi caso, copié la vieja calculadora de windows xp para seguir usandola en el 7), y resto:
0x1FC00000
-0x10000000
------------------
=0x0FC00000 = 264241152 bytes en decimal = 252MB "pelaos"
...o, como se empeñan los del IEC, "Mebibytes" https://en.wikipedia.org/wiki/Template: ... s_of_bytes
¿Que haces tu para que te salgan 243.625MB?

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

Lo de las caras y los LBA... pues, vaya! la razon de ser de los LBA es precisamente ser una abstraccion logica (LOGICAL block address) sobre la geometria fisica real del dispositivo de almacenamiento para facilitarle el trabajo al programador, y lo suyo es acceder a ellos empezando por el LBA 0 y finalizando en el LBA que sea el ultimo... Si uno tiene que andarse rompiendo la cabeza con detalles de una geometria extraña en el disco, segun la que se supone que tienes que acceder a datos contiguos usando LBAs distintos y que progresan en direcciones opuestas, ya no sé que sentido tiene usar direccionamiento por LBAs.
Desde luego, si es para liar la cabeza a la gente, como dices tu, reto conseguido! xD
Pero es que ademas, la Zone0 existe solo en la Head0 y la Zone8 solo tiene presencia en la Head1, segun el esquema de la documentacion.
Yo no se como se las arreglaron para liarla tanto ni para qué, la verdad.

Lo que no consigo encontrar en esa documentacion es que librería controla el acceso al disco y de que modo se supone que comunicarse con ella el programador.
Se menciona un sistema de ficheros llamado MFS... igual simplemente piden archivos, como si fuera FAT y ya la librería se encarga de todas las complicaciones. Claro que eso no soluciona nuestras absurdas disquisiciones tecnicas, verdad? xDDDD

Igual el programador lo unico que tiene que hacer es definir los archivos que quiere, asegurarse de que le caben en la RAM cuando los necesite y encargarle al sistema de ficheros MFS que se encargue de sacar y meter archivos en ese galimatias.

--Datos irrelevantes para quien los quiera: El 64DD gira los discos a ~2400rpm, y tiene una tasa de transferencia de entre 0.5MB y 1MB por segundo dependiendo de si está leyendo de las zonas interiores o las exteriores (cuando mas lejos del centro, mas datos se pueden meter por rotacion).
1MB no parece gran cosa, pero, para hacer comparaciones irrelevantes, las consolas de CD de la epoca, con sus lectores 2X, tiraban a 300KB maximo.

EMaDeLoC escribió:También puede ser que todo eso que comentas del byte de revisiones y otros fuesen datos que solo manejaban y editaban el fabricante del cartucho y que los desarrolladores no necesitaban saber.

Dado que Nintendo controlaba total y ferreamente el acceso a la produccion de cartuchos, todas las ROMs tenian que ser aprobadas por ellos. Una de las cosas que hacian era mantener una lista de los codigos de juegos. Como el gobierno los DNIs y las matriculas de los coches, vamos. El "gamecode" o ID, te lo asignaba Nintendo, pero tambien podías intentar pedir uno a tu gusto a ver si aun estaba disponible. Y lo podías pedir en cualquier momento del proceso. Tecnicamente a la N64 le da igual lo que haya ahi... como si no hay nada. Como mucho, le puede importar al propio software del juego, pero eso ya depende de cada casa de desarrollo, como el ejemplo que puse del Wetrix, que usa el byte de region para establecer el funcionamiento del juego. Hay ROMs beta por ahi con y sin gamecode, y con un monton de variaciones entre con y sin. Supongo que quedaba a la eleccion de la desarrolladora el momento en que solicitaban un gameID y el momento en que lo incorporaban a la ROM.
Lo de los numeros de version o revision, solo se asignan para ROMs que son publicadas en forma de cartucho (o parte de un emulador oficial, como el de Zelda en GC y los de la VC). No se asignaban para versiones en desarrollo. Claro que eso no impedia que, mientras tanto, los programadores pusiesen ahi lo que les diese la gana.

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

Lo del "cartucho RAMROM" me convence porque el documento especifica un rango de 16MB llamado RAMROM_GAME_OFFSET.
Pero no debe funcionar con ROMs normales, si no que seguramente haya que subirlas con la herramienta asociada al cartucho ese, con loaders y cosas, porque hay mucha cosa rara por ahi en medio que no coincide con una ROM comercial normal.
Lo de los 16MB debe ser la capacidad concreta de ese cartucho.
Es un poco confuso eso de ponerlo ahi como si fuera algo universal de la N64, aplicable a cualquier cartucho...

En fin, todo lo que nos de algo sobre lo que discutir y sacarnos los ojos, genial, verdad? xDDDDDD

@radorn ojo que no me quejaba de los ladrillos de post que estáis escribiendo eh, sólo digo que tras leerlos todos de golpe era un poco jodido localizar quien había dicho que cosa

radorn escribió:

EMaDeLoC escribió:A mi el rango de direcciones de D1A2 me sale de 255.459.328 direcciones de bytes, que dividiendo en el estandar de 1024 salen 243'625MB. ¿Como hace tú el cálculo?

Pues tal que asín:

0x1000 0000 to 0x1FBF FFFF Cartridge Domain 1 Address 2
0x1FC0 0000 to 0x1FC0 07BF PIF Boot ROM

Abro calculadora con modo hexadecimal (en mi caso, copié la vieja calculadora de windows xp para seguir usandola en el 7), y resto:
0x1FC00000
-0x10000000
------------------
=0x0FC00000 = 264241152 bytes en decimal = 252MB "pelaos"
...o, como se empeñan los del IEC, "Mebibytes" https://en.wikipedia.org/wiki/Template: ... s_of_bytes
¿Que haces tu para que te salgan 243.625MB?

Yo cojo los dos datos que hay en negrita:

Cartridge Domain 1(Address 2):
------------------------------
0x1000 0000 to 0x1000 003F ROM header:
---------------------------------------
0x1000 0000 initial PI_BSB_DOM1_LAT_REG value
0x1000 0001 initial PI_BSB_DOM1_PGS_REG value
0x1000 0002 initial PI_BSB_DOM1_PWD_REG value
0x1000 0003 initial PI_BSB_DOM1_PGS_REG value
0x1000 0004 to 0x1000 0007 Clock Rate
0x1000 0008 to 0x1000 000B Boot address offset
0x1000 000C to 0x1000 000F Release offset
0x1000 0010 to 0x1000 0013 CRC1
0x1000 0014 to 0x1000 0017 CRC2
0x1000 0018 to 0x1000 001F Unused
0x1000 0020 to 0x1000 0033 Image name
0x1000 0034 to 0x1000 003A Unused
0x1000 003B Manufacturer ID
0x1000 003C to 0x1000 003D Cartridge ID
0x1000 003E Country code
0x1000 003F Unused

0x1000 0040 to 0x1000 0B6F RAMROM_BOOTSTRAP_OFFSET
0x1000 0B70 to 0x1000 0FEF RAMROM_FONTDATA_OFFSET
0x1000 0FF0 to 0x1000 0FFF Unused
0x1000 1000 to 0x10FF 9FFF RAMROM_GAME_OFFSET
0x10FF A000 to 0x10FF AFFF RAMROM_APP_READ_ADDR
0x10FF B000 to 0x10FF BFFF RAMROM_APP_WRITE_ADDR
0x10FF C000 to 0x10FF CFFF RAMROM_RMON_READ_ADDR
0x10FF D000 to 0x10FF DFFF RAMROM_RMON_WRITE_ADDR
0x10FF E000 to 0x10FF EFFF RAMROM_PRINTF_ADDR
0x10FF F000 to 0x10FF FFFF RAMROM_LOG_ADDR
0x1100 0000 to 0x17FF FFFF Unused
0x1800 0000 to 0x1800 0003 GIO Interrupt Register (R)
0x1800 0004 to 0x1800 03FF Unused
0x1800 0400 to 0x1800 0403 GIO Sync Register (R/W)
0x1800 0404 to 0x1800 07FF Unused
0x1800 0800 to 0x1800 0803 Cartridge interrupt Register (R)
0x1800 0804 to 0x1F39 FFFF Unused

Los resto como haces tú:

Le sumo 1 para contar la primera dirección que es un byte que se quedaría suelto:
F3A0000
Convertir a decimal y dividir por kibibytes de esos. Total: 243,625 MiB.
Fijate que entre la última dirección del rango Unused, 0x1F39 FFFF, y la que usas tú, 0x1FC0 0000, hay todo un hueco que no esta documentado en el detalle de D1A2.
Lo más curioso es que al principio el documento dice:

Y luego deja un hueco y se queda tan ancho.
Vamos, que pueden ser 243 o 252MiB... Si el 64drive esta basado en los datos del D1A2, creo que serán 243, o si no ya estarían disponibles los 252MiB en el flashcart.
El documento, por si alguien no sabe de qué estamos hablando.

radorn escribió:Lo de las caras y los LBA... pues, vaya! la razon de ser de los LBA es precisamente ser una abstraccion logica (LOGICAL block address) sobre la geometria fisica real del dispositivo de almacenamiento para facilitarle el trabajo al programador, y lo suyo es acceder a ellos empezando por el LBA 0 y finalizando en el LBA que sea el ultimo... Si uno tiene que andarse rompiendo la cabeza con detalles de una geometria extraña en el disco, segun la que se supone que tienes que acceder a datos contiguos usando LBAs distintos y que progresan en direcciones opuestas, ya no sé que sentido tiene usar direccionamiento por LBAs.
Desde luego, si es para liar la cabeza a la gente, como dices tu, reto conseguido! xD
Pero es que ademas, la Zone0 existe solo en la Head0 y la Zone8 solo tiene presencia en la Head1, segun el esquema de la documentacion.
Yo no se como se las arreglaron para liarla tanto ni para qué, la verdad.

Pues espera, que no te he dicho que lo de los cabezales lean por turnos puede ser mentira y en realidad lean a la vez, y que la cara 0 sea en realidad la mitad interior del disco y la cara 1 la mitad exterior...
No en serio, puede ser así. El que diseña el protocolo de comunicación no tiene porque estar en contacto con quien hace el lector ni con los programadores, establece las reglas y que cada uno se apañe. Luego el ingeniero de discos decide que los discos se leerán de una manera y el programador hará la librerías LBA como le parezca mejor. Mientras funcione todos contentos.

radorn escribió:Lo del "cartucho RAMROM" me convence porque el documento especifica un rango de 16MB llamado RAMROM_GAME_OFFSET.
Pero no debe funcionar con ROMs normales, si no que seguramente haya que subirlas con la herramienta asociada al cartucho ese, con loaders y cosas, porque hay mucha cosa rara por ahi en medio que no coincide con una ROM comercial normal.
Lo de los 16MB debe ser la capacidad concreta de ese cartucho.
Es un poco confuso eso de ponerlo ahi como si fuera algo universal de la N64, aplicable a cualquier cartucho...

Es que yo creo que los 16MB era el límite inicial que le contaban a los desarrolladores, no por el diseño de la N64, si no por el precio de los chips, y para empezar establecieron la estructura del D1A2 para que los desarrolladores tuvieran una estructura definida para no liarse demasiado. Luego la D2A1 estaba ahí para cuando los cartuchos de 32MB estuvieran disponibles. Creo que el Zelda fue el primero en ser de 32MB. El direccionamiento a 64MB ya puede ser lo que digo de los bancos de memoria o alguna de esas direcciones Unused mal documentadas.

radorn escribió:En fin, todo lo que nos de algo sobre lo que discutir y sacarnos los ojos, genial, verdad? xDDDDDD

A mi ya me duele la cabeza de tantos datos técnicos... El otro día busqué una calle en el Maps con una dirección hexadecimal.

Voy a empezar Hybrid Heaven en los próximos días, algunos consejos?

No usaré el modo alta definición, en cuanto a la versión PAL o NTSC voy a probar cual funciona mejor.

BMBx64 escribió:Voy a empezar Hybrid Heaven en los próximos días, algunos consejos?

No usaré el modo alta definición, en cuanto a la versión PAL o NTSC voy a probar cual funciona mejor.

Creo que es un rpg por turnos, ¿no?.

Hace años quise jugarlo pensando que tendría un pelín de la experiencia jugable adulta del metal gear, pero cuando me encontré con ese percal no pude seguir con el.

Me sacan del juego los combates por turnos, pero a gorrazos, vamos.

Es cierto que Hybrid Heaven no es un juegazo pero tampoco es mal juego

El problema es que la mezcla de géneros dejó transpuesto a más de uno y se tiende a compararle con la obra maestra de Konami de aquella época...y claramente sale perdiendo

@BMBx64 Yo lo jugue parcialmente mediante alquiler en su dia. Llegué a un jefe tan cabron que no pude con el y deje de alquilarlo. Incluso eche un par de partidas de multijugador con unos amigos, pero no les entusiasmó el tema.

Respecto a PAL o NTSC... En mis pruebas en su momento, creo recordar que, como casi todos los juegos PAL a pantalla completa, usa escalado por VI, lo cual no es sorprendente, siendo un juego de origen japonés. Ya me darás tu opinion de primera mano reciente, pero creo que será mejor usar la version NTSC... claro que si tienes consola PAL irá a ~61Hz

.

En el hilo sobre la N64 mini comenté la posibilidad de rehacer el RCP, reduciendo sus fallas, para obtener un RCP con esteroides.
Entonces, sabiendo que había mods de overclocking de la consola que aceleraban los juegos, me pregunté si habría overclocks de solo el RCP y busqué por ahí.
Y bueno, no he encontrado gran cosa...
Pero ninguna búsqueda es en vano y he encontrado un video de ElectronAsh (igual alguien ya lo conoce, por ese nick o por OzOnE) que ya por el 2013 había conseguido conectar HDMI en la N64 usando un FPGA, y por algún motivo tenía el RCP a 70MHz. Es un poco más de 10% con lo que se consigue rascar 2-3fps, y quizá eso ayuda a que el frameskip no sea tan quisquilloso y mantenga más fps en todas las situaciones.
Eso claro si es verdad porque en el video solo se ve una pantalla temblorosa del Top Gear Rally que parece ir bastante fluido.
https://www.youtube.com/watch?v=NCbkDgCIKRQ

Por cierto, ElectronAsh esta trabajando en varios proyectos a la vez, según su Twiter. Por lo visto, algo de una N64 comprimida, sustituir el RCP por un R10000, o rehacer la placa base de la Dreamcast con un FPGA metido...

Bueno, el caso es que he encontrado un hilo de AssemblerGames con un bonito mapa de los relojes de frecuencias de la N64 hecho por eb1560 que parece muy interesante como dato técnico de la consola.



Y bueno, si es verdad que puede subirse el reloj del RCP algo y luego configurar el mod HDMI para adaptarse a las nuevas frecuencias de video, puede ser interesante un RCP overclokeado.
Pero como a estas alturas no he encontrado nada más, o bien a la gente no le interesa, o no se puede.

@BMBx64 ¿Sabes para cuando, más o menos, se liberará la nueva librería?

Señor Ventura escribió:Creo que es un rpg por turnos, ¿no?.

Hace años quise jugarlo pensando que tendría un pelín de la experiencia jugable adulta del metal gear, pero cuando me encontré con ese percal no pude seguir con el.

Me sacan del juego los combates por turnos, pero a gorrazos, vamos.

Es un tipo de combate peculiar, tienes movilidad normal del personaje con la cámara en plan Z target siguiendo al enemigo y tienes que ir haciendo tiempo para rellenar una barra de acción, esquivándolo o no exponiéndote demasiado a su zona de ataque, algunos hasta intentan agarrar.

Cuando atacas o te atacan entonces se pausa la acción y tienes diferentes menús, por lo pronto he visto muy pocas opciones, pero se van añadiendo nuevas según vas peleando (y puntos de experiencia con niveles de habilidades).

Nunca lo he completado por la falta de espacio en el CPAK, pero esta vez miraré de analizarlo (técnicamente y jugable) y hacerle alguna especie de review

bluedark escribió:@BMBx64 ¿Sabes para cuando, más o menos, se liberará la nueva librería?

La libn64? Marathon la va actualizando aquí:
https://github.com/tj90241/n64chain/tree/master/libn64

La capa que yo estoy haciendo con todo el soporte RDP aún no está lista.