[HILO OFICIAL] Nintendo 64

En las distintas revisiones de placas de N64 se han usado 4 chips DAC de video distintos:
-VDC-NUS: típico de las primeras consolas NTSC, las famosas NS10xxx y NJ10xxx con el mod "fácil" a RGB.
-S-RGB A: exclusivo de las N64 francesas NUS-001(FRA) con RGB oficial.
-DENC-NUS: El mayoritario presente en las siguientes consolas y en las PAL
-AVDC-NUS/MAV-NUS: Presente en las consolas más modernas, más barato de producir e instalar.
Y por las especificaciones, todos los chips sacan S-video.

Peeeeroooo... Las N64 francesas no tienen cableado el S-video del chip al conector, por lo que solo sacan compuesto. Que yo sepa son las únicas que no sacan s-video nativo. Aunque es posible añadirselo con dos resistencias, dos condensadores y algo de maña. Pero para eso metes RGB y te quedas más contento...

Cambiando unos componentes de las placas las N64 pueden configurarse como PAL o NTSC. Es decir, podian fabricar placas genéricas y después añadir los componentes para una región a otra según necesidades. Por eso todos los chips sirven para todas las regiones.
Otra cosa quizá no, pero para ahorrar pasta en producción los de Nintendo son unos putos genios...

@P13RR3 Otra cosa sobre lo de los cables S-Video en general, no solo por la N64.
S-Video es un tipo de señal en dos partes que transmite luminancia y crominancia por separado, sin embargo, si no hay buen apantallamiento (shielding) electromagnetico entre ambos hilos, por la proximidad entre estos a lo largo del cable desde la consola hasta la TV, acaba por filtrarse, una en la otra por interferencia electromagnetica.
Debido a cómo estan codificadas estas señales, el resultado mas visible es que aparecen puntitos por toda la pantalla, que es la señal de cromimancia entrando en la de luminancia, especialmente donde hay colores intensos.

Yo mismo aun no tengo un cable de calidad que apantalle bien, y puede hacerse bastante notorio. En una TV CRT puede que tengas que fijarte bastante y ser consciente de ello para notarlo, pero en cualquier otro tipo de TV o captura a PC, si se nota bastante.

Este es el tipo de advertencias que depende de tu caso personal a veces es mejor no saberlas y vivir en la dulce ignorancia, pero en otros casos te salvan de una sorpresa desagradable. Yo me curo en salud y lo digo xD

El cable que enlazaste, si es como aparece en la foto, tiene pinta de no tener nada o casi nada de apantallamiento, viendo lo fino que es el cable, y seguramente presente este problema. De hecho, creo que tuve uno igual hace años.

Muchas gracias por la información extra @P13RR3, @radorn y @EMaDeLoC

La Nintendo 64 que tengo no es ni de las transparentes ni la edición Pikachu, por lo tanto creo que no voy a tener problemas

Un saludo

@radorn
Soy consciente del cable que tengo, comencé con RCA y pase a este, obviamente note mejoría, pero como dices, en la ignorancia se es feliz, hasta que empiezas a saber cosas como el apantallamiento del que hablas y la importancia de tener un cable con calidad, así que esté hecho lo solucionaré, espero, con un cable del famoso thefoo83 (no sé si lo escribí bien), que parece que dan buenos resultados.

EMaDeLoC escribió:-S-RGB A: exclusivo de las N64 francesas NUS-001(FRA) con RGB oficial.

Yo tengo una N64 francesa NUS-001 ¿simplemente con un cable RGB oficial de Nintendo se vería ok? ¿hay que hacerle un mod, no?

@cegador
Pero seguro, ¿eh? La etiqueta es así:


En tal caso tienes dos opciones:
-Instalarle el mismo mod amplificador RGB que las primeras NTSC. Es fácil de poner pues se inserta en los pines del conector de salida y luego sueldas 3 cables en la placa base. Son los mismos puntos en ambas placas, pero con cuidado de no meter mucho cable por el agujero, pues podría hacerte cortocircuito con el chip del otro lado. Si instalas este mod necesitarias un cable RGB de Gamecube con Sync stripper o Sync-on-luma. También un cable SNES NTSC con sync-on-luma.

-Comprar las partes que faltan e instalarlas. En ebay encuentras kits, más baratos que el otro mod, con todas las partes que necesitas. Problemon: son piezas minúsculas, apenas 2mm la más grande. Necesitas a un neurocirujano para soldarlas en su sitio. Encima una pieza (el diodo zener) no suele venirte en el tamaño que toca y tienes que hacer un apaño para soldarlo y que quede bien. Aún así yo lo recomiendo porque no existe RGB más cercano a uno oficial. Con este mod necesitas un cable RGB para SNES PAL con C-sync. También te valdría uno con sync-on-composite y sync stripper. Como dije antes, la francesa no saca s-video así que un cable con sync-on-luma no te va a funcionar. Pero como dije el chip si tiene salida de s-video, pero aún mejor, tiene salida C-sync limpia. Solo tendrías que soldarle un cable a ese pin del chip y soldar el otro extremo al pin de salida luma del conector de video y podrías usar un cable de SNES PAL con sync-on-luma. Es soldadura dificil también, pero si has podido soldar las partes que faltaban, esto será pan comido.

Bueno, igual te he saturado de información... Si hay algo que no entiendes preguntamelo.

@EMaDeLoC Cuando llegue a casa confirmo que es francesa NUS-001.

La tengo conectada con un cable s-video (ni idea de qué tipo es, pero todo funciona ok). Resulta que el cable me toco en un sorteo que hizo Conker64 (cuando tenía otro nick )

PD: Me acabo de acordar de que por casa tengo un cable RGB de Super Nintendo que compré hace años a retrocables (que no he llegado a sacar de su plástico)...

cegador escribió:La tengo conectada con un cable s-video

He comentado antes que la francesa no tiene cableado el s-video...
Es un poco raro. Luego pon fotos si puedes del cable y como lo tienes conectado a la tele.

La pegatina de mi consola:

Vale, no pone FRA. Lo debí soñar.

Edito: la confusión se debió a una web de modificaciones que visité en su momento... entendí que si mostraba NUS-001 era francesa...

@cegador Quizá la obtuviste de francia o algo así y te quedaste con la idea de que era el modelo especifico francés. Lo que pasa es que solo las primeras remesas de consolas francesas eran RGB+SECAM (el sistema tradicional de TV analogica en color en francia, distinto de PAL). Despues se dejaron de complicaciones y metieron consolas PAL normales en Francia, dado que la mayoría de TVs francesas tambien aceptaban ese formato por conexion de video compuesto (no necesariamente por antena).

Lo siguiente son datos vagos y especulaciones mias, no tengo datos confirmados ni solidos, así que si alguien sabe cómo fue la cosa en realidad, a ver si lo puede aclarar.

Recuerdo en su dia que la Nintendo Acción sacaba una pequeña nota de prensa hablando de un retraso de uno o dos meses en el lanzamiento de la N64 en Francia debido al formato de TV SECAM (que estaba mal escrito o lo leó yo mal como "ESCAM" xD). Luego, por internet, recuerdo vagamente leer algo de que la N64 francesa vino inicialmente con un conversor interno de RGB a compuesto SECAM, o quizá externo.
Tambien es posible que usasen RGB directamente, pues fue precisamente la industria audivisual francesa la que inventó el conector de 21 patillas Péritel, mas conocido por todo el mundo como SCART, siendo RGB parte de la especificacion inicial (no así S-Video), pensado principalmente para ser usado con decodificadores externos de Teletexto. El proposito de mencionar esto es que se me antoja probable que Francia de aquella tuviese una mayor cantidad de TVs compatibles con RGB por SCART que otras partes de Europa, haciendo factible su uso como conexion principal en ausencia de un codificador SECAM especifico para el mercado francés (y quiza el ruso y algun pais africano, donde tambien se adoptó SECAM por diferentes razones), que no tendría un rendimiento economico particularmente beneficioso para Nintendo.

cegador escribió:

EMaDeLoC escribió:-S-RGB A: exclusivo de las N64 francesas NUS-001(FRA) con RGB oficial.

Yo tengo una N64 francesa NUS-001 ¿simplemente con un cable RGB oficial de Nintendo se vería ok? ¿hay que hacerle un mod, no?

Ojocuidao con el tema de moddear para RGB, porque si no usas el mod universal de Tim Worthington (el que añade el RGB a cualquier N64 sin importar región) y lo que haces es completar el circuito RGB de una N64 FRA, el cable oficial RGB que debes usar es el de SNES PAL, no te va a servir el de SNES NTSC/GC PAL (que sí son el mismo).


Un saludo

@Falkiño Tengo que informarme mucho mas de estas cosas porque la verdad es que llegados a temas como ese no estoy muy puesto.
Pero confirmo lo que dices. Hace años compré una serie de cables y tengo un par RGB para el multi-av clasico pre-Wii. Funcionan perfectamente con mi GC PAL (aunque con puntitos de croma por apantallamiento insuficiente), pero en la SNES PAL se ve... bueno, casi no se ve nada de lo negro que está xD.
No me se las especificaciones exactas de uno y otro, pero dentro del capuchon del SCART hay 3 condensadores, que serán para las lineas RGB, pues se ve que la GC necesita correccion, mientras que la SNES no o una correcion diferente...

De verdad que lo de Nintendo y sus cables AV es de traca. Habría que diseñar un sistema de etiquetado para diferenciar los distintos "formatos" (por llamarlo de algun modo) de señal, con logotipos estandarizados como tienen los estandares de consumo (DVD, HDMI, BluRay) y hacer pegatinas imprimibles que se puedan pegar en los cables y en las consolas. Si el logo del cable coincide con el de la consola, funciona xDD

Organizacion Internacional de Normas y Estandares para Videojuegos Retro, OINEVIRE

radorn escribió:@Falkiño Tengo que informarme mucho mas de estas cosas porque la verdad es que llegados a temas como ese no estoy muy puesto.
Pero confirmo lo que dices. Hace años compré una serie de cables y tengo un par RGB para el multi-av clasico pre-Wii. Funcionan perfectamente con mi GC PAL (aunque con puntitos de croma por apantallamiento insuficiente), pero en la SNES PAL se ve... bueno, casi no se ve nada de lo negro que está xD.
No sabría decir exactamente cual es la diferencia, pero dentro del capuchon del SCART hay 3 condensadores, que serán para las lineas RGB.

De verdad que lo de Nintendo y sus cables AV es de traca. Habría que diseñar un sistema de etiquetado para diferenciar los distintos "formatos" (por llamarlo de algun modo) de señal, con logotipos estandarizados como tienen los estandares de consumo (DVD, HDMI, BluRay) y hacer pegatinas imprimibles que se puedan pegar en los cables y en las consolas. Si el logo del cable coincide con el de la consola, funciona xDD

