[Investigación] PsGroove en PSP

Te comento.
El USB_REQ_GET_STATUS que uso y el que usas, es identico, solo que tu envias todo al final, al hacer los case, y yo en el mio, lo hace dentro, sobre el return, es lo mismo poner eso que has puesto que poner 4, que es el tamaño de 2 x 2Byte.

En el case: case 4: //* PORT_RESET * // TODO: aun no hemos entrado, ni en el tuyo ni el mio.

la funcion hub_interrupt_transmit, es la hub_connect_port, si lo revisas es lo mismo, aunque en psgroove, este se lanza en el main, y aqui lo mandamos nosotros, como hace el de psfreedom.

case 8: //* PORT_POWER *
Es necesario tanto que descomentes el estado=ready_hub, como que despierte el hilo, como es en los demas proyectos, despues de los 6 puertos en power, se espera 150ms y se manda el connect port 1, y no son errores los que aparece, esque si no mandas nada, tu código se queda quieto hay, y no avanza.
Despues de los 150ms, y hub_connect_port, ya pide el GET STATUS, en este caso, mandando directamente el valor, no funciona, hay que esperar un poco, he puesto 100ms para probar, y he cambiado tu send request, al hilo, ahora no manda 4 clear features, solo 1, pero sigue fallando tu forma de hacer el envio, si usas mi metodo, que tb lo tienes implementado, si funciona, enviandolo en dos tandas, el primero(status) lo manda por el endpoint 1, y el segundo(changed) por el endpoint 0 y ahora ya se recibe el request port connection, donde se ve en pantalla dos veces, por que se marca en el código que ya no hay cambios, y a la 2º vez ya se queda en GET STATUS PORT, esperando...

Te mando el tuyo con estos cambios, para que veas la diferencia.

