Hilo de detalles y curiosidades de N64

@sev45lora Así es. Por eso mismo mi última consola fue Xbox One.

Ahora uso Steam (total... lo otro es comprar cajas vacías).

sev45lora escribió:@CarrieFernandez por eso digo que juego completo en físico ya no existe, por mucho que la gente quiera pensar lo contrario. Y seguro que mientras lo instalas, te baja cosas de Internet por detrás, que en el disco no está. O en ps5 no se instala ningún juego y se lee directamente desde el lector?

Hagas lo que hagas, es un juego digital encubierto. Cod a trozos, fornite a trozos, fifa a trozos, gta a trozos, etc.

Has puesto una selección de juegos como ejemplo,muy selecta.
Una cosa son parches, y otra,mapas,dlcs y modos on line.Que,por cierto,en mi caso me importan un comino.
Te voy a poner el ejemplo de los resident evil 7,8,2,3.Incompletos dices?.
De todas maneras,este no es el foro.
El que no quiera físico,que no compre.Pero hay de todo dentro del catálogo físico.

@mcfly todos los juegos que tengo de PS4 (lo más avanzado que tengo ahora mismo) suelen tener descargas y parches (DLC y expansiones aparte), pero todos los que probé a instalar sin actualizar se iniciaban y se jugaban bien. Esto no lo hice por capricho sino porque compré la consola en Julio del 2015 y en Agosto me mudé a un piso donde tardaron en instalarme la fibra tres meses y a mayores se cortaba la conexión casi a diario durante días así que tenía que jugar desde discos sin internet y como digo me funcionó todo sin problemas. Entre otros, que recuerde ahora mismo The Witcher 3 Day One Edition que ya os imagináis la de gigas de parches que tenía ese juego

Creo que somos exagerados con este tema, los juegos siempre han salido con bugs, errores, etc. Pero el 99% de las veces la versión que salía al mercado se podía jugar de principio a fin y en las reediciones se publicaban las versiones parcheadas sin que nadie se enterase. La diferencia es que antes estas reediciones permitían actualizar el juego un par de veces como mucho si vendía bien y ahora se puede actualizar y pulir durante años sin tener que distribuir el juego, lo que a la larga permite una versión final más pulida (aunque nunca 100% sin bugs). Hay excepciones a esto, desde el bug fatal del Digimon de PS1 hasta el Cyberpunk de PS4 o Sonic Boom de WiiU.

SuperPadLand escribió:@mcfly todos los juegos que tengo de PS4 (lo más avanzado que tengo ahora mismo) suelen tener descargas y parches (DLC y expansiones aparte), pero todos los que probé a instalar sin actualizar se iniciaban y se jugaban bien. Esto no lo hice por capricho sino porque compré la consola en Julio del 2015 y en Agosto me mudé a un piso donde tardaron en instalarme la fibra tres meses y a mayores se cortaba la conexión casi a diario durante días así que tenía que jugar desde discos sin internet y como digo me funcionó todo sin problemas. Entre otros, que recuerde ahora mismo The Witcher 3 Day One Edition que ya os imagináis la de gigas de parches que tenía ese juego

Creo que somos exagerados con este tema, los juegos siempre han salido con bugs, errores, etc. Pero el 99% de las veces la versión que salía al mercado se podía jugar de principio a fin y en las reediciones se publicaban las versiones parcheadas sin que nadie se enterase. La diferencia es que antes estas reediciones permitían actualizar el juego un par de veces como mucho si vendía bien y ahora se puede actualizar y pulir durante años sin tener que distribuir el juego, lo que a la larga permite una versión final más pulida (aunque nunca 100% sin bugs). Hay excepciones a esto, desde el bug fatal del Digimon de PS1 hasta el Cyberpunk de PS4 o Sonic Boom de WiiU.

