N64 PAL juegos de otra región

Los juegos de n64 tienen protección regional en el juego,para jugar a juegos de regiones diferentes a tú consola necesitas un adaptador que creo que se llama passport y que básicamente hace de puente entre un cartucho de la misma región que la consola y uno de otra región.
Salud.

Muchísimas gracias a las dos respuestas

Radorn me he quedado en blanco al ver tu respuesta muchas gracias por compartir tu sabiduría con todos nosotros, tu respuesta merece estar como tema principal de la sección retro la verdad...

Muchas gracias de nuevo, creo que como dices me voy a tener que pillar un cartucho que lea copias de seguridad mediante Roms, como tengo en super Nintendo que es una delicia

Sin problema. Espero haberte aclarado las dudas. Tiene su complicacion si te metes en detalles, pero, un un cartucho para ROMs basicamente te olvidas de todas ellas porque ya lo hace todo por ti.

elamhz escribió:Radorn me he quedado en blanco al ver tu respuesta

Hombre, no me digas eso, que seguro que de alguna cosa te habrás enterado

@radorn dinos la verdad, tú trabajaste en Nintendo en la división de desarrollo de hardware entre 1993 y 1999 ¿Verdad?

@Falkiño Juas. Si fuera verdad eso, estaría escribiendo mi propio motor para N64. En vez de "Unreal Engine" se llamaría "Ultra Engine" xD ... Claro que estaría maniatado por el secreto industrial y tampoco podría decir nada sobre el tema... así que quien sabe, igual si que soy un ex-ingeniero de N64 xD

Aprovecho y añado un posible cuarto metodo retorcido de restriccion anti-copia y anti-importacion.

Yo tengo N64s PAL y NTSC, y actualmente estoy jugando en la NTSC puesto que normalmente son esas versiones de los juegos las que uso. Si bien hay versiones PAL que tienen algun aspecto ventajoso sobre las NTSC, y no hablo del idioma, habitualmente la version NTSC es preferible.

El caso es que estaba jugando al mierdosillo SOUTH PARK, el FPS o "shot'em up subjetivo" (como los llamaban las revistas en mis tiempos) basado en el motor del Turok 2. Jugaba la version NTSC en la consola PAL.
Estando en el episodio donde todo el pueblo queda convertido en una especie de zombies-mutantes, llegué al jefe final, una abominacion bulbosa con tentaculos que te espera en el aparcamiento (por alguna razon cerrado con un muro) de la biblioteca municipal. Así que peleo con el, lo mato, sale la secuencia cinematica con los cuatro crios comentando la jugada, la pantalla hace fundido a negro... y en vez de mostrarme la pantalla de puntuacion y darme la oportunidad de salvar antes de pasar al siguiente episodio, resulta que el juego me devuelve el control del personaje, en el mismo recinto donde estaba el jefe, sin posibilidad de salir ni hacer nada mas porque no hay ninguna puerta ni nada.
Supuse que sería un error accidental así que me armé de paciencia y maté al jefe otra vez, con el mismo resultado, y quedandome con cara de idiota.
No se cual fue el razonamiento que seguí pero decidi poner la consola NTSC e intentarlo una vez mas, y, esta vez si, pasé la fase, vi la puntuacion, guardé y pude seguir adelante.

Durante bastante tiempo pensé que sería algun aspecto raro de la programacion que se atragantó en la diferencia de la frecuencia del BUS de video entre la consola PAL y NTSC. Completaron el juego en unos pocos meses reutilizando el motor que ya tenían, por eso el juego es tan soso y repetitivo, asi que no sería sorprendente que fuera un bug. Pero tambien se me ha dado por pensar si no sería uno de esos metodos retorcidos que a veces se usan para fastidiar a los piratas e importadores. Ya sabeis, el juego parece funcionar, pero hay cosas que fallan, te borra la partida o alguna otra patada en la espinilla.
La verdad es que en N64, salvo Rare que lo hizo en al menos dos juegos (DKR y JFG), no parece que haya mucho de eso, pero es una posibilidad a tener en cuenta.

Supongo que debería comprobar si la version PAL del juego tambien tiene este problema, tanto en la consola PAL como NTSC. Si fue un bug, quizá en la version PAL, que siempre se hacen despues, lo arreglaron... o igual ni siquiera eso y sigue ahí el bug, haciendo la version PAL imposible de terminar... xD La verdad, no creo que haya mucha gente que se haya pasado ese juego.