En USB_REQ_GET_STATUS. en if (value > 0) {
Kprintf("enviando estado puerto... %d\n",req->wIndex);
Comenta, descomenta la opción a usar
//status = DEVICE1_WAIT_READY; // Metodo tuyo
//EnvDataStaChgHubPort=1; // Metodo mio

http://www.megaupload.com/?d=ER6ULMJ4

Edito:
CaptainCPS-X:

hola,

no se si lo he entendido del todo bien, pero creo que uno de los problemas actuales es que una de las comunicaciones hay que hacerla en el momento exacto (cuando lo pida la ps3).

entiendo que estais buscando la forma de esperar esa peticion, pero no sería posible buscar esos tiempos por fuerza bruta? (de eso nos sobra en EOL ).

si eso fuese posible tendrías que hacer algo para que la PSP pidiese el nº de ms a esperar y en el hilo de debate y test nos repartiriamos tiempos a probar, que entre todos y con las ganas que hay, seguro que lo sacamos en un rato.

no se tampoco si ese sería el final o simplemente un paso más hacia el final, pero seguro que todos estariamos encantados de echaros una mano.

PD: he programado en C y otros lenguajes muchos años, pero nunca para consolas, no creo que me de tiempo a meterme en ese mundo a tiempo para ayudaros más en profundidad.

agalardi escribió:hola,

no se si lo he entendido del todo bien, pero creo que uno de los problemas actuales es que una de las comunicaciones hay que hacerla en el momento exacto (cuando lo pida la ps3).

entiendo que estais buscando la forma de esperar esa peticion, pero no sería posible buscar esos tiempos por fuerza bruta? (de eso nos sobra en EOL ).

si eso fuese posible tendrías que hacer algo para que la PSP pidiese el nº de ms a esperar y en el hilo de debate y test nos repartiriamos tiempos a probar, que entre todos y con las ganas que hay, seguro que lo sacamos en un rato.

no se tampoco si ese sería el final o simplemente un paso más hacia el final, pero seguro que todos estariamos encantados de echaros una mano.

PD: he programado en C y otros lenguajes muchos años, pero nunca para consolas, no creo que me de tiempo a meterme en ese mundo a tiempo para ayudaros más en profundidad.

yo ya intente enviar un request desde la psp a la ps3 para que en el log me indique el tiempo, pero sin resultados relevantes.

La verdad, es que no hace ser un fenomeno en consolas, tocamos los comandos basicos de c, asi que si te animas a instalar el sdk, no es necesario el sdk de darkalex para este proyecto, pues eso si instalas el pack que lo tienes en tema hilo_psgroove-port-para-psp-por-deviante-coming-soon_1483049
Luego un bloc de notas, o notepad++ o otro editor, un bat para compilar, con
make
pause

y a codear.

ok wuepe, voy a tratar de volver a pensar en C, pues llevo ya unos años centrado en delphi y vb, pero siempre es un gusto volver a los origenes.

entiendo que no hay posibilidad de debugs paso a paso y que cada cambio debe ser compilado y linkado para hacer las pruebas: ¿las haceis con la psp conectada al PC? ¿o la prueba es directa a PS3?

no me molestaré si ves que estoy en "pañales" y prefieres seguir a lo tuyo.

mientras trato de entender un poco el codigo que ya teneis, voy a ir instalando el kernel 1.5 en mi psp slim.

Pues se tiene que probar directamente en la consola ps3, pero esta puede estar en el menu normal, nada en especial.
Kernel 1.5 en slim... necesitas usar el timemachine con bateria pandora, para iniciar en hibrido 1.5/3.40

Bueno, los pasos son estos, crear driver, y espera a que se conecte el usb, al conectar.
Ya es maneja el callback int usb_request(int arg1, int arg2, struct DeviceRequest *req).
1º pide descriptor del hub
2º los 6 puertos en power y se pasa a modo hub_ready
3º Se conecta port 1, y llega el GET Status HUB, luego de responde a este llegamos a GET Status Port, y es lo que falta, para que nos mande el RESET PORT.

Suerte

perdon me confundi, lo siento

joder que "guerra" me ha dado lo del timemachine... la pagina de dark-alex cerrada... no encontraba los PBP, no tenia el PSAR.... pero bueno, ya estoy listo para comenzar a probar cosillas.

a ver si saco algo en claro, aunque solo sea para aprender como haceis las cosas.

agalardi escribió:hola,

no se si lo he entendido del todo bien, pero creo que uno de los problemas actuales es que una de las comunicaciones hay que hacerla en el momento exacto (cuando lo pida la ps3).

entiendo que estais buscando la forma de esperar esa peticion, pero no sería posible buscar esos tiempos por fuerza bruta? (de eso nos sobra en EOL ).

si eso fuese posible tendrías que hacer algo para que la PSP pidiese el nº de ms a esperar y en el hilo de debate y test nos repartiriamos tiempos a probar, que entre todos y con las ganas que hay, seguro que lo sacamos en un rato.

no se tampoco si ese sería el final o simplemente un paso más hacia el final, pero seguro que todos estariamos encantados de echaros una mano.

PD: he programado en C y otros lenguajes muchos años, pero nunca para consolas, no creo que me de tiempo a meterme en ese mundo a tiempo para ayudaros más en profundidad.

Me apunto a esto, que para brutos nosotros. Si explicais como hacerlo, pero explicado para "dummies", nos ponemos a probar tiempos.

Estuve la mañana cambiando el codigo actual donde se manejan los requests basandome en el psgroove.c pero luego de cambiar la mayoria de los switch a IF y condicionando los mismos con los miembros de la estructura "req" como aparece en psgroove no tuve resutados distintos.

Wuepe ¿por que en vez de esperar el request de reset (que debe estar ocurriendo pero no lo localizamos) no esperas unos millisegundos y continuas con los demas pasos haber si asi funciona?. Yo crei que la forma que Deviante habia colocado anteriormente debia funcionar para completar el proceso y continuar con los descriptores.

Si se me ocurre algo mas o encuentro alguna informacion la posteo, pues ahora mismo mi conocimiento de USB / PSP no es tan abarcador como el conocimiento que tengo de WinAPI y sus respectivas librerias.

Saludos y ojala se encuentre la forma de recibir el bendito reset jeje xD.

TIOPEPE escribió:

agalardi escribió:hola,

no se si lo he entendido del todo bien, pero creo que uno de los problemas actuales es que una de las comunicaciones hay que hacerla en el momento exacto (cuando lo pida la ps3).

entiendo que estais buscando la forma de esperar esa peticion, pero no sería posible buscar esos tiempos por fuerza bruta? (de eso nos sobra en EOL ).

si eso fuese posible tendrías que hacer algo para que la PSP pidiese el nº de ms a esperar y en el hilo de debate y test nos repartiriamos tiempos a probar, que entre todos y con las ganas que hay, seguro que lo sacamos en un rato.

no se tampoco si ese sería el final o simplemente un paso más hacia el final, pero seguro que todos estariamos encantados de echaros una mano.

PD: he programado en C y otros lenguajes muchos años, pero nunca para consolas, no creo que me de tiempo a meterme en ese mundo a tiempo para ayudaros más en profundidad.

Me apunto a esto, que para brutos nosotros. Si explicais como hacerlo, pero explicado para "dummies", nos ponemos a probar tiempos.

Tendríamos que pedirle a Brandon Wilson, tenia el mismo exacto problema, si no mira sus tweets:

Managed to fix device 3 issue; changed max packet size from 64 to 08 and the controller's happy. Now if I could just GET THE TIMING RIGHT...

no se si os servira esto

este es el link a la web

http://www.gamefreax.de/wp-content/uploads/ubstream.jpg

64Byte datos estáticos que se emula con Jig enviado a la PS3

Extracto de la corriente USB

Wuepe encontre esto, no se si se habia posteado ya pero es que creo es importante:

http://www.beyondlogic.org/usbnutshell/usb7.htm

A common Windows enumeration involves the following steps,

1. The host or hub detects the connection of a new device via the device's pull up resistors on the data pair. The host waits for at least 100ms allowing for the plug to be inserted fully and for power to stabilise on the device.


2. Host issues a reset placing the device is the default state. The device may now respond to the default address zero.


3. The MS Windows host asks for the first 64 bytes of the Device Descriptor.


4. After receiving the first 8 bytes of the Device Descriptor, it immediately issues another bus reset.


5. The host now issues a Set Address command, placing the device in the addressed state.


6. The host asks for the entire 18 bytes of the Device Descriptor.


7. It then asks for 9 bytes of the Configuration Descriptor to determine the overall size.


8. The host asks for 255 bytes of the Configuration Descriptor.


9. Host asks for any String Descriptors if they were specified.

At the end of Step 9, Windows will ask for a driver for your device. It is then common to see it request all the descriptors again before it issues a Set Configuration request.

The above enumeration process is common to Windows 2000, Windows XP and Windows 98 SE.

Step 4 often confuses people writing firmware for the first time. The Host asks for the first 64 bytes of the device descriptor, so when the host resets your device after it receives the first 8 bytes, it is only natural to think there is something wrong with your device descriptor or how your firmware handles the request. However as many will tell you, if you keep persisting by implementing the Set Address Command it will pay off by asking for a full 18 bytes of device descriptor next.

Normally when something is wrong with a descriptor or how it is being sent, the host will attempt to read it three times with long pauses in between requests. After the third attempt, the host gives up reporting an error with your device.

Luego de que el HUB esta listo el Host espera 100ms para que este listo y estabilizado y envia el Reset. Supongo que hay que tener en cuenta esos 100ms ya que el reset ocurrira en ese tiempo.

No se si ya eso esta implementado en el codigo, y agradeceria que me indicaras en que parte se encuentra ya que me gustaria entender mejor como se manejan los delays.

Saludos.

Pregunta, con el GET HUB STATUS y se responde con None (0x0000 en state, y 0x0000 en change), luego pregunta por el estado con GET PORT STATUS, y se le responde que esta FULL (0x0103 en state, y 0x0001 en change), a lo que contesta, Clear Connection Port 1, que es que esta desconectado, en vez de recivir el RESET que seria esta conectado.

Pero los comandos esos son los correctos, asi que el problema viene de atrás. Así que hay que revisar lo anterior, haber que se ha escapado.

Wuepe modifique el ultimo paquete que subiste en megaupload para Deviante y cambie :



Por otro lado no dio resultado la primera vez, salia lo mismo, pero luego intente algo en el PS3

- Me aseguro apagar el PS3 debidamente.
- Cambio el switch del Power Suply a OFF y espero un par de segundos.
- Teniendo conectado el PSP corro PSPGroove y espero que se prepare
- Cambio el Switch a ON y presiono Power ON con un dedo y rapidamente con otro dedo Eject (estuve haciendolo rapido antes pero ahora trato de hacerlo lo mas rapido posible).

Al hacer esto obtengo el siguiente resultado en pantalla y sigue en un loop evidente...

...
USB Connectado a velocidad FULL...OK
Respondiendo con HUB Descriptor... OK
OK Power 6 port Completado


Conectando port 1...
OK
GET PORT 1 STATUS
enviando estado de puerto... 1
OK-> Change... 0 1 OK
USB_REQ_CLEARFEATURE USB_RECIP_OTHER value: 1
ClearPortFeature called
GET PORT 1 STATUS
enviando estado puerto ... 1
OK
->Change... 0 1 OK
USB_REQ_CLEAR_FEATURE USB RECIP OTHER value: 1
USB_REQ_CLEAR_FEATURE->USB_RECIP_OTHER C_PORT_CONNECTION called
GET PORT 1 STATUS
enviando estado de puerto... 1
OK
-> Change... 0 0 OK
USB_REQ_CLEAR_FEATURE USB RECIP OTHER value: 1
USB_REQ_CLEAR_FEATURE->USB_RECIP_OTHER C_PORT_CONNECTION called
GET PORT 1 STATUS
...

Detuve el Loop ahi pero hay veces que me aparece el Puerto 2 en vez del 1 , pero no se que pueda significar esto.

Gracias por la informacion Wuepe, seguire investigando como pueda =).

