lovezno4 escribió:Matrox escribió:lovezno4 escribió:Pero el v4 incorpora lo de la actualizaciones de juegos?¿
SI
Es seguro confirmado?¿ es k leo en varios post que no esta implementado el parche para actualizar y supongo k funcionara tambien los jeugos k tiene problema de mandos como f1 y street fighter 4 no?¿ gracias
Bueno pues tendre k probarlo muchas gracias
lovezno4 escribió:Bueno pues tendre k probarlo muchas gracias
Hermes escribió:Elnef escribió:Lo he probado en W7 32 bits y en XP con idéntico resultado. También he probado con los fuentes anteriores de la V3 y lo mismo. Y he probado lo que ha comentado aibo19 y sigue igual. Siempre se genera el archivo de 4 KB y el hex final ocupa 32 kb.
¿Podrías explicarme que necesito para compilarlo en Linux?
Bueno, esto ha sido la clave para encontrar el problema. Eso y que estáis utilizando los compiladores de ifcaro[/n], que tiran de MinGW.
Yo sin embargo, tiro de compiladores creados con la ps3toolchain y cygwin, que se adapta mas a Linux en línea de comandos y de ahí que una estupidez se convierta en un problema![[+risas]](/images/smilies/nuevos/risa_ani3.gif "más risas")
El fallo está en que en Windows tu puedes abrir dos tipos de ficheros con la función fopen: de texto o binarios, que no existe nada mas que en Windows.
Eso hace que si abres un fichero, en cuanto detecta un caracter EOF, se da por finalizada la lectura y a tomar por saco, aparte de que en escritura hace una conversión de caracteres de salto de línea, etc
Asi que el problema es que si compiláis correctamente port1_config_descriptor.S, al convertirlo mediante raw2payload. exe, [b]se trunca el fichero generado, dando lugar a que el hex pese menos y que no funcione
Lamentablemente, hay programadores que no tienen en cuenta la peculiaridad de Windows/MSDOS, que no cuesta trabajo incluirla (la aplicación raw2payload.exe o es mía)
Bueno, para arreglar el problema, hay que ir a las líneas 24 y 30 de raw2payload.exe y cambiarlas por fi = fopen(argv[1], "rb"); y fo = fopen(argv[2], "wb");
Para compilar utilizando los compiladores de ifcaro, lo correcto sería ir a Makefile.payload y editar la línea
donde está PS3_COMPILERS por esta otra PS3_COMPILERS= $(PS3DEV)/ppu/bin
Entonces cambiamos el compila.bat por lo siguiente:set PS3DEV=k:/ps3dev
set MSYS=k:/ps3dev/msys
set PATH=%PS3DEV%/bin;%PS3DEV%/ppu/bin;%PS3DEV%/spu/bin;%PS3DEV%/MinGW/bin;%PS3DEV%/msys/1.0/bin;%PATH%;
gcc utils/raw2payload.c -o utils/raw2payload.exe
make clean
make
pause
Nótese que la linea gcc utils/... es la que compilará raw2payload para que no requiera la DLL de cygwin y se adapte a MinGW que vais a utilizar. Está línea la podéis comentar mas tarde (poniendo delante "REM " sin comillas, para los no versados) o que podéis hacerlo mediante línea de comandos en otra parte, etc. En todo caso, asi como está, requiere obviamente que esté el compila.bat en el mismo nivel de directorio que la carpeta "utils", para que ese utils/raw2payload.c sea visto por gcc. Tambien nótese que yo estoy utilizando la ruta "k:\ps3dev" que es donde tengo instalado el compilador de ifcaro y os corresponde a vosotros modificar eso, claro.
Saludos
Hermes escribió:Elnef escribió:Lo he probado en W7 32 bits y en XP con idéntico resultado. También he probado con los fuentes anteriores de la V3 y lo mismo. Y he probado lo que ha comentado aibo19 y sigue igual. Siempre se genera el archivo de 4 KB y el hex final ocupa 32 kb.
¿Podrías explicarme que necesito para compilarlo en Linux?
Bueno, esto ha sido la clave para encontrar el problema. Eso y que estáis utilizando los compiladores de ifcaro, que tiran de MinGW.
Yo sin embargo, tiro de compiladores creados con la ps3toolchain y cygwin, que se adapta mas a Linux en línea de comandos y de ahí que una estupidez se convierta en un problema
El fallo está en que en Windows tu puedes abrir dos tipos de ficheros con la función fopen: de texto o binarios, que no existe nada mas que en Windows.
Eso hace que si abres un fichero, en cuanto detecta un caracter EOF, se da por finalizada la lectura y a tomar por saco, aparte de que en escritura hace una conversión de caracteres de salto de línea, etc
Asi que el problema es que si compiláis correctamente port1_config_descriptor.S, al convertirlo mediante raw2payload. exe, se trunca el fichero generado, dando lugar a que el hex pese menos y que no funcione
Lamentablemente, hay programadores que no tienen en cuenta la peculiaridad de Windows/MSDOS, que no cuesta trabajo incluirla (la aplicación raw2payload.exe no es mía)
Bueno, para arreglar el problema, hay que ir a las líneas 24 y 30 de raw2payload.exe y cambiarlas por fi = fopen(argv[1], "rb"); y fo = fopen(argv[2], "wb");
Para compilar utilizando los compiladores de ifcaro, lo correcto sería ir a Makefile.payload y editar la línea
donde está PS3_COMPILERS por esta otra PS3_COMPILERS= $(PS3DEV)/ppu/bin
Entonces cambiamos el compila.bat por lo siguiente:set PS3DEV=k:/ps3dev
set MSYS=k:/ps3dev/msys
set PATH=%PS3DEV%/bin;%PS3DEV%/ppu/bin;%PS3DEV%/spu/bin;%PS3DEV%/MinGW/bin;%PS3DEV%/msys/1.0/bin;%PATH%;
gcc utils/raw2payload.c -o utils/raw2payload.exe
make clean
make
pause
Nótese que la linea gcc utils/... es la que compilará raw2payload para que no requiera la DLL de cygwin y se adapte a MinGW que vais a utilizar. Está línea la podéis comentar mas tarde (poniendo delante "REM " sin comillas, para los no versados
Saludos
EDITO: He subido de nuevo la V4, con el raw2payload corregido
alienmind escribió:Hola, ante todo gracias a hermes por su magnífico trabajo sin el cual muchos estaríamos aún estancados en la scene
Ahora una duda: estoy preparando unas imágenes del V4 para iphone (psfreedom), con el procedimiento descrito en viewtopic.php?p=1722202280.
Pero me encuentro con que el payload que da hermes en v4 (tanto el .bin como si lo compilo yo) no me funciona la emulación del bdvd. Creo que debe ser un problema de psfreedom y no del payload en sí, ya que en el port rockbox_psgroove me va perfecto el mismo .bin
Con disco va sin problemas.
¿Alguien tiene una idea de qué puede estar pasando?
Muchas gracias
