Popsatation y isos en ISZ?

Supongo que alguien se dará cuenta y lo podrá implementar en versiones superiores.

Saludos y gracias por la info.

Me temo que eso ya no depende de los programadores de la scene, sino de la propia Sony, ya que es el emulador el que tiene que soportar el formato, y no el conversor.

Según parece, los juegos que se compran en la PS3Store tienen su propio formato de compresión (ya lo dijo Dark), así que dudo que incluyan ningún formato extra.

Lo único que podemos esperar es que alguien consiga desencriptar el formato que usa Sony para comprirmir los juegos de PSX y programar alguna utilidad para que podamos usarlo con nuestros backups convertidos.

Yo converti un game de psx en EBOOT con un formato MDF y rulo perfecto.

Luego tuve 2 games mas con ese formato y pantalla en negro.....bastante raro pero no es extraño la verdad.

Lo mejor es descomprimirlo y crear un archivo .bin a pelo,sin pasar por iso.

Saludos

Un poco al hilo de esto:

Se pueden ripear nuestros BackUps de PSX y que ocupen menos espacio?

Hay alguna manera de consegir eBoots compartidos marca Sony? Porque me imagino que si sony tiene su propio sistema, lo habrá implementado de forma que ocupen poco espacio. O que un mismo eBoot contenga todos los Cd's de una misma saga.


S2

A ver... Sony utiliza compresión similar al zip en sus eboots del ps3store. Si se consigue hackear ese sistema, podremos comprimir nuestros juegos, si no, pues tendrán que implementar como sea un descompresor de los que ya tenemos dentro del emulador... En cuanto a lo de meter varios discos de una saga en un mismo eboot... Lo veo dificil...

Yo me pregunto...si Sony utiliza su propio formato y nosotros utilizamos ISO...¿porqué el emu lo lee? ¿el emu está programado para leer los dos formatos o es chorra?

También se podría hacer un programa "mediador" entre el emu y la ISO comprimida(tipo daemon tools), pero no sé hasta qué punto es viable.

Sirk escribió:A ver... Sony utiliza compresión similar al zip en sus eboots del ps3store. Si se consigue hackear ese sistema, podremos comprimir nuestros juegos, si no, pues tendrán que implementar como sea un descompresor de los que ya tenemos dentro del emulador... En cuanto a lo de meter varios discos de una saga en un mismo eboot... Lo veo dificil...

Sirk, no termino de entender tu respuesta.

El fw. oficial es capaz de leer arhivos que estan "comprimidos" en algo parecido al Zip. ¿Y ademas las isos? o eso es gracias a D. A. y el 3.02OE-B.

A que te refieres con los descompresores que hay dentro del emulador? (perdon por mi ignorancia)

Otra cosa. Aun no tengo la PS3 y no se cuando la tendré. Pero me imaginaba que en la store de Sony te descargarias por ejem un juego completo con un solo eboot. de manera que te fuera mas facil su manejo dentro de una memori stick (disco o lo que sea), de PS3 o PSP.


Y sobre el otro tema ¿alguien sabe algo?¿Hay algun proyecto en marcha?. Rip las isos de psx me parece algo muy util. Al igual que se hace con los UMD quitandole lo que sobra para hacerlos menos pesados. (alomejor D Alex piensa en ello para un futuro no muy lejano)

Hombre,eso de quitarle lo que le sobra....a que juego le sobra un video o un audio? No se si te refieres a eso.
En tal caso lo que si podria hacerse en comprimir los videos para que ocupen mucho menos y los audios a menos calidad y tal,llegarian a pesar mucho menos claro que si,pero no se si es viable....
Por ahi lei un tutorial (en EOL) que explicaba como quitar Videos y demas,no se si te interesa,un saludo y feliz año nuevo a "TOS"

hombre interesar interesa.


Que no hay videos que sobren.... Yo personalmente una vez visto el del principio como que me storba. Y ademas lo que tb se suele quitar son los idiomas, alguna musiquilla. etc.


Shirk a ver si me puedes contestar al otro post y me saca de dudas.