Exácto.Parece que haya que "justificar",la compra digital,por la idea generalizada de juego incompleto.
Hasta recuerdo el tomb raider de wii,que necesitaba de un parche,porque no salía una palanca que te dejaba continuar.
Otra cosa son los juegos realmente incompletos que requieren de descarga obligatoria(wolfenstein en switch),que te lo avisa claramente en portada.(smplemente por ahorrar costes en la capacidad de memoria de la tarjeta).De ahí,a que todos los juegos están incompletos,bugueados, o que instalan en hdd(mejor,así dura más el lector),va un trecho.

Por lo visto se ha filtrado un prototipo de Doom 64 recientemente:


Algo más de info por aquí

sev45lora escribió:@CarrieFernandez wii no tenía update y dlc. En wii u ya hay update y dlc. Cuando un juego tiene update y dlc, el juego en disco óptico, ya no está completo. Resto ya es descarga.

Desde que hay hdd interno, o ssd en el caso de ps5 y xbox series, ya es lo mismo que con la switch. Hay juegos en ps5, que si no se instala en el ssd y bajas algo de internet, no está completo.

Solamente una corrección. Aunque sean pocos sí hay juegos completos en disco en PS4 (especialmente indies que salen en físico) y con respecto a Switch, sí que hay juegos completos en la tarjeta. Yo por ejemplo tengo el Zelda Breath of the Wild completo en físico, incluyendo el juego parcheado hasta su último parche, y con los DLC instalados ya con sus parches también.

Además añado, si tenéis interés en coleccionar Switch, que sigáis ESTE HILO donde podréis ver las diferentes tiradas de los títulos de Switch y en qué parche vienen. Porque sí, muchos juegos de Switch (y prácticamente todos los que edita Nintendo) a medida que van fabricando tiradas lo hacen metiendo los juegos actualizados para requerir menos parches o hasta ninguno.

Un saludo!

@mcfly no estoy justificando lo digital. Solo digo que parece que lo sacan malamente y incompleto, para que descargagues el resto del juego. En pc ya toda la gente juega mayormente en digital, poca gente es ya en disco. Y veremos cuanta gente con ps5 y lector, cuantos juegos tendrán en físico y digital. Ya con lo de eneba y demás, te sale más barato en digital que físico

Conker64 escribió:Por lo visto se ha filtrado un prototipo de Doom 64 recientemente:

Algo más de info por aquí

Conker se acaba el año y creo que no hemos tenido nada grande en 2022 como Dinosaur Planet del 2021

@SuperPadLand este año salieron a la luz un par de juegos cancelados

@ALCAMJI el primero lo había olvidado, el segundo creo que no me enteré. Mañana le hecho un ojo.

Falkiño escribió:

sev45lora escribió:@CarrieFernandez wii no tenía update y dlc. En wii u ya hay update y dlc. Cuando un juego tiene update y dlc, el juego en disco óptico, ya no está completo. Resto ya es descarga.

Desde que hay hdd interno, o ssd en el caso de ps5 y xbox series, ya es lo mismo que con la switch. Hay juegos en ps5, que si no se instala en el ssd y bajas algo de internet, no está completo.

Solamente una corrección. Aunque sean pocos sí hay juegos completos en disco en PS4 (especialmente indies que salen en físico) y con respecto a Switch, sí que hay juegos completos en la tarjeta. Yo por ejemplo tengo el Zelda Breath of the Wild completo en físico, incluyendo el juego parcheado hasta su último parche, y con los DLC instalados ya con sus parches también.

Además añado, si tenéis interés en coleccionar Switch, que sigáis ESTE HILO donde podréis ver las diferentes tiradas de los títulos de Switch y en qué parche vienen. Porque sí, muchos juegos de Switch (y prácticamente todos los que edita Nintendo) a medida que van fabricando tiradas lo hacen metiendo los juegos actualizados para requerir menos parches o hasta ninguno.

Un saludo!