@radorn mil gracias por las explicaciones!

Me parece muy interesante lo de los CIC aunque no sé si termino de entender cómo funciona... Por favor corrigeme si me equivoco:

Por lo que he entendido, por un lado el CIC del cartucho valida el contenido de la ROM del mismo cartucho, ¿no? De esta manera, no podremos utilizar la ROM de un juego más moderno con el CIC de un cartucho más antiguo. Una pequeña protección anticopia para que no valgan juegos nuevos con copiones que utilizan CICs antiguos.

Y por otro lado, también la consola está preparada para aceptar unicamente CICs de su versión. Es decir, para PAL serían 710X. Esto es lo que verifica el PIF, ¿no?

Es decir, que tendríamos:
PIF (consola) - CIC (cartucho) - ROM (cartucho)

El PIF tiene que encajar con el CIC. En el prefijo (71 para PAL, 61 para NTCS).

Y luego el CIC con la ROM en el sufijo (bueno, los dos primeros tienen la nomenclatura invertida, pero espero que se entienda lo que quiero decir).

De esta manera, los adaptadores para otra región funcionarían siempre y cuando tuvieras la misma versión del CIC equivalente para la versión de la consola.

Los adaptadores siempre han sido algo que me han intrigado. Recuerdo uno que compré en Francia que ponía "support latest game Starfox 64", pero que no recuerdo que funcionase.

Y luego recuerdo aquél Passport Plus III de EMS que era el que sí que podía decir que me funcionase, por lo menos a mi. Porque recuerdo leer a mucha gente que se le había "fundido". En aquella época que se compraba poco por internet, recuerdo haberlo encargado en Chollogames (la tienda del centro de Madrid), pagando por adelantado y asumiendo yo la responsabilidad si no funcionaba. Le puse un cartucho third sin memoria interna y conseguí jugar al Sin and Punishment
Pero no quise trastear más, no se me fuera a "fundir". Otro día que pasé por Chollogames me reconocieron y me preguntaron que si yo era el del Passport 3 que si me funcionaba, a lo que asentí. Se sorprendieron, así que deberían de haber tenido más de un problema de que no funcionase.

Ahora que leo lo de que se les corrompía la memoria en lugar de "fundirse", me intriga mucho más saber cual era el problema por el que se brickeaba.

Curioso lo del South Park. Probé el juego en su día y por lo menos alguna risa me eché. No sabía que habían fusilado el motor del Turok de esa manera. Pero todavía recuerdo en el menú de opciones que podías elegir el tipo de control entre "Two Rock" (Turok) o "Brown Eye" (Goldeneye).

@avalancha
No te creas que yo entiendo todo el proceso de comunicacion entre el CIC y el PIF. Se los aspectos superficiales basicos y gracias. El proceso paso a paso, o qué es lo que diferencia la version PAL y NTSC de los mismos, por ejemplo, no lo conozco.
Pero a ver si consigo aclararte las dudas que planteas.

En toda ROM de juegos licenciados oficiales hay hay una cabecera de 1K los primeros 64bytes contienen:
-Una serie de valores de configuracion del hardware
-Dos CRCs que se calculan sobre el primer 1MB de la ROM después de la cabecera.
-Titulo del juego en 20 caracteres
-Codigo de idenfiticacion de producto en 4 caracteres en mayúsculas:
incluye un caracter que identifica el tipo de ROM (N=Cartucho, D=Disco 64DD, C=Cartucho con enlaces a un disco de 64DD), dos caracteres que identifican al juego (SM = Super Mario 64, ZL = Zelda Ocarina, Z2 = Zelda Majora... y muchos mas, obviamente, asignados por Nintendo segun iban saliendo juegos), un caracter de identificacion de region/idioma (Japanese, English, PAL, Spanish, Italian, French, Deustch, AUstralia... hay alguno mas raro)
-Finalmente un byte de version/revision de la ROM en hexadecimal. Cuando en los conjuntos de ROMs (GoodN64, No-Intro, TOSEC) ponen v1.0, 1.1, 1.2... se corresponden con 00, 01, 02 en este byte. Claro que luego te encuentras ciertas ROMs con valores raros como FF o 0F, como es el caso de las versiones de Zelda para GC y la Virtual Console, muchas versiones beta filtradas... y otras cosas.

