[Hilo Oficial] uLoader v5.1E (Emulacion saves, DLC, Wiiware)

plasma escribió:Creo entender, con mis humildes conocimientos sobre ordenadores personales, que si controlas las interrupciones del dispositivo usb, puedes "interrumpir" la comunicacion con el dispositivo hasta que te haga falta acceder a el y por lo tanto por ejemplo no estar haciendo trabajar todo el rato al disco duro... que se pone hirviendo con el uloader .

No, hombre, no . Si de hecho, le tuve que meter un watchdog al programa para evitar que el disco duro se eche a dormir por inactividad , pero lo de hacer trabajar "todo el rato", es cosa del juego, no mía (el watchdog solo interviene si han pasado mas de 16 segundos desde la última vez que se produjo un acceso)

Las interrupciones son un mecanismo que tienen los periféricos de solicitar al procesador que deje de hacer lo que está haciendo y que le haga caso, por así decir.

¿Y en que nos afecta poder hacer uso de ellas?.

Pues básicamente, hasta ahora , cuando queríamos transferir datos desde el HDD a memoria, teníamos que hacer una lectura mas o menos constante de los flags que intervienen para conocer cuando había acabado la transferencia, ya fuera con éxito o por algún tipo de error y habíamos usado dos métodos:

- Método Kwiirk: consiste en que el bucle del programa se está ejecutando constantemente y solo puede ser interrumpido por un hilo de mayor prioridad. Esto significa, que si una lectura requiere 100ms, durante esos 100ms no podrán ser atendidos los hilos de menor prioridad...

- Método Hermes: consiste en un bucle de programa al que se le introduce una syscall de temporización que lo que hace es "dormir" ese hilo durante una serie de microsegundos, para evitar que los hilos de menor prioridad no puedan ejecutarse. El inconveniente es que puede haber un desfase entre el momento en que se terminó la transferencia y el momento que pasamos a tratarla (por ejemplo, algo que tarde 40us y nosotros dormimos 125us), pero también existe un inconveniente secundario: aunque durmamos el hilo, estamos constantemente interrumpiendo a los hilos cuando dormimos/despertamos. Y estamos hablando de un procesador que trabaja a 243Mhz...

- Método por interrupciones: Aquí es el propio host EHCI el que te avisa de los cambios que se producen. Eso significa que podemos dormir el hilo y hacer que el vector (mas bien el hilo asociado) lo despierte al completar la transferencia. De esta forma, conseguimos no putear tanto a los hilos que tienen una prioridad inferior a la nuestra.

El inconveniente es que esa interrupción tiene un límite de tiempo para ser respondida (se puede programar en pasos desde 125us, que sería lo conveniente desde el punto de vista de velocidad de transferencia) y que se responde desde un hilo de programa en modo usuario, que me está creando una serie de problemas de conmutación (los tiempos de reacción son tan cortos, que hace que se puedan producir dos interrupciones y que en el propio vector cancelemos una de ellas sin querer, debido a la puñetera syscall que se encarga de volver a habilitar la mascara de interrupción...)

Seguramente, podría evitarlo subiendo el tiempo de respuesta, pero eso afectaría a la velocidad de transferencia... pero por suerte, el nuevo mload es mucho más poderoso que su predecesor

Una de las virtudes es que he habilitado el vector SWI (interrupciones por software) y ahora tenemos una especie de syscalls que nos permiten acceder desde modo supervisor a registros y zonas de memoria restringidas. Además, cuenta con la ventaja de que puedo llamar a las syscalls de verdad desde dentro.

El nuevo mload proporciona una serie de funciones desde "svc 0xcc" y gracias a eso puedo por ejemplo, habilitar la mascara de interrupciones directamente e incluso puedo ejecutar código a salvo de otras interrupciones (al entrar en modo supervisor mediante la función de ensamblador "svc 0xcc" automáticamente están deshabilitadas todas las interrupciones... lo que me va a permitir salvar efectos no deseados por parte de otros hilos).

Y en eso estoy trabajando ahora mismo, en dotar de servicios a esta nueva syscall que entre otras cosas, permite a otros módulos registrar su propio servicio y así por ejemplo, svc 0xab lo usa el sistema, solo que en nuestras consolas de casa, eso llevaría a un simple retorno. Pues ahora se puede utilizar este sistema para que otros posibles módulos compartan información registrando su propia función de servicios (de igual manera que puedo acceder a ciertos servicios que me presta mload)

Así que como veis, ando ocupado reforzando este tipo de detalles para luego centrarme en resolver los problemas que tiene el driver EHCI, con estas nuevas herramientas.

Lo que está claro, es que si mload antes era la caña, ahora es DIOS con éstas nuevas posibilidades

Bueno ahora entendemos un poco mas lo que estas haciendo, aunque no del todo pero lo que esta claro es que te lo estas currando. A ver que tal queda eso.

