Nuevo HDL_Dumx 0.9.0, mas rapido y mejorado

¡¡¡ Sirve con wine !!!

Decidido, tiro mi Partición windows en poco tiempo para usar kubuntu por toda la eternidad !!

Requiere alguna librería especial o con el wine simple se puede (me refiero a que si necesita algo extra para rular)

Saludos !

Me parece no necesita mas que los archivos que vienen en paquete para windows que les proporciono, de todas formas anexo la version para Linux.

Para la version Linux/MacOSX tenemos el codigo fuente el cual hay que compilar en la Distro que usemos, y lo interesante que es posible crear una compilacion para que el archivo resultante sea ejecutable en windows, pero desde Linux. Tambien trae la opcion de crear el archivo ejecutable en linux usando el motor de Wine y tenga la apariencia que tendria bajo windows en Linux.

Compilation
-----------

* Windows: You need to have CYGWIN (http://www.cygwin.com/) installed;
then use
make RELEASE=yes
make -c gui RELEASE=yes
to compile command-line or GUI version.

NOTICE: with current compilation flags hdl_dump would not handle
correctly Ctrl+C if ran from-within a CYGWIN shell. AFAIR, removing
"-mno-cygwin" might correct this behaviour, but will break Ctrl+C
handling when ran from a Command Prompt.

* Linux: Build and copy executable into a directory of your choice.
make RELEASE=yes
Advanced Linux build commands:
make XC=win # for Windows cross-compilation using mingw32
make -c gui # for WineLib compilation
make -c gui XC=win # for GUI cross-compilation using mingw32

* FreeBSD and MacOS X: You'll need to have GNU make installed, then
gmake RELEASE=yes IIN_OPTICAL_MMAP=no
or
make RELEASE=yes IIN_OPTICAL_MMAP=no

Muy interesante, si señor, tendre que buscar un juego para probarlo.

Los cambios de la 0.9.0

.9.0
+ new networking server
+ copy_hdd command (doing what the name says), contributed by JimmyZ
~ fixed an inssue where APA might get broken on interrupted install
(when main partition overwrites __empty one)
~ help has been revised

Permite copiar el disco duro entero.

Puede que a lo mejor ya no de problemas con God of War 2? Quien sabe.

Milmirex escribió:¡¡¡ Sirve con wine !!!

Decidido, tiro mi Partición windows en poco tiempo para usar kubuntu por toda la eternidad !!

Requiere alguna librería especial o con el wine simple se puede (me refiero a que si necesita algo extra para rular)

Saludos !

Wine, wine, hay que buscar alternativas que ya hace tiempo que existen!

EDIT: mira, aqui hay una nueva GUI! Es como hdldumb, pero para linux ^^

http://psx-scene.com/forums/ide-hdd-discussion/54654-linux-hdl_dump-gui-very-early-alpha.html

Como puse en este hilo:
http://www.elotrolado.net/showthread.php?s=&threadid=606441

Os dejo el Khdldump compilado (debeis meter el hdldump compilado en /usr/bin)

http://www.elotrolado.net/attachmen...stid=1704915727

Si estais en MAC teneis xDump, pero no hay version con el 0.9.0 (aun, esperemos), supongo que habra alguna manera de substituir el binario como con el hdldump GUI de Lordbogamy.

xDump 0.9.9 (basado en hdldump 0.8.6)
http://xdumb.free.fr/downloads/XDumb_0.9.9.zip

Pagina oficial (en frances e ingles):
http://xdumb.free.fr

queria hacer una pregunta de aclaracion:

entonces la velocidad de taspaso de juegos del pc a la ps2 por red no depende del ELF que hay en la consola, sino del hdldump??? es que eso no lo tengo muy claro.

gracias

al conectar con el disco duro, me aparece: "Se ha forzado la interrupcion de una conexion existente por el host remoto"

Como lo arreglo?

mandrakke escribió:queria hacer una pregunta de aclaracion:

entonces la velocidad de taspaso de juegos del pc a la ps2 por red no depende del ELF que hay en la consola, sino del hdldump??? es que eso no lo tengo muy claro.

gracias

Depende de ambos, tambien esta actualizado el ef de la consola.

como que esta actualizado el elf de la consola? el nuevo hdl dump manda otro elf a la consola o algo asi?

No, lo tienes que meter tu, esta en el archivo para descargar

esto creo que ya lo hablamos. se hace mediante este tutorial , verdad??

turorial para cargar elf en la play2 con cd de arranque

He ejecutado el hdld_svr.elf en la play2, mediante el ulaunchelf. Y desde el ordenador le doy a Attach, y me aparece esto:

curiosa utilidad.

Ya estube hablando con Suloku. Este aplicativo me parece "demasiado cogido con pinzas"

Me explico. Teoricamente se establece una comunicacion por UDP y este protocolo es un protocolo en el cual no existe acknowledge es decir que puede perfectamente perder paquetes por el camino puesto que no se cerciora si llega o no ( es por ello que aparentemente la velocidad incrementa) . Tecnicamente, si existe una conexión suficientemente pura entre emisor y receptor se puede llegar a mayores velocidades passando archivos pero este protocolo de comunicación es un protocolo que se suele usar para streaming en tiempo real donde si se pierde un paquete no tiene importancia puesto que el siguiente lanzado ya se come el anterior.


Francamente... si tienes un ordenador con doble nucleo y dedicas una cpu solamente para este fin o programa puede ser factible que funcione pero si la linea ( el cable ) esta sometida a algun campo magnetico o pasa por debajo de la TV , o bien esto se prueba con wifi ( esto va por ti Suloku) esto tiene que fallar mas que una escopeta de feria. Es mas... todo depende de si las interrupciones de la CPU pueden interferir en el proceso de envio del paquete.

Ejemplo: Tenemos un archivo como el GOW2 de 8 gigas ( o 7 depende de como se haga el backup) y lo vamos pasando .... si por un casual mientras esta pasando te salta un escaneo en el ordenador del antivirus .... ese archivo aunque solo le falten 200k por pasar , esta visto para sentencia.


No se... no me parece tan "cojonudo" este programa. Otra cosa es que el HDLD_Server cree un buffer suficientemente "dedicado" para que pueda asumir en un momento dado la perdida de paquetes. Aun asi no me fiaria mucho de este tipo de software... y desdeluego... si lo tubiera que passar por wifi , lo descartaria del todo.

SAludos

escufi escribió:curiosa utilidad.

Ya estube hablando con Suloku. Este aplicativo me parece "demasiado cogido con pinzas"

Me explico. Teoricamente se establece una comunicacion por UDP y este protocolo es un protocolo en el cual no existe acknowledge es decir que puede perfectamente perder paquetes por el camino puesto que no se cerciora si llega o no ( es por ello que aparentemente la velocidad incrementa) . Tecnicamente, si existe una conexión suficientemente pura entre emisor y receptor se puede llegar a mayores velocidades passando archivos pero este protocolo de comunicación es un protocolo que se suele usar para streaming en tiempo real donde si se pierde un paquete no tiene importancia puesto que el siguiente lanzado ya se come el anterior.


Francamente... si tienes un ordenador con doble nucleo y dedicas una cpu solamente para este fin o programa puede ser factible que funcione pero si la linea ( el cable ) esta sometida a algun campo magnetico o pasa por debajo de la TV , o bien esto se prueba con wifi ( esto va por ti Suloku) esto tiene que fallar mas que una escopeta de feria. Es mas... todo depende de si las interrupciones de la CPU pueden interferir en el proceso de envio del paquete.

Ejemplo: Tenemos un archivo como el GOW2 de 8 gigas ( o 7 depende de como se haga el backup) y lo vamos pasando .... si por un casual mientras esta pasando te salta un escaneo en el ordenador del antivirus .... ese archivo aunque solo le falten 200k por pasar , esta visto para sentencia.


No se... no me parece tan "cojonudo" este programa. Otra cosa es que el HDLD_Server cree un buffer suficientemente "dedicado" para que pueda asumir en un momento dado la perdida de paquetes. Aun asi no me fiaria mucho de este tipo de software... y desdeluego... si lo tubiera que passar por wifi , lo descartaria del todo.

SAludos

Ummm, que interesante, puede que tengas razón, sin embargo tambien hay que tener en cuenta el protocolo de alto nivel que hayan creado para la comunicación entre el cliente y el servidor. Si éste se encarga del control CRC del stream, no debería haber problemas. Echando un vistazo al código saldríamos de dudas; de todas formas me cuesta trabajo pensar que ésta gente no haya tenido en cuenta las limitaciones propias de usar UDP... pero vamos todo puede ser.

Saludos.

siliconarm escribió:
Ummm, que interesante, puede que tengas razón, sin embargo tambien hay que tener en cuenta el protocolo de alto nivel que hayan creado para la comunicación entre el cliente y el servidor. Si éste se encarga del control CRC del stream, no debería haber problemas. Echando un vistazo al código saldríamos de dudas; de todas formas me cuesta trabajo pensar que ésta gente no haya tenido en cuenta las limitaciones propias de usar UDP... pero vamos todo puede ser.

Saludos.

Es muy probable que esta gente se haya dedicado a usar justamente las características del UDP para dar mas velocidad. Es decir.. para poder anunciar que es mas rapido. Lo que ya puede ser una autentica locura es que es muy probable que este aplicativo funcione mejor en linux que en windows al tener controlados los procesos que se ejecutan y no aparezcan sorpresas o subprocesos no controlados , y digo que es una locura por que seguro que la versión para windows funciona mejor bajo linux + wine ( cosa realmente paradojica)

Reitero... si la fuente es pura , el emisor también y tenemos una cpu o un core dedicado a este proceso ( cosa que podria perfectamente haber sido hecho por los autores) ahi tienes un UDP que podriamos decir que es un TCP sin acknowledge y por tantno menor tamaño de trama = > mayor velocidad.

No se no lo veo claro.. igual los tios lo han probado bajo unas caracteristicas deteerminadas y no lo dejan claro

Aun puede ser mejor... podria incluso combinar los 2 protocolos y con suficiente tiempo de reacción de la CPU ( cosa factible dado el step de las cpus actuales) recalcular si usar udp o tcp al haber perdido algún paquete y volver a enviar , con lo cual pareceria ser mas rapido pero en verdad no lo seria

La mejor manera... que alguien lo pruebe con un fichero grande

Saludos

P.D: El UDP es lo que tiene... no hay mas...

Si claramente se a dicho en el foro de discusion de la Scene las ventajas y desventajas de usar UDP cuando se buscaron soluciones a la baja velocidad de transferencia, la principal limitante es la consola que no puede manejar velocidades mas altas usando TCP por lo que descidieron probar con UDP que bien explicaron se maneja en envios de informacion que no es indispensable lleguen completamente integros como es el video bajo demanda o streaming, pero me parece y segun recuerdo estan usando -no recuerdo si es un algoritmo creado o es alguna opcion del mismo hardware y protocolos de red- para evitar esta perdida de paquetes y por eso este limitado a una velocidad menor de la que podria obtenerse.

Ahora, si es la opcion correcta o no solo el tiempo lo dira y seran necesarias muchas pruebas de juegos que instalen.

Efectivamente sólo probando sabremos que hay de todo ésto.

De todas formas, creo que no es para llevarse las manos a la cabeza, actualmente existen muchos protocolos de comunicaciones sin ack por ejemplo el X.25/X.28 siendo uno de los protocolos más extendidos en los sistemas de comunicación finacieros (aunque hay que decir que normalmente no en tiempo real).

La gracia está en la implementación de un protocolo superior que permita mediante checksum (que sí implementa UDP) y secuencias repetir la emisión de paquetes en caso necesario. Imagino que por aquí habran apuntado, si no mal vamos.

nokerx escribió:He ejecutado el hdld_svr.elf en la play2, mediante el ulaunchelf. Y desde el ordenador le doy a Attach, y me aparece esto:

Por que me sale ese error, y ahora solamente me deja subir archivos con el hdl_dump_gui-2.1 ?

dentro del Ulanunchelf:

FileBrowser->MISC->PS2Net

despues ejecuta el server del hdldump normalmente

sL1pKn07 escribió:dentro del Ulanunchelf:

FileBrowser->MISC->PS2Net

despues ejecuta el server del hdldump normalmente

wow!!! nose por que, pero funciono!!! el puto amo xDD me has salvao de una buena xD

a ver si es verdad que no tarda tanto!!

lo pone en el post oficial de psx-scene

Para los users de macOS/X:

Cuando salio esta version notifique al creador de Xdumb que habia salido, ayer me contesto con la nueva version de Xdumb 1.0 (creo que aun no es publica) diciendo que no lo habia podido hacer funcionar.

Le acabo de comentar el truco del ps2net, asi que supongo que en breve tendreis la nueva version disponible.

En hora buena... mas opciones para los MacUser como algunos amigos -¿o son enemigos?- que usan este sistema operativo.

sL1pKn07 escribió:dentro del Ulanunchelf:

FileBrowser->MISC->PS2Net

despues ejecuta el server del hdldump normalmente

HOLA MIRA VI ESTE POST TUYO Y A MI ME PASA LO MISMO KE HA ESTE XAVAL PERO YO HE METIDO EL CD EN LA PLAY GRABADO CON EL ALCOHOL 120 Y NO ME FUNCIONA NADA NISIKIERA EL HDL_GUI...KE PUEDO HACER=?¿?

Que programa m pillo que sea simple para meter los juegos por red desde Windows.

¿Como se arracaba la ps2 en modo servidor? Creo q era manteniendo el boton X de la ps2 al arranque del HD Advance

¿Como miro la ip de la ps2?

¿Con un cable UTP normal es suficiente, o lo necesitamos cruzado?

¿Solo metiendo la ip en el programa y seleccionando la ISO del backup se pasa??

Quizas estas preguntas han sido solucionadas en post anteriores pero tras leerlos todos no me ha quedado muy claro, si alguien pudiese contestar a estas preguntas en un solo post.

Gracias de antemano y un saludo.

Buenas,

A mí no me compila en una máquina con Debian, en otro post he puesto la salida del error.

hdl_dump.c:1260: error: expected ‘;’ before ‘now’
hdl_dump.c:1262: error: ‘progress_t’ has no member named ‘remaining’
hdl_dump.c:1263: warning: incompatible implicit declaration of built-in function ‘fprintf’
hdl_dump.c:1263: error: ‘stdout’ undeclared (first use in this function)
hdl_dump.c:1265: error: ‘progress_t’ has no member named ‘pc_completed’
hdl_dump.c:1265: error: ‘progress_t’ has no member named ‘remaining_text’
hdl_dump.c:1266: error: ‘progress_t’ has no member named ‘curr_bps’
hdl_dump.c:1268: error: ‘progress_t’ has no member named ‘pc_completed’
hdl_dump.c:1270: error: ‘now’ undeclared (first use in this function)
hdl_dump.c:1272: warning: implicit declaration of function ‘fflush’
hdl_dump.c: In function ‘show_usage_and_exit’:
hdl_dump.c:1434: warning: implicit declaration of function ‘strrchr’
hdl_dump.c:1434: warning: incompatible implicit declaration of built-in function ‘strrchr’
hdl_dump.c:1441: warning: incompatible implicit declaration of built-in function ‘fprintf’
hdl_dump.c:1441: error: ‘stdout’ undeclared (first use in this function)
hdl_dump.c:1452: warning: implicit declaration of function ‘strcmp’
hdl_dump.c:1535: warning: implicit declaration of function ‘exit’
hdl_dump.c:1535: warning: incompatible implicit declaration of built-in function ‘exit’
hdl_dump.c: In function ‘map_device_name_or_exit’:
hdl_dump.c:1546: warning: incompatible implicit declaration of built-in function ‘fprintf’
hdl_dump.c:1546: error: ‘stderr’ undeclared (first use in this function)
hdl_dump.c:1546: warning: incompatible implicit declaration of built-in function ‘exit’
hdl_dump.c: In function ‘handle_result_and_exit’:
hdl_dump.c:1563: warning: incompatible implicit declaration of built-in function ‘exit’
hdl_dump.c:1571: warning: incompatible implicit declaration of built-in function ‘fprintf’
hdl_dump.c:1571: error: ‘stderr’ undeclared (first use in this function)
hdl_dump.c:1575: warning: incompatible implicit declaration of built-in function ‘fprintf’
hdl_dump.c:1580: warning: incompatible implicit declaration of built-in function ‘fprintf’
hdl_dump.c: In function ‘main’:
hdl_dump.c:1736: warning: implicit declaration of function ‘signal’
hdl_dump.c:1736: error: ‘SIGINT’ undeclared (first use in this function)
hdl_dump.c:1759: error: too many arguments to function ‘dump_device’
hdl_dump.c:1865: warning: implicit declaration of function ‘strtoul’
hdl_dump.c:1922: error: ‘stdout’ undeclared (first use in this function)
hdl_dump.c:1922: error: too many arguments to function ‘cdvd_info’
hdl_dump.c:1931: error: too many arguments to function ‘cdvd_info’
make: *** [hdl_dump.o] Error 1