Despues del estos 64bytes, el resto del 1K contiene el bootcode, que tiene que ser compatible con el CIC de turno.
No estoy muy seguro de cómo se combinan estos elementos, pero, por un lado tenemos el CIC y el PIF comunicandose, para lo cual tienen que ser del mismo tipo (NTSC, PAL, MPAL), sin lo cual el PIF no arranca la CPU de la N64. Una vez llegados a este punto, estándo la CPU arrancada a cierto nivel, se lee la cabecera de la ROM a la RAM y tambien el primer mega despues. El bootcode, que creo que se ejecuta en la CPU, interactua de alguna manera con el PIF y el CIC para permitir el calculo de las sumas de comprobacion de ese primer 1MB de ROM, y se compara el resultado con los valores de la cabecera. Si todo sale bien, el PIF permite el arranque completo y la ejecucion de la ROM. Pero si la combinacion de CIC, bootcode y CRCs no es correcta, el juego no arranca y lo unico que obtienes es una CPU en bucle NOP y una pantalla en negro.

Una vez arrancado el programa de la ROM, entraría en juego lo de comprobar el OsTvType si es que esa ROM en particular usa esa tecnica. Bastantes ROMs pasan del OsTvType, aunque no tantas como sería deseable, especialmente de juegos de primera linea.

Lo de los diferentes CICs, el patron no se corresponde con una simple progresion temporal. Primeramente todas las 3rd parties usaron siempre el CIC "normal", el 7101/6102 y nunca se molestaron con las revisiones posteriores. Los juegos publicados por Nintendo si fueron usando los nuevos, pero no siempre en progresion.
Por ejemplo, Zelda Ocarina usa ya el x105, pero hay juegos posteriores que usan el x103.
Cada desarrollador escogía el CIC segun le parecía. Me imagino que los CICs posteriores serían mas caros tambien.

Hago un inciso para añadir que el x105, además de hacer variar el calculo de los CRCs, tiene una caracterísitca que no tienen los demás, que es que ofrece una funcion por la cual el juego puede mandar en cualquier momento un "desafío" en forma de valor numerico, y el CIC x105 le devuelve un valor de respuesta. Cada valor de "desafío" siempre tiene la misma respuesta.
Solo Rareware implementó esta funcionalidad en la seguridad de dos de sus juegos.
En Jet Force Gemini, si el juego no puede obtener las respuestas a los desafíos, impide al jugador saltar, correr y creo que disparar, haciendo el juego imposible.
Banjo-Tooie, por otra parte, tiene buena parte de su contenido encriptado, y el sistema de desencriptado integra los valores de respuesta del CIC en el algoritmo, de forma que sin un x105 autentico, no hay desencriptacion de contenidos, y no hay juego xD.
Esta tecnica impide el uso de boot-emulators, porque, aunque con estos se puede superar el chequeo inicial de arranque usando un CIC diferente al con el que está "firmada" la ROM, cuando el programa que ya corre en la CPU empieza a mandar "desafios" al CIC, este no puede ofrecer las respuestas esperadas.
Estos juegos tuvieron que ser crackeados en su momento para superar esta medida anticopia. Existe parche para las versiones PAL y NTSC de JFG, pero en el caso de BT creo que solo hay para NTSC y para PAL no, pero no estoy seguro.
El 64drive se puede configurar para usar un x105, superando este impedimento, y la revision HW2 del mismo incluye un UltraCIC, capaz de ofrecer las respuestas a los desafios incluso corriendo en modo 6102/7101.
El Everdrive creo que depende de las versiones hackeadas.

En la epoca de los copiones, cuando empezaron a salir juegos con CICs nuevos, una de las primeras tecnicas que use usaron fue modificar la ROM reemplazando el bootcode en la cabecera de la ROM por el bootcode 6102/7101 y recalculando los CRCs.
Rareware combatió esto en Diddy Kong Racing, un juego que usa originalmente el x103, de manera que si detecta el bootcode modificado, renderiza los graficos mal, cambiando el motor del juego para renderizar la cara trasera de los poligonos en vez de la delantera, y luego el juego acaba cascando tambien xD... Tengo que grabar un video de eso en algun momento.
@Conker64 igual te interesa a ti, y hasta puedes hacerle un analisis mas profundo para tu pedazo de hilo