Existe alguna forma de volver a dar reset a la cuenta de control Parental ???

Por algun motivo no me funciona la que utilice!!!

Alguna sugerencia ...

Gracias

A ver si lo he entendido...

Lo de las interrupciones es un "puerto de escucha" (direccion de memoria) donde el dispositivo le dice al procesador... "eh! que tengo algo que decirte", como por ejemplo "he terminado la operacion que me mandaste previamente" o "he pasado a inactividad total, que lo sepas". Ahora el programa solo tendria que estar pendiente de cuando se activa el "puerto de escucha" y mirar que le pasa al disposivo, y actuar en consecuencia, y no tener que crear un bucle infinito por programa, con otros bucles dentro que se ejecutan uno u otro segun la situacion dada, y que ademas todo iba por tiempo calculado a ojo de buen cubero, que no es lo mismo que responder a la interrupcion... el equivalente seria un Timer de VB que vigila la interrupcion, no?

Cada milisegundo...
Select Case interrupcion
case 0
seguirhaciendoloqueestuvierashaciendo
case 1
vetealafuncion actuaenconsecuencia
End Case

Lo otro lo interpreto como que ahora se puede crear un software que te permita "controlar" totalmente el hardware de la Wii, o casi.

Igual no he entendido ni papa...

EDITO :

Ahora que lo pienso con el "Timer" estariamos en las mismas... quizas sea cosa de que cuando se vaya a ejecutar alguna funcion, o todas, lleve la funcion un parametro "interrupcion" que haga que se comporte esa funcion de una u otra forma... igual es una empanada mental lo que tengo

plasma escribió:A ver si lo he entendido...

Lo de las interrupciones es un "puerto de escucha" (direccion de memoria) donde el dispositivo le dice al procesador... "eh! que tengo algo que decirte", como por ejemplo "he terminado la operacion que me mandaste previamente" o "he pasado a inactividad total, que lo sepas". Ahora el programa solo tendria que estar pendiente de cuando se activa el "puerto de escucha" y mirar que le pasa al disposivo, y actuar en consecuencia, y no tener que crear un bucle infinito por programa, con otros bucles dentro que se ejecutan uno u otro segun la situacion dada, y que ademas todo iba por tiempo calculado a ojo de buen cubero, que no es lo mismo que responder a la interrupcion... el equivalente seria un Timer de VB que vigila la interrupcion, no?

Cada milisegundo...
Select Case interrupcion
case 0
seguirhaciendoloqueestuvierashaciendo
case 1
vetealafuncion actuaenconsecuencia
End Case

Lo otro lo interpreto como que ahora se puede crear un software que te permita "controlar" totalmente el hardware de la Wii, o casi.

Igual no he entendido ni papa...

EDITO :

Ahora que lo pienso con el "Timer" estariamos en las mismas... quizas sea cosa de que cuando se vaya a ejecutar alguna funcion, o todas, lleve la funcion un parametro "interrupcion" que haga que se comporte esa funcion de una u otra forma... igual es una empanada mental lo que tengo

No es exactamente así: El procesador tiene una señal (por una patita del chip ) donde los periféricos pueden solicitar una interrupción. Y en ese momento, salvo que las interrupciones estén deshabilitadas (que se puede) pasa a tratarlas.

Evidentemente, esa señal se comparte con varios periféricos, por lo que hay un chip (en este caso Hollywood) que se encarga de dar acceso a todas estas señales siguiendo un orden de prioridades (y el registro que habilita la interrupción EHCI no es accesible desde modo usuario)

Cuando se produce la interrupción, el procesador cambia al modo interrupción, testea los flags de los registros de Hollywood y en función de ésto, vuelve a modo usuario mandando una señal para despertar un hilo que previamente, hemos registrado para tratar dicha interrupción.

El hardware USB, tiene un registro reservado (y que yo desconocía hasta hace poco) que le permite habilitar las interrupciones para EHCI (USB 2.0) , OHCI0 y OHCI1 (ambas USB 1.1) y además, puedes fijar la cadencia en la que interrumpirá al procesador en caso de ser necesario.

Esto es así por que puede que el procesador no de abasto... date cuenta que hablamos de tiempos como 125 microsegundos que son realmente, muy cortos. Pero no es el mismo caso que con un timer de los que hablas.

Un timer cíclico no está sincronizado con la señal de interrupción y constantemente está jodiendo al software, mientras que este "timer" lo que indica que si interrumpe al procesador, no debe molestarle al menos hasta que haya pasado un tiempo prudencial.

La diferencia es que por ejemplo, en el Guitar Hero World Tour, aparece una barra de carga al principio: con la versión 2.8D, que usa un timer de 125 us, la barra llega como 3/4 del total, mientras que con interrupciones a 125us, llega a solo a la mitad. Eso es porque via interrupciones, el tiempo entre que se produce una interrupción y la acción, es cortísimo, mientras que con el timer, puede que el flag se levante 1us después y requerir otros 125 us de espera...

