DaXHordes.org

Por petición de mm_david_mm

Los ejecutables (aplicaciones) de un sistema moderno, llevan bastante información aparte del código en sí. Suelen ser formatos bastante complejos en los que se adjunta información importante para que el sistema operativo que vaya a usar el dicho ejecutable sepa por ejemplo la dirección de memoria en que debe cargarlo, dónde se halla el punto de entrada del código (es decir, dónde empezar a ejecutarlo), las diferentes secciones (código, datos, memoria reservada, etc...), y varios parámetros más. Todo esto va ordenado en el fichero ejecutable, por ejemplo, los EXE de Windows, los llamados ejecutables MZ, porque los dos primeros bytes del fichero corresponden a las letras "MZ".

En el caso de la PSP (así como sus hermanas mayores) se usa el estándar del formato de ejecutables (Unix, Linux, Solaris, MacOS, salvo evidentemente para Microsoft), los llamados ELF (Executable and Linkable Format, formato ejecutable y enlazable). Este formato permite no sólo la creación de ejecutables, sino también librerías de enlazado dinámico (por ejemplo las DLL de Windows -que no son ELF-).

Por tanto el firmware de la PSP ejecuta básicamente un tipo especial de ELF modificado por Sony (que recibe el nombre de módulo), por lo que no cumple completamente el estándar ELF, sino que incorpora o modifica elementos de ese mismo estándar para ajustarse a las particularidades del firmware de la PSP y también para conseguir cierta "seguridad" debido a que es un formato cerrado y propiedad de Sony. Hoy en día no hay problema en generar ELFs totalmente compatibles con el firmware de PSP como demuestran los homebrews.

Podemos distinguir 3 formas en que la PSP (OFW) puede ejecutar código:

• Ficheros PRX (PSP Relocatable Executable) desde NAND
• Ficheros BOOT.BIN y EBOOT.BIN desde el UMD.
• Ficheros EBOOT.PBP desde el MS

Para ejecutar cualquiera de estos formatos (que son todos ELF, recordemos) en un OFW es necesario que estén firmados por Sony y debidamente cifrados. Si disponemos de CFW, muchas de estas restricciones son suprimidas, y podemos por ejemplo arrancar PRXs desde el MS o ejecutar código sin firmar ni cifrar, lo que nos abre las puertas del software casero.

PRX (PSP Relocatable Executable)

Los ficheros PRX son ELF relocalizables, es decir, no llevan dirección de carga, sino que se pueden cargar en la dirección que el firmware considere oportuna. Esto implica un proceso extra por parte del firmware que se llama relocalización o reubicación del ejecutable (de ahí lo de "Relocatable"). Lleva información sobre si el módulo es modo usuario o modo kernel, para que se cargue en la zona de memoria correspondiente.

Los PRX también pueden ser meras librerías, es decir, no son aplicaciones sino un conjunto de funciones que pueden ser usadas por una aplicación. La mayoría de los PRXs del firmware son librerías.

UMD (BOOT.BIN & EBOOT.BIN)

Estos dos tipos de ejecutables sólo se pueden arrancar desde el UMD (umd0 o disc0). La diferencia entre ellos es que BOOT.BIN está en claro y EBOOT.BIN está cifrado. Estos ficheros suelen contener generalmente un ELF estático o un PRX.

EBOOT.PBP

El estándar para ejecutar aplicaciones desde el MS (incluídas las actualizaciones de firmware). En realidad está compuesto de varios ficheros embebidos (uno detrás de otro), con diferente información (nombre, versión, icono, vídeo y música a mostrar en el XMB, etc...). Uno de estos ficheros es un ELF, que sería realmente lo que finalmente se ejecuta por parte del firmware. De nuevo, puede ser un ELF estático o más comunmente un PRX.

Respecto a las ISO (por cierto, siglas de International Organization for Standardization -sí, ya sé que no corresponden las siglas, pero eslokay -, que viene de ISO 9660, el sistema de ficheros estándar que usan los discos ópticos -CD, DVD, UMD-), son simples "imágenes" (copias bit a bit del disco en un fichero) de un disco UMD. El CFW simplemente hace que un fichero ISO pase como si fuera un disco UMD realmente metido en el lector (redireccionando las llamadas al dispositivo umd0 o disc0 al fichero ISO).