Saludos.

he estado probando a insertar algo de codigo para que al comenzar te pida el tiempo a esperar de forma que podamos ir probando diferentes valores sin recompilar y así podríamos participar todos. me ha matado que la psp no tiene teclado y no se como pedir el numero. mañana lo hare recogiendo el valor de un fichero, que tambien es facil de modificar por todos. (dios, como me esta costando volver a C)

por otro lado he revisado mucho tiempo el codigo (muuucho tiempo), y debo reconocer que no me entero aun al 100% pero he mirado el source de psfreedom y veo alguna diferencia:

por un lado hay muchos miembros de estructuras a los que poneis valores directamento, mientras que en psfreedom usan la macro cpu_to_le16, por ejemplo y los mas relevantes al problema actual: port_status y port_change. entiendo que los valores ya son unsigned de 16 bits pero...

por otro lado vosotros tratais de hacer todos los pasos correctamente siguiendo un protocolo mientras que he visto que quizas sea mas efectivo poner enabled directamente el puerto al realizarse la conexion. logicamente luego no seria necesario manejarlo en usb_request. copio la funcion donde lo he visto:



a ver si sale algo de esto, me voy a sobar que mañana es dia de curre.

agalardi escribió:he estado probando a insertar algo de codigo para que al comenzar te pida el tiempo a esperar de forma que podamos ir probando diferentes valores sin recompilar y así podríamos participar todos. me ha matado que la psp no tiene teclado y no se como pedir el numero. mañana lo hare recogiendo el valor de un fichero, que tambien es facil de modificar por todos. (dios, como me esta costando volver a C)

por otro lado he revisado mucho tiempo el codigo (muuucho tiempo), y debo reconocer que no me entero aun al 100% pero he mirado el source de psfreedom y veo alguna diferencia:

por un lado hay muchos miembros de estructuras a los que poneis valores directamento, mientras que en psfreedom usan la macro cpu_to_le16, por ejemplo y los mas relevantes al problema actual: port_status y port_change. entiendo que los valores ya son unsigned de 16 bits pero...

por otro lado vosotros tratais de hacer todos los pasos correctamente siguiendo un protocolo mientras que he visto que quizas sea mas efectivo poner enabled directamente el puerto al realizarse la conexion. logicamente luego no seria necesario manejarlo en usb_request. copio la funcion donde lo he visto:


static void
hub_connect_port (struct psfreedom_device *dev, unsigned int port)
{
  if (port == 0 || port > 6)
    return;
  switch_to_port (dev, 0);
  /* Here, we must enable the port directly, otherwise we might loose time
     with the host asking for the status a few more times, and waiting for it to
     be enabled, etc.. and we might miss the 5seconds window in which we need
     to connect the JIG */
  dev->hub_ports[port-1].status |= PORT_STAT_CONNECTION;
  dev->hub_ports[port-1].status |= PORT_STAT_ENABLE;
  /* If the speed flag set is not the same as what the device suports, it will
     not work */
  if (psfreedom_is_high_speed ())
    dev->hub_ports[port-1].status |= PORT_STAT_HIGH_SPEED;
  else if (psfreedom_is_low_speed ())
    dev->hub_ports[port-1].status |= PORT_STAT_HIGH_SPEED;
  dev->hub_ports[port-1].change |= PORT_STAT_C_CONNECTION;
  hub_port_changed (dev);
}


a ver si sale algo de esto, me voy a sobar que mañana es dia de curre.

Estuve verificando eso y creo que tiene sentido, haber que nos dice el Wuepe =), tal vez eso tenga que ver con el problema actual ya que en el comment del codigo dice que se deble poner enable directamente o de otra manera se perderia tiempo con el Host preguntando por el status unas cuantas veces, esperando a que el mismo se ponga enabled , etc. Tambien menciona que se podria perder esos 5 segundos en los que se debe conectar el JIG (que es el exploit como tal).

Nota:

Vi que en nuestro port tiene esto...



pero supongo que deberia ser...



ademas de agregar esto justo antes de esas dos lineas...



No lo he compilado pero voy a ver que sucede.

Saludos.

Como nota añadir.

En esta funcion:

Con esto, el PC, si reconoce la psp como hub,

y ahora he comentado...

Forzando a iniciar en PORT_STAT_POWER; y que no mande a los 150 la conexión.

Pero ciertamente, funciona diferente en el PC que la PS3.

En el pc, justo después de pedirnos el descriptor del hub, nos pide ya el GET STATUS HUB(en la ps3 no lo pide), y luego nos pone en power los 6 puertos, que es esta el hub_ready(esto igual que la ps3), pero aun así la pega es que en la ps3, si no mandamos en 150ms que conecte al puerto 1, se queda quieto aquí(no pide nada nuevo), pero en el PC, sigue trabajado y sin pedirlo nos pregunta por los estados de los puertos GET STATUS PORT(debe de ser el s.o. windows quien lo pide), le he respondido que están encedidos(power), y no se ha quejado, y se queda esperando unos segundos y luego nos vuelve a preguntar por los estados(antes de volver a preguntar es el momento para mandar conectar el port 1), le mando otra vez que están en power y ahora me desconecta el usb.

En cambio en la ps3, el GET STATUS HUB, lo hace cuando le damos a conectar puerto 1, antes no lo pide, y luego nos pide los estados de los puertos, que ya esta en FULL el port 1, pero nos manda que no se conecto, y nos manda a clear la connection.

Este code esta bien:

Puesto que cuando se le da a conectar, ya esta en power el puerto, así que se le asigna que esta conectado en modo full, y ciertamente hay un cambio, que es conectar.
Por ello seria bueno, saber por que es diferente en windows 7, que en la ps3, y que hacen el psfreedom, ya sea en un n900, htc... para ver si responde igual que a nosotros.
Comentar, que poniendo el 0x1C9 ahora en la ps3, si descimentamos para que si haga la conexión, en la ps3 dice que desconectes algún dispositivo que se esta usando mucha energía xD, en cambio en el otro CCCC no se queja.
Es el ID del dispositivo, devería de ser CCCC, pero en la ps3 hace lo mismo de un modo que de otro, pero será para que la gente no detectará en windows que era un hub el ps jailbreak, por que con CCCC da dipositivo desconocido en el PC.

quizas no sea importante mi otra observacion, pero decidme que lo teneis controlado: el formato de ciertos parametros o miembros de estructuras deberían ser almacenados en "little endian" por lo que aunque "0xCCCC" será siempre "0xCCCC" quizás otros como "0x1C9" sea tratado como "0x9C10".

Ademas de port_status y port_change tambien debería usarse en el idVender, idDevice, etc.

Siento no poder hacer otra cosa de momento que revisar codigo y elucubrar.

...pero aun así la pega es que en la ps3, si no mandamos en 150ms que conecte al puerto 1, se queda quieto aquí(no pide nada nuevo)...