Sí, el cable RGB para SNES PAL solo sirve en la SNES PAL y en una N64 FRA que le completes el circuito. Tiene 3 resistencias en los colores y en la señal de sincronía/compuesto, las 4 hacia tierra.
Por contra, la Super Famicom/SNES NTSC y la GC PAL sí comparten cable RGB, en este caso lo único que tienen es un condensador en cada color y ya está.

Si haces el mod universal de Tim Worthington, por defecto usa los cables de SuperFami/ SNES NTSC/ GC PAL, de ahí que los chinos que hacen copias baratas vendan esos cables diciendo "RGB Super Famicom SNES NTSC N64 GC" en eBay y similares.

Si quieres usar el cable de SNES PAL con el mod universal tienes que soldar tres puntos de la placa y entonces el cable va xD En la práctica no lo hace nadie, porque la cantidad de cables de SNES NTSC en el mercado es muy superior a la de SNES PAL y porque es más factible encontrar cables oficiales de GC PAL que de SNES PAL en Europa, así que ahí queda eso.

Si te sirve, aquí tienes una web donde puedes ver el pinout del AV Multi Out y las diferencias regionales en los cables de Nintendo, guárdala para futuras referencias que es muy útil:

https://gamesx.com/wiki/doku.php?id=av:nintendomultiav


Un saludo

@cegador Pues no te queda otra que buscarte el mod RGB de Tim. Es más complicado que el del amplificador, pero más fácil que el RGB francés.
O te puedes quedar con el S-video que también va bien para un CRT.

@Falkiño @radorn Lo de qué cable usar según el mod ya lo había respondido yo un par de mensajes antes...

Me siento ignorado...

radorn, en Francia el SCART es obligatorio por ley. Se pensó como un estandar para conectar ordenadores y aparatos de video a monitores y televisores, ahorrando la tontería de convertir una señal que de forma nativa ya era RGB al SECAM para que luego se tuviera que convertir al RGB igualmente dentro del monitor o televisor. También lo quisieron como medida proteccionista para que nadie importara aparatos del exterior. Pero el conector les salió tan bien de calidad que los fabricantes decidieron meterlo por defecto en los aparatos europeos sin importar el país, y se acabó implementando (y de paso se ahorraban una línea de producción).

En cuanto a porqué a las consolas les faltan componentes para el RGB y se tiene que suplir en el cable, de esta manera Nintendo se ahorraba un piquito en los costes de producción de cada consola y así al que quería RGB le cobraban el cable propietario caro. Ya he dicho que en Nintendo en el tema de ahorrar costes son unos genios.

Y si te apañas soldando (que creo que si) y te sobra un cable de esos tipo Gamecube de condensadores, puedes convertirlo a SNES PAL bastante fácil (Falkiño ya te lo ha explicado, pero te lo resumo): abres el euroconector, desueldas los condensadores, sueldas los cables directamente a donde estaban conectados, y luego sueldas una resistencia de 75Ohm por un lado al conector donde esta soldado el cable y por el otro al conector de su derecha.
Algo tal que así:


Y ya tienes cable para SNES PAL.

@EMaDeLoC no es que te ignoremos, es que nos quedamos cegados por la luminosidad de tu alucinancia y no nos enteramos al leerte.

Falkiño escribió:Si te sirve, aquí tienes una web donde puedes ver el pinout del AV Multi Out y las diferencias regionales en los cables de Nintendo, guárdala para futuras referencias que es muy útil:
https://gamesx.com/wiki/doku.php?id=av:nintendomultiav

Si, conozco GamesX/NFG-Games desde hace tiempo . De hecho, en ese foro nació el DAC RGB para N64 de Tim Worthington, nombre de usuario entonces "viletim" (tambien eviltim en otros sitios).
Antes de alcanzar su forma final actual, con PCB y funciones extra como el de-blur, vendió un par de lotes desde ese foro en forma de CPLDs preprogramados sueltos y las instrucciones online con los puntos de soldaje y cómo completar el DAC con resistencias y demás, y luego otros diseñaron circuitos amplificadores que añadirle.
Tengo 4 de esos CPLDs que compré no recuerdo hace cuantos años angustiado por no quedarme sin el mod, y al final, entre unas y otras, nunca instalé ni uno, y luego llegó la versión mejorada y ahora me da no-se-qué poner este... Si, es pa matarme, aunque en mi defensa, mi vida es una mierda desde hace muchos años, pero en fin.

Interesante lo de que tenga selector para tipo de cable. Mas interesante sería modificar la SNES PAL para usar el cable RGB mas comun con ella... habrá que preguntar por ahí. Además, se me antoja mas resistente a interferencias lo de tener los condensadores al final del cable, en el capuchon SCART antes de entrar en la TV, pues así la señal viaja mas fuerte por el cable y luego se reduce, y con ella, el nivel relativo del ruido inducido por interferencias externas
Si no me equivoco en lo que acabo de decir, podría decirse que la cutrería de Nintendo a veces proporciona alguna ventaja al usuario xDDD
Digo esto por la experiencia de conectar el cable RGB de GC a la SNES y no ver casi nada. Las resistencias del de SNES PAL tambien tendrán que hacer algun tipo de reduccion de señal que consiga una reduccion de interferencias, pero la verdad es que no se suficiente de electronica para saber cual de las dos opciones protege mas de ruido e interferencias. En principio un condensador siempre acaba teniendo un efecto de filtro de pase bajo, reduciendo las altas frecuencias ¿así que igual tambien reduce la definicion horizontal?
Bueno, lo dejo que al final la voy a liar.

EMaDeLoC escribió:Lo de qué cable usar según el mod ya lo había respondido yo un par de mensajes antes...

Me siento ignorado...

Yo es que no me quise meter en los detalles de los diferentes mods RGB y qué cables usar. Como vi que te esplayabas lo ignoré, pues es un tema que no controlo y tampoco iba a poder intervenir. Confié en tu sapiencia y no me metí.
Me meteré a fondo con todo ello cuando me ponga manos a la obra a instalar mods. Intentaré guardar la referencia pero probablemente acabe siendo yo mismo uno de los que venga a hacer preguntas sobre temas mil veces respondidos Pero bueno, todos los presentes tenemos experiencia en responderlas tambien, así que no me lo tengas muy en cuenta

EMaDeLoC escribió:en Francia el SCART es obligatorio por ley. Se pensó como un estandar para...

Pues no sabía eso tampoco. Muy interesante el dato. Para una cosa buena que inventan estos franchutes, y se la querían quedar para ellos solos xDDD

EMaDeLoC escribió:Y si te apañas soldando (que creo que si) y te sobra un cable de esos tipo Gamecube de condensadores, puedes convertirlo a SNES PAL bastante fácil...

Me lo apunto tambien. Es algo que ya pensé hacer en su momento (incluido buscar el "cómo"), pero se quedó "para otro momento", como tantas otras cosas

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

He abrierto y documentado mis dos cables RGB que mencioné antes. Uno basico y el otro con salidas RCA en medio del cable.
La verdad es que por fuera no están mal, pero por dentro son bastante cutres, con hilos de baja calidad, montaje cutre y soldadura chapucera, y sin apantallamiento individual de los hilos, ni nada que se le asemeje.

Ambos conectan los hilos principales correctamente: el audio directo, y los RGB con condensadores de 220uF en linea. Pero luego hay algunas diferencias entre ellos.

---Cable con RCAs AV en medio del cable---
-Cables del color correcto para RGB, pero el resto de hilos son una fiesta.
-Tiene apantallamiento general de todo el cable, conectado a la patilla SCART de masa de video compuesto (17) y no al blindaje exterior. Es la unica masa conectada en el extremo SCART, que comunica con las dos patillas de masa (5 y 6) del extremo MultiAV
-Conecta la patilla de modo de entrada (8) de SCART a la patilla de +12V del MultiAV (3) (sync en NTSC). Esto hace que la TV se encienda con la consola en modo 4/3.
-La patilla de blanking SCART (16) a los +5V del MultiAV (10), de forma directa en apariencia. Sin embargo, mi multimetro chinorris de hace años dice que hay 100ohm entre esas patillas, así que debe haber una resistencia en el capuchon del MultiAV, pero parece un termosellado macizo, asi que no puedo abrirlo sin cargarmelo.
-La patilla SCART de video compuesto (20) usada para la sincronizacion tiene un condensador de 200uF igual que las lineas RGB, por alguna razon. Hubiera valido para filtrar un poco los "chroma dots" y que no se filtrasen en RGB si la hubieran puesto del lado MultiAV, pero poniendola del lado SCART, no entiendo de que sirve...

---Cable sin RCAs---
-Usa cables de cualquier color para cualquier cosa, sin ningun orden ni concierto discernibles.
-Conecta las masas de audio (4) y blanking (18) del SCART uniendolas en un unico hilo que conecta a una unica patilla de masa del extremo MultiAV
-Conecta la patilla de modo de entrada (8) de SCART a la patilla de +5V del MultiAV (10) provocando en TVs compatibles que entre en modo 16:9. Como esto resultaba muy molesto, desconecté este hilo.
-La patilla de blanking de SCART (16, y que alguien me diga el termino epañol, por favor) va conectada, con una resistencia de 75ohm en linea, a la patilla de +5V del MultiAV (10) imagino que para reducirlo a los 1-3V que señalizan el uso de RGB externo.
-El video compuesto para sincronía va de SCART 20 a MultiAV 9 va directo, sin ninguna resistencia que mi multimetro haya podido medir.

En fin. Debería comprarme unos cables de calidad o echarme unas horas cazando materiales y herramientas de calidad para hacermelos yo, porque estos están llenos de chorraditas y cutreces.

@radorn Un colega tenía un cable RGB sin condensador en el pin 20 del scart y le daba problemas de imagen. Le soldé un 220uF copiando otro cable y se solucionó. Ni idea de porqué a veces lo necesita y otras no, creo que es algo del rollo de sincronía para filtrarla del compuesto, pero como digo, ni idea.

Yo le compré hace un par de meses unos cables a thefoo.83 en ebay, un RGB Gamecube PAL con clean sync y un RGB SNES PAL normal y de maravilla, son de muy buena calidad y de paso me cubren tanto la N64 RGB francesa como la N64 RGB japo. No es que sean baratos, pero para lo que te van a costar los materiales y demás, creo que te sale más a cuenta comprarle alguno.

@radorn yo he mirado por curiosidad el euroconector de mis dos cables oficiales RGB de Cubo y tienen 9 pines (+1 si contamos el 21 de tierra general). Hasta donde recuerdo son los tres colores, sincronía por compuesto, audio izqdo y dcho y el de voltaje para cambiar el canal al RGB, además de las dos tierras que van a las dos del pcb de la consola y que en el euroconector son para los tres colores y para el audio.

Falkiño escribió:@radorn yo he mirado por curiosidad el euroconector de mis dos cables oficiales RGB de Cubo y tienen 9 pines (+1 si contamos el 21 de tierra general).