Yo era feliz antes de saber esto, ¿sabes? . Por lo que he ojeado, la única opción para tener el Breath of the Wild completo en físico es comprar una edición japonesa concreta, ¿no? Entiendo que viene en castellano...

@RiGaL sí, tiene castellano (el nuestro no el latinoamericano) y es compatible con los saves que tengas. Edición completa definitiva.

@Conker64 tienes por ahí el análisis técnico que hiciste con tu anterior cuenta de Conkers Bad Fur Day?

@SuperPadLand otro juego recuperado de N64 que también salió al final en GameCube



Y aquí tampoco tocaron los gráficos como con Animal Crossing

@SuperPadLand
Hola, supongo que te refieres a este extracto de escena:


Aplica un 40% de deducción por el cullback y calcula sobre 18-21 fps que va sobre ese segmento, cerca de 90K diría, con mucho texturizado, iluminación, goraud, z-buffer, etc

Creo que tenía más cosas del Conker, del modo debug y algunos efectos, todo repartido, pero no tiene un análisis tocho en el hilo.

Otra novedad más para n64 obviamente

emulador de snes Sodium64 aun en desarrollo, se está usando la libdragon

aquí los detalles https://github.com/Hydr8gon/sodium64

cada vez hay más cosas homebrew para este genial sistema

john D9 escribió:Otra novedad más para n64 obviamente

emulador de snes Sodium64 aun en desarrollo, se está usando la libdragon

aquí los detalles https://github.com/Hydr8gon/sodium64

cada vez hay más cosas homebrew para este genial sistema

Sería interesante ver un video que testee rom, yo no tengo flash card para probar .

Os dejo un vídeo de un juego homebrew de N64 con iluminación cell shading ( simulación) y sombras dinámicas.En el video está la rom para descargar, yo diría que funciona a 640x480 se ve muy nítido.

Y otro donde también consigue simular la iluminación cell shading pero por otros métodos.

Y otro donde hay iluminación dinámica y ""bump mapping""
https://cdn.discordapp.com/attachments/587982213493030913/1040679126505361408/0001-2473.mp4


Salud.

@dirtymagic ha llegado el momento de abrir un hilo con estos vídeos preguntándose ¿Era N64 más potente que PS2?

dirtymagic escribió:Os dejo un vídeo de un juego homebrew de N64 con iluminación cell shading ( simulación) y sombras dinámicas.En el video está la rom para descargar, yo diría que funciona a 640x480 se ve muy nítido.

Lo he comprobado rapidamente y está a 640x480. La máquina es bien capaz y no hay que irse a títulos de gran presupuesto, Virtual Chess va 640x480 a poco framerate. Supongo que ellos habrán optimizado todo lo posible para tener un framerate bastante decente, además de muy pocos elementos en escena.

SuperPadLand escribió:@dirtymagic ha llegado el momento de abrir un hilo con estos vídeos preguntándose ¿Era N64 más potente que PS2?

Ese que lo abra @Bullrun que seguro que le hace ilusión.

@EMaDeLoC
Sí en el video lo dicen, también en los comentarios del propio video hay un mensaje anclado de uno de los que han hecho el otro video, como hacen ellos el cell shading y por lo visto su forma es más eficiente.
Esta claro que igual más potencia en geometría es difícil de sacar a la N64, pero parece que están consiguiendo efectos chulos con el color combiner.
@SuperPadLand
Espero que no, , el hilo de SS vs PSX estuvo bien, pese algunos , que querían demostrar lo indemostrable.
Salud.

¿Las N64 de colores y semitransparentes se vendieron en España? ¿A partir de que año?

ashurek escribió:¿Las N64 de colores y semitransparentes se vendieron en España? ¿A partir de que año?

Sí, mirando la publicidad de Centro Mail de Nintendo acción como a principios del 2000. El dato que tengo es que en mayo ya estaban a la venta, así que antes de eso.

@X_Glacius Muchas unidades no se venderían y de ahí el precio bastante superior al de la clásica negra