A lo mejor si que está pidiendo, pero no nos enteramos.

Posiblemente me equivoco, pero con sceKernelSleepThread estamos haciendo que el hilo se duerma, cuando lo que queremos es que siga despierto escuchando diferentes eventos...

Esto es un fallo común en la programacion de microcontroladores y PLC's (y en VB con el MsgBox, que te para TODO el código hasta que aceptas o cancelas...); no hay que hacer que duerma, sino que en ese lapso de tiempo no ejecute las instrucciones que nos interese, pero que siga ejecutando lo que nos interesa. Que tal programar un temporizador genérico que cuente milisegundos y condicionar el código al valor de ese temporizador? al fin y al cabo, es lo que hace el PSGroove...

Repito, puede que me equivoque si el thread que dormís no es el mismo que el que se encarga de las transacciones, pero creo que lo usais de forma genérica para todos los paquetes de la comunicacion...

... aquí(no pide nada nuevo), pero en el PC, sigue trabajado y sin pedirlo nos pregunta por los estados de los puertos GET STATUS PORT(debe de ser el s.o. windows quien lo pide), ...

Windows tiene peticiones URB, PnP y algunas más que no me acuerdo, y todas ellas van en cascada: cuando conectamos un usb, primero pide descripción el sistema PnP (que debe tener algún tipo de código especial cuando se conecta un HUB para rotar las peticiones de estado de conexión de puertos), esto se le pasa al HUB y el HUB al dispositivo. Éste contesta al HUB y del HUB se envía al sistema PnP, quien lo envía al controlador (.inf, por llamarlo de alguna forma) USB adecuado. El GET STATUS PORT se envía desde el sistema PnP de Windows, no desde los paquetes URB que son los que llevan la información del cambio de dirección y habilitacion de dispositivo.

Me he tirado un par de días con el USBLyzer mirando tramas, y algo he llegado a entender: para saber como funciona todo esto en Windows está muy bien probar, pero para que funcione el programa en la PS3 no tiene nada que ver.

Saludos!



EDIT: Ok, creo que me he colado, en realidad lo que haceis es activar el thread cada vez que hay que enviar respuesta justo despues de establecer el tiempo de sleep... sorry.


Por otra parte, revisando código, me he encontrado con esto:


Eso no debería ser simplemente g_reportrequest.size = size;?

LoPelut, acostumbrado a pasar el tamaño de la estructura en este tipo funciones yo ni me había percatado, pero tiene sentido. Eso si, los maestros que lo corroboren.

por otro lado wuepe y CaptainCPS-X, no habra muchas diferencias al programar para consolas, pero realmente me esta costando dios y ayuda hacer 2 cosillas.

si trato de usar funciones como fopen, fseek, etc. para leer de un fichero, o para escribir un log (creo que me enteraré mejor del funcionamiento y la secuencia de los callbacks en lugar de verlo en pantalla), simplemente pongo los includes stdio y stdlib, pero no compila.

si cambio el makefile para comentar las lineas: # USE_KERNEL_LIBC = 1 y # USE_KERNEL_LIBS = 1, entonces compila bien, pero me da un error: "loadcore.c: doLinkLibraryEntries: Cannot link library [Kernel_Library]".

se que este foro no es para que los novatos aprendamos, pero teniendo experiencia previa programando, creo que con un par de empujones puedo llegar a hacer mis propias pruebas y ayudar no solo revisando codigo y diciendo teorias.

agalardi escribió:LoPelut, acostumbrado a pasar el tamaño de la estructura en este tipo funciones yo ni me había percatado, pero tiene sentido. Eso si, los maestros que lo corroboren.

por otro lado wuepe y CaptainCPS-X, no habra muchas diferencias al programar para consolas, pero realmente me esta costando dios y ayuda hacer 2 cosillas.

si trato de usar funciones como fopen, fseek, etc. para leer de un fichero, o para escribir un log (creo que me enteraré mejor del funcionamiento y la secuencia de los callbacks en lugar de verlo en pantalla), simplemente pongo los includes stdio y stdlib, pero no compila.

si cambio el makefile para comentar las lineas: # USE_KERNEL_LIBC = 1 y # USE_KERNEL_LIBS = 1, entonces compila bien, pero me da un error: "loadcore.c: doLinkLibraryEntries: Cannot link library [Kernel_Library]".

se que este foro no es para que los novatos aprendamos, pero teniendo experiencia previa programando, creo que con un par de empujones puedo llegar a hacer mis propias pruebas y ayudar no solo revisando codigo y diciendo teorias.

No me hagas mucho caso, pero creo que hay que deshabilitar algun flag para poder trabajar en modo user desde un codigo en modo kernel... busca en el psgroove de deviante, hay algo relacionado con k1 si no recuerdo mal. Si el problema es que no te compila sin sacar esas directivas, lo que te digo no creo que sirva de mucho...

agalardi escribió:...
si trato de usar funciones como fopen, fseek, etc. para leer de un fichero, o para escribir un log (creo que me enteraré mejor del funcionamiento y la secuencia de los callbacks en lugar de verlo en pantalla), simplemente pongo los includes stdio y stdlib, pero no compila.
...

si quieres escribir ficheros las funciones son las siguientes:


de todas maneras en el pspsdk vienen ejemplo bastante majos sobre todo si hay alguna cosa con la que dudes

edito: estas funciones funcionan exactamente igual que fopen, fseek, etc., de todas maneras mirate bien la api
http://psp.jim.sh/pspsdk-doc/group__FileIO.html

Interesante bug.

g_reportrequest.size = sizeof (size);
por
g_reportrequest.size = size;

Habria que probar cambiar

Se tedria que poner

en los 3 casos de endpoint

Y Ahora, mirar por que no hace caso a responder al GET STATUS HUB.

Puesto que antes, tenia puesto el tamaño de 8 bit(1byte) en wMaxPacketSize = 1, y deveria de estar en 8byte wMaxPacketSize = 8

esto es el hub_header_descriptor, solo que en la estructura teneis cambiados de orden 0xA9 y 0x00, forman un int, supongo que por lo del little y big_endian... no se si esnifando podemos ver en que orden se envian estos bytes cuando enviamos la estructura y cuando enviamos el strp en


Lo que parece cierto es que, segun habeis comentado, en lugar de hacer


haceis



habiendo cambiado antes en hub_header_desc el orden de algunos bytes y haciendo que funcione. Con esto quiero decir que a lo mejor el (struct StringDescriptor *)strp hay que cambiarlo por (const unsigned char *)hub_header_desc.


EDIT: Error, esto no creo que esté bien (o llenamos de basura información del driver). En ese campo se espera el descriptor de cadena del driver, y le estamos pasando la cabecera entera.

http://psp.jim.sh/pspsdk-doc/structStringDescriptor.html