El emulador de sony ya estaba preparado para isos no comprimidas.
Simplemente divide la entrada en bloques de 16 sectores de psx (16*2352 bytes), con una cabecera que contiene los offsets y las longitudes de los bloques comprimidos (que descomprimidos siempre tendran el tamaño 16*2352), ademas de un hash desconocido.
El emulador primero mira el tamaño del bloque comprimdo: si es exactamente 16*2352, entonces entiende que ese es un bloque no comprimido; en caso contrario entiende que es un bloque comprimido y los descomprime a un buffer de 16*2352 bytes.

En lo que al hash se refiere, el chequeo es mandado a tomar por culo por oe, asi que ni molestarse en mirar que tipo de hash es

La compresion, casi que es mejor implementar una en lugar de invertir la de sony, al menos de momento. Se puede usar el algoritmo deflate como usan dax/cso, pero sobre esos bloques de 16*2352 bytes, y listo, solo habria que reemplazar la llamada a la funcion de descompresion original por la llamada a la nueva funcion, y el pops.prx de sony se encargaria de los indices/longitudes igual que si una iso de la ps3store fuera.

Joer, nen, yo de mayor quiero ser como tú .

Bueno, pues, ¿alguien que entienda y que se ponga manos a la obra? (tampoco es cuestión de cargarlo todo a las espaldas de Alex) .

Muchas gracias por tu esplicacion, haroma he ha quedado mas claro.
Entinces comprimir las isos seriaposible, pero pasandolas a otros formatos como el cso como explicas tu dark_alex, y modificar lo necesario del firmware para que en vez de cojer el formato propio de compresion de sony que coja el tuyo. Si no he entendido mal.

Saludos

Dark_AleX escribió:El emulador de sony ya estaba preparado para isos no comprimidas.
Simplemente divide la entrada en bloques de 16 sectores de psx (16*2352 bytes), con una cabecera que contiene los offsets y las longitudes de los bloques comprimidos (que descomprimidos siempre tendran el tamaño 16*2352), ademas de un hash desconocido.
El emulador primero mira el tamaño del bloque comprimdo: si es exactamente 16*2352, entonces entiende que ese es un bloque no comprimido; en caso contrario entiende que es un bloque comprimido y los descomprime a un buffer de 16*2352 bytes.

En lo que al hash se refiere, el chequeo es mandado a tomar por culo por oe, asi que ni molestarse en mirar que tipo de hash es

La compresion, casi que es mejor implementar una en lugar de invertir la de sony, al menos de momento. Se puede usar el algoritmo deflate como usan dax/cso, pero sobre esos bloques de 16*2352 bytes, y listo, solo habria que reemplazar la llamada a la funcion de descompresion original por la llamada a la nueva funcion, y el pops.prx de sony se encargaria de los indices/longitudes igual que si una iso de la ps3store fuera.

Usando este método en teoría no se perdería velocidad ni nada, no? me refiero usando algo de tipo dax/cso... incluso se podría llegar a ganar ( me refiero porque el cuello de botella esta en el mem ) es solo una teoría pero que piensas?

Si la gran mayoria de juegos de PSP no se ven afectados al cargarlos desde ms en Cso, no deberia afectar para los backups de PSX.

No se cuanta cpu debe usar el emu de Psone, todo seria probar. Quizas en los videos pueda notarse pero si la compresion es inteligente no afectaria.

¿Existe algun plugin que indique el % de cpu que se usa en ese momento?

Un saludo.

Madre mia el propio Dark Alex me ha contestado a una pregunta!!!


Bueno y despues de alucinar en colores....

Tampoco parece un proceso tan complicado (sobre el papel y visto con los ojos de un inexperto) es decir, los materiales para comprimir por ejemplo en CSO los tenemos, lo unico seria ser capaces de modificar ese algoritmo.

Dark eres un crack. Muchas gracias por la informacion. Y que sencillo haces que parezca todo.