@ashurek las versiones de colores, llamadas FUNtastic (sí, así de cutre ) tienen además mejorada la salida de vídeo ligeramente. Una Funtastic por vídeo compuesto se ve casi igual de bien que por S-Video; y mejor que el compuesto de las negras clásicas. Lo malo es que el foro de zetaboards donde se hablaba de esto con vídeos y fotos lleva años borrado; pero bueno, te dejo el dato por si alguna vez te topas con una N64 de colores a buen precio y tienes dudas.

Un saludo!

Falkiño escribió:@ashurek las versiones de colores, llamadas FUNtastic (sí, así de cutre ) tienen además mejorada la salida de vídeo ligeramente. Una Funtastic por vídeo compuesto se ve casi igual de bien que por S-Video; y mejor que el compuesto de las negras clásicas. Lo malo es que el foro de zetaboards donde se hablaba de esto con vídeos y fotos lleva años borrado; pero bueno, te dejo el dato por si alguna vez te topas con una N64 de colores a buen precio y tienes dudas.

Un saludo!

Visualmente las FUNtastic me parecen muy chulas. Mantengo de la época mi N64 negra (la de toda la vida) y además tengo una JAP con mod RGB para usar. Teniendo RGB no creo que volviera a video compuesto

He encontrado esta web donde detallan todas las N64 Funtastic: https://nintendo64.fandom.com/wiki/Funt ... lor_Series

Estamos jugando S&P en el hilo de este foro y he descubierto que si se termina el juego en modo difícil desbloquea un modo turbo:


Y deja claro que la N64 esta moviendo el juego original con una mano atada a la espalda.

Es un juego "on rails".Aunque sí,se mueve con soltura.

mcfly escribió:Es un juego "on rails".Aunque sí,se mueve con soltura.

Bueno, la carga gráfica o mala optimización puede apretar al hardware sin importar el género. Pero en este caso lo comentaba porque el juego normal a ratos se ralentiza en explosiones y cosas así, supongo que es intencionado en plan camara lenta o lo de siempre que la consola detecta 29fps y baja a 20 de golpe.

@SuperPadLand Pues eso es lo malo de jugar emuladores.

De alguna manera los emuladores " arreglan " caídas de framerate pero da una experiència irreal...

Ahora me entero que se le puede hacer OC a la consola, me he quedado de piedra...

PHANTASIA escribió:Ahora me entero que se le puede hacer OC a la consola, me he quedado de piedra...

No es que se note mucho, pero mas que overclocking, lo que ocurre es que la n64 está UNDERclockeada.

Es una larga historia xD

PHANTASIA escribió:Ahora me entero que se le puede hacer OC a la consola, me he quedado de piedra...

Habría sido más interesante el video si hubieran medido los fps en ambos casos

ashurek escribió:

PHANTASIA escribió:Ahora me entero que se le puede hacer OC a la consola, me he quedado de piedra...

Habría sido más interesante el video si hubieran medido los fps en ambos casos

Por algún motivo no hay medidor de FPS en ninguna comparativa de estas.
Pero por ejemplo si te fijas en el Turok 2 se nota bastante.

PHANTASIA escribió:Ahora me entero que se le puede hacer OC a la consola, me he quedado de piedra...

No me queda muy claro si suben mucho los fps o no se nota demasiado, la verdad es que es un tema muy interesante y por lo que veo tampoco es excesivamente complicado de hacer.
Puede meterle un buen boost a los juegos de n64 que por lo general pecan de un framerate bastante precario por decirlo de forma suave

Antaño tenían miedo de que las consolas muriesen a los pocos años y así tenemos cosas como Master System, Megadrive o N64 saliendo con un 20-30% menos de potencia de lo que sus CPU podían aguantar, aunque en el caso de N64 igual fue por ahorrarse la refrigeración activa.