en teoría debe haber un paquete de 34 bytes: uno para longitud (correcto,9 bytes), otro para tipo de descriptor (correcto, hub es tipo 0x29) y un array de 32 bytes máximo (del cual usamos 7 con basura). No creo que sea un fallo, ya que no se hace nada dañino, pero tampoco creo que esté bien. En resumen, no creo que sea importante.

a los scenerss...
como va el asunto?? en que parte estais atascados o por donde va el port?

LoPelut escribió:


Lo que parece cierto es que, segun habeis comentado, en lugar de hacer
[code]usb_send_request((const unsigned char *)&HUB_Hub_Descriptor, sizeof(HUB_Hub_Descriptor),0); // endpoint 0 control[/code]

haceis

[code]
usb_send_request((const unsigned char *)&hub_header_desc, sizeof(hub_header_desc),0); // endpoint 0 control

habiendo cambiado antes en hub_header_desc el orden de algunos bytes y haciendo que funcione. Con esto quiero decir que a lo mejor el (struct StringDescriptor *)strp hay que cambiarlo por (const unsigned char *)hub_header_desc.


EDIT: Error, esto no creo que esté bien (o llenamos de basura información del driver). En ese campo se espera el descriptor de cadena del driver, y le estamos pasando la cabecera entera.

http://psp.jim.sh/pspsdk-doc/structStringDescriptor.html

en teoría debe haber un paquete de 34 bytes: uno para longitud (correcto,9 bytes), otro para tipo de descriptor (correcto, hub es tipo 0x29) y un array de 32 bytes máximo (del cual usamos 7 con basura). No creo que sea un fallo, ya que no se hace nada dañino, pero tampoco creo que esté bien. En resumen, no creo que sea importante.

Una pregunta tonta, que hace muchos años que no toco programación.....pero muchos.....
Donde está definido hub_header_desc?
Gracias.
Un saludo!

reqtools escribió:Una pregunta tonta, que hace muchos años que no toco programación.....pero muchos.....
Donde está definido hub_header_desc?
Gracias.
Un saludo!

Supongo que es esto (pero lo curioso es que esta estructura no se usa en el codigo actual, solo se declara)...



Saludos.

azsxdcf escribió:a los scenerss...
como va el asunto?? en que parte estais atascados o por donde va el port?

porque tu los vas a ayudar!!!!

esa presion!!!!!

ve y compra un clon xD mejor o actualiza tu ps3....

si no han puesto novedades es que no lo hay......

NeoRyoga escribió:

azsxdcf escribió:a los scenerss...
como va el asunto?? en que parte estais atascados o por donde va el port?

porque tu los vas a ayudar!!!!

esa presion!!!!!

ve y compra un clon xD mejor o actualiza tu ps3....

si no han puesto novedades es que no lo hay......

nada

NeoRyoga escribió:

azsxdcf escribió:a los scenerss...
como va el asunto?? en que parte estais atascados o por donde va el port?

porque tu los vas a ayudar!!!!

esa presion!!!!!

ve y compra un clon xD mejor o actualiza tu ps3....

si no han puesto novedades es que no lo hay......

Que aburrido tienes que estar chaval.....hay dias tontos y tontos todos los dias!

Abenlx escribió:

NeoRyoga escribió:

azsxdcf escribió:a los scenerss...
como va el asunto?? en que parte estais atascados o por donde va el port?

porque tu los vas a ayudar!!!!

esa presion!!!!!

ve y compra un clon xD mejor o actualiza tu ps3....

si no han puesto novedades es que no lo hay......

Que aburrido tienes que estar chaval.....hay dias tontos y tontos todos los dias!

quien?

CaptainCPS-X escribió:

reqtools escribió:Una pregunta tonta, que hace muchos años que no toco programación.....pero muchos.....
Donde está definido hub_header_desc?
Gracias.
Un saludo!

Supongo que es esto (pero lo curioso es que esta estructura no se usa en el codigo actual, solo se declara)...

/* 11.23.2.1  Class-Specific AC Interface Descriptor */
struct usb_hub_header_descriptor {
   unsigned char  bLength;         /* 8+n */
   unsigned char  bDescriptorType;      /* USB_DT_CS_HUB */
   unsigned char  bNbrPorts;      /* n */
   unsigned short wHubCharacteristics;   /* hub characteristics */
   unsigned char  bPwrOn2PwrGood;      /* Port settling time, in 2ms */
   unsigned char  bHubContrCurrent;      /* ? */
   unsigned char  DeviceRemovable;      /* [n/8] */
   unsigned char  PortPwrCtrlMask;      /* [n/8] */
} __attribute__ ((packed));


Saludos.

el uso lo tienes aquí, solo que defines la variable hub_header_desc y la inicializas a la vez:




PD: he redefinido #define USB_DT_HUB_HEADER_SIZE (sizeof(struct usb_hub_header_descriptor))
para sacarle el (n), supongo que debe ser para aprovechar el define segun el descriptor que se pida mas adelante.

Saludos!

No empeceis a manchar el hilo por favor, este hilo es solo y exclusivamente, para los sceners que ayuden y/o colaboren en el proyecto, cando tengan avances los iran posteando como han echo hasta la fecha, si alguien tiene curiosidad de saber como va el proyecto o tiene algunas dudas sobre el susodicho, postearlas en el hilo de debate: hilo_debate-y-testers-psgroove-en-psp_1485197

Y por favor no me vengais diciendo que si me las doy de admin y tal y cual, dejemos trabajar a estos makinas tranquilos por favor, no nos piden otra cosa, respetarlos que bien merecido se lo tienen, un saludo y mucho animo a todos los sceners que le estan echando horas y muchos huevos diarios

azsxdcf escribió:quien?

NeoRyoga, que para postear esa gilipollez se podia haber callado,pero bueno si vamos a dejarlo.

LoPelut escribió:

CaptainCPS-X escribió:

reqtools escribió:Una pregunta tonta, que hace muchos años que no toco programación.....pero muchos.....
Donde está definido hub_header_desc?
Gracias.
Un saludo!

Supongo que es esto (pero lo curioso es que esta estructura no se usa en el codigo actual, solo se declara)...

/* 11.23.2.1  Class-Specific AC Interface Descriptor */
struct usb_hub_header_descriptor {
   unsigned char  bLength;         /* 8+n */
   unsigned char  bDescriptorType;      /* USB_DT_CS_HUB */
   unsigned char  bNbrPorts;      /* n */
   unsigned short wHubCharacteristics;   /* hub characteristics */
   unsigned char  bPwrOn2PwrGood;      /* Port settling time, in 2ms */
   unsigned char  bHubContrCurrent;      /* ? */
   unsigned char  DeviceRemovable;      /* [n/8] */
   unsigned char  PortPwrCtrlMask;      /* [n/8] */
} __attribute__ ((packed));


Saludos.

el uso lo tienes aquí, solo que defines la variable hub_header_desc y la inicializas a la vez:

//#define USB_DT_HUB_HEADER_SIZE(n)   (sizeof(struct usb_hub_header_descriptor))
#define USB_DT_HUB_HEADER_SIZE   (sizeof(struct usb_hub_header_descriptor))