En el Guitar Hero World Tour noto un rendimiento parecido usando 500us en interrupción.

Por otro lado, el resto de cosas lo que me permiten, no es solo acceder al hardware libremente, si no modificar el sistema!.

De hecho, el parche que me proporciona SWI (Interrupciones de software) lo realizo en caliente, al cargar mload y eso me permite cosas como ésta:

OH0: deleting USB device (hub 0, port 0) failed. Device may have been removed.
$IOSVersion: SDI: 06/08/07 18:17:16 64M $
$IOSVersion: SO: 06/28/07 02:37:15 64M Release/apricot-win/HEAD $
$IOSVersion: KD: 08/30/07 04:58:02 64M Release/apricot-win/SDK_FW_30_4_13_branch $
$IOSVersion: WD: 12/05/07 19:50:52 64M Release/apricot-win/SDK_FW_36_4_18_branch $
$IOSVersion: NCD: 06/28/07 02:37:17 64M Release/apricot-win/HEAD $
$IOSVersion: WL: 06/28/07 02:37:25 64M Ver.4.30.44.0/Release $
$IOSVersion: STM: 06/28/07 02:37:18 64M Release/apricot-win/HEAD $
$IOSVersion: OH1: 06/08/07 18:17:21 64M $
Set IPC access rights: salt=ffff0000, n=0
$IOSVersion: ETH: 08/09/07 18:09:02 64M Release/apricot-win/SDK_FW_30_4_13_branch $
$IOSVersion: SSL: 06/21/07 14:52:11 64M Release/srd/HEAD $
$IOSVersion: KBD: 08/27/07 11:20:18 64M $
OH1:configured USB device at port 0, vid: 0x057e pid: 0x0305

Eso que ves es el log que se produce al cargar los módulos OHCI0 y OHCI1 (emtre otros) que van detrás del módulo mload gracias a la captura del vector SWI y a las facilidad de registrar una función (en este caso, es la función svc 0xab, indice 4, que sirve para volcar un texto como log)

Desde el modo usuario los permisos están muy restringidos y no podemos hacer casi nada: ahora disponemos de la posibilidad de ejecutar y modificar cosas desde el Modo Supervisor e incluso una función que nos permite hacerlo desde Modo Sistema.

Vamos, por decirlo de forma clara: podemos acceder a todo el hardware y el software desde el Starlet, expandir sus posibilidades sin necesidad de tener que volver a instalar el cIOS, por lo que se puede considerar el cIOS definitivo

Estamos con ansias para que saques este CIOS,,,,en realidad tengo que decir que es le mejor trabajo echo con carga de usb loaders....Tengo que decir que eh abandonado completamente el gx..

Salu2

Hermes y esos agregados que le haces al cios podrian reutilizarse de algun modo para agregarlo al mios??? asi podrian cargarse copias de seguridad de gamecube por usb... si es que hay alguien que porte tu modulo al mios.

seria viable???

saludos.

emulation escribió:Hermes y esos agregados que le haces al cios podrian reutilizarse de algun modo para agregarlo al mios??? asi podrian cargarse copias de seguridad de gamecube por usb... si es que hay alguien que porte tu modulo al mios.

seria viable???

saludos.

Hombre, solo sabiendo que la GC accede directamente al hardware de disco, ya se sabe que es imposible, independientemente de otros problemas que pueda haber.

Aquí podemos emular el disco porque hay un procesador que hace de interfaz (hay una capa de software por medio, vamos) y eso permite que modificando el driver en el Starlet, podamos conectar con todos los juegos, de forma transparente a ellos.

Pero vamos, a mi el tema de GC, ni fú, ni fa

no digo que lo hagas tu... pero supongo que alguien podria si quisiera xDDDD.
en fin. xD

Aunque se dice que con el suficiente esfuerzo todo es tecnicamente posible, hermes te esta dando una explicacion tecnica de por que no se podria (o seria muy, muy dificil).

emulation escribió:no digo que lo hagas tu... pero supongo que alguien podria si quisiera xDDDD.
en fin. xD

es imposible debido a que para jugar GC la consola entra en modo GC y literalmente se convierte en una GC (solo le faltaria transformarse fisicamente como los transformers), entonces recuerda la GC no poseia puertos usb, por eso como comenta hermes al jugar GC busca cargar directamente desde el hardware de disco, pues por ningun otro lado puede pues un GC no posee nada mas, solo las ranuras de memoria y para usarlas de esa forma necesitas una memoria de esas co entrada para sd (creo que son las geko) y un homebrew para gc en disco boteable..... es la unica forma (un amigo asi lo usa)...

asi que dejemos el tema del cubo en el baul de los recuerdos