Si, Nintendo, en vez de comprar conectores genericos y montar el cable con ellos, se ve que los pedía a medida y solo ponía las patillas justas... peseteros, centimeros, penny-pinchers xDD
Y creo que hacen lo mismo con los conectores de cualquier otro cable del que yo sea consciente. Si no necesita una patilla en concreto, no la ponen. Es realmente irritante si quieres usar un cable viejo o estropeado para hacer otra cosa. Por ejemplo, usar el capuchon desmontable de un cable AV estandard oficial viejo o roñoso (ha caido en mis manos alguno que otro a lo largo de los años) para montar un RGB o S-Video. No puedes, porque faltan patillas. Supongo que se podrían fabricar si te empeñas, pero vaya...

Del cable RGB oficial de GC pasé en su dia por dos motivos. Me pareció carisimo (30 euros por un puto cable) y no tenía salida de audio separada, que usaba para conectarlo al PC para grabar o a un radiocasette estereo con entradas RCA, dado que mi TV de 14 pulgadas no tenía sonido estéreo, y francamente, con la calidad que veía en el 14" con compuesto no me imaginaba que RGB fuera a ofrecer tanta diferencia.
De hecho, creo que alguna vez, no se cómo, pude ver RGB en persona, y me chocó que los colores eran diferentes, y que parecia todo muy suavizado, probablemente por que la TV hacía algun tipo de efecto de resaltado de bordes para compuesto. Es posible que lo comprase en algun momento y luego lo devolviese o lo revendiese... no estoy seguro la verdad.

@radorn hoy en día hay algunos fabricados a mano, como los del famoso thefoo.83 que sacan el audio fuera del euroconector, son los llamados multiaudio. Y lo mejor es que si quieres se puede pasar el audio por el euroconector igualmente con el mismo cable.




Un saludo

@Falkiño Gracias por la referencia. Solo comentaba una queja que tenía entonces. Ahora ya que tenga o no tenga salida de audio separada no me preocupa demasiado porque tengo las cosas conectadas de otra forma. Pero en su momento fue un factor decisivo. Si hubiese tenido un precio mas razonable para un cable fabricado en masa en China, probablemente lo hubiese comprado. No se, por debajo de 20 me lo hubiese pensado, supongo, pero, en mi opinion, debería haber costado al rededor de 10-15... o menos.
Luego están estos cables nuevos hechos artesanalmente, ensamblando a mano componentes, muchas veces, de calidad profesional, donde se entiende perfectamente que cuesten mas. Pero Nintendo no tenía excusa ninguna para cobrar, en 2002, 30 euros por un cable RGB sin salida de audio externa fabricado en China. Un abuso, en mi opinion.

Pues nada, hoy enciendo mi N64 y oigo unos ruiditos saliendo del adaptador... Sigue funcionando, pero, por precaucion, para no arriesgarme a tener que reemplazar la N64 tambien, he preferido poner una de las que tengo en reserva. Creo que esta que ha empezado a renquear es la original que venia con mi primera N64 alla en marzo de 1997.

Ahora lo que queda es ver si intento reparar esta, o reemplazar los componentes internos por una picoPSU, que me creo que me dará la oportunidad de poner cuatro mandos con rumbles con modificacion para usarlos sin pilas, gracias al mayor amperaje disponible en los 3.3v con respecto a la original.

De electricidad y electronica se mas bien poco. ¿Serán los condensadores?

@radorn Pueden ser los condensadores, es lo que más suele fallar con el tiempo. Si tienes con qué medir voltajes comprueba que tal va. Lo suyo es que abras la consola y midas los voltajes mientras esta en marcha. El más importante es el de 3.3V, no debe bajar de 3.1 ni subir de 3.5. El de 12V no es tan importante a menos que conectes un 64DD, pero como lo usa un regulador para dar 5V a ciertos circuitos de video, comprueba que no baje de 11V.

Yo pillé una PSU china hace poco por 10€. No es de muy buena calidad, pero me sirve como fuente de respaldo y para usarla cuando destripo una consola y hago alguna prueba. Lo de cambiar las tripas para meter otra fuente no es mala idea, así puedes poner un convertidor que dé más confianza.

@EMaDeLoC Tengo un multimetro de los chinos de hace años. No me fio mucho de el. La verdad es que me faltan cosas basicas. El multi que tengo ni siquiera mide capacitancia para revisar los condensadores como es debido, y no tengo ni idea de cómo usarlo para revisar transistores ni qué resultados serían los correctos xD. Al final solo se medir voltajes, resistencia, y continuidad.
Lo abriré para ver si hay algun condensador inflado o reventado.

Por ahora tengo otros dos adaptadores originales, uno de una N64 transparente de un cash converters y otro de una N64 que me pasó un amigo al que no le va lo retro y ya no la usaba. Malo será que revienten los dos seguidos tambien.

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

Cambiando de tema: Me he topado con esta imagen de archivo de USA Today.

Es una buena foto promocional de entronces, con una iluminacion interesante y tal.
El mando tiene el pozo del stick con forma cuadrada, como algunos prototipos de entonces, pero lo mas interesante, que se nota gracias a la alta resolucion de la fotografía, está en la mitad trasera de la carcasa del cartucho, donde se ve lo que parece un espacio para etiquetas. Parece que Nintendo consideró en algun momento poner etiquetas en el canto de los cartuchos, de forma similar a los cartuchos de NES y la version americana de SNES. pero saliendo de la parte trasera, en vez de la delantera.
La etiqueta del cartucho parece pintada a mano con ceras o rotuladores xD

@radorn Mi voltímetro no es de los chinos pero hace lo mismo que el tuyo y me ha ido bastante bien. Si que se hecha en falta un tester de condensadores pero tampoco me ha hecho mucha falta.
Si quieres saber si es preciso, testea los voltajes de una fuente de ordenador. Como suelen ser muy fiables de voltajes, si te marca bien los 5V y los 12V, pues te puedes fiar.

En cuanto a la foto, bien por el cambio del pozo del joystick y mal por dejarnos sin etiquetas en el lomo del cartucho. De hecho los cartuchos de la n64 junto a los de Gameboy me parece de mal almacenaje al no tener de origen esa etiqueta. Pero bueno, no hay más remedio que aguantarse.

@radorn sí, tiene pinta de que la etiqueta de atrás continuaba hacia arriba, para que se viese que juego era, porque vaya mierda tener cartuchos apilados y tener que andar sacando uno a uno a ver cual es el que te interesa xD.
Siempre he pensado en ponerle pegatinas de esas que venden en un pack con muchisimos titulos, pero por pereza...

Me pasó ayer una cosa rarísima jugando al Donkey Kong 64 me iba todo estupendo y al ponerme esta mañana ,se me borraron las partidas en el everdrive.. y solo en ese juego, los demás no.. os suena de que puede ser?

@valdivia ¿Qué everdrive tienes? ¿Es de hace mucho? ¿Tiene el OS actualizado? ¿Sabes la versión de la ROM de DK64?
El DK64 tiene un sistema anti-piratería especial en el que hace comprobaciones aleatorias del CIC y si no le gusta lo que encuentra te borra la partida. A veces también es por un problema del OS para manejar la memoria de guardado. En principio con los últimos Everdrive con UltraCIC II y el último OS no debería surgir ningún problema.

Espero que esto te aclare lo que ha pasado.

EMaDeLoC escribió:@valdivia ¿Qué everdrive tienes? ¿Es de hace mucho? ¿Tiene el OS actualizado? ¿Sabes la versión de la ROM de DK64?
El DK64 tiene un sistema anti-piratería especial en el que hace comprobaciones aleatorias del CIC y si no le gusta lo que encuentra te borra la partida. A veces también es por un problema del OS para manejar la memoria de guardado. En principio con los últimos Everdrive con UltraCIC II y el último OS no debería surgir ningún problema.

Espero que esto te aclare lo que ha pasado.

Mira tengo el everdrive oficial con lo siguiente:

Firmware:2.33
os:2.12
Assembly date: 1.7.2014

La roms es donkey kong 64 (E) [!].z64

En este caso la partida se puede recuperar?

@valdivia
Que versión de everdrive?
1, 2.5 o la 3.

valdivia escribió:Mira tengo el everdrive oficial con lo siguiente:

Firmware:2.33
os:2.12
Assembly date: 1.7.2014

La roms es donkey kong 64 (E) [!].z64

En este caso la partida se puede recuperar?

En el foro de Krikzz hay hilos reportando problemas de partidas guardadas en DK64 entre 2015 y 2016. Me temo que tu Everdrive no esta equipado con el UltraCIC II que era el que solucionaba el problema de la medida antipirata.
Sin embargo este problema ya ocurría mucho antes de salir el Everdrive y hay parches o ROMs parcheadas que evitan el borrado. Has de buscar una ROM que en vez de [!] tenga [f2], es el parche dos y en principio es el que arregla el problema. Si quieres pásate por el hilo viejo en Krikzz que hablan más en detalle de como lidiar con el problema: https://krikzz.com/forum/index.php?topic=3654.0

Otra solución que hay, pero que no te hará gracia, es comprar la versión 2.5 o la 3.

En cuanto a recuperar la partida... Prueba con un recuperador de archivos en el PC a ver si se encuentra alguna copia del savegame que no esté borrada, pero es complicado que haya alguna. Una vez se sobreescribe la información, se pierde.

Edit: @valdivia ¿Sabes si tu everdrive lleva Ultracic o un cic normal?

EMaDeLoC escribió:

valdivia escribió:Mira tengo el everdrive oficial con lo siguiente:

Firmware:2.33
os:2.12
Assembly date: 1.7.2014

La roms es donkey kong 64 (E) [!].z64

En este caso la partida se puede recuperar?

En el foro de Krikzz hay hilos reportando problemas de partidas guardadas en DK64 entre 2015 y 2016. Me temo que tu Everdrive no esta equipado con el UltraCIC II que era el que solucionaba el problema de la medida antipirata.
Sin embargo este problema ya ocurría mucho antes de salir el Everdrive y hay parches o ROMs parcheadas que evitan el borrado. Has de buscar una ROM que en vez de [!] tenga [f2], es el parche dos y en principio es el que arregla el problema. Si quieres pásate por el hilo viejo en Krikzz que hablan más en detalle de como lidiar con el problema: https://krikzz.com/forum/index.php?topic=3654.0

Otra solución que hay, pero que no te hará gracia, es comprar la versión 2.5 o la 3.

En cuanto a recuperar la partida... Prueba con un recuperador de archivos en el PC a ver si se encuentra alguna copia del savegame que no esté borrada, pero es complicado que haya alguna. Una vez se sobreescribe la información, se pierde.

Edit: @valdivia ¿Sabes si tu everdrive lleva Ultracic o un cic normal?

Pues si te soy sincero no sé cuál everdrive es lo compre en Emere hace años y costaba 99 ,yo creo que el mío es anterior a los que sacaron con pila de botón.. como podría saber cuál es? Me da miedo empezarme una partida y se me borre, eso no veas como molesta ,creo que me lo pasaré en el cartucho original.