/* Hub class specific Descriptor */
static const struct usb_hub_header_descriptor hub_header_desc = {
  .bLength =      USB_DT_HUB_HEADER_SIZE,
  .bDescriptorType =   USB_DT_CS_HUB,
  .bNbrPorts = 6,
  .wHubCharacteristics = 0x00a9,
  .bPwrOn2PwrGood = 50,
  .bHubContrCurrent = 100,
  .DeviceRemovable = 0x00,
  .PortPwrCtrlMask = 0xFF,
};


PD: he redefinido #define USB_DT_HUB_HEADER_SIZE (sizeof(struct usb_hub_header_descriptor))
para sacarle el (n), supongo que debe ser para aprovechar el define segun el descriptor que se pida mas adelante.

Saludos!

LoPelut, No me pude dar cuenta de que la declaracion estaba en el mismo codigo que expuse en mi ultimo post , y es cierto si se utiliza la estructura.

Saludos.

LoPelut escribió:el uso lo tienes aquí, solo que defines la variable hub_header_desc y la inicializas a la vez:

//#define USB_DT_HUB_HEADER_SIZE(n)   (sizeof(struct usb_hub_header_descriptor))
#define USB_DT_HUB_HEADER_SIZE   (sizeof(struct usb_hub_header_descriptor))

/* Hub class specific Descriptor */
static const struct usb_hub_header_descriptor hub_header_desc = {
  .bLength =      USB_DT_HUB_HEADER_SIZE,
  .bDescriptorType =   USB_DT_CS_HUB,
  .bNbrPorts = 6,
  .wHubCharacteristics = 0x00a9,
  .bPwrOn2PwrGood = 50,
  .bHubContrCurrent = 100,
  .DeviceRemovable = 0x00,
  .PortPwrCtrlMask = 0xFF,
};


PD: he redefinido #define USB_DT_HUB_HEADER_SIZE (sizeof(struct usb_hub_header_descriptor))
para sacarle el (n), supongo que debe ser para aprovechar el define segun el descriptor que se pida mas adelante.

Saludos!

Muchas gracias