como hay gente negada por dios...
ya se sabe que no tiene esa opcion, pero si se tiene un driver usb que funciona,modificando mios para que lo reconozca en teoria deberia poderse, claro no seria sencillo, pero teoricamente podria ser no?
que para algo ees que han sacado versiones de mios modificadas.

Yo no estoy en tema de programacion Wii/GC, pero si alguien como Hermes, que parece que un poco del tema sabe, te dice "que sabiendo que la GC accede directamente al hardware de disco, ya se sabe que es imposible, independientemente de otros problemas que pueda haber", yo tomaria nota.

Otra opcion es que demuestres lo contrario haciendolo vos.

Dios mio sigue la terquedad... solo menciono que se podria hacer si se modificara mios para tener el acceso que no tiene actualmente... si no sabes de programacion porque aseguras que es imposible... que es dificil lo es pero no imposible. Lo haria con gusto si supiera programar para wii/gc cosa que aun no conozco xD.

Conozco otros lenguajes con los que me gano la vida xD. vease java/c#/php/algo de abap... etc etc...

emulation escribió:Dios mio sigue la terquedad... solo menciono que se podria hacer si se modificara mios para tener el acceso que no tiene actualmente... si no sabes de programacion porque aseguras que es imposible... que es dificil lo es pero no imposible. Lo haria con gusto si supiera programar para wii/gc cosa que aun no conozco xD.

Conozco otros lenguajes con los que me gano la vida xD. vease java/c#/php/algo de abap... etc etc...

La Wii en modo GC es una GC, y salvo que toquetees el hardware no va a tener acceso a las cosas que no tenía la GC.

emulation escribió:Dios mio sigue la terquedad... solo menciono que se podria hacer si se modificara mios para tener el acceso que no tiene actualmente... si no sabes de programacion porque aseguras que es imposible... que es dificil lo es pero no imposible. Lo haria con gusto si supiera programar para wii/gc cosa que aun no conozco xD.

Conozco otros lenguajes con los que me gano la vida xD. vease java/c#/php/algo de abap... etc etc...

No es terquedad hombre, es un argumento valido con las suficientes bases. En teoría nada es imposible, siempre la primera limitante a vencer para lograr algo que parece imposible es quitarse la idea de que lo es.
Sin embargo tu insistencia en que "es posible" solo parte de un "si alguien quisiera se podría", cosa distinta sería que dijeras "lo voy a intentar sin importar lo difícil que sea". Si Hermes que con creces nos ha mostrado su talento argumenta que no es un trabajo viable, para alguien que no tiene los conocimientos como muchos de nosotros, es imposible, más aún si se espera cómodamente a que alguien más lo haga.

emulation escribió:Dios mio sigue la terquedad... solo menciono que se podria hacer si se modificara mios para tener el acceso que no tiene actualmente... si no sabes de programacion porque aseguras que es imposible... que es dificil lo es pero no imposible. Lo haria con gusto si supiera programar para wii/gc cosa que aun no conozco xD.

Conozco otros lenguajes con los que me gano la vida xD. vease java/c#/php/algo de abap... etc etc...

es verdad sigue la terquedad, pero de tu lado ... yo no dije que no sepa de programacion, yo dije que no programo wii/gc, que es muy distinto, y la explicacion de hermes es mucho mas logica que tu "se puede por que yo digo". Hacelo y demostralo, o STFU.

Gracias por la detallada explicacion Hermes. Ha sido muy instructiva.

Supongo que con el acceso al Modo Sistema los programadores de homebrew podran mejorar mucho sus programas .

He notado que con la version 2.8d la inicializaciOn del uloader me desconecta el control primario, un dIa de estos tuve que desconectar el wii por un buen rato y luego volver a conectarlo para que porfin me reconociera el control 1 cuando arranco el uloader, lo curioso es que la consola no falla, y el programa funciona, pero con el control desconectado no es mucho lo que se pueda hacer

Saludos

Alguien me puede indicar cual es la diferencia en el NeoGamma vs ell Uloader, ya que estuve viendo en softmods que el NeoGamma tiene un stick en el foro , pero no se a que se debe si pienso que el Uloader es mucho mejor, bueno en realidad no si y me gustaria que ustedes me dijeran cual es la diferencia.


Slud2

Yo tenia instalado antes el neogamma, pero que tenga yo entendido, es para cargar backups desde la unidad de DVD, no se si abrán sacado una versiOn para carga desde el USB, como el uloader (que efectivamente eso hace)....

Ahora, si decides instalar un backup launcher como neogamma, ten en cuenta los siguiente:
- Tienes que ponerte a quemar los backups en discos de calidad (el lector lo vale)
- Nunca vas a obtener la velocidad real del lector (6x) dado que estos trabajan en menos velocidad (3x)

Un usb loader como uloader te permite (haciendo la inversiOn en un hd claro esta) cargar juegos mucho mAs rApido que el propio disco original, en comparaciOn no se cuantas x mas puede ser, pero definitivamente es bastante mAs rApido, y es mucho mAs ordenado y "limpio".