Dark_AleX escribió:
La compresion, casi que es mejor implementar una en lugar de invertir la de sony, al menos de momento. Se puede usar el algoritmo deflate como usan dax/cso, pero sobre esos bloques de 16*2352 bytes, y listo, solo habria que reemplazar la llamada a la funcion de descompresion original por la llamada a la nueva funcion, y el pops.prx de sony se encargaria de los indices/longitudes igual que si una iso de la ps3store fuera.

Me suena a que pronto tendremos (Gracias a DA) un compresor

Eso depende.

Dejemos al genio trabajar, y si lo considera oportuno adelante. Sino, seguro que alguien ya tiene la idea. Incluso yo mismo si supiera por donde empezar lo intentaría.

Todo a su tiempo....

La verdad es que leer a Alex es como ver a un crack del futbol, si es que hacen que parezca hasta facil y todo.... la realidad debe ser bien distinta.

saulotmalo escribió:
Usando este método en teoría no se perdería velocidad ni nada, no? me refiero usando algo de tipo dax/cso... incluso se podría llegar a ganar ( me refiero porque el cuello de botella esta en el mem ) es solo una teoría pero que piensas?

Pienso que tu teoría es errónea. Por simple lógica se deduce que la ejecución de código comprimido siempre será más lenta que la ejecución de código no comprimido, ya que para el primer caso, aparte de ejecutar, necesita descomprimir. Otra cosa es que el consumo extra repercuta o no negativamente, en el rendimiento del juego.

No es que yo sepa mucho de videoconsolas, y no mucho mas de ordenadores (yo soy mas de electronica). Pero si el procesador, al emular PSX, no lo lleva hasta los topes, podremos usar el "cachito" de procesador que nos queda y usarlo para desencriptar el algoritmo de compresion, solo perjudicando al consumo de bateria. Otra cosa seria optimizar al maximo este algorimto de descompresion para hacer que use menos el procesadory por lo tanto menos bateria. No se, o por lo menos eso creo.

Saludos a todos.

raedon escribió:
Pienso que tu teoría es errónea. Por simple lógica se deduce que la ejecución de código comprimido siempre será más lenta que la ejecución de código no comprimido, ya que para el primer caso, aparte de ejecutar, necesita descomprimir. Otra cosa es que el consumo extra repercuta o no negativamente, en el rendimiento del juego.

claaaaro por eso a las gráficas muchas veces se les envía el contenido comprimido... ays... a ver lo que importa es el cuello de botella si una cosa es mucho más lenta y de otra vas sobrada digamos almacenamiento lento y por otra parte mucho procesador el comprimir es buena idea. Te lo dice un informático .

saulotmalo escribió:
claaaaro por eso a las gráficas muchas veces se les envía el contenido comprimido... ays... a ver lo que importa es el cuello de botella si una cosa es mucho más lenta y de otra vas sobrada digamos almacenamiento lento y por otra parte mucho procesador el comprimir es buena idea. Te lo dice un informático .

si... efectivamente lo que siempre hay que mirar son los cuellos de botella, pero precisamente de lo que mas tira un emulador es de procesador a menos que no utilice recompilacion estatica, pero este no es el caso. Si llegamos y comprimimos se va a notar casi seguro..... ahora la gracia esta en mirar si los fps que perdemos merece la pena perderlos o no.

una de las razones además que pienso que no se notará tanto o no se notará es porque si os fijais los juegos ya están comprimidos (los de la ps3store) por lo tanto cuando hicieron el emulador tubieron en cuenta un tiempo de procesamiento. Solo nos queda que esperar.

No se si lo sabreis o no, pero en Pspain han dicho de pronto saldra el 3.03 OE y que este posiblemente pueda tener COMPRESION PARA LOS JUEGOS DE PSX . Este tio no para de trabajar.
Gracias por todo dark_alex .

Saludos

Yo había oido en PSPUpdates que estaba confirmado que D_A iba a implementar la compresion DAX/CSO en el 3.03EOA

Juas, que lo confirme él ... estaría bien, pero no sería para tanto

Prefiero que el Ps3stores saque ya un jodido juego PAL ... que probablemente algun hispanoamericano quiera jugar a un juego en español en su PSP con su PS3