No he podido evitar fijarme en que hay variables(constantes en realidad) que las definis en hexadecimal mientras que otras lo haceis en decimal ¿Tiene un porque? Mirando el source del PSGroove ( http://github.com/psgroove/psgroove/blo ... scriptor.h ) todo, absolutamente todo esta definido en hexadecimal.

Me explico un poco mejor para hacerme entender:

lo definis asi:

unsigned char bNbrPorts; /* n */

y mas tarde lo inicializais asi:

.bNbrPorts = 6,

¿al declarar la constante de tipo char no guardara el compilador el 0x36 que es el que corresponde al caracter "6" en vez del numero 6 que es lo que se pretende? Como este caso he visto alguno mas

Un saludo y suerte, os la mereceis por el curro que os estais metiendo

No es lo mismo 6 que '6'

Al poner el 6 sin las comillas simples, si guarda el 0x06, pero gracias por la nota, lo miraremos, por si algo de eso se ha colado.

He adjuntado un programa que escribí hace un rato (PSP FILE IO) para demostrar de manera simple como Abrir un archivo para escritura o lectura. Esto nos servirá para llevar un LOG de lo que ocurre mientras corre el PSPGroove.

Aqui tienen el código del main.c:

EDIT: Si se desea escribir en un archivo existente al final del mismo sin sobre-escribirlo se debe utilizar este flag "PSP_O_APPEND".

EDIT 2: He adjuntado la Revision 2 del "PSP FILE IO" y ahora maneja el inicio y salida mediante botones . Ademas le añadi mas informacion, etc.

EDIT 3: Revision 3 adjuntada. (Corregida la detección de fallos al abrir / escribir el archivo)

REV 3:



REV 2:



REV 1:



Dentro del ZIP esta el binario PBP y el código fuente. Comente casi todas las lineas detalladamente y espero les sirva.

*CORREGIDO* - El único problema con mi programa es que se queda congelado al finalizar todo, no se por que y hay que hacerle reset al PSP para salir.

Saludos.

CaptainCPS-X escribió:He adjuntado un programa que escribí hace un rato (PSP FILE IO) para demostrar de manera simple como Abrir un archivo para escritura o lectura. Esto nos servirá para llevar un LOG de lo que ocurre mientras corre el PSPGroove.

Aqui tienen el código del main.c:

EDIT: Si se desea escribir en un archivo existente al final del mismo sin sobre-escribirlo se debe utilizar este flag "PSP_O_APPEND".

EDIT 2: He adjuntado la Revision 2 del "PSP FILE IO" y ahora maneja el inicio y salida mediante botones . Ademas le añadi mas informacion, etc.

EDIT 3: Revision 3 adjuntada. (Corregida la detección de fallos al abrir / escribir el archivo)

REV 3:

/*
PSP FILE IO (REV 3)

Descripcion: Ejemplo de entrada y salida de archivos utilizando el PSPSDK
Por: CaptainCPS-X (2010)

Rev 1: No tiene manejo de salida.
Rev 2: Agregado el manejo de Inicio y de Salida usando botones (entre otros detalles).
Rev 3: Corregida la deteccion de fallos al abrir / escribir el archivo.

Tome de referencia esta pagina: http://www.psp-programming.com/forums/index.php?topic=68

*/

#include <stdlib.h>
#include <stdio.h>
#include <string.h>

#include <pspkernel.h>
#include <pspdebug.h>
#include <pspiofilemgr.h>
#include <pspctrl.h>

#define printf pspDebugScreenPrintf

PSP_MODULE_INFO("pspfileio", 0x1000, 1, 1);

int flags         = PSP_O_RDWR | PSP_O_CREAT ;   // Flag de Lectura / Escritura y Crear archivo de no Existir.
SceMode mode      = 0777;                     // Permiso CHMOD para todo tipo de accion.
const char file[]   = "ms0:\\pspfile.txt";         // Archivo a escribir / leer
char fbuffer[256];                           // Buffer que se usara para rellenar de texto.

void PSPFileIO();                           // Prototipo de la funcion principal.
int bFinished = 0;                           // Variable para saber si se ha realizado la funcion principal.

int main(int argc, char *argv[]) {

   // Iniciamos la pantalla para debug / depurar
   pspDebugScreenInit();

   // debug
   printf("PSP FILE IO (REV. 3) - por CaptainCPS-X (2010) \n\n");

   // debug
   printf("Este programa abrira el archivo [ %s ] y si no existe lo creara en la Memory Stick del PSP. Luego escribira varias cadenas de texto como forma de prueba.\n\n", file);

   printf("PRECIONA \"X\" PARA CONTINUAR...\n\n");

   // Buffer data de botones   
   SceCtrlData pad_data;

   // Loop atento a botones
   for(;;) {

      // Leemos el buffer de botones, por si acaso se ha precionado alguno
      sceCtrlReadBufferPositive(&pad_data, 1);

      // Si se ha precionado "X" realicamos la funcion principal
      if(pad_data.Buttons & PSP_CTRL_CROSS)
      {
         // Si ya se realizo todo, continua el Loop
         if(bFinished) continue;

         // debug
         printf("Iniciando funcion principal...\n\n");

         // Funcion principal
         PSPFileIO();
         
         // debug
         printf("PRECIONA \"O\" PARA VOLVER AL XBM...\n");
      }

      // Si se ha precionado "O" salimos del programa
      if(pad_data.Buttons & PSP_CTRL_CIRCLE)
      {
         // debug
         printf("Saliendo del programa...\n");
         
         // Salir del programa
         sceKernelExitGame();
      }

   }

   return 0;
}

void PSPFileIO() {

   // Abrimos el archivo y nos devuelve el ID
   
   SceUID fp = sceIoOpen(file, flags, mode);

   if(fp < 0) {
      // Error al abrir / crear el archivo.
      printf("Error al abrir / crear [ %s ].\n\n", file);
      
      bFinished = 1;
      
      return;
   }

   // debug
   printf("[ %s ] abierto / creado correctamente.\n\n", file);

   // Llenamos el buffer con una cadena de texto.
   sprintf(fbuffer, "Hola Mundo!.\n");

   // Escribimos el buffer al archivo y nos devuelve la cantidad de bytes escritos.
   
   // debug
   printf("Escribiendo: %s", fbuffer);

   int flen = sceIoWrite(fp, fbuffer, strlen(fbuffer));

   // Llenamos el buffer con una cadena de texto nuevamente.
   sprintf(fbuffer, "%d bytes escritos.\n", flen);

   // Escribimos por ultima vez el buffer al archivo.
   
   // debug
   printf("Escribiendo: %s", fbuffer);
   
   sceIoWrite(fp, fbuffer, strlen(fbuffer));

   // Cerramos el archivo

   // debug
   printf("\nCerrando archivo.\n\n");

   sceIoClose(fp);

   bFinished = 1;

}


REV 2:

/*
PSP FILE IO (REV 2)

Descripcion: Ejemplo de entrada y salida de archivos utilizando el PSPSDK
Por: CaptainCPS-X (13-sep-2010)

Rev 1: No tiene manejo de salida.
Rev 2: Agregado el manejo de Inicio y de Salida usando botones (entre otros detalles).

Tome de referencia esta pagina: http://www.psp-programming.com/forums/index.php?topic=68

*/

#include <stdlib.h>
#include <stdio.h>
#include <string.h>

#include <pspkernel.h>
#include <pspdebug.h>
#include <pspiofilemgr.h>
#include <pspctrl.h>

#define printf pspDebugScreenPrintf

PSP_MODULE_INFO("pspfileio", 0x1000, 1, 1);

int flags         = PSP_O_RDWR | PSP_O_CREAT ;   // Flag de Lectura / Escritura y Crear archivo de no Existir.
SceMode mode      = 0777;                     // Permiso CHMOD para todo tipo de accion.
const char file[]   = "ms0:\\pspfile.txt";         // Archivo a escribir / leer
char fbuffer[256];                           // Buffer que se usara para rellenar de texto.

void PSPFileIO();                           // Prototipo de la funcion principal.
int bFinished = 0;                           // Variable para saber si se ha realizado la funcion principal.

int main(int argc, char *argv[]) {

   // Iniciamos la pantalla para debug / depurar
   pspDebugScreenInit();

   // debug
   printf("PSP FILE IO (REV. 2) - por CaptainCPS-X (2010) \n\n");

   // debug
   printf("Este programa abrira el archivo [ %s ] y si no existe lo creara en la Memory Stick del PSP. Luego escribira varias cadenas de texto como forma de prueba.\n\n", file);

   printf("PRECIONA \"X\" PARA CONTINUAR...\n\n");

   // Buffer data de botones   
   SceCtrlData pad_data;

   // Loop atento a botones
   for(;;) {

      // Leemos el buffer de botones, por si acaso se ha precionado alguno
      sceCtrlReadBufferPositive(&pad_data, 1);

      // Si se ha precionado "X" realicamos la funcion principal
      if(pad_data.Buttons & PSP_CTRL_CROSS)
      {
         // Si ya se realizo todo, continua el Loop
         if(bFinished) continue;

         // debug
         printf("Iniciando funcion principal...\n\n");

         // Funcion principal
         PSPFileIO();
         
         // debug
         printf("Listo!...(PRECIONA \"O\" PARA VOLVER AL XBM.)\n");
      }

      // Si se ha precionado "O" salimos del programa
      if(pad_data.Buttons & PSP_CTRL_CIRCLE)
      {
         // debug
         printf("Saliendo del programa...\n");
         
         // Salir del programa
         sceKernelExitGame();
      }

   }

   return 0;
}

void PSPFileIO() {

   // Abrimos el archivo y nos devuelve el ID
   SceUID fp = sceIoOpen(file, flags, mode);

   if(!fp) {
      // Error al abrir / crear el archivo.
      printf("Error al abrir / crear [ %s ]\n", file);
      
      bFinished = 1;
      
      return;
   }

   // debug
   printf("[ %s ] abierto / creado correctamente.\n\n", file);

   // Llenamos el buffer con una cadena de texto.
   sprintf(fbuffer, "Hola Mundo!.\n");

   // Escribimos el buffer al archivo y nos devuelve la cantidad de bytes escritos.
   
   // debug
   printf("Escribiendo: %s", fbuffer);

   int flen = sceIoWrite(fp, fbuffer, strlen(fbuffer));

   // Llenamos el buffer con una cadena de texto nuevamente.
   sprintf(fbuffer, "%d bytes escritos.\n", flen);

   // Escribimos por ultima vez el buffer al archivo.
   
   // debug
   printf("Escribiendo: %s", fbuffer);
   
   sceIoWrite(fp, fbuffer, strlen(fbuffer));

   // Cerramos el archivo

   // debug
   printf("\nCerrando archivo.\n\n");

   sceIoClose(fp);

   bFinished = 1;

}


REV 1:

/*
PSP FILE IO

Descripcion: Ejemplo de entrada y salida de archivos utilizando el PSPSDK
Por: CaptainCPS-X (13-sep-2010)

Nota: Luego de hacer todo el PSP no responde y hay que darle un hard reset. No se por que razon.

Tome de referencia esta pagina: http://www.psp-programming.com/forums/index.php?topic=68

*/

#include <stdlib.h>
#include <stdio.h>
#include <string.h>

#include <pspkernel.h>
#include <pspdebug.h>
#include <pspiofilemgr.h>

#define printf pspDebugScreenPrintf

PSP_MODULE_INFO("pspfileio", 0x1000, 1, 1);

int flags         = PSP_O_RDWR | PSP_O_CREAT ;   // Flag de Lectura / Escritura y Crear archivo de no Existir.
SceMode mode      = 0777;                     // Permiso CHMOD para todo tipo de accion.
char fbuffer[256];                           // Buffer que se usara para rellenar de texto.

int main(int argc, char *argv[]) {

   // Iniciamos la pantalla para debug / depurar
   pspDebugScreenInit();

   // Abrimos el archivo y nos devuelve el ID
   SceUID fp = sceIoOpen("ms0:\\pspfile.txt", flags, mode);

   if(!fp) {
      // Error al abrir / crear el archivo.
      printf("Error al abrir / crear el archivo.\n");
      return 0;
   }

   // debug
   printf("Archivo abierto / creado correctamente.\n\n");

   // Llenamos el buffer con una cadena de texto.
   sprintf(fbuffer, "Hola Mundo!.\n");

   // Escribimos el buffer al archivo y nos devuelve la cantidad de bytes escritos.
   
   // debug
   printf("Escribiendo: %s", fbuffer);

   int flen = sceIoWrite(fp, fbuffer, strlen(fbuffer));

   // Llenamos el buffer con una cadena de texto nuevamente.
   sprintf(fbuffer, "%d bytes escritos.\n", flen);

   // Escribimos por ultima vez el buffer al archivo.
   
   // debug
   printf("Escribiendo: %s", fbuffer);
   
   sceIoWrite(fp, fbuffer, strlen(fbuffer));

   // Cerramos el archivo

   // debug
   printf("Cerrando archivo.\n\n");

   sceIoClose(fp);

   // debug
   printf("Listo!.");

   return 0;
}


Dentro del ZIP esta el binario PBP y el código fuente. Comente casi todas las lineas detalladamente y espero les sirva.

*CORREGIDO* - El único problema con mi programa es que se queda congelado al finalizar todo, no se por que y hay que hacerle reset al PSP para salir.

Saludos.

CaptainCPS-X, yo he creado una pequeña funcion para realizar los logs. No está muy depurada, ni tiene mucho control de errores, pero como es solamente para debugear un poco no importa demasiado. tiene cojones lo que me ha costado hacerla con lo poca cosa que es.



despues la estoy usando dentro de cada funcion para que en el fichero me quede una secuencia real y entender un poco mas como funciona todo esto.

creo que es muy sencillo cambiarla un poco para que añada la hora, etc.

de momento sigo tratando de entender la version r37, pero no estaría mal tener la ultima version ya que no lo veo actualizado en http://code.google.com/p/eol-psgroove/

por cierto, ¿a los maestros no os vendría bien poner algo así? seguro que a vosotros no os cuenta nada hacer algo 100 veces mejor que lo mio.

Me parece muy buena tu funcion =). Por cierto habra que esperar a la ultima revision del codigo fuente de Wuepe ya que yo ando realizando pruebas con un Timer / Temporizador alterno para el PSP. Si me resulta colocare el codigo para usarlo en vez de usar el Kernel Sleep o Delay.