Por cierto buscando algún vídeo con framerate test de este OC (no lo encontré), me tope con que ya han hecho OC a la GPU de Switch

El cuello de botella no está en la CPU.

De hecho subirle la velocidad solo a la CPU puede empeorar las cosas, por aquí hay un vídeo con la CPU a 187,5 MHz y contador de fps (y es probable que el contador no esté contando bien), sin overclock funciona mejor (y sin debug y estadísticas también), pero vamos que solo acelera el programa, no lo hace más suave.


@Señor Ventura
Pon la historia, a ver si coincide con lo que se

Conker64 escribió:El cuello de botella no está en la CPU.

De hecho subirle la velocidad solo a la CPU puede empeorar las cosas, por aquí hay un vídeo con la CPU a 187,5 MHz y contador de fps (y es probable que el contador no esté contando bien), sin overclock funciona mejor (y sin debug y estadísticas también), pero vamos que solo acelera el programa, no lo hace más suave.

@Señor Ventura
Pon la historia, a ver si coincide con lo que se

Tengo entendido que el bottleneck depende del juego, hay algunos más CPU dependientes y otros más GPU dependientes.
Hay mucha gente que le tiene hecho OC a N64, imagino que se notará aunque sea poco.

@PHANTASIA
Depende de lo que haga el motor, en el caso de Golden Eye es muy CPU intensivo y ese mod por lo que sea no le sienta bien.

Yo subirle el clock a la consola no lo veo buena idea, si un juego sigue enviando 20 superficies de las cuales solo 8 y media se ven, ahí no hay nada que hacer, ni fillrate suficiente para cubrir ese pico.

Conker64 escribió:El cuello de botella no está en la CPU.

De hecho subirle la velocidad solo a la CPU puede empeorar las cosas, por aquí hay un vídeo con la CPU a 187,5 MHz y contador de fps (y es probable que el contador no esté contando bien), sin overclock funciona mejor (y sin debug y estadísticas también), pero vamos que solo acelera el programa, no lo hace más suave.

@Señor Ventura
Pon la historia, a ver si coincide con lo que se

Pero este problema es más por como se hacían los juegos no? Por eso sí pones en emulador 60fps los juegos de la quinta gen se aceleran casi todos (si no se rompen).

@SuperPadLand
Bueno yo lo vería como 2 cosas distintas, si subes la frecuencia de la CPU no tengo demasiado claro de que 1 segundo siga siendo 1 segundo, muchas mediciones se hacen con contadores internos que se desajustan a veces con el overclock.

Lo otro depende si el juego tiene los tiempos de animación y otras cosas atadas al framerate, que en cuanto lo subes se aceleran, por otro lado ajustar en base a la tasa es parte de la idea del frameskip, para no perder velocidad si no llega al target o ir más suave cuando pueda, con lo cual funcionan bien a 60fps los que estén diseñados así.

La N64 necesita más velocidad de RCP. Subirle los Hz aparte de mejorar su potencia también sube la velocidad de la RAM, con lo cual mejora su rendimiento también.
El problema es que la salida de vídeo del RCP esta también atada a su reloj, por lo que en cuanto se hace OC por encima de los margenes de tolerancia del standar de vídeo, te quedas sin señal. Y no, los margenes no dan para una mejora sustancial.

Supongo que será por eso que no es común el OC en la N64, porque hacerlo en la CPU solo acelera el juego y no mejora los fps, y hacerlo en el RCP hace que te quedes sin señal de vídeo, con lo cual es absolutamente inútil.

Hace casi 10 años ElectronAsh hizo algo parecido a un mod HDMI y le hizo OC al RCP sin perder imagen, debido a mejores tolerancias del HDMI, y seguramente un software más específico. Aún así solo lo pasa de 62.5MHz a 70MHz, un poco más del 10% extra, lo cual no esta mal.


En los comentarios ElectronAsh da algunas informaciones técnicas.