Saludos

emulation escribió:como hay gente negada por dios...
ya se sabe que no tiene esa opcion, pero si se tiene un driver usb que funciona,modificando mios para que lo reconozca en teoria deberia poderse, claro no seria sencillo, pero teoricamente podria ser no?
que para algo ees que han sacado versiones de mios modificadas.

Intenta meter una cinta VHS en tu reproductor de DVD, según tu se podria, es el mismo caso, no se puede simular que enchufas un USB a una consola que no lo tiene, aunque en este caso la wii los tenga, cuando entra en modo GC su hardware es de GC, y esta no tenia puertos USB

Para los interesados en GC que le echen un ojo al sdboot, necesitan un sdgecko y no se si habra alguno compatible con sdhc y no es que tenga una compatibilidad total con los juegos de GC

la comparación de vhs esta fuera de lugar... porque no se puede por limitaciones físicas...
en cambio lo de mios ( GC ) podría hacerse modificando software, pero ya se ha dicho que no es nada sencillo.

347 posts y no has aprendido nada ... demostra que sabes mas que hermes, y hacelo vos, a mi me vendria barbaro poder cargar mis juegos de GC en mi disco.

kwanbis... es que comparas una cinta de VHS formato totalmente diferente... en un reproductor de dvd obvio por limitaciones físicas y tecnológicas no se puede...

Tendría que aprender C, xD he buscado el código fuente del mios patcher y del cmios rev 3. Solo encontré el de wiigator ( mios patcher ), no entiendo nada de las lineas de código porque no se como funciona la wii y su modo gamecube.

Joder que siempre me rayaba los punteros de memoria xD y me ha parecido ver mas de 1 xDDDD

si alguien que sepa me explica podría ir viéndolo. ya que todos dicen es imposible, no se puede.... y luego piden que lo haga uno...!!!! pffff xDDDD

emulation escribió:la comparación de vhs esta fuera de lugar... porque no se puede por limitaciones físicas...
en cambio lo de mios ( GC ) podría hacerse modificando software, pero ya se ha dicho que no es nada sencillo.

No es por nada, pero ésta discusión está fuera de lugar y las especulaciones no llevan a ninguna parte. Lo cierto es que no se puede y aunque hubiera una posibilidad remota, ni la va a buscar nadie, ni merece la pena discutir sobre el tema.

Como a mi lo de GC me la suda, no he mirado ni los MIOS, ni los TUYOS (xD) pero para empezar, lo mas probable es que como pasa con PS2, haya algún registro que cambia la configuración de hardware y "desaparecen" ciertas cosas, se capa la velocidad del procesador y se limita la memoria (este tipo de cosas ya las han comentado gente que lleva mas tiempo que yo con la Wii y abrieron el camino, además de que conocen la GC al dedillo), que el acceso directo al hardware de disco complica mucho las cosas y que en caso de poder poner en marcha el Starlet, tendrías que crear el kernel al completo para darle soporte (vamos, canela fina)

Eso es tarea imposible desde el punto de vista práctico, que es el que cuenta. Y en estas discusiones, si el 99.99% de posibilidades apuntan a que no se puede, defender el 0.01% sin tener un conocimiento que pueda respaldar eso de forma bastante clara, es de necios y no conduce a nada (eso de que todos están equivocados menos yo, solo funciona si tienes pruebas de que lo que dices es cierto)

Y si aun así tienes ganas de hablar del tema... pues abre otro hilo, que este ya está muy sobrecargado y tiene otro propósito

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