@valdivia Abre el cartucho y mira a ver si tiene un chip como el de la esquina inferior izquierda de esta foto:

Es un chip CIC que reune la funcionalidad de un CIC NTSC y otro PAL (lleva dos números impresos). Normalmente iba bien para la mayoría de juegos pero no puede con el sistema antipiratería del DK64.

Puedes jugar al DK en el everdrive y cada vez que acabes hacer una copia de seguridad de la partida en el ordenador. Es un engorro, pero es la solución que más a mano tienes sin tener que comprar otr Everdrive o el juego original.

@EMaDeLoC
¿Estás seguro de que el DK64 tiene medidas adicionales de restriccion y castigo anticopia?
De los juegos que usan el CIC x105 yo solo estaba al tanto de que tuviesen medidas retorcidas el Banjo-Tooie que usa las caracteristicas especiales del chip para proporcionar las claves de desencriptado de los archivos del juego, y por tanto no arranca si usas emulacion de carga con otro CIC, y Jet Force Gemini, que tambien detecta estas funciones especiales del CIC x105, y si no las ve, te impide correr y disparar, impidiendote pasar del portal que abre la primera fase.
DK64 creo que no tenia mas seguridad que la que puedan tener Zelda o Paper Mario, por ejemplo, que es que necesitan el chip para arrancar pero tambien arrancan con emulacion de arranque.

...

He consultado unos *.NFOs que tengo de los antiguos cracks y "releases" de la scene y en el de Donkey Kong 64 se habla de un posible mal volcado inicial, y subsiguiente re-volcado, que se ha de usar el bootemu de Zelda y que el juego usa EEPROM de 16kbit y que hay un parche para que funcione con el de 4kbit con capacidad para una sola partida en vez de 3. Este parche era necesario dado que muchos copiones de entonces solo emulaban el EEPROM de 4kbit. Efectivamente el conjunto GoodN64 contiene unas ROMs de DK64 etiquetadas con (Save), indicando algun tipo de parcheo referente al guardado.
No encuentro ningun indicio serio por ahí ni por ningun otro lado de que DK64 tenga problemas de guardado por medidas anticopia relativas al CIC x105.

...

La verdad es que no me he puesto a jugar al DK64. Me da un poco de pereza. Ahora, además, he reemplazado el 7101 con el que compré mi 64drive por un 7105, y hay que puentear un jumper en la placa para que cargue el bootloader adecuado de la flash interna, con lo cual en este momento, aun usando mi super-conector-T, no puedo cargar el menu del cartucho con un CIC normal y probar si con el 64drive pasa lo mismo.
La verdad es que es la primera vez que oigo todo esto de los problemas con los guardados de DK64, y la gente que lo comenta por ahí siempre lo hace en relacion a la familia ED. Nunca he oido de nadie que se queje de lo mismo con el 64drive, aunque no estoy diciendo con ello que no tenga el mismo problema.

---------------------------
@valdivia No se a qué se habrán debido tus problemas de guardado. No descartes haber tenido corrupcion de datos en la SD. Esas cosas pasan.
Hasta esta conversacion estaba completamente convencido de que DK 64 no tenía nada raro en cuanto a medidas anticopia. Con las afirmaciones de EMaDeLoC ahora me surgen dudas, pero yo diría que todo indica a que realmente no hay nada de eso.