Con respecto a lo de los adaptadores de importacion: Yo en aquella epoca no tenía acceso ni mucha idea de importar nada, y la idea de pagar una millonada para traer un juego del extrangero en vez de esperar al lanzamiento local me parecía un tanto ridicula y para gente sin capacidad de paciencia. En parte tenía razon, pero tambien había ventajas que en alquel momento, en mi ignorancia, se me escapaban. El caso es que yo no tuve un Passport3 hasta 2010 o así, y de modelos anteriores tampoco tengo idea. Eso si, del cadaver putrefacto de mi primer PP3 que murio, me fabriqué un simple adaptador que hace pasar la linea del CIC de la ranura trasera a la consola, permitiendome hacer algunas tareas. Subí un video en el hilo de curiosidades de N64 hace meses donde se me ve usandolo para demostrar una serie de curiosidades.

Lo de la corrupcion/fundirse, es culpa del propio diseño, que comparte con toda los ActionReplay/GameShark en los que está basado. Estos cartuchos, por su funcionalidad, tienen que tener una memoria interna reescribible para poder almacenar los codigos de trucos, y el AR/GS tambien aceptaba actualizaciones del software mediante algunos metodos.
La raiz del problema es que, siendo un cacharro barato (al margen del precio al que lo vendieran), TODO, el software, la lista de codigos y probablemente hasta la memoria de configuracion del FPGA que implementa toda la logica del cartucho, va almacenada en la misma memoria reescribible (dos chips eeprom creo).
Como el software tiene bastantes bugs, es muy facil que con cualquier accion se corrompa algo en esa memoria y ya nunca pueda volver a arrancar por si mismo. Quizá solo se te fastidie la lista de codigos y el cartucho arranque hasta que entre en el menú e intente leer la lista y muera en el intento, o quizá la corrupcion haya tocado la ROM de arranque en si y ya ni muestre la pantalla de logotipo...
Mi primer PP3 murio, si no recuerdo mal, experimentando cargar mis juegos PAL en la consola NTSC que compre con Conker. A partir de entonces, al arrancar, salía el logotipo del fabricante, pero cuando tenía que salir el menu, veía una pantalla negra durante un segundo o así, y, luego, basura digital. Precioso... Mi diagnostico: Lista de trucos corrupta, el menu intenta leerla y muere en el intento... o quizá la corrupcion tocó alguna otra cosa, quien sabe.
El software de estos cartuchos tiene muchos bugs y facilmente sobreescriben lo que no deberían y se te quedan tocados para siempre...
Ni el AR/GS ni, especialmente, derivados como el PP3 tienen ningun mecanismo de recuperacion en caso de estos previsibles desastres. En el caso de los primeros, tenías que mandarlo de vuelta al fabricante para que lo reflasheasen, y en el caso del PP3, siendo de Hong Kong... no creo que ofreciensen si quiera eso.

En el AR/GS, además, está esta funcion que tienen para usar juegos con CICs diferentes, mediante la cual tienes que arrancar el cartucho con un CIC "normal", ir al menu de "keycodes" y seleccionar uno diferente con la esperanza de que se corresponda con el CIC del juego que quieres usar. En ese momento, la ROM del AR/GS ha sido modificada para sobreimponer un CRC nuevo compatible con el CIC del juego que quieres usar. Lo cierto es que incluso el bootcode para ese CIC es leída desde la ROM del cartucho original, pues, siendo codigo con copyright, la ROM del AR/GS no lo incluye. Una vez seleccionado el keycode, con la ROM del AR/GS ya modificada con los CRCs apropiados, apagas la consola. En este momento, el cartucho de trucos ya solo es arrancable con un juego que contenga el CIC y bootcode apropiados, que ya no es Mario 64 o el juego "normal" que en este momento tengas conectado. Mucha gente "ladrilleaba" sus cartuchos de trucos de esta manera, pues seleccionaban un keycode equivocado y luego no tenían un cartucho apropiado para volver a arrancar.
Una vez arrancado el AR/GS con el nuevo keycode y cartucho correspondiente, en el momento en que el menu del cartucho de trucos arranca, automaticamente restaura los CRCs a los correspondientes al CIC "normal", de manera que la siguiente vez que arranques, tendrás que volver a usar un cartucho estandar. Esto quiere decir que si, por ejemplo, estás hackeando el Zelda (x105) y, por la razon que sea, tienes que apagar la consola, para el siguente arranque, tienes que volver a poner Mario 64 o Turok, o alguno de esos, cambiar el keycode desde el menu, apagar, poner Zelda y, ahora, si, arrancar con Zelda... me da vueltas la cabeza un caldo de cultivo perfecto para equivocarse de keycode y ladrillear el cacharro xD
Por suerte yo tengo CICs de todos los tipos (al menos en PAL), así que puedo sobrevivir a esto.