En otro orden de cosas, estoy trabajando ya directamente desde el vector de interrupción de la Wii, para tener un mejor control y estoy tratando de resolver un problema que conduce a que en casos puntuales, la unidad se queda pillada y solo se desbloquea desenchufando y enchufando de nuevo, y aún no se en que punto y bajo que condiciones ocurre esto y si tiene alguna solución (si es lo que yo creo, solo se solucionaría haciendo un reset al Host EHCI, pero eso llevaría a la muerte del driver bluetooth y no puedo salvarlo.

Los errores de lectura son persistentes y que yo sepa, son ajenos al driver y de hecho, la mayoría de los errores suelen darse fuera de actividad: debe ser que el hardware es bastante chusquero o simplemente, que la incesante actividad acaba provocando errores de forma natural y al no poder cachear en memoria esa lectura, se dejan ver mas de lo necesario.

Wenas. He leido el tema de la carga de backups de GC desde el disco duro, y bueno yo pensaba como el compañero emulation,

Si tenemos un hardware preparado para cargar isos desde el disco duro, y un sofware que es el MIOS que no sabe como utilizar ese hardware, ¿no seria posible enseñarle como hacerlo? desde el desconocimiento de como programarlo parece factible, aunque se ve que Hermes no da credito al asunto.

Saludos.

No quiero intervenir en el offtopic pero ya se consiguió hace tiempo arrancar juegos de GC en modo Wii "toqueteando" el MIOS. Concretamente sólo se descapó la frecuencia del procesador, pues era una simple sustitución binaria. Ya no me acuerdo dónde y quién lo hice, creo k ¿emuk[y algo más]?, joder no consigo acordarme de su nombre, y eso que hizo muchas cosas, como el cargador de GC por SD.

Hermes escribió:
----------------------------------------------

En otro orden de cosas, estoy trabajando ya directamente desde el vector de interrupción de la Wii, para tener un mejor control y estoy tratando de resolver un problema que conduce a que en casos puntuales, la unidad se queda pillada y solo se desbloquea desenchufando y enchufando de nuevo, y aún no se en que punto y bajo que condiciones ocurre esto y si tiene alguna solución (si es lo que yo creo, solo se solucionaría haciendo un reset al Host EHCI, pero eso llevaría a la muerte del driver bluetooth y no puedo salvarlo.

Los errores de lectura son persistentes y que yo sepa, son ajenos al driver y de hecho, la mayoría de los errores suelen darse fuera de actividad: debe ser que el hardware es bastante chusquero o simplemente, que la incesante actividad acaba provocando errores de forma natural y al no poder cachear en memoria esa lectura, se dejan ver mas de lo necesario.

espero puedas solucionarrlo, pues en mi caso asi como aveces lo detecta a la primera y no me da ningun problema ni cambiando de juego, aveces desde que lo conecto y enro al uloader me pide unplug/plug y despues de eso puede que no se interrumpa o que cada cambio de juego me pida el unplug/plug, entonces si no me equivoco con lo que estas trabajando es en hacer el Unplug/plug desde software y eso ya seria lo unico que me faltaria para dejar al 100% mi disco duro...

ESPERANDO LISTA LA NUEVA VERSION.....

emulation escribió:Dios mio sigue la terquedad... solo menciono que se podria hacer si se modificara mios para tener el acceso que no tiene actualmente... si no sabes de programacion porque aseguras que es imposible... que es dificil lo es pero no imposible. Lo haria con gusto si supiera programar para wii/gc cosa que aun no conozco xD.

Conozco otros lenguajes con los que me gano la vida xD. vease java/c#/php/algo de abap... etc etc...

http://hackmii.com/2009/08/of-tmds-and-hardware/

Puede hacerse.

Vrsquid escribió:

emulation escribió:Dios mio sigue la terquedad... solo menciono que se podria hacer si se modificara mios para tener el acceso que no tiene actualmente... si no sabes de programacion porque aseguras que es imposible... que es dificil lo es pero no imposible. Lo haria con gusto si supiera programar para wii/gc cosa que aun no conozco xD.

Conozco otros lenguajes con los que me gano la vida xD. vease java/c#/php/algo de abap... etc etc...

http://hackmii.com/2009/08/of-tmds-and-hardware/

Puede hacerse.

Repito, agradecería que si se quiere hablar del tema, se hiciera en otra parte. Pero ya que mencionas eso, ahí lo único que dice es que hay una serie de dispositivos de los que normalmente se ocupa el Starlet, que pueden ser devueltos al PPC, pero para lo que propone el amigo, lo que tienes que hacer es justo lo contrario: tener el Starlet operativo con un kernel apropiado y el driver EHCI y luego ocuparte de hacer la comunicación interprocesador y las modificaciones necesarias para que el software encargado del disco, ignore su camino normal y reciba los datos de otra parte (y eso requiere alojar un programa que se ocupe de ello en el PPC tambien, lo cual causará problemas)

Vamos que incluso si fuera posible hacerse (y no hubiera otro registro que fuera el que fijase el modo GC y al hacerlo, perdieses todas las características como velocidad del procesador, memoria y acceso a otros dispositivos, vamos algo que obligase a capar el hardware si quieres trabajar como una GC) en la práctica no se puede, porque a ver quien es el guapo que reversa todo el código, vence todas las dificultades y crea ese kernel (incluso teniendo la facilidad de MINI) para ponerlo en marcha (incluidos los parches necesarios para compatibilizar juegos). Además, todo eso es mucho mas facil hacerlo con un SD gekko y vosotros mismos mencionais sus limitaciones en cuestión de compatibilidad.

Y repito, este tema, mejor tratadlo en otra parte, sobre todo si esto va a ser una discusión sobre si es posible o no, por parte de gente que no se va a poner a ello y que se está agarrando a que lo haga otro y a teorías sin demostración (en teoría la PS3 se puede crackear, en la practica, eso no es posible, o lo que es lo mismo, imposible. Pues aquí lo mismo, hasta que alguien lo demuestre con hechos)

Saludos

Hola Hermes.
Bueno ya que por lo visto algunos quieren que le hagas unos agregados a Uloader, como el de que prepare el café, otros el GCUloader, pues ya que la unidad de DVD prácticamente quedo en desuso, me gustaría ver si podrías agregarle una versión modificada de… el método del Twilight Maria para que hiciera pan tostado, así podríamos echarnos un buen café acompañado de pan tostado mientras jugamos en la Guii.
Mira qué, si lo logras, seguramente ahora si le pondrán la chincheta a este hilo que tanto se la merece, pues ahora si Uloader estaría siendo realmente util.
P.D. Esperando con ansias el nuevo Cios, mload, y Uloader. Por lo que comentas al patito feo le llego la hora de convertirse en cisne.
Saludos.

El cafe depende de lo que se caliente el disco duro.

Hablando de café: parece que he solucionado un problema que tenía de rebote de interrupción con la nueva forma de trabajarlas y llevo como 6450 segundos sin cuelgues.

En ese tiempo, se han producido dos errores que han requerido cerca de 4 segundos para rearmarse (tengo con el reset bulk en funcionamiento y en un modo de reintentos 0 en la práctica). Un error se ha producido a los 1100 segundos aproximadamente y otro 1819 segundos después: estos errores no dependen de mí, si no que se producen en el dispositivo (por los microcortes que mencionaba el otro día o simplemente, porque el tráfico de información los provoca por un error)

Lo bueno es que estoy trabajando con la maxima velocidad de respuesta (125ms).

Como veis, esto requiere tiempo porque las pruebas son muy largas

Por cierto, una de las chuladas nuevas, es que ahora cuando conectais el pendrive se enciende cuando empieza a ser montado y se apaga cuando termina el montaje. De esta forma, si se os clavara el juego, extraes el pendrive, esperas un segundo y enchufas, veras que se ilumina brevemente cuando lo vuelva a montar (y así si hay un problema, se puede discernir entre un cuelgue de verdad y un mal montaje)

Por otro lado, la interrupción cuando trabaja en modo pasivo, se encarga de liberar del modo USB 2.0 el resto de dispositivos, lo que será bueno para poder usar accesorios en el puerto 1 y evitar problemas con el Wiimote, aparte de que el hilo trabaja a menor prioridad que el modulo OHCI1

bueno no le voy a seguir con el tema, ojala aprenda algo y pueda hacer algo sino pues allí queda xD

Me gustaria si me ayudan a ver si Conocen algun Hilo de como compilar los source code de los usbloaders??

Saludos

Tengo un problema. He leido una especie de solución antes pero me da problemas y no puedo descargar un archivo.

Cuando cargo el uLoader, me da el error "Could not utilize USB subsystem ret:-1".

No sé que pasa, por que ni desde el USB ni desde la SD me funciona...

Hermes escribió:Hablando de café: parece que he solucionado un problema que tenía de rebote de interrupción con la nueva forma de trabajarlas y llevo como 6450 segundos sin cuelgues.

En ese tiempo, se han producido dos errores que han requerido cerca de 4 segundos para rearmarse (tengo con el reset bulk en funcionamiento y en un modo de reintentos 0 en la práctica). Un error se ha producido a los 1100 segundos aproximadamente y otro 1819 segundos después: estos errores no dependen de mí, si no que se producen en el dispositivo (por los microcortes que mencionaba el otro día o simplemente, porque el tráfico de información los provoca por un error)

¿Porqué tanto tiempo? Llevo un tiempo sin tocar el driver pero creo recordar que montar un dispositivo era bastante rápido, creo que menos de un segundo o ¿es por el usbtimeout cuando se produce un error de lectura? si es así supongo que bajándolo se aceleraría el volverlo a montar.
uhmm ¿el usbtimeout sigue teniendo sentido con interrupciones?
Ya tengo ganas de ver tus cambios, sobre todo en el mload y el modo supervisor.

Hermes escribió:Lo bueno es que estoy trabajando con la maxima velocidad de respuesta (125ms).

Genial, entonces se supone que el driver irá bastante rápido y sin apenas afectar al rendimiento de la cpu.

Me gustaria saber si se puede lanzar el uloader desde una particion FAT del HD.

Saludos

djseijin escribió:Me gustaria saber si se puede lanzar el uloader desde una particion FAT del HD.

Saludos

Con el forwarder oficial no, con homebrew channel sí.

Tengo el HBC 10.2. Si lo actualizo al 10.3 afecta el uloader o no tiene nada que ver?

burton123 escribió:Tengo el HBC 10.2. Si lo actualizo al 10.3 afecta el uloader o no tiene nada que ver?

no pasa nada actualiza trankilo

Saludos

PD: hermes porque no sacas una beta y te ayudamos a probarla??? y podemos generarte mas datos... creo que muchos de nosotros tenemos tiempo para ayudarte

rodries escribió:¿Porqué tanto tiempo? Llevo un tiempo sin tocar el driver pero creo recordar que montar un dispositivo era bastante rápido, creo que menos de un segundo o ¿es por el usbtimeout cuando se produce un error de lectura? si es así supongo que bajándolo se aceleraría el volverlo a montar.
uhmm ¿el usbtimeout sigue teniendo sentido con interrupciones?
Ya tengo ganas de ver tus cambios, sobre todo en el mload y el modo supervisor.

Pues porque cada dispositivo tarda lo que tarde y se pueden producir errores, pero tengo comprobado que mi HDD, tarda en montar esos 4 segundos desde un Reset Bulk, sin que haya fallo por medio.

Ahora bien, lo que me tiene loco y me está llevando a "destrozar" literalmente el driver, es que no entiendo porque cojones en un momento dado, se produce un error irrecuperable que hace que que el dispositivo retorne error en cuanto utiliza un comando que precise el lun (es decir, pasa todo hasta el test ready y si fuerzo el request sense, tambien va todo correcto, pero el Inquiry peta
y si lo elimino, entonces peta al tratar de leer sector, aunque aumente el timeout de forma bestial)

¿por que? Pues ni puñetera idea: se que no son los toggles y no sirve de nada ni los clearhalt, ni hacer reset del puerto, ni hacer Reset Bulk y por supuesto, si fuerzo el reset EHCI (lo cual hace que el Wiimote deje de responder), tampoco sirve de nada... solo sirve desenchufar/enchufar, puesto que no puedo apagar el puerto.

Pero no creas que esto es por causa de algo raro que esté haciendo yo, porque tengo comprobado que pasa incluso en las primeras versiones de Kwiirk y no es csa de usar interrupciones o no.

El timeout siempre es necesario pues cuando se produce un error no se envía el STS_INT y a menos que fuera un error en el host, no vas a recibir un STS_ERR, que por otra parte, nunca recibirás con el EHCI_TUNE_CERR a cero. La única manera, es que el dispositivo cambie el estado del puerto y entonces lo puedes detectar mediante la interrupción.

Pero para que te hagas una idea del problema, en el fallo del __send me devuelve el puerto como 0x1005 muchas veces. Es decir: que si no fuera por el timeout, se quedaría eternamente leyendo.

Y lo desesperante del tema es cuando llegas y por probar que el reset EHCI se activa pulsando el boton EJECT y que todo funciona bien (una función que he puesto para mis test), coges y desenchufas/enchufas y te tiras mas de hora y media SIN UN SOLO ERROR (eso si OHCI0 y OHCI1, KO) y luego lo pruebas todo junto y te da 10 errores en 20 minutos con un cuelgue que obliga desenchufar/enchufar, pero en otras ocasiones se tira una hora sin errores, etc

Asi que lo que voy a hacer, es meter en la nevera lo que tengo hecho hasta ahora, volver sobre mis pasos y revisar todo meticulosamente, por si alguna de las cosas que he tocado está haciendo que el driver me devuelva más errores de los debidos, pero creo que el bloqueo de los comandos que precisan el LUN, es insalvable, pues no es cosas del HOST EHCI, si no del dispositivo en cuestión, mas bien.

buenas, lo primero gracias hermes por tu trabajo.yo queria comentar que tengo todas las caratulas salvo una que siempre me descarga una imagen mal y es l del fifa ,hay algun metodo para solucionar esto??

Capovitore escribió:buenas, lo primero gracias hermes por tu trabajo.yo queria comentar que tengo todas las caratulas salvo una que siempre me descarga una imagen mal y es l del fifa ,hay algun metodo para solucionar esto??

baja la caratula de wiiboxart.com manual mente colocala en tu sd y agregala manualmente, noonline

Buenas, tengo una pregunta a ver si me podeis ayudar. Solo me funcionan los juegos si los vuelco directamente en la consola.

Si intento meter un iso obtengo un "error from the loader: 4" con el 222, una carga infinita con el 223 y un "DISC ID IS NOT EQUAL" con el 249.
Curiosamente, si el ISO lo grabo en un DVD y después lo paso a la consola, parece que si que va perfecto con el 222. Qué puede ser?

Uso un pendrive de 8GB Kingston y los juegos los estoy volcando con wiithon y con wbfs manager.
Un saludo y muchas gracias a Hermes por su trabajo, los que nos dedicamos a esto sabemos el tiempo y el esfuerzo que lleva.

intenta con el wbfs_win.exe que viene en el rar del uloader...

ya lo probé, lo que me hace es que me sale como si empezara y después se queda ahí y vuelve a la línea de comandos.

no sé si te servirá, hermes, pero dados los problemas que me daba la actual versión de uloader con the conduit instalé un canal con el cloader que viene en el loadstructor y lo he podido terminar sin un sólo parón del hd ... con uloader los parones eran constantes