Los ficheros CSO/DAX son simplemente ISO comprimidas, por lo que ocupan menos en el MS. Pero hay que descomprimir al vuelo los datos a la hora de usarlos, por lo tanto tienen un retardo mayor que una ISO sin comprimir debido al proceso que supone la descompresión.

Creo que hasta aquí es suficiente, porque más habría que meterse en terreno más técnico, que igualmente podéis consultar en advancedpsp.tk.

Saludos!

Gracias por las explicaciones.

Me quede con una duda en la parte

m0skit0 escribió:Los ficheros CSO/DAX son simplemente ISO comprimidas, por lo que ocupan menos en el MS. Pero hay que descomprimir al vuelo los datos a la hora de usarlos, por lo tanto tienen un retardo mayor que una ISO sin comprimir debido al proceso que supone la descompresión.

El retardo a la hora de utilizar un cso es solo al abrir el juego o todo los tiempos de carga son mas lentos?

Aprovechando el topico... los juegos que permiten instalar datos en la MS para agilizar los tiempos de carga.
Al utilizar una copia desde la MS serviria de algo instalar datos en la ms? o no sirve para nada?

fNk escribió:El retardo a la hora de utilizar un cso es solo al abrir el juego o todo los tiempos de carga son mas lentos?

Todo es más lento, ya que la descompresión es, como digo, al vuelo. Para ser más claros, no se descomprime todo el CSO de golpe (porque habría que hacerlo en la MS y entonces no tendría ninguna utilidad), sino sólo las partes requeridas en cada momento en RAM.

fNk escribió:Al utilizar una copia desde la MS serviria de algo instalar datos en la ms? o no sirve para nada?

Sí sirve porque te ahorras el tiempo de proceso que se gasta en el sistema de ficheros. Me explico: las imágenes ISO, como ya dije, son copias bit a bit del disco y esto incluye toda la información del sistema de ficheros (ISO 9660). Para acceder a la estructura de directorios y ficheros se necesita montar dicha imagen con controlador del sistema de ficheros en cuestión. Al instalar datos en la MS, se salta este paso. Aunque también te digo que la ganancia de tiempo es prácticamente despreciable si se usa una ISO.

Es decir, en la teoria es mas rapido pero en la practica no lo vamos a notar. Mas o menos como pasa con jugar con CSO, es mas lento pero en la practica es dificilmente apreciable

Niños, leeros todo esto que no veas como se aprende!!!!!

NEOBARON escribió:Mas o menos como pasa con jugar con CSO, es mas lento pero en la practica es dificilmente apreciable

Ahí si que no estoy tan de acuerdo. Todo depende de cómo esté programado el juego: bien programado (pocos accesos al UMD) se nota menos, mal programado (muchos accesos al UMD) se nota más.

También cuanto más comprimido esté, peor para la velocidad de ejecución.

NEOBARON escribió:Niños, leeros todo esto que no veas como se aprende!!!!!

Uf, me asustaste empezando con lo de "niños"... Ah, por cierto, se dice "leed"

Lo de los juegos mas o menos me lo figuraba, que hay cada truño con tiempos de carga por ahi... recuerdo el Raw vs Smackdown (no recuerdo que año) que tenia una carga para una pantalla de carga

Ups! gazapazo ortografico!! efectivamente el imperativo es LEED, se me cae la cara de verguenza

Joder m0ski, sabes de todo, tambien de temas sexuales?

Pues sí. Hay muchos programadores profesionales que programan con el culo. Y otros tantos supuestos "ingenieros" de software que mejor me quedo callado (entre ellos el Sr. Bill Gates).

NEOBARON escribió:Joder m0ski, sabes de todo, tambien de temas sexuales?

¿De dónde crees que viene la expresión "el moro y el oro"?

Muy interesante, acabo de descubrir por qué a veces el circuito en MotorStorm desaparece. Gracias.

Gracias por la explicación =P.

Muchísimas gracias por tomarte el esfuerzo m0skit0