Luego está el X-Ploder 64 (o X-Plorer 64, no estoy seguro), mucho menos extendido y del que casi no se nada. En un canal de IRC de GoldenEye hace años hable con un tio de finlandia que tenía uno, y le hice alguna pregunta, pero no obtuve mucha informacion clara, la verdad.
Creo que maneja el cambio de keycodes de otra manera, sin necesidad del menu, lo cual lo hace mucho mas seguro en ese sentido.
Con respecto a la corrupcion de la ROM, ya no tengo ni idea.

Mi Action Replay se murió despues de arrancar PilotWings con un codigo que me permitía reemplazar el modelo 3D del girocoptero con el del biplano Cessna que se ve volando entre los aeropuertos del nivel Little States. El juego arrancó, disfruté del truco, y cuando volvi a encender la consola, ya no arrancó mas...
Años despues logré revivirlo con una combinacion experimental del PP3 muerto que mencioné y un cartucho flash con una ROM de AR con cabecera modificada y un PC antiguo con puerto paralelo de impresora. Con todo eso y un par de truquillos, logré poner al AR muerto en una consola con el menú del AR corriendo, lo que me permitió re-flashearlo con una ROM en buen estado, reviviendolo.
En su dia lo comenté en un par de foros en ingles pero nadie mostró ningun interes. El proceso que ideé era una locura y es un milagro que funcionase xD, y ya ni recuerdo todos los detalles exactos.

La tecnica que se comenta por ahí desde hace años para revivir AR/GSs muertos necesita de usar, y arriesgar la vida de, un segundo AR/GS en buen estado. Yo no tenía un segundo AR, ni ganas de comprarlo para arriesgarme a matarlo tambien, así que pensé en algo diferente y loco y me salió bien xD

radorn escribió:El 64drive se puede configurar para usar un x105, superando este impedimento, y la revision HW2 del mismo incluye un UltraCIC, capaz de ofrecer las respuestas a los desafios incluso corriendo en modo 6102/7101.
El Everdrive creo que depende de las versiones hackeadas.

Las dos versiones actuales de Everdrive usan UltraCIC II y no necesitan de versiones hackeadas para los juegos.

@EMaDeLoC Ah, bien, no lo sabía. No estoy actualizado con las versiones de los EDs la verdad Me quedé en las que dependian exclusivamente de CICs originales y tampoco podían usar el x105 porque el menú estaba firmado solo para el CIC normal.

@radorn Uf, han pasado años desde entonces...

@EMaDeLoC Ya te digo que no le sigo la pista a la acera Everdrive de la calle retro. Probablemente debería estar un poco mas al tanto, pero empezando porque los primeros modelos me parecieron muy limitados y me fui al 64drive, y luego empezaron a sacar actualizaciones una tras otra para cosas que el 64drive ya tenía o se podían añadir con una actualizacion de firmware y tal... la verdad es que me dejó una impresion de chapuza y desconecté.
Ya veo que luego fueron ganando soporte, y el hecho de ser la opcion mas barata (relativamente, estas cosas baratas no se puede decir que sean, a no ser los clones chinorris) también invitó a mas gente a añadir capacidades al menu y todo eso, y, si bien no me gusta la forma de hacer del entorno ED, no puedo negar que ahora tiene cosas que el 64drive aun no y que lleva años de retraso en implementar, como el motor de trucos.
Creo que este año podría haber novedades muy interesantes en el 64drive. He hablado con marshallh sobre el tema, pero no se en que punto del proceso está en este momento. Habrá que esperar.