- Añadido dev/mload shadow engine. Para evitar la detección de los dispositivos en juegos como PoP, sin necesidad de parches
- Añadido soporte para ficheros . wip (añadir a la carpeta "codes" en la SD o USB. Ver el txt de la versión para mas informacion)
- Eliminado el soporte para el puerto 1 USB (no funciona bien y no se donde está el problema )
NOTAS:
-tengo que subir una actualización de los fuentes de mload (4.1) que hace uso del nuevo dispositivo usb 2.0. Los cIOS v5 siguen siendo válidos, dado que los cambios no afectan al cIOS, si no a los módulos externos de apoyo. La razón es que el antiguo dev/usb2 es detectado por el PoP y por motivos de conveniencia, se ha procedido a cambiar de nombre.
- Evidentemente, mañana podría salir un juego que detectara el nuevo dispositivo, pero la cosa sería tan sencilla como volver a cambiar el nombre del dispositivo por otro, con lo cual, de poco servirá tratar de bloquear dicho dispositivo y por otro lado, si las contramedidas van a consistir en eso, mejor. Lo realmente importante es que dev/mload ya no puede ser detectado e incluso si quisieramos, podríamos utilizar nombres de dispositivos generados de forma aleatoria a partir de ahí (y usar una tabla de referencia para enlazarlos), pero no vamos a entrar en estados paranoicos sin necesidad y además, cuanto mas facil sea de eliminar la contramedida y mas atractivo sea utilizar dicho método, mejor para nosotros
-La versión 5.0C de uLoader, tiene un modo específico para ocultar los dispositivos de fatffs_module cuando no se precisa hacer uso de la emulación FFS (es decir, cuando no se emulan los saves o cuando no se oculta la actualización del diario). De esta forma, se garantiza un mínimo impacto y en el funcionamiento y los dispositivos de los que hace uso el módulo, dejan de ser un problema desde dicho modo.
Hermes . ahora me dan "error fat fss" los .ciso al cargarlos por SD como el super mario galaxy 2 con el cios 222, con el 223 no da error. Algunos juegos .ciso al cargar por SD tb tiran error de fat con el cios 223 y tengo que pasar al 224, la tarjeta es SDHC de 8gigas y con las versiones anteriores no he tenido ningun problema, me es mas comodo que el disco duro ya que tengo solo los juegos que utilizo y es muy portable para llevar la wii de viaje por ejemplo.
Por DVD carga los .ciso bien y por USB tb sin problema.
Yo creo que la mejor opción que tiene nintendo es que te contrate con un buen contrato , así mata dos pájaros de un tiro les ayudas y te quitan de ayudar a la scene .
laranjito escribió:Hermes . ahora me dan "error fat fss" todos los .ciso al cargarlos por SD como el super mario galaxy 2 con el cios 222, con el 223 no da error.
Por DVD error -1 (cios 222), no carga
Lo de la SD, no lo entiendo, porque por USB si que lanza juegos en formato .ciso, salvo que sea un problema de que no monta la SDHC porque de algún problema (no es raro que las SDHC se comporten de forma inestable (no las recomiendo por eso) y el hecho de que cargue al seleccionar cIOS 223, demuestra eso). Además, lo nuevo no debería afectarle, porque eso va por otra vía. De todas formas, luego pruebo de cargar algo por mi SDHC de 4GB, por si fuera un error de otra cosa mas antigua.
Lo del DVD, tampoco es afectado por lo nuevo, así que...
Lo nuevo lo único que hace es cargar fatffs_module en un supuesto que antes no se cargaba, pero en ese supuesto no se trata de montar ni el dispositivo de la SD, ni el de USB, con lo cual es imposible que retorne error ahí (de hecho,ayer era mas probable con la versión 5.0B que ahora)
En los supuestos en los que se cargaba fatfss normalmente (.ciso, Wiiwares, etc), solo se procede al ocultamiento de dev/mload despues de enviar una orden justo cuando estamos a punto de lanzar el juego y ese dispositivo solo se utiliza desde el PPC y en ese momento, está inactivo. Con lo cual, tampoco puede producir error alguno.
Hermes, tanto tiempo. La verdad es que no he tenido mucho tiempo libre desde Enero hasta ahora, pero siempre me doy una vueltita por el Hilo para ver como andan las cosas.
Queria reportarte 2 problemas que he tenido, las 2 relacionadas con la carga de Backups desde la lectora de DVD (interna).
El primero es que no me dejaba cargar los juegos desde ahí, se colgaba con el titulo "Reading The Banner", revisando encontré que se estaba usando la función de carga desde FAT para leer el banner desde disco. Aqui esta el parche:
Spaceman Spiff escribió:Hermes, tanto tiempo. La verdad es que no he tenido mucho tiempo libre desde Enero hasta ahora, pero siempre me doy una vueltita por el Hilo para ver como andan las cosas.
Queria reportarte 2 problemas que he tenido, las 2 relacionadas con la carga de Backups desde la lectora de DVD (interna).
El primero es que no me dejaba cargar los juegos desde ahí, se colgaba con el titulo "Reading The Banner", revisando encontré que se estaba usando la función de carga desde FAT para leer el banner desde disco. Aqui esta el parche:
Hola nen.
En esa parte, no hay ningún bug, ya que la función correcta es fun_fat_read a la que se pasa fp=NULL para cambiar el funcionamiento a DVD.
Otra cosa es que tu chip sea un tanto puñetero y te de problemas
El segundo parche no es correcto, puesto que hay que asegurar que el buffer está alineado a 32 bytes y tu estás alineando el offset...
EDITO:
Humm, ya veo donde está el posible problema
El tema está en que si el buffer no está alineado a 32, se utiliza el desplazamiento para corregir el offset hacia atrás, de ésta forma:
WDVD_UnencryptedRead(buffer, 0x40, offset - mod);
Eso tiene un problema y es que si el buffer no está alineado a 4 bytes, el offset no será correcto.
Hermes escribió:Otra cosa es que tu chip sea un tanto puñetero y te de problemas
El segundo parche no es correcto, puesto que hay que asegurar que el buffer está alineado a 32 bytes y tu estás alineando el offset...
Hermes, mis problemas con mi chip (que definitivamente es puñetero!) no son con el iobuffer, sino con los offset no alineados. En caso de que le pase un offset que no sea multiplo de 32, utiliza el offset que le mande (offset & (~0x1F)), con lo que devuelve algo totalmente distinto a lo que se le pidio leer.
El iobuf siempre esta alineado, ya que los buffers que usas para hacer I/O sobre el disco siempre los adquiris con memallign, y si hay algun iobuf no alineado, corrigiendo el código fuente del uLoader se arregla. Los offsets no están precalculados y pueden que no siempre esten alineados.
/* Calculate offset */ offset = ((u64)lba) << 2;
/* Calculate sizes */ mod = ((u32) offset) & 31;
if (mod) { // Offset not aligned...
Fijate en el comentario del código del parche que te mande (y que ya estaba desde antes), dice "Offset not aligned", que es la intención del código. Y por eso también se llama a la función WDVD_UnencryptedRead con el offset cambiado, para acomodar el offset para no tener problemas con los offsets que no estén alineados. La alineación del iobuf no es lo que me esta importando en esa parte del código, afortunadamente están siempre alineados.
Spaceman Spiff escribió: Hermes, mis problemas con mi chip (que definitivamente es puñetero!) no son con el iobuffer, sino con los offset no alineados. En caso de que le pase un offset que no sea multiplo de 32, utiliza el offset que le mande (offset & (~0x1F)), con lo que devuelve algo totalmente distinto a lo que se le pidio leer.
El iobuf siempre esta alineado, ya que los buffers que usas para hacer I/O sobre el disco siempre los adquiris con memallign, y si hay algun iobuf no alineado, corrigiendo el código fuente del uLoader se arregla. Los offsets no están precalculados y pueden que no siempre esten alineados.
Fijate en el comentario del código del parche que te mande (y que ya estaba desde antes), dice "Offset not aligned", que es la intención del código. Y por eso también se llama a la función WDVD_UnencryptedRead con el offset cambiado, para acomodar el offset para no tener problemas con los offsets que no estén alineados. La alineación del iobuf no es lo que me esta importando en esa parte del código, afortunadamente están siempre alineados.
Deberia aprender aunque sea un poco sobre eso. Me da gusto ver que hay quienes se interesan en el funcionamiento de Uloader y se preocupan en corregir ciertos detalles, que bueno
Tambien aprovecho a felicitarte Hermes por tu excelente trabajo y seguir dando manteniemiento a uLoader, realmente eres grande
Wismaster escribió:Buenas, siempre hace falta tenerlo en la sd aunque lo tengas instalado como canal??
Un saludo
Te refieres a uLoader no es asi?, Pues depende de si quieras la version actual, ya que si haria falta tenerlo en la SD ya sea para lanzarlo por el HomeBrew Channel, o para que lo utilize un Canal ForWarder (Acceso Directo), en caso de que tu canal sea "Full" pues sería como si tuvieras 2, lo recomendable es un ForWarder que no dan tantos problemas .
Saludos
Hermes
MegaAdicto!!!
11.053 mensajes desde ene 2003
Editado 1 vez. Última: 22/05/2010 - 20:05:35 por Hermes.
Hermes escribió:Otra cosa es que tu chip sea un tanto puñetero y te de problemas
El segundo parche no es correcto, puesto que hay que asegurar que el buffer está alineado a 32 bytes y tu estás alineando el offset...
Hermes, mis problemas con mi chip (que definitivamente es puñetero!) no son con el iobuffer, sino con los offset no alineados. En caso de que le pase un offset que no sea multiplo de 32, utiliza el offset que le mande (offset & (~0x1F)), con lo que devuelve algo totalmente distinto a lo que se le pidio leer.
El iobuf siempre esta alineado, ya que los buffers que usas para hacer I/O sobre el disco siempre los adquiris con memallign, y si hay algun iobuf no alineado, corrigiendo el código fuente del uLoader se arregla. Los offsets no están precalculados y pueden que no siempre esten alineados.
/* Calculate offset */ offset = ((u64)lba) << 2;
/* Calculate sizes */ mod = ((u32) offset) & 31;
if (mod) { // Offset not aligned...
Fijate en el comentario del código del parche que te mande (y que ya estaba desde antes), dice "Offset not aligned", que es la intención del código. Y por eso también se llama a la función WDVD_UnencryptedRead con el offset cambiado, para acomodar el offset para no tener problemas con los offsets que no estén alineados. La alineación del iobuf no es lo que me esta importando en esa parte del código, afortunadamente están siempre alineados.
Saludos
Humm, ¿te has fijado que la lectura tocha ( en el if (size)), si la tomáramos tal y como tu modificas la rutina, necesariamente, tendría un offset no alineado a 32?
Yo recuerdo que esa parte me la modificaste tu y me fallaron juegos al instalar y otras personas reportaron el mimso problema... y por eso volví a ajustar el modulo a iobuf, que es a quien corresponde.
buffer=memalign(32, 32768+64); if (!buffer) return -1;
while(len>0) { size= (len>32768) ? 32768 : len;
if(size>mod) size-=mod;
/* Read data */ ret = WDVD_UnencryptedRead(buffer, (size+mod+31) & ~31, offset - mod); if (ret < 0) goto out;
/* Copy data */ memcpy(iobuf, buffer + mod, size);
iobuf+=size;
len-= size;
offset+= (u64) size;
mod=0; }
/* Success */ ret = 0;
out: /* Free memory */ if (buffer) free(buffer);
return ret; }
Esta modificación está pensada para offset y memoria desalineada (que hay algún caso) y debería irte bien
Pero como tu me lo mandas, si offset no está alineado, en caso de ser una lectura corta, sería offset-mod y ese offset estarí alineado, pero donde se supone que deberían estar alineados los datos en memoria, (en if(size)), ahí recibirá offset, puesto que no se modifica con posterioridad y lo mismo pasaría con la última lectura, pues toda la rutina está ajustada a alineación de memoria y no de offset
tengo un problema, tengo una wii actualizada con el pimp my wii a 4.1E, decir ke antes de actualizar ya me pasaba , el caso es ke cuando meto un backup con neogama se me reinicia, bien me baje el uloader 5.0C, instale las cios con su instalador las 222 y las de arrbia ke creo ke son las 202, bien tengo las ios 38 rev 17 instaladas.
Wismaster escribió:Buenas, siempre hace falta tenerlo en la sd aunque lo tengas instalado como canal??
Un saludo
Te refieres a uLoader no es asi?, Pues depende de si quieras la version actual, ya que si haria falta tenerlo en la SD ya sea para lanzarlo por el HomeBrew Channel, o para que lo utilize un Canal ForWarder (Acceso Directo), en caso de que tu canal sea "Full" pues sería como si tuvieras 2, lo recomendable es un ForWarder que no dan tantos problemas .
Saludos
Okis gracias, mas que nada es que me la a dejado un amigo y no tenia ninguna sd suya para poder dejarle el uloader, por eso lo keria instalar como canal.
xboxadicto escribió:tengo un problema, tengo una wii actualizada con el pimp my wii a 4.1E, decir ke antes de actualizar ya me pasaba , el caso es ke cuando meto un backup con neogama se me reinicia, bien me baje el uloader 5.0C, instale las cios con su instalador las 222 y las de arrbia ke creo ke son las 202, bien tengo las ios 38 rev 17 instaladas.
pues cuando meto un backup me sale dvd Error -1
alguna solucion??
gracias
alguien puede a yudarme???
Tmv_Josue
Let's Go To HeLL
2.856 mensajes desde nov 2009 en Cancún México
Editado 1 vez. Última: 23/05/2010 - 01:18:14 por Tmv_Josue.
Okis gracias, mas que nada es que me la a dejado un amigo y no tenia ninguna sd suya para poder dejarle el uloader, por eso lo keria instalar como canal. Saludos
Pues en ese caso... porque no le instalas uno de los canales de Josete2k que aunque son forwarders puedes cambiarle el .dol ForWarder por el .dol de uLoader 5.0c inyectandoselo con el CustomizeMii 3.11, de esa forma tendrá la versión mas actual sin necesidad de una SD , aunque no se que pasara con la función de la carpeta codes que se usa desde la SD además de la obvia complicación que habrá con este canal "Full" cuando se modifique uLoader nuevamente y tu amigo quiera esta actualización.
xboxadicto escribió:
xboxadicto escribió:tengo un problema, tengo una wii actualizada con el pimp my wii a 4.1E, decir ke antes de actualizar ya me pasaba , el caso es ke cuando meto un backup con neogama se me reinicia, bien me baje el uloader 5.0C, instale las cios con su instalador las 222 y las de arrbia ke creo ke son las 202, bien tengo las ios 38 rev 17 instaladas. pues cuando meto un backup me sale dvd Error -1 alguna solucion?? gracias
alguien puede a yudarme???
La verdad no se a que se deba pero por qué no lo checas en la búsqueda del hilo o espera a ver si alguien te puede ayudar, pero no te desesperes .
No se si colaboras con Wanin o no pero uno de los desarrolladores de otro Loader me pidio que te escribiera esto de su parte:
"If you have a direct line to Hermes, you might want to let him know that the in development rev20 already has a solution to the problem. From what giantpune has shown me, it seems Wanin is just blocking reads of the IOS modules from the games."
Esto a referente a juegos como POP.
Supongo que la razon del mensaje debe ser para que te informaras con wanin y facilitarte la tarea no se como lo veas.
No se si colaboras con Wanin o no pero uno de los desarrolladores de otro Loader me pidio que te escribiera esto de su parte:
"If you have a direct line to Hermes, you might want to let him know that the in development rev20 already has a solution to the problem. From what giantpune has shown me, it seems Wanin is just blocking reads of the IOS modules from the games."
Esto a referente a juegos como POP.
Supongo que la razon del mensaje debe ser para que te informaras con wanin y facilitarte la tarea no se como lo veas.
Ya ¿que te crees que es lo que estoy haciendo yo?. Bloquear el dispositivo dev/mload. De hecho, podría hacer que solo desde mis módulos , de forma interna, se pudiera utilizar el resto de dispositivos (en lugar de eso, he preferido renombrar dev/usb2) o incluso podría modificar los nombres de los dispositivos desde uLoader, antes de cargarlos (rastreando el binario del módulo en busca de las cadenas específicas) de forma aleatoria o asistida por el usuario, y así ningún desarrollador de software podría fiarse de que haya un dispositivo.
Con respecto a otros loaders, la solución a dev/mload es tan sencilla como añadir una función desde el propio mload que haga que se retorne error en las siguientes aperturas. El "problema " es que añadir dicha función requeriría un nuevo cIOS y el dispositivo dev/usb2 (o como lo llames), seguiría siendo visible y necesitaría una solución pos-mload y además, aparte de que muchos se han quedado estancados en la V4 (y mira que hace tiempo de la V5) mload se ha diseñado, precisamente, para adoptar las soluciones sin necesidad de actualizar el cIOS
Por eso yo puedo resolver el problema sin tener que sacar una "v6", cargando el módulo fatffs con unas modificaciones, pero el problema para otros, es que como mload es abierto, les toca a ellos adoptar las soluciones por su cuenta (como puedes comprender, si otras personas siguen un camino diferente al mío, les tocará a ellos arreglar los problemas a su manera)
rockbass2560 escribió:Me sorprende lo rapido que cambio de parecer...
¿Quien ha cambiado de parecer?
Veamos, hagamos memoria:
- La versión 5.0B lleva en espera como un mes. Evidentemente, se trataba de arreglar otras cosas... que finalmente, no se han arreglado (puerto USB 1).
- El soporte WIP es algo que debería haber metido en la versión 5.0, pero al final entre pitos y flautas, no lo hice. Tardé 10 minutos en añadirlo y entra dentro del soporte mínimo que puedo darle al programa (y que de hecho, me comprometí a ello). Lo que no voy a atender a todas las ideas peregrinas que se le ocurra a la gente y menos por parte de gente que pedir pide, pero hacer, no hacen ni el huevo.
- Como dije el otro día, aparte de haber estado con gripe, etc, tambien dije que este tipo de protecciones como el PoP no son mi terreno, por lo que si la gente me pide un parche para un juego, no lo voy a hacer, pero si me dicen donde está el problema y se puede solucionar desde Starlet, ahí si puedo echar una mano, por que esa es mi especialidad.
Lee el texto en spoiler y dime donde se contradicen mis palabras o es que vosotros interpretáis mis palabras mal (te las explico con parentesis)
Por otro lado, estáis comentando de que al parecer un juego, tiene una protección contra los cIOS ...
Vale ¿y que queréis que yo haga, majetes?
El que sepa en que consiste el problema, puede desarrollar un parche o proporcionar los datos a partir de los cuales se pueda encontrar una vía inteligente para evitar el problema (como pasó con lo del BCA) (es decir, me estoy comprometiendo a adoptar una medida vía Starlet si alguien me cuenta en que consiste el problema del chequeo)
Pero si estáis esperando a que yo vaya adquiriendo los juegos y saltando las protecciones que aparezcan, la llevais clara, porque ese no es mi terreno, ni yo dispongo de todos los juegos, ni tengo ganas de andar con ello. (es decir: hay gente que se piensa que yo tengo todos los juegos o que me dedico a desprotegerlos: esa no es mi función y por supuesto, no los tengo todos)
Si aparece una solución en otra parte, pues entonces se mirará de añadirla a uLoader, (como por ejemplo, los parches WIP que es algo que debí meter antes y además, debía una versión 5.0B) pero ahora mismo, no hace falta que recuerde otra vez que yo me considero retirado y el desarrollo de uLoader terminado (esto significa lo que significa: que solo si me sale del nabo o me apetece, por decirlo finamente, haré cosas, pero que la gente no debe esperar a que yo las haga y mucho menos exigirlas) y aunque es posible que corrija algunos bugs o añada cosas nuevas que vayan apareciendo, (version 5.0B en mente) no va a ser iniciativa mía buscar soluciones y en todo caso, si se me reportan datos concretos de lo que trata de detectar la protección, podría mirar si es posible engañar vía cIOS que es en lo único en lo que podría aportar soluciones (si son posibles), que no implicaran tener que crear una nueva versión de cIOS (lo cual, si es mi especialidad: a cada uno, lo suyo) (traducido: si se cual es el problema porque otro lo ha contado y se puede arreglar utilizando el propio mload sin necesidad de sacar un nuevo cIOS, me estoy comprometiendo a intentar arreglarlo. ¿Sabes cuanto tardé en apañar una solución,una vez que supe que se detectaba dev/mload? )
Saludos
- Con respecto a la solución al problema, en fatffs solo tuve que añadir el siguiente procedimiento para evitar la detección de dev/mload (cosa que ya se había comentado en otra parte, que venía de ahí) en la rutina que controla la syscall de apertura de fichero:
En cristiano, se tarda 5 minutos en hacer eso y su funcionamiento consiste en que justo antes de lanzar el juego, abro un dispositivo llamado "no_mload" que devolverá error, pero que fija un flag que hará que si intentas abrir "dev/mload", en su lugar abrirá dev_kk que no existe.
Después de jugar un rato, mi cuñado (que hizo de betatester) me informó que se quedaba en pantalla en blanco en un punto y al igual que tu sabes que 1+1=2, yo se que el siguiente dispositivo en ser detectado, es "dev/usb2" por lo que añadí una comprobación para ello que colgaba la consola con el led encendido, con lo cual ya até todos los cabos: volví a pasarle lo mismo, soloque esta vez, en vez de colgar la conosla, retornaba dev_kk para ocultar el dispositivo y le dejé jugando.
¿Siguiente paso?. Decidir que hacer. Tomé la decisión de renombrar dev/usb2 en mis fuentes y me dediqué a intentar arreglar lo del puerto 1, hasta que lo mandé a hacer puñetas y colgué la 5.0B para que pudierais testearla los demás (además, ya tenia algo de fiebre, porque como ya dije, no es que estuviera recuperado del todo)
Ayer saqué la versión "buena" que bloquea la selección de puerto 1 y añade un par de tonterías para bloquear las partes de fatffs que esté fuera de uso en un supuesto (para evitar la detección de fat, sd: y usb: cuando no se usan, pero se deja vulnerable eso cargando desde .ciso por ejemplo)
Fíjate lo que habré cambiado de opinión que conozco una solución mejor y no la he hecho porque no me apetece tener que desensamblar los IOS 37, 38, 57 y 60 para encontrar los parches necesarios y he preferido adoptar la solución mas facil de todas (y la mas imperfecta, pero eso da igual, porque funciona).
Con respecto a lo que estuvimos comentando Spaceman Spiff y yo, eso no significa que vuelva, si no que los colegas tienen un trato preferente y si Spaceman Spiff tiene un problema que yo puedo ayudar a resolver, eso está hecho (que encima, hablamos de alguien al que le debemos mucho)
Así que tengo la versión 5.0D a la espera cuya única novedad, es que funciona con el chip raro de éste colega
Pero vamos, lo de cambiar de parecer no he cambiado: sigo con la misma idea sobre el tema.
Saludos
josete2k
Abonado
34.235 mensajes desde nov 2001 en EOL... ¿no me ves?
Hermes escribió:Así que tengo la versión 5.0D a la espera cuya única novedad, es que funciona con el chip raro de éste colega
Pero vamos, lo de cambiar de parecer no he cambiado: sigo con la misma idea sobre el tema.
Saludos
Mira, igual me soluciona alguna de mis instalaciones también..... aunque últimamente uso WBFS_WIN he tenido que recurrir a instalar desde la consola y las instalaciones se colgaban en raras ocasiones.
Como siempre digo, maldito Hermes, siempre innnovando. (leer con voz de Homer J. Simpson)
Hermes escribió:Así que tengo la versión 5.0D a la espera cuya única novedad, es que funciona con el chip raro de éste colega
Pero vamos, lo de cambiar de parecer no he cambiado: sigo con la misma idea sobre el tema.
Saludos
Mira, igual me soluciona alguna de mis instalaciones también..... aunque últimamente uso WBFS_WIN he tenido que recurrir a instalar desde la consola y las instalaciones se colgaban en raras ocasiones.
Como siempre digo, maldito Hermes, siempre innnovando. (leer con voz de Homer J. Simpson)
Bueno, una cosa que me di cuenta ayer de la rutina antigua, es que se libera un buffer de memoria, dos veces si se dá cierta condición y eso puede dar lugar a una corrupción chunga .
Son de esos pequeño detalles que te das cuenta cuando te pones y lo haces tu (esa rutina viene de antiguo y no es mía, aunque una vez la tocamos por el mismo problema que estaba comentando Spaceman y luego o tuve que hacer de otra forma, por que otros reportaron problemas)
La versión 5.0D la dejo en reserva por el momento (lo mismo no la llamo así al final), por si tuviera que mirar algo más.
Por cierto, la 5.0C tiene una novedad y es que refresqué la parte de libogc que se encarga de los Wiimotes, pero no he mirado si hay algún soporte nuevo o alguna diferencia.
Hermes muchas gracias por la aplicación pero tengo una pregunta. Estoy instalando los wiiware y los virtual console y se me instalan en la SD abria alguna forma de que se instalaran en Hard Disk en formato fat32 como los ciso. Si se puede si me pueden explicar como se hace se los agradecere.
kobe_bryant escribió:Hola a todos. Al intentar actualizar uloader por red me da un error de update.txt. ¿Cómo puedo solucionar el error y actualizarlo? Si no lo puedo solucionar, ¿en el enlace http://mods.elotrolado.net/~hermes/wii/ ... loader.dol está la última versión (5.0C o 5.0D)? Gracias por la ayuda y un saludo a todos
Si es la última versión 5.0c pero solo el .dol, ¿por qué no lo descargas desde la pagina principal donde esta todo empaquetado con las utilidades y cambios en .txt donde Heremes ya lo colgó , aunque se le paso editar el nombre del hilo a v5.0c.
No es queja si me da gusto que hayas implementado mejoras, y pues que golpe de suerte que alguien mas haya encontrado el problema y asi facilitartelo, solo me confundi con tu comentario de que estas retirado y aun asi das un soporte "minimo" (que de minimo no tiene nada). Suerte con eso, aun asi tu paradigma de desarrollo es muy tuyo y voy a leer lo que has dejado de comentario (aunque sea muy propio y exclusivo de la programacion wii...)
Y no te preocupes entiendo bien el codigo del lenguaje, solo no se que quiere decir esas variables pero bueno ya lo explicaste, saludos y si yo se que ULoader es algo que se mejora entre cuates (o scene) jaja. De todas maneras que bueno que todos salen ganando por esto, Saludos y enserio que te mejores
Por cierto, muchas veces los juegos de N64 me dan pantallazo negro al iniciarlos. Tanto los juegos en PAL como en NTSC-USA (tengo Wii PAL). He probado de todo, pero a veces me pasa, y para que a partir de un pantallazo negro se pueda ejecutar un juego de N64 exitosamente parece que tengo que desenchufar/enchufar la consola, si no, no ahi manera
Tengo un problema con un par de juegos y sus caratulas... especificamente son Super Mario Galaxy 2 y Sonic Unleashed...
Coloque la caratula a uno y automaticamete se colocó en el otro la misma... si a un juego lo pongo en "español" el otro tambien se pone asi... Si elimino la caratula de uno, se elimina en la otra...!
Ya intente poner las caratulas desde la SD, Internet y el WBFS Gui...
Que podria estar sucediendo? No los reconoce el uLoader 5.0c como juegos independientes?
Lo curioso es que en otro Wii con uLoader 5.0c SI se ponen con las caratulas correspondientes...
si dices que te pasa lo mismo usando otros programas, podría ser un problema de corrupción de la partición WBFS. borra los juegos y vuelve a meterlos a ver qué pasa.
Hermes, estuve revisando un poco el código que da soporte a los parches WIP. Me parece que esta faltando un enganche, fijate que las rutinas wipreset y wipregisteroffset no son llamadas nunca en el código (o no supe encontrarlas) por lo tanto patchu8 esta utilizando valores no inicializados.
Aprovechando que todos los offset son relativos al archivo (y no a posiciones de memoria cuando el dol este cargado), agregué los llamados para parchar el dol justo antes de que las diferentes secciones sean cargadas en memoria.
No tengo ningún archivo WIP para probar en este momento, pero voy a ver si puedo generar uno y probar si esto esta funcionando correctamente, así puedo darte un parche definitivo.
Spaceman Spiff escribió:Hermes, estuve revisando un poco el código que da soporte a los parches WIP. Me parece que esta faltando un enganche, fijate que las rutinas wipreset y wipregisteroffset no son llamadas nunca en el código (o no supe encontrarlas) por lo tanto patchu8 esta utilizando valores no inicializados.
Aprovechando que todos los offset son relativos al archivo (y no a posiciones de memoria cuando el dol este cargado), agregué los llamados para parchar el dol justo antes de que las diferentes secciones sean cargadas en memoria.
No tengo ningún archivo WIP para probar en este momento, pero voy a ver si puedo generar uno y probar si esto esta funcionando correctamente, así puedo darte un parche definitivo.
-u32 do_wip_code(void); - void patch_dol(void *Address, int Section_Size, int mode) { DCFlushRange(Address, Section_Size); @@ -570,8 +568,6 @@ void patch_dol(void *Address, int Section_Size, int mode)
vidolpatcher(Address, Section_Size);
- do_wip_code(); - /*HOOKS STUFF - FISHEARS*/
DCFlushRange(Address, Section_Size);
Saludos
Hola.
Pues no lo se, tío: yo he sacado esa parte del usbloader gx y lo único que cambia, es que en vez de llamar a esa rutina para todas las secciones, abriendo X veces el fichero y luego parcheando X veces, he partido la rutina en dos y solo se abre el fichero una vez y eso si, se hace el parche (teóricamente) X veces por cada sección.
Seguramente tengas razón (mañana le hecho un ojo en detalle), pero ya te digo que en el usbloader gx ninguna de esas dos funciones es llamada (o al menos yo no las veo al buscar la cadena)
Hermes escribió:Pues no lo se, tío: yo he sacado esa parte del usbloader gx y lo único que cambia, es que en vez de llamar a esa rutina para todas las secciones, abriendo X veces el fichero y luego parcheando X veces, he partido la rutina en dos y solo se abre el fichero una vez y eso si, se hace el parche (teóricamente) X veces por cada sección.
Seguramente tengas razón (mañana le hecho un ojo en detalle), pero ya te digo que en el usbloader gx ninguna de esas dos funciones es llamada (o al menos yo no las veo al buscar la cadena)
Saludos
Mire el código, ya que habías comentado que estaba basado en usbloader gx, que es el que se esta quejando la gente en gbatemp que no le anda el soporte de WIP. En los que dicen que anda bien es en NeoGamma y en el Cfg Loader.
Igualmente, Hermes, de ahí a que lo que yo haya hecho este del todo correcto es otro tema... Yo ya tengo un historial con uLoader
Hermes escribió:Pues no lo se, tío: yo he sacado esa parte del usbloader gx y lo único que cambia, es que en vez de llamar a esa rutina para todas las secciones, abriendo X veces el fichero y luego parcheando X veces, he partido la rutina en dos y solo se abre el fichero una vez y eso si, se hace el parche (teóricamente) X veces por cada sección.
Seguramente tengas razón (mañana le hecho un ojo en detalle), pero ya te digo que en el usbloader gx ninguna de esas dos funciones es llamada (o al menos yo no las veo al buscar la cadena)
Saludos
Mire el código, ya que habías comentado que estaba basado en usbloader gx, que es el que se esta quejando la gente en gbatemp que no le anda el soporte de WIP. En los que dicen que anda bien es en NeoGamma y en el Cfg Loader.
Igualmente, Hermes, de ahí a que lo que yo haya hecho este del todo correcto es otro tema... Yo ya tengo un historial con uLoader
Cierto, la gente dice que con el GX no funcionan los WIP....
Hermes
MegaAdicto!!!
11.053 mensajes desde ene 2003
Editado 1 vez. Última: 24/05/2010 - 21:58:15 por Hermes.
Spaceman Spiff escribió: Mire el código, ya que habías comentado que estaba basado en usbloader gx, que es el que se esta quejando la gente en gbatemp que no le anda el soporte de WIP. En los que dicen que anda bien es en NeoGamma y en el Cfg Loader.
Igualmente, Hermes, de ahí a que lo que yo haya hecho este del todo correcto es otro tema... Yo ya tengo un historial con uLoader
Bueno, le he echado un ojo rápido y ya está corregido .
Veamos la función Wireset inicializa el offset de una tabla que debe actualizarse con offset y longitud en la rutina de parches, según he entendido.
Para que la cosa no de problemas, he sacado el parcheo do_wip() fuera de ahí y lo he dejado para el final, justo cuando se cargan los dol.
Lo que has pinchado en load_dol no es correcto, puesto que el main.dol es cargado de otra forma y escaparía a tu control, aparte de que tal como lo haces tu, actualizarias el offset de la tabla al dol y no a su posición de destino (wipregisteroffset, registra las secciones del dol, según entiendo)
Como do_wip se llamaría fuera, de la zona de parches, he añadido una rutina que flushea los datos.
No puedo estar seguro de que funcione 100% pero yo apostaría que si. De todas formas, ya les vale a los de usbloader gx, por inducirme a equivocarme
Saludos
PD: ¿os dais cuenta porque a veces me cabrean ciertas cosas de ciertos desarrolladores y prefiero hacer las cosas yo mismo?. Para una puta cosa que copio y resulta que está mal el "original"
josete2k
Abonado
34.235 mensajes desde nov 2001 en EOL... ¿no me ves?
josete2k escribió:Es que también te vas a mirar el mejor loader de todos.... a code dump no le gana nadie.
Joder, he pillado uno que conozco la dirección svn sin saber quien inventó el wip ese de los cojones... pero se supone que si copias algo, lo copias bien
En mi caso, aparte de ser inducido a error, enseguida me puse a mirar la solución sin parche y por cierto, el parche que vi primero, era para versión NTSC y mi cuñado tiene PAL... si ni siquiera tengo el juego para saber si el WIP funciona
josete2k
Abonado
34.235 mensajes desde nov 2001 en EOL... ¿no me ves?
El original es de Wiipower, el autor de Neogamma. Los parches WIP surgieron a raíz del New Super Mario, puesto que era la forma más rápida de añadir parches al vuelo (aunque el uLoader ya emulaba la BCA)
void wipparsebuffer(u8 *buffer, u32 length) // The buffer needs a 0 at the end to properly terminate the string functions { u32 pos = 0; u32 offset; char buf[10];
)![[+risas]](/images/smilies/nuevos/risa_ani3.gif "más risas")
![[tadoramo]](/images/smilies/adora.gif "Adorando")
![[oki]](/images/smilies/net_thumbsup.gif "Ok!")
![[babas]](/images/smilies/babas.gif "Babeando")
![[Alaa!]](/images/smilies/nuevos/sorprendido_ani2.gif "Ala!")
Deberia aprender aunque sea un poco sobre eso.![[bye]](/images/smilies/nuevos2/adio.gif "adios")
pero por qué no lo checas en la búsqueda del hilo o espera a ver si alguien te puede ayudar, pero no te desesperes ![[risita]](/images/smilies/nuevos/sonrisa_ani1.gif "risita")
.![[burla3]](/images/smilies/nuevos/burla_ani2.gif "burla3")
![[decaio]](/images/smilies/nuevos2/decaido.gif "decaido")
![[snif]](/images/smilies/nuevos/triste_ani1.gif "llorando")
![[carcajad]](/images/smilies/nuevos/risa_ani2.gif "carcajada")