Saludos.

chavales de verdad salga o no salga hay que quitarse el sombrero si señor.

saludos.

He logrado hacer un programa para PSP que pone a prueba las librerias de SDL en el PSPSDK para crear un TIMER / Temporizador (o mas de uno si se necesitan)

Con eso no habria que usar los delay de Kernel ni nada por el estilo, el timer funciona como el SetTimer de Windows API.

Por ejemplo si uso...



Significa que en un Intervalo de '10ms' el timer realizara un callback (llamado) a myTimer()
que por ejemplo lo tengo ahora mismo como modo de prueba, asi...



Aclaro algo, podemos tener otros timers activos pendientes a otras cosas con un minimo de precicion de 10ms de intervalo, que en el caso nuestro para el PSPGroove nos conviene.

Todavia no he terminado el programa de ejemplo y por eso coloco pedazos del mismo, pero es que ya tengo que dormir. Mas tarde cuando regrese compartire el codigo y todos los detalles necesarios para implementar los Temporizadores de las librerias SDL al PSPGroove.

Saludos.

DeViaNTe [COMING SOON]

Ha remodelado su código, y lo ha adaptado del psfreedom, parece interesante, y por su vertiente habría que mirar si funciona diferente o funciona igual que la rama que se usa aqui.

Habría que mirar, si con los cambios que ha metido, que esta bien estructurado funciona.

Esperemos, que en el de el, se pase de los GET Port Status y si devuelva el Reset.

De todas maneras, eso de tener que cargar siempre su eboot con ese splash, relanteliza el testeo.

hilo_psgroove-port-para-psp-por-deviante-coming-soon_1483049
svn
http://code.google.com/p/psp3jb/

wuepe escribió:DeViaNTe [COMING SOON]

Ha remodelado su código, y lo ha adaptado del psfreedom, parece interesante, y por su vertiente habría que mirar si funciona diferente o funciona igual que la rama que se usa aqui.

Habría que mirar, si con los cambios que ha metido, que esta bien estructurado funciona.

Esperemos, que en el de el, se pase de los GET Port Status y si devuelva el Reset.

De todas maneras, eso de tener que cargar siempre su eboot con ese splash, relanteliza el testeo.

hilo_psgroove-port-para-psp-por-deviante-coming-soon_1483049
svn
http://code.google.com/p/psp3jb/

Me parece muy interesante también, y considero que en el futuro Deviante debería agregar un tipo de espera luego de preparar el HUB para entonces conectar el PSP al PS3 y hacer las pruebas pertinentes. He probado el binario de la R3 y luego de mostrar varios detalles en pantalla se limpian todos los mensajes y no parece hacer nada mas.

Estaré atento a su progreso a ver si logra pasar el Reset y logra enviar los descriptores.

Saludos.

wuepe escribió:De todas maneras, eso de tener que cargar siempre su eboot con ese splash, relanteliza el testeo.

instalar este plugin, es un vsh menu que añade otras cosilla entre las cuales saltarse el Gameboot al cargar un eboot.



http://www.megaupload.com/?d=4MGY0X50

jotax escribió:

wuepe escribió:De todas maneras, eso de tener que cargar siempre su eboot con ese splash, relanteliza el testeo.

instalar este plugin, es un vsh menu que añade otras cosilla entre las cuales saltarse el Gameboot al cargar un eboot.

http://i34.tinypic.com/r1n5es.png

http://www.megaupload.com/?d=4MGY0X50

Y de donde bajo la versión compilada de Deviante, para probarla??

nickieto escribió:

jotax escribió:

wuepe escribió:De todas maneras, eso de tener que cargar siempre su eboot con ese splash, relanteliza el testeo.

instalar este plugin, es un vsh menu que añade otras cosilla entre las cuales saltarse el Gameboot al cargar un eboot.

http://i34.tinypic.com/r1n5es.png

http://www.megaupload.com/?d=4MGY0X50

Y de donde bajo la versión compilada de Deviante, para probarla??

no has entendido creo, este es un plugin ya compilado para saltarse el gameboot de la f0, se salta el gameboot al ejecutar cualquier eboot.pbp