PSP & desarrollo ASM, comienzo imposible!?

Moderadores: Kravenbcn, largeroliker, fidelcastro, cerealkiller, pspCaracas, dark_sasuke, m0skit0, LnD, ka69, zacky06

Avatar de Usuario
m0skit0
Administrador
Administrador
Mensajes: 5585
Registrado: 03 Sep 2009, 09:35
Ubicación: 0xdeadbeef

Re: PSP & desarrollo ASM, comienzo imposible!?

Mensaje por m0skit0 »

Vamos a ver... ¿Un PRX de 60Ks? ¿Un desensamblado de 15k líneas? ¿Qué parte de "hazte un "Hello world" con el PSPSDK y vemos el PRX resultante" no hemos entendido? :lol:

¿Y cómo es posible que el "RAR" tenga 5 descargas ya? :juasjuas:
Imagen

Avatar de Usuario
DaniPhii
Habitual
Habitual
Mensajes: 273
Registrado: 19 Sep 2009, 19:17
PSN ID: DaniPhii
Gamertag Xbox Live: DaniPhii
Twitter: DaniPhii
Ubicación: Spain

Re: PSP & desarrollo ASM, comienzo imposible!?

Mensaje por DaniPhii »

m0skit0 escribió:¿Y cómo es posible que el "RAR" tenga 5 descargas ya? :juasjuas:
La gente descarga lo primero que pilla pa' ver qué es. Aunque sea un plugin que le borre toda la flash en un arranque y se queden con un precioso e instantáneo brick. xD
PSP-2004 ZY · TA-085v1 · 6.60 ME-2.3

Avatar de Usuario
largeroliker
Administrador
Administrador
Mensajes: 8283
Registrado: 03 Sep 2009, 09:46
PSN ID: larger0o
Gamertag Xbox Live: larger0o
Steam ID: larger0o
Twitter: larger0o
Ubicación: Málaga
Contactar:

Re: PSP & desarrollo ASM, comienzo imposible!?

Mensaje por largeroliker »

DaniPhii escribió:La gente descarga lo primero que pilla pa' ver qué es. Aunque sea un plugin que le borre toda la flash en un arranque y se queden con un precioso e instantáneo brick. xD


:lol:
Imagen
Steam Deck · Xbox Series X · PS5 · Switch · PS Vita · WiiU · PS3 · new 3DS XL · Xbox 360 · PSP · PS2

Avatar de Usuario
Darthvader38
Enteradillo
Enteradillo
Mensajes: 67
Registrado: 24 Ene 2010, 06:39

Re: PSP & desarrollo ASM, comienzo imposible!?

Mensaje por Darthvader38 »

He!
Que se sepa que por un pequeño accidente no subi el SRC.
Asi que lo subo todo de nuevo en un rar con el src INCLUIDO.
Salu2!

M0skit0, no entiendo la queja, cual es el problema con lo que subi!?
Lo que me falto el src...
Si es por el tamaño del prx, siempre crece el size nada mas que declaro
el pspDebugScreenInit();

Empezamos?
(Estare ausente par de dias despues de este mensaje,
salu2 hasta entonces!)
No tiene los permisos requeridos para ver los archivos adjuntos a este mensaje.

Avatar de Usuario
m0skit0
Administrador
Administrador
Mensajes: 5585
Registrado: 03 Sep 2009, 09:35
Ubicación: 0xdeadbeef

Re: PSP & desarrollo ASM, comienzo imposible!?

Mensaje por m0skit0 »

Nada. Me cago en pspDebugScreenInit().
Imagen

Avatar de Usuario
m0skit0
Administrador
Administrador
Mensajes: 5585
Registrado: 03 Sep 2009, 09:35
Ubicación: 0xdeadbeef

Re: PSP & desarrollo ASM, comienzo imposible!?

Mensaje por m0skit0 »

Imagen

Avatar de Usuario
Darthvader38
Enteradillo
Enteradillo
Mensajes: 67
Registrado: 24 Ene 2010, 06:39

Re: PSP & desarrollo ASM, comienzo imposible!?

Mensaje por Darthvader38 »

1-Cuando dices(en el ->http://daxhordes.org/forum/viewtopic.php?f=33&t=9802) que:

"todos los codigos de los stubs son"

jr $ra
nop

"son sustituidos por"

jr $ra
syscall <número de syscall>

Significa esto que la instruccion syscall que lei en
el curso solo la usa el sistema porque sabe el # de la syscall
que debe llamar?
Mi duda es si yo puedo usar la instruccion "syscall" (no me importa como obtener el #
de la syscall en este momento) deseo saber si corresponde la instruccion al mismo
"bit parent" del curso.

Una conclusion (obvia), es que no me deberia encontrar nunca
la instruccion syscall en el desensamblado de un prx porque no es hasta que se carga
el prx, que este sabe que syscall corresponde a la funcion que desea usar.
Por lo tanto, tampoco podre saber que "bit parent" corresponde a la instruccion
syscall si no es en "tiempo de ejecucion".
Es esto correcto? :geek:
Espero q me haya dado a entender.
Finalmente y de nuevo, que "bit parent" es syscall? ;)