Por si alguien no lo recuerda, ElectronAsh estuvo haciendo pruebas de replicar el RCP con una placa FPGA:

Conker64 escribió:@Señor Ventura
Pon la historia, a ver si coincide con lo que se

Según recuerdo, los DIE que encargó fabricar silicon graphics salieron con errores, y bajaron la frecuencia para que no se reprodujeran, pero ocurria que no se sincronizaba bien, o con la memoria, o con la parte gráfica, y les tocó rebajar su capacidad también. No se si además tocaron la arquitectura, lo digo pero no implica que sea cierto. Fueron retocando cada componente hasta dejarlo como lo conocemos ahora.

Mas o menos lo recuerdo así. ¿Cuanta potencia se perdió por el camino a causa de todo esto?, pues ni idea, pero mis sensaciones cuando lo leí fueron bastante considerables.

@Señor Ventura
Sí, esa la historia que siempre he escuchado, el estándar de frecuencias para ese tipo de CPU eran 80, 100, 133 MHz, los cambios que tuvieron que hacer al RCP a saber, en base al pdf oficial de Nintendo subió de 60 a 62.5Mhz (lo puse hace tiempo en el hilo), pero a saber si la cifra original era más alta o el chip diferente.

@EMaDeLoC
Lastima que usara Top Gear Rally, uno de los juegos más estables del sistema y no alguno más irregular para ver si mejoraba algo.

@EMaDeLoC Creo que el tema de los relojes de la N64 iba así:
Hay dos cristales con su correspondientes chips multiplicadores y divisores para generar dos frecuencias (o combinados en un solo chip que reune ambas funciones en modelos posteriores):
Del primero se saca la frecuencia del bus entre la RDRAM y el RCP, que va a 250MHz. De ese pulso, el RCP deriva la frecuencia del bus entre si mismo y la CPU, y esta, como sabemos tiene su propio multiplicador del que sale el famoso overclock que pone todo a cámara rápida porque la mayoría de juegos sacan de ahí su nocion de paso de tiempo.
Este reloj es el mismo en todas las consolas, ya sean NTSC, PAL o MPAL.
Luego está el cristal y multiplicador del que se deriva la velocidad del bus digital AV que comunica los componentes VI (Video Interface) y AI (Audio Interface) con los correspondientes DACs de video y audio. Este reloj varía entre regiones dado que de el también deriva el DAC de video la frecuencia de la portadora color para video compuesto y s-video.

Según me comentó marshallh una vez hace años, entre el AI y VI y el resto del RCP hay un FIFO para lidiar con la diferencia de frecuencia entre el bus AV digital con el que está sincronizado y la frecuencia interna del resto del RCP.

Por tanto, si todo esto lo estoy recordando bien, la frecuencia del RCP no se deriva realmente del bus de video, si no que es universal entre todas las consolas.

Que el overclock del RCP estropee la señal de video puede deberse a una de varias razones o una combinacion de ellas:
-Sobrepasar la capacidad de ese FIFO para lidiar con la diferencia de frecuencias
-El hecho de que el RCP tiene que generar un modo de video que encaje con lo que el VI puede aceptar a su actual frecuencia
-Mera inestabilidad por overclock.


(NOTA: Mi ausencia todo este tiempo se debió, entre otras cosas, a que ya no tengo nada de consolas. Cosas de la vida. Prefiero no hablar de ello, pero dada la naturaleza del hilo, y mi historial previo, consideré que era necesario hacerlo saber)

Hola @radorn , me alegro de verte por aquí.

radorn escribió:Por tanto, si todo esto lo estoy recordando bien, la frecuencia del RCP no se deriva realmente del bus de video, si no que es universal entre todas las consolas.