@radorn No te aseguro nada porque la info la he sacado de los foros de Krikzz. En enlace que he puesto antes ( https://krikzz.com/forum/index.php?topic=3654.0) hablan tanto del problema de la EEPROM como de la medida antipirata, pero si no lo he entendido mal el primer problema conocido fue con la EEPROM y de ahí los parches (hablan de hasta 3 distintos). Al parecer no fue hasta más adelante que se descubrió el sistema antipirata, que por lo visto no ocurre tampoco con frecuencia. Al menos eso es lo que he entendido leyendo el hilo por encima.

Aparte, en el hilo dedicado a las incompatibilidades del Everdrive64 mencionan expresamente la medida antipirata de Rare:

Donkey Kong 64 (Should work with Ultra CIC II)
Rare's piracy protection CIC erases the save file after a random hours of play on flashcarts like the Everdrive 64. Older versions of the Everdrive 64 OS may also have problem handling 16kB EEPROM saving properly. Later OS versions have better EEPROM saving handling, but the anti-piracy CIC still deletes the save file. There is a hack that changes the game to use SRAM saving to get around the saving problem. "Donkey Kong 64 (E) [f1] (Boot&Save).z64" and "Donkey Kong 64 (U) [f2].z64" from the goodset are reported to have the SRAM hack pre-patched (the boot hack is not actually needed on ED64 but the save hack is, the boot hack is for older backup devices). It's required to force SRAM on the game before loading the rom with this SRAM hack.
Note: The Ultra CIC II successfully emulates Rare's anti-piracy protection CIC, so if your Everdrive 64 has an Ultra CIC II installed, this game should work properly. Japanese version should work as well in that case, and there's no need for any patches.

Siendo una info casi oficial (o al menos así parece), no la pongo en duda pero tampoco te lo aseguro porque no es mía.

@EMaDeLoC Si, ya me leí bastante detenidamente el hilo, y tambien busqué sobre el tema, y en el foro de ASSEMbler, donde estuvieron los foros de los EverDrive antes de tener los suyos propios, hay tambien un hilo sobre el tema mas o menos de las mismas fechas, donde Link83, un habitual de estos circulos que he visto por diversos sitios, consultaba a LaC, el autor original de los parches mencionados ahí como solucion al problema, asegurando que en DK64 no hay proteccion anticopia de ese tipo que requiriese de crackeado, como si lo tienen JFG y BT, que todo lo que hace el parche es redirigir el guardado a SRAM.
https://assemblergames.com/threads/whic ... ost-533607
Si el que hizo el parche dice que no tuvo que crackear, me parece dificil que el problema sea la ausencia de un CIC x105, ni que un parche que no crakea nada solucione un problema supuestamente causado por una medida anticopia...
No se... me suena a que hay o había algun problema con el ED, a nivel de hardware o software, que causaba ese problema. Igual lo han solucionado en nuevas acualizaciones de software...

... También está esto https://assemblergames.com/threads/whic ... ost-579490 claro que no dice si lo pidió con un x105...

Ahora ya me quedo fastidiado con la duda de si este problema es cosa de Rare o del ED...
Debo dedir que no haber oido esta queja antes de que apareciese el ED, en fin, huele un poco a chamusquina.

@valdivia ¿Tienes actualizado el menu, el firmware, y/o lo que toque en tu ED64? En todo caso, supongo que si estás muy paranoico y no quieres arriesgarte a perder el avance otra vez, puedes usar las versiones parcheadas esas o el cartucho original, como ya has dicho.

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

Se me ha ocurrido algo altamente especulativo: Asumiendo que realmente el parche de LaC que redirige el guardado en EEPROM 16kbit a SRAM 256kbit arregla este problema de las partidas borradas (del que solo he oido quejas de gente con EDs) supuestamente causado por una medida de sabotaje contra "piratas" puesta deliberadamente por Rareware usando las funciones especiales del CIC x105, es posible que a pesar de que el propio autor no realizase ningun tipo de crackeado contra esas medidas, el hecho de redirigir a SRAM en si mismo vuelva inefectiva la medida anti-copia. Aunque LaC modificase el juego para guardar en EEPROM en vez de SRAM, es posible que las rutinas de las medidas de sabotaje anti-copia residan en un proceso independiente de las rutinas de guardado normales. Quizá la medida de sabotaje, asumiendo que exista, acceda a la EEPROM de manera independiente, corrompiendo los datos sin usar el mismo proceso que el guardado normal.
Si eso fuera así, al redirigir el guardado normal a SRAM, sin pretenderlo, lo habría a salvo de ese hipotetico proceso malintencionado que trata de corromper los datos de una EEPROM que nisiquiera está ahí.

Ahora tengo mas ganas de probar a jugar DK64 con CIC 7102 y emulacion de arranque a ver si me borra la partida o qué.

@valdivia ¿En qué punto del juego estabas antes de que apareciera el problema? Fue al llegar a algun punto en concreto? o despues de un numero determinado de horas de juego? Ya habías apagado la consola y vuelto a encenderla para continuar el juego antes o fue la primera vez?

@radorn Creo que es algo más sencillo que eso...
Tanto en la lista de compatibilidad como el hilo de Krikzz, el problema de las partidas borradas en el Everdrive desaparece cuando se pasó de un CIC donado por un cartucho al UltraCIC II que emula todos los CIC, incluidos los x105.
Por lo que he mirado del 64drive, usa su propio sistema para emular los CIC, aunque al principio requería de un chip de un cartucho donante. Tal vez Marshall hizo un parche específico para los CIC x105 y sin darse cuenta eliminaba la protección ani-pirata, o viera que el DK64 borraba partidas de forma aleatoria e incluyera en el firmware o el OS que se interceptaran las llamadas de borrado.
Dado que según algún usuario de Krikzz ya se conocia el problema de antes y había que meterle un crack a la ROM para jugar en Doctor v64, es posible que Marshall ya conociera el problema y se limitara a implementar la solución de alguna manera, bien con emulación CIC completa, bien con parcheos al vuelo. El Everdrive incluye y aplica parches para algún que otro juego, aunque no el DK64 que yo sepa.

Según el hilo en Krikzz los parches solo resuelven los problemas de guardado con las distintas memorias disponibles en las reproducciones antiguas y el uso de estas roms parcheadas puede dar resultados inesperados. Es decir, ni los parches se hicieron para el Everdrive, ni el Everdrive tuvo en cuenta los parches.

En fin, es posible que juegues al DK64 con tu 64drive, o lo haga yo con mi Everdrive, y no haya borrado ni ningún otro problema, pero con flashcarts antiguos si lo haya.

Solo falta que @valdivia nos aclare cual es su Everdrive para saber si es de los antiguos con CIC viejo.

@EMaDeLoC Hay dos versiones del 64drive (sin contar con la pre-release, que tienen algunos miembros de #n64dev), la HW1 de 2011, que tengo, y la nueva HW2 con los famosos 240MB.
La HW1 usa CICs originales sacados de cartuchos (de donde tambien salen las carcasas que usaba) y la HW2 usa alguna forma de UltraCIC (en el que marshallh mismo hizo parte del desarrollo y/o la ingenieria inversa. Hay una presentacion en una convencion de hackers de hace unos años donde hablan del tema).
En el 64drive hay tres binarios que se encadenan. El bootloader, el boot-emulator y el menú. Cuando arrancas la consola desde cero, lo primero que arranca es el bootloader, que es visto por la consola como un cartucho normal, y está almacenado en una memoria flash dedicada dentro de la consola. Una vez ese programa ha cargado, intenta leer el FAT32 de la tarjeta SD (o, alternativamente, CF en el HW1) y cargar "menu.bin". Si no encuentra una tarjeta, o no está formateada, o no hay menu.bin, muestra una pantalla con el logo de 64drive y un mensaje diciendo qué problema ha encontrado.
En realidad en esa flash interna hay dos bootloaders diferentes. Uno firmado para el CIC 7101/6102 y otro para el x105. Segun el CIC que instales en la placa, tienes que dejar libre o puentear un jumper para que se acceda al banco correcto.
Una vez dentro del menú, eliges una ROM, y, al intentar cargarla, el menú copia la ROM a la RAM del cartucho y configura el hardware para emular el save adecuado, cambiar la region de la consola de acuerdo con la region de la ROM y resetea la consola. En este momento, la ROM no carga directamente, si no que, primero, carga el boot-emulator, creo que, desde la misma flash que el bootloader. El bootemulator es un software que, con "magia" (xD), confunde al juego para que cargue con un CIC diferente al CIC para el que está firmada la ROM.
Esto es así por una sencilla razon. Ya no es solo que si tienes un CIC normal no puedes hacerlo funcionar como otro. Es que sencillamente no se puede cambiar el tipo de CIC al vuelo con la consola encendida. Te quedas con el CIC con el que la consola arrancó el bootloader/menú del cartucho flash. Incluso si implementasemos un cambio de modo en caliente en el UltraCIC, el sistema de seguridad de la consola interpretaría el cambio de la misma forma que un corte de comunicacion con el CIC, parando la CPU. Aún con UltraCIC, sigue siendo necesario un boot-emulator si cargas ROMs desde un menú, porque el CIC del menú y el de la ROM que cargues no necesariamente van a ser el mismo, y no puedes cambiarlo en caliente,.
En el 64drive HW2, cargando por USB desde el PC, puedes decirle al Ultra CIC que actue como cualquier variante de CIC, porque con la energia que proporciona el USB el cartucho ya está funcionando antes de que se encienda la consola. Pero, si cargas con el bootloader/menú, que está firmado para 7101/6102, no puedes decirle que actue como un x103 o lo que sea.
Lo que sucede es que el Ultra CIC, aparte de emular todos los CICs existentes, tambien puede emular las funciones especiales del x105... INCLUSO cuando está funcionando como un 7101/6102. Esa es la clave. Las funciones de arranque y las funciones extra que trae el x105 son independientes.

El 64drive se puede configurar tambien para que, al darle a reset, se vuelva al juego o al menú. Seguro que el ED64 hace lo mismo. Esto se consigue, al menos en el 64drive, porque, al darle a reset, el cartucho deja de redirigir el trafico del PI a la RAM interna donde esta tu ROM y vuelve a dirigirlo a la flash donde están el bootloader y el boot-emulator. Este, a su vez, lee una serie de registros que le dicen lo que hacer: O bien acceder a la SD y copiar el menú a la RAM del cartucho para arrancarlo, o bien volver a arrancar el boot-emulator desde la flash y que este arranque la ROM que ya está en la RAM. Si tu cartucho flash tiene menú y funcion de volver a menú con un reset en vez de tener que apagar y encender, ten por seguro que está haciendo "escala" por el bootloader. No es lo mismo un reset con un cartucho original que con uno para ROMs.
De hecho, este mismo paso intermedio es el que se usaba en las versiones antiguas de hardware y firmware de ambos 64drive y EverDrive 64 para hacer lo de "guardar la partida con RESET" antes de que ambos implementasen el guardado en tiempo real.

Aclarado todo esto, comento sobre lo que has dicho:

EMaDeLoC escribió:Por lo que he mirado del 64drive, usa su propio sistema para emular los CIC

Es el mismo codigo UltraCIC, implementado en un PIC, creo. marshallh y compañía publicaron el codigo en GitHub (bajo el repositorio de mikeryan, creo), y como KriKzZ no para de sacar una revision tras otra de los EDs, tuvo la oportunidad de incluirlo en una version publica antes que el propio marshallh en su 64drive HW2 xD.

EMaDeLoC escribió:Tal vez Marshall hizo un parche específico para los CIC x105 y sin darse cuenta eliminaba la protección ani-pirata, o viera que el DK64 borraba partidas de forma aleatoria e incluyera en el firmware o el OS que se interceptaran las llamadas de borrado.

No... Cuando tenía conversaciones mucho mas frecuentes con marshallh, hablando sobre los juegos con proteccion especial del 6105, tuve un lapsus mental y mencioné el DK64 junto con BT y JFG, y este me corrigió, a lo que asentí, reconociendo el error. Si marshallh hubiese incluido algo especial para ese juego, no hubiera hecho esa corrección.

O bien no hay tal medida antipirata y es un error de alguna version antigua del ED, a nivel de hardware o firmware, o bien si hay tal medida y, por alguna razon, nadie con un 64drive con CIC 7101/6102 ha jugado lo suficente al DK64 para encontrarse el problema. Esto segundo me sorprendería mucho, pero supongo que es posible.

EMaDeLoC escribió:Dado que según algún usuario de Krikzz ya se conocia el problema de antes y había que meterle un crack a la ROM para jugar en Doctor v64, es posible que Marshall ya conociera el problema y se limitara a implementar la solución de alguna manera, bien con emulación CIC completa, bien con parcheos al vuelo.

No, el parche es especificamente para redirigir el guardado. DK64 guarda nativamente en EEPROM 16kbit.
En la mayoría de copiones de la epoca, el tema del guardado solía ser bastante problematico. Al contrario que hoy en dia donde el cartucho emula todos los chips de guardado y vuelca los datos automaticamente (o con reset) a la misma SD donde están las ROMs, en los copiones antiguos la cosa varíaba mucho segun el copion que tuvieras. Desde usar adaptadores externos (http://n64.icequake.net/mirror/www.bung ... ts/Ds1.htm http://n64.icequake.net/mirror/www.bung ... /DX256.htm), a usar conectores en T similares al chapucero que me hice yo para usar los chips de guardado de cartuchos originales, y luego hacer copia manual al PC con programas de carga y descarga especificos que comunicaban por puerto paralelo. Ten en cuenta que, excepto el Z64, que usaba discos magneticos ZIP de 100MB, ninguno de los otros copiones tenía almacenamiento reescribible no-volatil interno, si no que usaban CD-ROM o puerto paralelo.
Debido a esto eran habituales los parches para redirigir los guardados a otros tipos de guardado. Los guardapartidas mas populares a los que convertir un juego eran EEP4kbit y SRAM256kbit, debido a que se podían comprar adaptadores de Bung (fabricante del V64) que almacenaban partidas de ese tipo (con botones para bankswitching, creo),y porque tambien eran los que mas proliferaban en cartuchos originales. Hay mas eep4 que eep16 y mas sram que flash en cartuchos originales. Por eso.
Incluso el Crack que hay para Jet Force Gemini redirije el guardado Flash 1024kbit a SRAM256kbit (permitiendo solo 1 o 2 bloques de guardado en vez de los 6 que ofrece el juego), aunque solo hace esto si no detecta la presencia de un chip Flash.
El parche de DK64 no fue diseñado para saltarse ninguna medida de seguridad (palabras del autor), si no solo para redirigir el tipo de guardado EEP16, relativamente poco habitual, por algo mas comun en la epoca, SRAM.

Por eso digo que hay 3 opciones:
A: Algunas versiones del HW o FW del ED dan problemas con DK64, incluida la que tiene @valdivia. y no hay mas misterio.
B: Realmente hay una medida de sabotaje deliberado contra "piratas" en DK64 basada en las funciones especiales del CIC blablabla_5 y solo los usuarios de EDs sin Ultra CIC han jugado lo bastante al juego para toparse don su ira, mientras que los usuarios de 64drives HW1 sin CICs x105 casi no han tocado el juego y por tanto no se han topado con el problema, o, si lo han hecho, no lo han contado.
C: De ser cierto B, tambien sería posible mi teoría especulativa de que, al redirigir a SRAM, la rutina de sabotaje se quedaría sin su presa, convirtiendose el parche en un crack involuntario. No obstante, sigo dudando de que haya tal medida "anti-pirata" y creo que lo mas probable es la opcion A.

Perdonar el retraso aquí están la foto

Y por cierto esto de borrar la partida como dicen no creo que sea casualidad ya me pasó hace tiempo y actualicé el os del everdrive ,pensé que se solucionó, pero otra vez se me borro y solo con ese juego ningúno mas pasa

https://ibb.co/7JV52tB

@valdivia
Como ha corrido mucha tinta y supongo que te lo has perdido, vuelvo a preguntar:
En qué punto del juego estabas antes de que se borrase tu partida?
Lo digo por saber hasta donde tengo que llegar si intento recrear tu problema.

Pego tu imagen bien, porque la pusiste como si fuera HTML y el foro no lo acepta así
Efectivamente tienes un CIC 7101.

radorn escribió:@valdivia
Como ha corrido mucha tinta y supongo que te lo has perdido, vuelvo a preguntar:
En qué punto del juego estabas antes de que se borrase tu partida?
Lo digo por saber hasta donde tengo que llegar si intento recrear tu problema.

Pego tu imagen bien, porque la pusiste como si fuera HTML y el foro no lo acepta así
Efectivamente tienes un CIC 7101.

Pues me paso la primera vez al principio poco despues de rescarta a diddy kong y la ultima fue justo cuando jugaba el minijuego que estaba en el segundo nivel, que es una carrera con tiny kong, contra un bicho.

Siempre me ha pasado al principio esta vez tenia 3 horas de juego y por cierto que everdrive tengo? creo que tambien este tenia problemas con el banko tooi o lo mismo me equivoco

@valdivia Hmmm. OK. Pues parece razonable. En algun momento debería por fin ponerme con ese juego, que solo lo jugué de alquiler en su dia. A ver si en algun momento me animo y revierto mi 64drive a modo CIC normal y pruebo.

Sobre qué ED tienes, yo no lo se. Yo tengo 64drive y no le sigo la pista a los EverDrives. Son cartuchos distintos, de fabricantes distintos. Creo que @EMaDeLoC u otros sabrán identificarlo.

Lo que si te puedo confirmar es que tienes un CIC (chip de anticopia del cartucho) del tipo 7101, y, por tanto, no vas a poder usar las versiones normales de Banjo Tooie y Jet Force Gemini, porque tienen medidas anticopia especiales que dependen del CIC 7105, que tiene funciones extra que no tienen otras variantes del CIC. Hay otros juegos que usan CIC 7105, pero no usan esas funciones extra, y se los puede engañar para funciona con un CIC 7101 como el tuyo, que es exactamente lo que hacen estos cartuchos de ROMs.
El Banjo Tooie directamente no va a cargar, y solo verás una pantalla negra, porque usa las funcione extra esas para descodificar los datos del juego (texturas, modelos 3d, programa)... El JFG, por otro lado, cargará, pero una vez llegues a la primera fase y tomes el control de tu personaje, encontrarás que solo puedes andar a pasto de tortuga, y tampoco tu arma no dispara, lo cual hace imposible avanzar en el juego. Los de Rare eran unos cachondos...
Tienes que buscar las versiones parcheadas, que te permiten cargar y jugar normalmente aunque no tengas un CIC 7105 en el cartucho. Seguro que en el propio foro de KriKzZ tienen enlaces o te pueden indicar.

@radorn Completísima explicación de como funciona el 64drive.

Empezaré por el final de tu post largo: estoy conforme con las opciones, pero en cuanto a la B, que haya el sistema antipirata pero que solo los usuarios de ED64 lo hayan reportado o que los de 64drive no lo hayan jugado lo sufiente... Hay matices que añadir aquí.

Me puse a mirar un poco las direferencias entre memorias EEPROM y SRAM, solo por la wikipedia, pero revela una diferencia sustancial entre ambas memorias. Las EEPROM pueden comunicarse a traves de protocolos, mientras las SRAM leen o escriben datos según este activa la línea correspondiente. De ahí la necesidad de parches según los copiones o flashcarts que se fuesen a utilizar en su momento.
Pues debido al uso de protocolos algunas EEPROM aceptan comandos y uno de esos comandos, y aquí viene lo interesante, es el borrado completo del chip.

Valdivia comentó al principio que se le habían borrado LAS partidas, lo que cuadra con el uso del comando de borrado del chip. Pensemos en este comando: ¿cuantas veces se usaría en todo el catálogo de la N64? Normalmente cada juego con memoria interna guarda dos o tres partidas distintas para que así varias personas puedan seguir con la suya simultaneamente. Es normal que se pueda borrar una partida, ¿pero todas a la vez? ¿Hay algún juego que implemente borrar toda la memoria de guardado del cartucho con un solo botón?
Digo esto porque, ¿y si en el momento de implementar Marshall los comandos de EEPROM en su 64drive no implementó el de borrado del chip? Tendría sentido pues para qué gastar esfuerzo y espacio en un comando que a priori no se usa. Asumiendo claro que la EEPROM de DK64 trabaje por comandos. ¿Y porqué el Everdrive si funciona? Intuyo que Krikzz se limitaria a usar una librería genérica para controlar la EEPROM que incluyera el comando y por eso se borran las partidas. Esto estaría en el firmware y no podría deshacerse con una actualización del OS.

En cuanto a la función antipirata, esta podría estar oculta o incluso su código no estar presente, sino que fuera el propio juego quien escribiera el código al vuelo al juntarse determinadas circunstancias, y por eso no ser detectado al leer el código. Si además es un evento aleatorio que sucede tras varias horas de juego, su monitorización se haría tediosa.
Hemos de pensar que el código del juego es complejo ya que incluye un bug que Rare no pudo solucionar más que añadiendo el expansión pak junto el cartucho. Si Rare no pudo encontrar el origen del bug, a la escene le pude costar encontrar una función oculta en el código.

Esta explicación esta pillada por los pelos ya que son muchas suposiciones: si es una EEPROM de comandos, si Marshall no hizo esto, si Krikzz hizo aquello, si la medida antipirata existe... Pero da sentido a que se borren las partidas solo con el Everdrive.
No creo que se trate de un problema (en el sentido de defecto) de los primeros Everdrive en su hardware o firmware ya que otros juegos usan EEPROM y no dan problemas. Solo Star Wars Racer tiene reportados problemas de guardado pero no le pasa a todo el mundo y tampoco borra completamente la partida. Viendo que Banjo Tooie y Jet Force Gemini si tienen sistemas antipirata, resultaría extraño que DK64 tenga el CIC x105 y sin embargo funcione con los x101 sin rechistar.

En resumen Radorn, es posible que juegues 50 horas al DK64 con tu 64drive y no te ocurra nada porque los comandos que usa el sistema antipirata no esten implementados en el flashcart.

Para saber si efectivamente existe este sistema antipirata habría que coger un cartucho como el ED v2 de Valdivia, quitarle el chip 7101 que lleva, cambiarlo por un 7105 y jugar al DK64 sin parar. Si se borran las partidas, es defecto del cartucho en alguna parte (hardware, software...), pero si no se borran, se vuelve a instalar el 7101 y vuelven a borrarse, es que realmente existe un sistema antipirata en el juego.

@valdivia Tu cartucho es un Everdrive v2. El v2.5 ya lleva UltraCIC y no te daría problemas con el Banjoo y el Jet Force, aunque para tu flashcart existen parches para esos juegos.
Para el DK64, solo se me ocurren tres soluciones:
-que te compres otro Everdrive, lo cual es una pasta para un solo juego.
-que cambies el CIC 7101 por un 7105, lo cual es engorroso y has de sacrificar un juego.
-que te compres un DK64 original, la solución más barata y sencilla.

¿Podrías confirmar que se te borraron todas las partidas del juego, o solo se borro una partida? ¿O se borro solo una partida porque no tenias más guardadas?

EMaDeLoC escribió:@radorn Completísima explicación de como funciona el 64drive.

Empezaré por el final de tu post largo: estoy conforme con las opciones, pero en cuanto a la B, que haya el sistema antipirata pero que solo los usuarios de ED64 lo hayan reportado o que los de 64drive no lo hayan jugado lo sufiente... Hay matices que añadir aquí.

Me puse a mirar un poco las direferencias entre memorias EEPROM y SRAM, solo por la wikipedia, pero revela una diferencia sustancial entre ambas memorias. Las EEPROM pueden comunicarse a traves de protocolos, mientras las SRAM leen o escriben datos según este activa la línea correspondiente. De ahí la necesidad de parches según los copiones o flashcarts que se fuesen a utilizar en su momento.
Pues debido al uso de protocolos algunas EEPROM aceptan comandos y uno de esos comandos, y aquí viene lo interesante, es el borrado completo del chip.

Valdivia comentó al principio que se le habían borrado LAS partidas, lo que cuadra con el uso del comando de borrado del chip. Pensemos en este comando: ¿cuantas veces se usaría en todo el catálogo de la N64? Normalmente cada juego con memoria interna guarda dos o tres partidas distintas para que así varias personas puedan seguir con la suya simultaneamente. Es normal que se pueda borrar una partida, ¿pero todas a la vez? ¿Hay algún juego que implemente borrar toda la memoria de guardado del cartucho con un solo botón?
Digo esto porque, ¿y si en el momento de implementar Marshall los comandos de EEPROM en su 64drive no implementó el de borrado del chip? Tendría sentido pues para qué gastar esfuerzo y espacio en un comando que a priori no se usa. Asumiendo claro que la EEPROM de DK64 trabaje por comandos. ¿Y porqué el Everdrive si funciona? Intuyo que Krikzz se limitaria a usar una librería genérica para controlar la EEPROM que incluyera el comando y por eso se borran las partidas. Esto estaría en el firmware y no podría deshacerse con una actualización del OS.

En cuanto a la función antipirata, esta podría estar oculta o incluso su código no estar presente, sino que fuera el propio juego quien escribiera el código al vuelo al juntarse determinadas circunstancias, y por eso no ser detectado al leer el código. Si además es un evento aleatorio que sucede tras varias horas de juego, su monitorización se haría tediosa.
Hemos de pensar que el código del juego es complejo ya que incluye un bug que Rare no pudo solucionar más que añadiendo el expansión pak junto el cartucho. Si Rare no pudo encontrar el origen del bug, a la escene le pude costar encontrar una función oculta en el código.

Esta explicación esta pillada por los pelos ya que son muchas suposiciones: si es una EEPROM de comandos, si Marshall no hizo esto, si Krikzz hizo aquello, si la medida antipirata existe... Pero da sentido a que se borren las partidas solo con el Everdrive.
No creo que se trate de un problema (en el sentido de defecto) de los primeros Everdrive en su hardware o firmware ya que otros juegos usan EEPROM y no dan problemas. Solo Star Wars Racer tiene reportados problemas de guardado pero no le pasa a todo el mundo y tampoco borra completamente la partida. Viendo que Banjo Tooie y Jet Force Gemini si tienen sistemas antipirata, resultaría extraño que DK64 tenga el CIC x105 y sin embargo funcione con los x101 sin rechistar.

En resumen Radorn, es posible que juegues 50 horas al DK64 con tu 64drive y no te ocurra nada porque los comandos que usa el sistema antipirata no esten implementados en el flashcart.

Para saber si efectivamente existe este sistema antipirata habría que coger un cartucho como el ED v2 de Valdivia, quitarle el chip 7101 que lleva, cambiarlo por un 7105 y jugar al DK64 sin parar. Si se borran las partidas, es defecto del cartucho en alguna parte (hardware, software...), pero si no se borran, se vuelve a instalar el 7101 y vuelven a borrarse, es que realmente existe un sistema antipirata en el juego.

@valdivia Tu cartucho es un Everdrive v2. El v2.5 ya lleva UltraCIC y no te daría problemas con el Banjoo y el Jet Force, aunque para tu flashcart existen parches para esos juegos.
Para el DK64, solo se me ocurren tres soluciones:
-que te compres otro Everdrive, lo cual es una pasta para un solo juego.
-que cambies el CIC 7101 por un 7105, lo cual es engorroso y has de sacrificar un juego.
-que te compres un DK64 original, la solución más barata y sencilla.

¿Podrías confirmar que se te borraron todas las partidas del juego, o solo se borro una partida? ¿O se borro solo una partida porque no tenias más guardadas?

Muchas Gracias por la ayuda , ahora por lo menos se que everdive tengo, menos mal que en los siguientes solucionaron todos los problemas y yo que pensaba que el mio era perfecto.

Sobre lo de las partidas fue siempre solo una la que se acababa borrando ,teneia pensado hacer copias de la partida pero este juego no lo permite y menos mal que tengo un cartucho suelto del donkey kong 64 ya no juego mas con fuego

Mi ultima duda el parche del banjo tooi tiene como idioma el español?

valdivia escribió:Sobre lo de las partidas fue siempre solo una la que se acababa borrando

Bueno, eso descarta el comando de borrado del chip, pero hay otro comando que borra sectores de memoria así que aún no descarta mi teoría.

valdivia escribió:teneia pensado hacer copias de la partida pero este juego no lo permite y menos mal que tengo un cartucho suelto del donkey kong 64 ya no juego mas con fuego

Mi ultima duda el parche del banjo tooi tiene como idioma el español?

[/quote]
Si tienes el original juega al original, hombre.
Puedes hacer las copias de las partidas de cualquier juego que ejecutes en el everdrive, solo copia el archivo sabe correspondiente que está en la carpeta Ed64/save de la tarjeta a través del ordenador.
En cuanto al parche del Banjo no sé si admite la ROM europea y ahora no puedo mirarlo (hablo desde el móvil). Antes he mencionado un hilo del foro de Kirkzz de incompatibilidades del everdrive, ahí hay información del parche.

@valdivia Por desgracia para quienes lo necesitan, parece que solo la versión americana de Banjo-Tooie fue parcheada, y esta no tiene las traducciones a francés, alemán y español que si tiene la version europea. El parche es de los tiempos de la scene original de N64 y, cuando empezaron a salir los flashcarts de N64, se empezó a desenterrar material antiguo de entonces. Creo que el autor, LaC nuevamente, dijo que sí había parche PAL, pero nadie parece tenerlo... También es probable que yo entendiera mal y que realmente nunca existiera.

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

@EMaDeLoC los guardas EEPROM en los cartuchos de N64 son chips de 8 patillas, y a ellos llega una linea de comunicacion en serie que los conecta con el PIF dentro de la consola. creo que este bus es denominado SI, Serial Interface. Los chips SRAM van conectados al PI, o Parallel Interface, que ya conocemos, igual que los chips ROM. Los chips FlashRAM tambien van conectados al PI.
Hay que recordar que el bus PI es un bus intercalado o "interleaved", que envia y recibe datos por las mismas lineas por donde indica las direcciones. Este diseño requirió de usar chips ROM especiales y por eso no se pueden usar chips de memoria normales como en consolas de cartucho anteriores y solo desde hace unos pocos años hay placas repro con sus correspondientes chips controladores para convertir el protocolo del bus.

Volviendo al SI, siendo este un bus en serie, parece bastante esperable que la EEPROM use comandos. Sin embargo, el mero hecho de estar en el PI no libra al SRAM, y mucho menos al Flash, de usar comandos tambien. Y digo esto porque he visto mas de una vez conversaciones tecnicas sobre N64 hablando de cómo acceder a chips de guardado especificos, y que hay variantes. No todos los chips Flash son iguales, y creo que los SRAM tampoco. A medida que Nintendo iba cambiando los chips en su linea de produccion, tambien actualizaba las librerías de acceso a los chips de guardado en la ultralib para soportar todos los modelos en circulacion, o quizá ya los tenía preparados de antemano, quien sabe. La cosa es que esto denota que no todos los chips de un mismo tipo se acceden exactamente igual. Se que el SI incluye, entre otras lineas de control, dos que son /read y /write. Hay que activar esa linea cada vez que quieres leer o escribir en uno de los chips. Obviamente los chips ROM no responden a /write... probablemente ni estén conectados. Y cada chip sabe a qué rango de direcciones debe responder o ignorar.

En mi experiencia personal trasteando con la N64 he encontrado "pruebas circunstanciales" que parecen confirmar que no todos los chips SRAM son iguales: Hace años hice copias de mis cartuchos originales y sus partidas guardadas usando metodos un tanto rocambolescos, con un Action Replay, un Passport 3, controller paks, un NeoMyth 64... una historia que, si a alguien le interesa, puedo contar aqui o en el hilo de curiosidades, la cosa es que el Action Replay (o GameShark en America) tiene un "save manager" capaz de copiar datos de partidas de cartucho a notas de juego en un Controller Pak, y tambien volverlas a copiar de vuelta al cartucho.
Como sabemos hay 5 tipos de guardado en cartuchos EEPROM 4k y 16k, SRAM 256k y 768k, y Flash 1024k, y luego está el CP que es tambien SRAM 256k.
El save manager del AR/GS guarda sin problema las partidas EEPROM en notas de CP sin compresión. Si tienes alguna forma de copiar datos del Controller Pak al PC, puedes extraer las notas con una serie de programas y usar los datos en un emulador o pasarlas al flashcart sin problema. No he tenido ningun problema con ninguno de mis cartuchos originales con EEPROMs, todos han funcionado. Claro que tampoco tengo tantos juegos como para tener una alta confianza estadística.
En el caso de SRAM, siendo ambos chips del mismo tamaño y siendo que el formato del CP ya ocupa lugar, el cartucho hace compresion de datos. Por ejemplo, mi partida de Zelda acabó reducida a 19 paginas del CP.
Sin embargo, la partida de otro juego SRAM que tengo, Smash Bros, no solo no lo copia, si no que ni lo ve, no aparece en el administradors de "saves". O bien el AR/GS intenta comprimirlo y viendo que no va a caber, desiste y no muestra nada, o bien sencillamente no es capaz de comunicarse con el chip porque las rutinas de acceso que tiene no valen para ese chip. Yo me decanto por lo segundo.

EMaDeLoC escribió:Viendo que Banjo Tooie y Jet Force Gemini si tienen sistemas antipirata, resultaría extraño que DK64 tenga el CIC x105 y sin embargo funcione con los x101 sin rechistar.

A mi me parece que no resulta extraño en absoluto si recordamos la historia del desarrollo de DK64, que empezó como juego de DD, donde lo que se autenfica con el CIC y el PIF es la ROM de arranque del 64DD, y no el disco. Por tanto, cuando lo convirtieron a cartucho, y con los problemas que ya tuvieron (y el feliz accidente que permitió la salida del EP al mercado al margen del DD) para terminar el juego a tiempo, lo extraño sería que se pusiesen a implementar medidas de sabotaje antipirata en el ultimo momento ¿no crees?
Hasta donde yo se, el CIC interno del 64DD tampoco tiene medidas de seguridad extra como las del x105, lo cual tambien es esperable, si tenemos en cuenta que, de haber sido lanzado al gran publico, lo que se piratearía serían los discos, y no el 64DD en si, que es el que lleva el CIC para que la consola arranque su ROM. A fin de cuentas, el 64DD no es otra cosa que un cartucho enorme que lee discos magneticos xD. No muy diferente de un flashcart que lee tarjetas SD si lo piensas. La piratería en DD, por tanto, no hubiera dependido de un CIC, pues ya lo vas a tener porque viene con el DD, si no de los discos, que tendrán su formato especifico y alguna medida para entorpecer su replicacion tambien, aunque seguramente nada que no acabasen solucionando en poco tiempo los piratas comerciales. Estoy convencido de que el motivo principal de que no saliese el DD fue el terror que tenía Nintendo a que le pirateasen los discos, que fue tambien la razon por la que siguieron con cartuchos.

EMaDeLoC escribió:Las EEPROM pueden comunicarse a traves de protocolos, mientras las SRAM leen o escriben datos según este activa la línea correspondiente. De ahí la necesidad de parches según los copiones o flashcarts que se fuesen a utilizar en su momento.

No, lo de los parches para diferentes guardados te aseguro que fue por lo que dije antes. Había mas cartuchos originales y adaptadores multibloque (que enlacé antes, si te los has peridido) con eep4 y sram256 que con eep16 y desde luego flash1024. Se hicieron los parches para facilitar el uso con copiones y las capacidades mas comúnmente disponibles en ellos. Nada que ver con las propiedades electronicas de los diferentes tipos de memoria.

EMaDeLoC escribió:Pues debido al uso de protocolos algunas EEPROM aceptan comandos y uno de esos comandos, y aquí viene lo interesante, es el borrado completo del chip.

Valdivia comentó al principio que se le habían borrado LAS partidas, lo que cuadra con el uso del comando de borrado del chip. Pensemos en este comando: ¿cuantas veces se usaría en todo el catálogo de la N64? Normalmente cada juego con memoria interna guarda dos o tres partidas distintas para que así varias personas puedan seguir con la suya simultaneamente. Es normal que se pueda borrar una partida, ¿pero todas a la vez? ¿Hay algún juego que implemente borrar toda la memoria de guardado del cartucho con un solo botón?

Creo que estás especulando demasiado. Exista o no un comando de borrado completo. nada impide borrar con una escritura de 00s o FFs. Los chips EEPROM de N64 son 512 y 2048 bytes. No ganas nada implementando comandos exoticos.

Además...

valdivia escribió:Sobre lo de las partidas fue siempre solo una la que se acababa borrando

Esto me suena mas a corrupcion de datos. Cada juego es un mundo, pero muchos tienen medidas de comprobacion e incluso de copia doble en las partidas guardadas para asegurar la integridad de los datos.
A mi me suena a un error de transmision o de copia de los datos, la partida queda corrupta, y, cuando el juego la va a revisar, ve que hay un problema, trata de corregirlo y no puede, y dice, "esto no vale y lo borro".
Eso o la hipotetica medida de sabotaje.

EMaDeLoC escribió:¿y si en el momento de implementar Marshall los comandos de EEPROM en su 64drive no implementó el de borrado del chip? Tendría sentido pues para qué gastar esfuerzo y espacio en un comando que a priori no se usa. Asumiendo claro que la EEPROM de DK64 trabaje por comandos. ¿Y porqué el Everdrive si funciona? Intuyo que Krikzz se limitaria a usar una librería genérica para controlar la EEPROM que incluyera el comando y por eso se borran las partidas. Esto estaría en el firmware y no podría deshacerse con una actualización del OS.

Todo esto me parece aun mas improbable. Los eeproms de la N64 son ya archiconocidos en la scene. Si hubiera tal comando estaría implemetado y no tendría sentido ninguno decir "bueno, no se si esto se usa o no, así que me lo salto y cruzo los dedos para que no pase nada". No, lo implementas y te quedas tranquilo.

Despues de toda esta divagacion y analisis, y el detalle de la partida individual que nos da @valdivia, me inclino aun mas que antes por un error en el ED que causa corrupcion y el propio juego se ve obligado a corregirlo, borrando esa partida concreta, y no toda la eeprom.

EMaDeLoC escribió:coger un cartucho como el ED v2 de Valdivia, quitarle el chip 7101 que lleva, cambiarlo por un 7105

¿Acepta ser usado así? ¿Tiene tambien booloader dual como el 64drive HW1? (el HW2 asumo que no lo tiene, dado que usa un UltraCIC, igual que los EDs mas nuevos)

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

AÑADO y CORRIJO: Me acabo de dar cuenta de una cosa. EEPROM son las siglas de Electronically Erasable and Programmable Read Only Memory. Es ROM, no RAM. Antes de las EEPROMs existian las ROMs, que se fabrican directamente con los datos ya escritos, y las EPROMs (Electronically Programmable ROM) que se podían programar electricamente de un tiron y usarlas en lugar de una ROM tradicional, pero, para borrarlas, hay que retirar una etiqueta y exponer el chip, visible a traves de un cristal, a luz ultravioleta (aunque tambien puede funcionar la luz natural del Sol), que lo borra completamente y entonces se puede volver a PROGRAMAR.
En este contexto, el concepto de programar es diferente al de escribir. Mientras que otras memorias se pueden escribir de manera aleatoria (RAM, y sus variantes, como SDRAM, S-RAM...), o por bloques (Flash), las memorias PROGRAMABLES, se escriben de una sola vez, y si quieres volver a escribir algo nuevo tienes que borrarlas completamente y volverlas a escribir, o, mejor dicho, programar, de un tiron.
Las EEPROM son iguales, con la diferencia de que el borrado se puede hacer electronicamente, sin necesidad de luz ultravioleta.

Todo esto para decir que es imposible que el 64drive no incorpore el comando de borrado, como sugeriste, pues es algo inherente al proceso de manipular una EEPROM. Los juegos realmente cachean el contenido de los guardapartidas en la RAM de la N64 y, cuando hay datos modificados, borran y reescriben el chip entero.

Así que seguimos con la teoria de que o bien hay una medida de sabotaje anti-piratas y los usuarios del 64drive no han jugado lo suficiente al DK64 para toparse con el (o no se han quejado de ello, hasta donde yo se), o hay versiones del ED que tienen algun tipo de fallo que provoca este problema.

Bueno radorn, me rindo ante tus conocimientos de las memorias. Pero algunas EEPROM no necesitan borrarse completamente para reescribirlas, algunas se organizan por bloques o sectores tan pequeños como un simple byte.
De hecho respondiendo a Valdivia:

EMaDeLoC escribió:

valdivia escribió:Sobre lo de las partidas fue siempre solo una la que se acababa borrando

Bueno, eso descarta el comando de borrado del chip, pero hay otro comando que borra sectores de memoria así que aún no descarta mi teoría.

Y tiene sentido que para los juegos de N64 la EEPROM se divida en 4 bloques: tres para guardar partida y uno para guardar configuración. Aunque depende de cada juego y de la información a guardar: SM64 guarda 4 partidas y OoT guarda dos. Así no hay que volcar toda la memoria y voverla a guardar descartando la partida que se quiere borrar.
Así que las EEPROM tanto se pueden borrar enteras como por bloques.

Y efectivamente el DK64 se desarrolló para 64DD, pero eso no significa que no implementaran medidas antipirata en algún momento. El cambio de disco a cartucho no se hizo de la noche a la mañana, fue un proceso de meses. Recuerda que ya se avisó con 4 o 5 meses antes de su lanzamiento que el juego vendría con el EP, y una medida que borrase las partidas tras una comprobación aleatoria de CIC y quedase oculta no consumiría mucho tiempo. Hablamos de tal vez una docena de lineas de código C o quizá entre 50 y 70 instrucciones de ensamblador. No es tan imposible.

En cuanto a que sea desconocido el error para el 64drive, pues no. He encontrado un log antiguo en esta página y dice:

Menu version 1.08 (02.19.2012)
Bugfixes:
Loading zero-byte files doesn't hang UI
Scrolling regulated for PAL users
MP3 playback glitching fixed for PAL users
Small sorting issue
Quickstart after picking an item caused conflicts
Possible fix for DK64 save issues

Por tanto Marshall sabía que había un problema de guardado e implementó la solución. Si era un problema específico con ese juego que nada tenía que ver con un modo antipiratería, se queda por resolver.

Por cierto:

Menu version 1.10 (09.08.2012)
Bugfixes:
Improved region detection (Thanks radorn)

Esto es todo lo que puedo matizar a lo que dices, lo demás se escapa de mis conocimientos, por lo que efectivamente puede tratarse de un defecto de los Everdrive en algún punto que hace tiempo que no tienen los 64drive.

radorn escribió:

EMaDeLoC escribió:coger un cartucho como el ED v2 de Valdivia, quitarle el chip 7101 que lleva, cambiarlo por un 7105

¿Acepta ser usado así? ¿Tiene tambien booloader dual como el 64drive HW1? (el HW2 asumo que no lo tiene, dado que usa un UltraCIC, igual que los EDs mas nuevos)

Pues investigando un poco en los foros en palabras del propio Krikzz:

Not enough just enable 6105 mode in cic, also need to change bootcode in ED64 and make some changes in OS.
As for changes in OS, in the past i tried to use 6105 with ED64 v2, but some games stoped working, i still don't know why.

Eso fue en 2015, y dado que no vende el v2 desde noviembre del 2014 y que con el UltraCIC se arregló el problema (fuese cual fuese), creo que directamente pasó del tema.

El caso es que al final ambos flashcarts tenian el problema, el 64drive lo resolvió pronto y en el Everdrive con un fix para copiones antiguos se resolvía hasta la aparición del UltraCIC. Si el borrado es por unas características particulares de la gestión de memoria del DK64 o una medida antipirata, se va a quedar en el misterio.

A menos que puedas hacerle un downgrade a tu 64drive y alternar entre un CIC x102 y un x105, no podrás comprobar si existe el error de guardado.

EMaDeLoC escribió:A menos que puedas hacerle un downgrade a tu 64drive y alternar entre un CIC x102 y un x105, no podrás comprobar si existe el error de guardado.

A mediados del año pasado por fin desoldé, con medios bastante rudimentarios, un 7105 de un cartucho de PD en un estado bastante lamentable que compré en un rastro antes si quiera de que saliera el 64drive porque al principio de todo, en 2011, podías incluso comprarlo sin carcasa ni CIC y ponerlos tu, pero me ahorré el trabajo de agujerear yo la carcasa y tal y lo compre CON. Además puse un 7101 para usar comodamente homebrew por USB, que logicamente viene firmado para ese CIC, e injertarle el bootcode del x105 y recalcular los CRCs... que pereza...
Desoldé el 7101 del 64drive y puse el 7105, y puenteé el jumper de cambio de banco del bootloader.
La cosa es que, teniendo mi fabuloso conector T que visteis en el video de "mira mamá, sin cartucho", lo unico que tengo que hacer es quitar el puenteado de ese jumper para que vuelva a modo normal y poder probar. Pero esperaré a instalar un interruptor para cambiar de modo facilmente antes de hacer la prueba del DK64.

EMaDeLoC escribió:Pero algunas EEPROM no necesitan borrarse completamente para reescribirlas, algunas se organizan por bloques o sectores tan pequeños como un simple byte.

Eso suena... caro ...y lento. Debe ser para usos muy especializados.

EMaDeLoC escribió:En cuanto a que sea desconocido el error para el 64drive, pues no. He encontrado un log antiguo en esta página y dice:

Menu version 1.08 (02.19.2012)
Bugfixes:
Loading zero-byte files doesn't hang UI
Scrolling regulated for PAL users
MP3 playback glitching fixed for PAL users
Small sorting issue
Quickstart after picking an item caused conflicts
Possible fix for DK64 save issues


Por tanto Marshall sabía que había un problema de guardado e implementó la solución. Si era un problema específico con ese juego que nada tenía que ver con un modo antipiratería, se queda por resolver.

Buen trabajo de investigacion. La verdad es que no recordaba ese detalle. Debió ser una de esas cosas que se solucionaron sin haberme afectado a mi ni haber tenido noticias de que existiera, con lo cual no me quedó en la memoria.
Y eso que busqué "64drive dk64 save" y en los resultados sale esa pagina de nesworld, pero en el texto de resumen de duckduckgo no salen referencias a dk64 o save, solo 64drive, y siendo una review no supuse que sacaría los changelogs del menu ni que en ellos se fuera a mencionar el juego.

Una cosa que me sorprende es que el fix esté en el menú y no en el firmware... O sea, el menú es un programa que corre en la CPU de N64 como si fuera un juego, hace sus cosas navegando la SD, cargando juegos, y todo eso, y cuando el juego arranca, ya no pinta nada. ¿En qué manera puede afectar un arreglo en el menú para solucionar algo que pasa mientras se ejecuta el juego? No lo entiendo. Voy a tener que preguntarle, pero me da no se que molestarle, está bastante liado.
Tengo copias de todas las actualizaciones historicas tanto del menu como del firmware, pero las de firmware nunca trajeron changelog para ver si aclaraban algo
En realidad no son changelogs, si no un resumen de novedades correspondientes a la version que acompañan, sin incluir los cambios anteriores. Siempre me pareció un error hacerlo así, pero supongo que no me pareció suficientemente importante para molestarle con ello.

De todas formas, a ver si tambien voy a tener que usar un menú anterior a 1.08, y reflashear con firmware de la serie 1.x tambien, porque ahora está en la 2.x y creo que no son compatibles... vaya lio.

EMaDeLoC escribió:Por cierto:

Menu version 1.10 (09.08.2012)
Bugfixes:
Improved region detection (Thanks radorn)

[Hechos de los Apostoles 10:25-26] Y según Pedro entraba, Cornelio le salió a recibir; y cayendo a sus pies, le adoró. (26) Mas Pedro le levantó, diciendo: Levántate, que yo mismo también soy hombre.

Por aquel entonces, reuní todas las ROMs con idiomas mas allá del inglés y japones, y, manualmente (porque soy un inutil que no sabe programar ni usar herramientas avanzadas), revisé con un editor hexadecimal las cabeceras. Para ver qué codigos de región tenian, y apuntar equivalencias.
Esto lo repetí un par de ocasiones por que me encontré novedades en ROMs de prototipos y alguna cosa mas.
Cuando tenía novedades, se las pasaba.
Sin embargo, este mismo año cuando le iba a pasar una que acababa de encontrar, encontré que algunas de las que ya le habia pasado, ni siquiera las había puesto aun.
Creo que debe estar guardandolas para el menú 2.0, si es que sale algun dia a este ritmo. Pero yo tengo una version de prueba con las novedades xD.
Me pregunto si krikzz tiene todos los codigos de region que he encontrado yo, o incluso si tiene alguno que a mí se me haya escapado. No se tampoco si el y marshallh comparten esta informacion. En fin.
¿No puse algo de esto tambien el el hilo de curiosidades? me falla la memoria ya...

@EMaDeLoC acabo de hablar con marshallh sobre el tema del DK64

(12:29:39) radorn: One more thing. It's been brought to my attention, from ED64 users, that there's some problems with DK64 wiping saves. They solve that using the old patch which converts the save to SRAM. Additionally, they pointed me to an old 64drive menu release note where something about DK64 and save issues was also mentioned.
(12:30:48) radorn: What's the deal? Are there CIC x105 related anti-copy sabotage measures too, like with JFG and BT?
(00:24:31) marshallh: dk64 is buggy as hell
(00:24:49) marshallh: i think the problem with dk64 was my eeprom emulation which had a latent bug
(00:24:54) marshallh: i found it once i ported code to HW2
(00:24:59) marshallh: so far nobody has reported problems

Creo que no lo esclarece todo, pero algo es algo.

@radorn Bueno, algo si esclarece cuando dice que el juego es "buggy as hell" lo que yo entiendo a que es propenso a dar errores.
Con otro juego no significaría mucho, pero sabiendo que esté en concreto lo lanzaron con el expansion pak para mitigar un bug, significa que su código es muy problemático.
Puede que sea problemático en parte de forma intencionada, pero es más factible que en la conversión de DD a cartucho se les liara el código y sea algo especial al manejar la memoria de guardado, y como es el único, conlleve errores difíciles de diagnosticar y solucionar y se entienda como una medida anticopia.
En resumen, no descarto completamente que haya alguna medida anticopia por ahí dentro, pero siguiendo los antecedentes y la experiencia de marchall con la N64, lo dejaremos en que el juego es problemático de emular o replicar en otro medio.
Igualmente sería interesante probar el juego arrancando con un CIC x105 y cambiándole después a un x102, a ver si se reproduce el error. Aclararía algo.