2-Otra duda: Es el firmware el encargado de guardar y cargar toda la informacion de los registros
en una pila cada vez que se ejecuta otro hilo de ejecucion perteneciente a otro modulo?
Digo, un hilo de otro modulo tendria sus propios valores con los que trabaja en los registros,
cuando le llega su "turno" de ejecucion, el firmware tendria que guardar todos los valores del hilo anterior en una
pila y entonces cargar los pertenecientes al nuevo hilo para que este siga su trabajo?
Es esta suposicion correcta?


Salu2 DaxH + M0skit0!

Avatar de Usuario
m0skit0
Administrador
Administrador
Mensajes: 5585
Registrado: 03 Sep 2009, 09:35
Ubicación: 0xdeadbeef

Re: PSP & desarrollo ASM, comienzo imposible!?

Mensaje por m0skit0 »

Significa esto que la instruccion syscall que lei en el curso solo la usa el sistema porque sabe el # de la syscall que debe llamar?

No entiendo muy bien a qué te refieres con "solo la usa el sistema".

Mi duda es si yo puedo usar la instruccion "syscall" (no me importa como obtener el # de la syscall en este momento) deseo saber si corresponde la instruccion al mismo "bit parent" del curso.
Una conclusion (obvia), es que no me deberia encontrar nunca la instruccion syscall en el desensamblado de un prx porque no es hasta que se carga el prx, que este sabe que syscall corresponde a la funcion que desea usar. Por lo tanto, tampoco podre saber que "bit parent" corresponde a la instruccion
syscall si no es en "tiempo de ejecucion". Es esto correcto? :geek: Espero q me haya dado a entender. Finalmente y de nuevo, que "bit parent" es syscall? ;)

Lo siento, no sé qué es "bit parent".

Otra duda: Es el firmware el encargado de guardar y cargar toda la informacion de los registros en una pila cada vez que se ejecuta otro hilo de ejecucion perteneciente a otro modulo?

Correcto, eso es el contexto del hilo, pero ten en cuenta que la PSP no es realmente multitarea. Es decir, el kernel no hace cambio de contexto hasta que no se llama a una syscall. De ahí que la PSP se cuelgue por completo en caso de un bucle infinito sin llamada al sistema en modo usuario. En este caso el chip syscon comprueba un registro que el kernel modifica cada vez que es llamado. Si este registro no cambia de valor en X tiempo, el syscon apaga la consola.
Imagen

Avatar de Usuario
Darthvader38
Enteradillo
Enteradillo
Mensajes: 67
Registrado: 24 Ene 2010, 06:39

Re: PSP & desarrollo ASM, comienzo imposible!?

Mensaje por Darthvader38 »

Error!-> "bit pattern". <- de aqui lo que queria saber es la representacion binaria de la
instruccion syscall por si deseara hacer un patch.

Sobre las syscall's, quise decir que no tiene
sentido intentar llamarlas si no sabemos cual es cual.
(Cuando digo intentar llamarlas es bajo la DIRECTA declaracion de "syscall")
Ej: syscall 0x01b4 <- De donde puedo asumir que esto es sceIoOpen?!
Quiero decir, el firmware es quien las usa bajo la
declaracion syscall 0x02b4...
nosotros lo que usamos son stubs que luego el firmware determina
si sustituye el stub(por syscall) o salta a la funcion si es modo usuario.Entendi bien esto?

Salu2! :oki:

Avatar de Usuario
m0skit0
Administrador
Administrador
Mensajes: 5585
Registrado: 03 Sep 2009, 09:35
Ubicación: 0xdeadbeef

Re: PSP & desarrollo ASM, comienzo imposible!?

Mensaje por m0skit0 »

Darthvader38 escribió:Error!-> "bit pattern". <- de aqui lo que queria saber es la representacion binaria de la instruccion syscall por si deseara hacer un patch.

¿Crees que voy a acordarme de la representación binaria de una instrucción? Lo siento pero no :lol: Lo puedes ver en el manual oficial de MIPS. De todas formas no necesitas buscar ninguna representación binaria para parchear, eso se suele hacer con el desensamblado y mirando los desplazamientos (offsets). El desensamblado igualmente incluye el código máquina (se llama código máquina, machine code, no bit pattern :)). Tú olvídate del código máquina y la representación de las instrucciones en binario, eso es 1) aleatorio (es decir, cada fabricante tiene su propio lenguaje máquina) y 2) trivial (es fácil trabajar con él).

Darthvader38 escribió:Sobre las syscall's, quise decir que no tiene sentido intentar llamarlas si no sabemos cual es cual. (Cuando digo intentar llamarlas es bajo la DIRECTA declaracion de "syscall") Ej: syscall 0x01b4 <- De donde puedo asumir que esto es sceIoOpen?! Quiero decir, el firmware es quien las usa bajo la declaracion syscall 0x02b4... nosotros lo que usamos son stubs que luego el firmware determina si sustituye el stub(por syscall) o salta a la funcion si es modo usuario.Entendi bien esto?

Sí, eso es. El kernel es el único que sabe qué syscall corresponde con qué función, y también ten en cuenta que las syscalls son aleatorizadas cada vez que se resetea el kernel. Pero ten en cuenta que el kernel sustituye los stubs, pero es tu código en modo usuario el que las llama, no el kernel. El kernel simplemente carga el módulo en memoria y luego hace las operaciones que deba sobre él (por ejemplo, resolver los stubs, relocalizar, etc...). De hecho syscall es precisamente para pasar de modo usuario a modo kernel.

PD: tío, deja de meter "enters" por todo el texto, me pones nervioso xD
Imagen

Responder