Pues revisando la documentación efectivamente el reloj de vídeo es independiente del RCP. Yo también lo decía de memoria, pero claramente la tuya es mejor que la mía.
Sin embargo la salida de vídeo digital sigue generandose enteramente en el RCP, y si esta calibrada según la velocidad del reloj del chip, puede que se altere demasiado cuando hay un OC, aunque haya un FIFO encargandose de pasarla con otra frecuencia universal al DAC.
Es la conclusión que saco de que OC a la CPU sea en cierta manera común, pero hacerlo al RCP no tanto.

Pero vamos, me fio más de tu experiencia que de la mía.

Alguien en otro foro contó sus peripecias cambiando cristales en la consola. La conclusión es que el vídeo se va al carajo a menos que se use un mod HDMI que da cierto margen, pero no mucho, e igualmente aparecen otros errores.

Y sin querer entrar en tu vida como pides, espero y deseo que te vaya bien, y que puedas aportar tu sabiduria en el foro proximamente.

La conclusion que saco yo es que no se puede hacer OC a la consola sin adaptar el software para operar adecuadamente bajo las nuevas sincronías. Puede que incluso haya que sacrificar la compatibilidad con señales de video normativas, y hasta con los DACs originales, pues, incluso si nos limitamos a RGB o sacrificamos el color en compuesto y svideo, lo cierto es que el DAC recibe una orden desde el bus de video para generar un pulso de sincronizacion que posiblemente no tendría la duración apropiada para el nuevo modo de video, aún asumiendo que tuviesemos un receptor capaz de sincronizar a la velocidad rara con la que acabásemos. Si bien también puede que esto último no fuera demasiado problema en la práctica, tiene potencial para causar dificultades.

Para que esta modificacion fuese útil, habría que hackear o, mas bien, decompilar, modificar, y recompilar (algo potencialmente posible ahora en algunos juegos) todo el software para que quisiésemos usar con este mod OC, que, además, tendría que ser conocido y, para ser realistas, suficientemente popular y extendido como para justificar tal esfuerzo.

Primero habría que hacer un OC equilibrado que modificase tanto el complejo RDRAM-RCP-CPU como el subsistema AV, sustituir completamente los DACs, y modificar el software, tanto a nivel del motor, para ajustar la escala temporal en todos los componentes del motor que lo requieran (una tarea ardua sin duda, aún asumiendo que se tenga un codigo fuente funcional) como tambíen la especificacion del modo de video para el RCP y VI. Todo esto al mismo tiempo. Todo es interdependiente. Las partes no son útiles por separado.

Igual me equivoco, pero yo creo que es algo que jamás despegará, a no ser que alguien ponga mucho esfuerzo y recursos en ello.
Si alguien diseñase una técnica de OC que se hiciese popular y la hiciese mucha gente, habría una base establecida y podría valer para desarrollos nuevos y las modificaciones de juegos licenciados que la comunidad se animase a hacer, pero es la pescadilla que se muerde la cola. Ambas cosas dependen la una de la otra. Sin software diseñado para tal mod OC nadie querrá modificar su consola porque no sirve para software existente, y sin una base de usuarios que tenga hecho semejante mod ¿quién se va a animar a hacer algo que solo va a correr en su consola particular?
Tendría que aparecer de un paladín de brillante armadura que diseñase un mod OC de aplicacion universal, preferiblemente, o sea, que valga en cualquier versión de la consola, y, al mismo tiempo, producir contenido para dicho mod, lo suficientemente interesante como para que mucha gente se anime a hacerlo solo para poder usar ese contenido, y así se podría abrir una puerta a que saliesen mas cosas... El problema es que, visto lo visto con la consola, no parece que se pueda hacer un OC que inmediatamente beneficie el software existente sin efectos secundarios. Solo valdría para desarrollos nuevos y modificaciones. No vale sacar el mod sin software compatible.

En fin. A mi todo esto ya no me afecta al carecer del hardware. Ahora, como mucho, usaré emuladores.

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

Pensando un poco mas en el tema, una idea muy remota y que con una certeza del 90% fracasará a nivel de hardware pero que tendría cierta viabilidad potencial a nivel de software es la siguiente

Del clockgen que da la frecuencia al bus de RDRAM del que se nutren esta, el RCP y la CPU, sale una frecuencia de 250MHz. De ahí, el RCP deriva sus 62.5MHz (divide entre 4), que a su vez sirve de frecuencia para el bus entre este y la CPU, que, con un multiplicador de 1.5X llega a los 93.75 que conocemos.
El selector del multiplicador de la CPU se puede aumentar, si... pero también se puede reducir: en vez de tomar los 62.5 y multiplicar por 1.5 para obtener 93.75, ¿que tal si ponemos el multiplicador a 1x (las opciones son 1x, 1.5x, 2x y 3x), y overclockeamos la RDRAM a tal velocidad que haga que el RCP vaya a 93.75, pasandole esta velocidad a la CPU, sin necesidad de multiplicar nada?
El problema claro, es que la RCP iría a 93.75MHz (un aumento del 50% respecto a la velocidad normal) y la RDRAM igualmente subiría un 50%, de 250MHz a 375MHz... pero bueno, con una buena cantidad quizá con nitrógeno líquido, yo creo que....
La idea de esta locura es que mantendría la CPU a su velocidad original... lo que le haga al resto de componentes y como reaccione el software ya no sabría decirlo. Lo que es bastante seguro es que no creo que nadie lo haya probado, así que no se puede decir con certeza que no funcionaría xD

@radorn Es demasiado overclock para la RDRAM.
El tema no es la temperatura, que también, sino que cada método de fabricación de transistores tiene su tiempo de propagación que le da su velocidad máxima. En un datasheet que puse por el hilo la máxima velocidad de reloj son 250MHz, porque será la velocidad que garantiza una estabilidad del 100%. Quizá con nitrógeno líquido y subiendo voltaje se pueda llegar a 275MHz, pero a partir de ahí sería demasiado inestable. O ardería en llamas...

No recuerdo cuanto se podía retocar por software la señal de vídeo. Sé que se puede establecer la resolución y si es vídeo NTSC o PAL, pero los timmins concretos de vídeo... No estoy seguro.

@EMaDeLoC Yo de OC se muy poco, pero lo que dices tiene sentido, así que mi locura queda descartada.
Sería interesante ver qué resultado daría al aplicarlo aplicarlo en un emulador LLE...

Respecto a lo de cambiar los modos de video. En principio parece que el VI necesita que se le proporcionen unos parámetros para configurar la salida de video. Conker64, en su anterior encarnacion con un nick que ya no recuerdo, me había pasado unos valores para NTSC porque me picaba la curiosidad de ver si lograba entender cómo funcionaban esos valores. Está en este hilo pero ya no recuerdo los detalles. A algunos valores les pude encontrar el sentido y la relacion a los timings que conozco, pero con otros me fue imposible por mas vueltas que les dí.

Yo creo que la temporizacion de video no se escoge como si fueran opciones predefinidas, si no que se define con parametros que se le pasan al VI. Tiene sentido que sea asi teniendo en cuenta que se necesita dar soporte a tres velocidades diferentes de bus AV desde el mismo chip. y que, además, como recordarás, al usar los modos de video oficiales de un formato en una consola de otra región, acababa variando la velocidad (NTSC en consola PAL daba 61.x Hz, aunque creo que eso solo afectaba al refresco de pantalla y no al ritmo de juego, pero tampoco se de nadie que hiciese pruebas consistentes)

Se que al principio de la scene, debido a los sistemas que se usaban para cargar ROMs de otras regiones, se hicieron parches y parcheadores (PALadin, por ejemplo) que incluían arreglos para audio por diferencia del timing esperado por la ROM y el que tenía la consola. Creo que básicamente cambiaban el tamaño del bufer de audio a nivel de libultra.

Me han pasado esta imagen supongo que lo habrá visto alguien