¿Tiene la Wiz VFP?

[flozanot]

Pues me lo vuelvo a plantear después de leer esto:


No software emulation or support code is provided for the VFP instruction set. This means that code
using VFP instructions can be run only on a processor that implements VFP hardware. Executing
VFP instructions without the presence of VFP hardware will result in a SIGFPE signal.


en http://www.qnx.com/developers/docs/6.4.1/neutrino/technotes/vector_floating_point.html
¿Lo estoy sacando de contexto? :confused:

[efegea]

Que el sistema operativo QNX no tenga emulación por software no significa que el kernel linux tampoco lo tenga.

[Segata Sanshiro]

Yo creo que viene a decir lo que ya sabíamos... La CPU de la Wiz no incluye unidad de coma flotante sino que se tiene que servir de un coprocesador (el VFP9), y dicho coprocesador no lo incluye el SoC de la Wiz. Creo que es una característica lo suficientemente importante como para que la pusieran bien grande en hojas de características y demás.

Por otro lado dice lo que comentaban en gp32x, el proceso genera una señal (SIGFPE) si se intenta ejecutar una instrucción de ese tipo (VMUL, VDIV, etc.), que hará que pete o no dependiendo de otras historias.

Aunque también es cierto que el SoC lleva una GPU. No sé, esta falta de información me recuerda totalmente a los inicios de la GP2X.

En fin, me callo que yo lo máximo a lo que llego es Fenix [wei]

[Franxis]

Yo creo que viene a decir lo que ya sabíamos... La CPU de la Wiz no incluye unidad de coma flotante sino que se tiene que servir de un coprocesador (el VFP9), y dicho coprocesador no lo incluye el SoC de la Wiz. Creo que es una característica lo suficientemente importante como para que la pusieran bien grande en hojas de características y demás.

Por otro lado dice lo que comentaban en gp32x, el proceso genera una señal (SIGFPE) si se intenta ejecutar una instrucción de ese tipo (VMUL, VDIV, etc.), que hará que pete o no dependiendo de otras historias.

Aunque también es cierto que el SoC lleva una GPU. No sé, esta falta de información me recuerda totalmente a los inicios de la GP2X.

En fin, me callo que yo lo máximo a lo que llego es Fenix [wei]

Segun la documentación, en la WIZ se puede usar la GPU para realizar operaciones básicas con reales (reales con resolución de 24 bit compatibles a nivel binario con los float de 32 bit de C), pero todavía no he hay nadie que lo haya hecho...

[efegea]

Segun la documentación, en la WIZ se puede usar la GPU para realizar operaciones básicas con reales (reales con resolución de 24 bit compatibles a nivel binario con los float de 32 bit de C), pero todavía no he hay nadie que lo haya hecho...

Oye pues eso me interesa MUCHO

[flozanot]

Segun la documentación, en la WIZ se puede usar la GPU para realizar operaciones básicas con reales (reales con resolución de 24 bit compatibles a nivel binario con los float de 32 bit de C), pero todavía no he hay nadie que lo haya hecho...

¿Podrías dar algún detalle más? ¿Dónde está esa documentación? ¿Es la de Accorn?
Y gracias por la información :) y por las posibles respuestas ;)

[Puck2099]

¿Podrías dar algún detalle más? ¿Dónde está esa documentación? ¿Es la de Accorn?
Y gracias por la información :) y por las posibles respuestas ;)

Esa documentación es "privada", así que os la tendrían que pasar los de GPH si quisieran.

[saboteur]

Esa documentación es "privada", así que os la tendrían que pasar los de GPH si quisieran.

¿Alguna vez tendremos una documentación y un SDK completo para la consola o sólo podrán programar los que estén con GPH? Porque parece que no hay forma de sacarle todo el jugo al cacharro.

[Puck2099]

¿Alguna vez tendremos una documentación y un SDK completo para la consola o sólo podrán programar los que estén con GPH? Porque parece que no hay forma de sacarle todo el jugo al cacharro.

Pues teniendo en cuenta que para que los de GPH tengan esa documentación de MES tienen que firmar un NDA, bastante tenemos con que algunos lo tengamos de extranjis...

[flozanot]

Vamos, que venden un cacharro "open source" de iure, pero propietario de facto.
Pues menudo "timo", porque al menos podrían suministrar un compilador.
En fin, me imagino que "googleando" al se podrá sacar en claro. :(

[Puck2099]

Vamos, que venden un cacharro "open source" de iure, pero propietario de facto.
Pues menudo "timo", porque al menos podrían suministrar un compilador.
En fin, me imagino que "googleando" al se podrá sacar en claro. :(

Lo que no se puede divulgar es la documentación del fabricante de los chips que en la mayoría de los casos es algo que los programadores no van a usar (y que está casi todo extraído e implementado en las varias bibliotecas de bajo nivel como picolib, castor o wiz_lib).

En cuanto al compilador, creo que hay un toolchain subido aquí o en GP2X, así que mucho no lo has buscado...

[hardyx]

Ostras, a mí también me interesa esa información. Me alegra saber que la GPU soporta coma flotante. A ver si GPH se porta y la libera junto con el SDK. Pero no entiendo por qué ocultan una característica que es determinante en comparación con la Dingoo o Pandora por ejemplo, ya que les puede hacer perder ventas. :loco:

[Puck2099]

Ostras, a mí también me interesa esa información. Me alegra saber que la GPU soporta coma flotante. A ver si GPH se porta y la libera junto con el SDK. Pero no entiendo por qué ocultan una característica que es determinante en comparación con la Dingoo o Pandora por ejemplo y eso les puede hacer perder ventas. :loco:

Porque, como he dicho más arriba, hay un NDA de por medio.

[flozanot]

Lo que no se puede divulgar es la documentación del fabricante de los chips que en la mayoría de los casos es algo que los programadores no van a usar (y que está casi todo extraído e implementado en las varias bibliotecas de bajo nivel como picolib, castor o wiz_lib).

En cuanto al compilador, creo que hay un toolchain subido aquí o en GP2X, así que mucho no lo has buscado...
Ya me di cuenta... compilado con --with-float=soft e incompatible con las libs SDL y OGL suministradas con la consola :(

[Puck2099]

Ya me di cuenta... compilado con --with-float=soft e incompatible con las libs SDL y OGL suministradas con la consola :(

¿Seguro que es incompatible? El que tengo yo no sé si será el que está por aquí subido, pero funciona perfectamente con las SDL y OpenGL...

[flozanot]

¿Seguro que es incompatible? El que tengo yo no sé si será el que está por aquí subido, pero funciona perfectamente con las SDL y OpenGL...

Con SDL tira si se usa la "open-2x", y el OGL casca como la bendición (nanoGL y libGLES) a pesar de compilar perfectamente.
Con la SDL y el GLES que viene con la consola no compila ni en broma.
Si lo has conseguido, di el cómo, por favor.

[Puck2099]

Con SDL tira si se usa la "open-2x", y el OGL casca como la bendición (nanoGL y libGLES) a pesar de compilar perfectamente.
Con la SDL y el GLES que viene con la consola no compila ni en broma.
Si lo has conseguido, di el cómo, por favor.

Pues a mi el toolchain me lo pasó Pickle hace la tira de meses (lo compiló él), si queréis y se pueden subir archivos tan grandes lo podría subir a los archivos de la web, pero aseguraros primero de que no funciona el toolchain que hay aquí para no subirlo y ocupar espacio en vano...

[flozanot]

Pues a mi el toolchain me lo pasó Pickle hace la tira de meses (lo compiló él), si queréis y se pueden subir archivos tan grandes lo podría subir a los archivos de la web, pero aseguraros primero de que no funciona el toolchain que hay aquí para no subirlo y ocupar espacio en vano...

Yo el que usé con moderado éxito fue el de:
http://wiki.open2x.org/open2x/wiki/index.php?title=Main_Page
Con sus propias libs SDL me tiraba bien, pero en cuanto me metí con OGL cascaba en la inicialización y no había manera. Si intentaba compilar contra las libs de GPH, me decía que el compilador debía de ser reconstruido porque las libs usan intrucciones hard y el compilador soft para coma flotante.

[xau]

A mi me pasó lo mismo que a flozanot, con las de open2x. Contra las de GPH imposible.

[flozanot]

Creo que ya he averiguado el tipo de soporte hardware que trae la Wiz para los cálculos de coma flotante: FPA, para juegos, de pt mdr. (Lo he sacado por analogía con el firm. RockBox)
Así que hay que construirse una toolchain compilada con --with-float=hard y pasarle al compilador resultante -mfpu=fpa y -mhard-float. En teoría.

[bitrider]

Pues las librerías que vienen en el firmware están compiladas con un tool-chain con VFP que, por lo que sé, es incompatible con FPA...

[joseperilla]

Hola, siento interrumpir, pero me podias explicar por que es importante esto y por que lamentais que GPH haya obviado dicha informacion? No tengo ni idea de programacion, solo tengo curiosidad y lo que si me preocupa es la repercusion que puede tener este tema en un usario como yo que solo le gusta trastear con la emulacion. Saludos a todos y gracias.

[hardyx]

Pues en palabras sencillas, que sólo hemos visto la punta del iceberg del potencial de la consola. Cuando se pueda usar el acelerador gráfico y las instrucciones de punto flotante realmente vamos a ver lo que es una Wiz.

[joseperilla]

Pues en palabras sencillas, que sólo hemos visto la punta del iceberg del potencial de la consola. Cuando se pueda usar el acelerador gráfico y las instrucciones de punto flotante realmente vamos a ver lo que es una Wiz.

Ok, gracias por tu respuesta. Un saludo.

[Rivroner]

Pues en palabras sencillas, que sólo hemos visto la punta del iceberg del potencial de la consola. Cuando se pueda usar el acelerador gráfico y las instrucciones de punto flotante realmente vamos a ver lo que es una Wiz.

Ojalá eso suceda algún día :) Espero que no pase como en Gp2X que sólo unos pocos iluminados pudieron aprovechar el potencial de los dos cores o micros o lo que fuese que tenía :D [wei]

[Zenzuke]

A mi conque lo usen unos pocos iluminados la verdad es que ya me sirve xDDD

[Gammenon]

Disculpad el reflote. Al final el tema del coma flotante como queda? Puedo usar float a saco en mis juegos o tengo que tirar de movidas de como fija?

[Puck2099]

Disculpad el reflote. Al final el tema del coma flotante como queda? Puedo usar float a saco en mis juegos o tengo que tirar de movidas de como fija?

Yo diría que no no tiene por hardware, pero creo que al pasar el flag -msoft-float al compilador ya lo pasa a coma fija él por ti (aunque igual no sea tan óptimo como hacerlo a mano).

[hardyx]

Pues yo no estoy muy seguro todavía, según la documentación tiene una unidad GTE que permite realizar cálculos en coma flotante, aunque no es un coprocesador unido a la CPU.

Además he recompilado un emulador con el SDK oficial, que compila con FPA activado y va algo más rápido (+3/4 fps). De hecho si le pones -msoft-float te dice que nanay, ya que todas las librerías están con FPA.

[Rivroner]

Pues yo no estoy muy seguro todavía, según la documentación tiene una unidad GTE que permite realizar cálculos en coma flotante, aunque no es un coprocesador unido a la CPU.

Además he recompilado un emulador con el SDK oficial, que compila con FPA activado y va algo más rápido (+3/4 fps). De hecho si le pones -msoft-float te dice que nanay, ya que todas las librerías están con FPA.

Pues aún no he recibido tu MP con esa nueva recompilación más rápida, sea el emu que sea serán bienvenidos esos 3-4 frames extras :D

Asias famigo [wei]

[Puck2099]

Pues yo no estoy muy seguro todavía, según la documentación tiene una unidad GTE que permite realizar cálculos en coma flotante, aunque no es un coprocesador unido a la CPU.

Además he recompilado un emulador con el SDK oficial, que compila con FPA activado y va algo más rápido (+3/4 fps). De hecho si le pones -msoft-float te dice que nanay, ya que todas las librerías están con FPA.

Pero si no me equivoco ese FPA es a nivel de emulación en el kernel, ¿no?

Yo me bajé la documentación del micro el otro día y creo que para los cálculos en coma flotante se remitían al coprocesador que dices...

[hardyx]

No tendría mucho sentido que el SDK compile con FPA para que sea emulado. Lo mismo el kernel le pasa los cálculos al GTE, pero para saberlo habrá que hacer puebas de punto flotante. Pero parece que va más rápido.

< - >

Pues aún no he recibido tu MP con esa nueva recompilación más rápida, sea el emu que sea serán bienvenidos esos 3-4 frames extras :D
Asias famigo [wei]
Es el Psx4Wiz, pero aún con esa mejora de velocidad sigue siendo más lento que la versión de zodttd. Por eso no he dicho nada. Me parece que el código que uso tiene el HLE a medio implementar. HLE ejecuta funciones sin usar la bios y hace que vuele.

[Puck2099]

No tendría mucho sentido que el SDK compile con FPA para que sea emulado. Lo mismo el kernel le pasa los cálculos al GTE, pero para saberlo habrá que hacer puebas de punto flotante. Pero parece que va más rápido.

¿Está el SDK para Linux? No uso coma flotante para casi nada, pero me gustaría probar la diferencia de rendimiento respecto a los GCC que tengo (que por cierto, compilando con el 4.0.2 de la GP2X va más rápido que con el 4.1.1 de la Wiz...)

[hardyx]

Si que hay una versión para Linux del GPH SDK. Estaba en la web coreana de FunGP. Tienes un enlace en este post (http://www.gp32spain.com/foros/showthread.php?t=72170).

[Franxis]

Me suena muy raro todo lo que estais contando...

Yo no consigo compilar nada con el SDK oficial de GPH para Windows, pero el toolchain viene con un arm-linux.crosstoolconfig.txt que contiene:



AR=
BINUTILS_DIR=binutils-2.16.1
BINUTILS_EXTRA_CONFIG=
BUILD=i686-pc-cygwin
BUILD_DIR=/home/crosstool-0.43/build/arm-linux/gcc-4.0.2-glibc-2.3.6
CC=
DEJAGNU=
EXTRA_TARGET_CFLAGS=
GCC_BUILD=
GCC_CORE_DIR=gcc-4.0.2
GCC_DIR=gcc-4.0.2
GCC_EXTRA_CONFIG=--with-float=soft --with-cpu=arm926ej-s --enable-cxx-flags=-mcpu=arm926ej-s
GCC_HOST=
GCC_LANGUAGES=c,c++
GDB_DIR=gdb-6.3
GLIBC_ADDON_OPTIONS==linuxthreads,
GLIBC_DIR=glibc-2.3.6
GLIBC_EXTRA_CC_ARGS=
GLIBC_EXTRA_CONFIG=--without-fp
GLIBC_EXTRA_ENV=
JUST_DOWNLOAD=
KERNELCONFIG=/home/crosstool-0.43/arm.config
LINUX_DIR=linux-2.6.15.4
LINUX_SANITIZED_HEADER_DIR=linux-libc-headers-2.6.12.0
NO_DOWNLOAD=
PREFIX=/cross-4.0.2/gcc-4.0.2-glibc-2.3.6/arm-linux
PTXDIST_DIR=
SHARED_MODE=--enable-shared
SRC_DIR=/home/crosstool-0.43/build/arm-linux/gcc-4.0.2-glibc-2.3.6
TARBALLS_DIR=/home/±â¼ú¿¬±¸¼Ò-Çö¼®ÁÖ/downloads
TARGET=arm-linux
TARGET_CFLAGS=-O
TOP_DIR=/home/crosstool-0.43
USE_SYSROOT=


Y ahi dice que --with-float=soft --without-fp

O sea que no cuadra con el hecho de que compileis con VFP, ya que parece que todas las librerias se compilaron con soft-float.

¿El SDK para Linux es diferente?

El GTE ya mire que soportaba operaciones con reales (que ocupaban 32 bit, pero que solo utilizaban 24 bit realmente), pero nadie parece haber hecho uso de esto... Además con el tema de la Pandora los gurus de gp32x.com parecen haber ignorado la WIZ...

Puck a mi los ejecutables compilados con el devkitgp2x (gcc 4.0.2) me funcionan más rápido que con cualquiera de los otros toolchain que he probado. De hecho el MAME no me arranca compilado con alguno de los otros toolchain. Y tampoco he conseguido compilar con profiling.

[WGoldman]

El GTE ya mire que soportaba operaciones con reales (que ocupaban 32 bit, pero que solo utilizaban 24 bit realmente), pero nadie parece haber hecho uso de esto... Además con el tema de la Pandora los gurus de gp32x.com parecen haber ignorado la WIZ...Respecto a esto, voy a decir lo que pienso sin tapujos: esta mas que claro que ha habido intereses economicos inpulsados por alguien para que los desarrolladores mas o menos importantes ignorasen a la Wiz. Revisando los temas escritos aqui durante los primeros meses y todo lo que he leido en GP32X, es TAN EVIDENTE, que me da mucha rabia que nadie lo haya mencionado antes.
Por poner un ejemplo simple, el emulador de PSX esta abandonado cuando se sabe que hay grandes mejoras que se podrian realizar con poco trabajo, y el programador no quiere liberar el codigo fuente. ¿Porque? Otros coders conocidos de la GP2X se han saltado la Wiz y llevan dos años esperando a la Pandora. ¿En cabeza de quien cabe tal cosa?.
La Pandora mas que una consola para la scene, esta siendo una consola para destruir o dividir a la scene.
Ale. Ya lo he dicho y me he quedado mas tranquilo. Perdonad el offtopic.

[Rivroner]

Eso que cuentas sí que se ha dicho antes WGoldman, y no sólo en este foro y en 1 sólo hilo, hay varios hilos aquí y allí contando esto que dices:

http://www.gp32x.com/board/index.php?/topic/51820-psx-with-3d-acceleration/

Claramente Zodttd es pro Pandora, debido al sueldo que recibe claro, y no quiere mejorar ni 1 frame y ni siquiera liberar su código del PSX4All hasta que no lo saque en la Pandora algún día de a saber que año.

[Gammenon]

Pues yo no estoy muy seguro todavía, según la documentación tiene una unidad GTE que permite realizar cálculos en coma flotante, aunque no es un coprocesador unido a la CPU.

Además he recompilado un emulador con el SDK oficial, que compila con FPA activado y va algo más rápido (+3/4 fps). De hecho si le pones -msoft-float te dice que nanay, ya que todas las librerías están con FPA.

Estoy muy pez en esto... El FPA ese es Floating Point Arithmetic o algo asi? Lo que dices es que el SDK tira de coma flotante por CPU "sin mas", sin coma fija ni nada?

[Astru]

Eso que cuentas sí que se ha dicho antes WGoldman, y no sólo en este foro y en 1 sólo hilo, hay varios hilos aquí y allí contando esto que dices:

http://www.gp32x.com/board/index.php?/topic/51820-psx-with-3d-acceleration/

Claramente Zodttd es pro Pandora, debido al sueldo que recibe claro, y no quiere mejorar ni 1 frame y ni siquiera liberar su código del PSX4All hasta que no lo saque en la Pandora algún día de a saber que año.

Hay uno en gp32x que propone esto:

Why don't try to contact Schtruck from http://www.fpsece.net/ because is mobile psx emu is better than PSX4all.

No tengo ni idea de programación, pero es posible portarlo a Wiz (si el señor Schtruck cediera el codigo fuente claro)?

[Gammenon]

La Wiz tiene soporte FPA asistido por hardware si usa el emulador de Accorn, si no, usara el emulador de Linux que NO ofrece soporte hardware para operaciones aritméticas con comas flotantes.
Y como parece que si que usa el emulador que suministra Accorn, la Wiz ofrece soporte hardware para las operaciones de coma flotante. Ahora, eso si, no os emocionéis metiendo caña, que es FPA, son cálculos rápidos pensados, entre otras cosas, para juegos y aplicaciones que no buscan gran precisión.
Vamos, que no le metáis nada mas grande que un "float" o la Wiz sufrirá XD

Entonces usando float a pelo ya tiene soporte hardware?

[hardyx]

Hay uno en gp32x que propone esto:

Why don't try to contact Schtruck from http://www.fpsece.net/ because is mobile psx emu is better than PSX4all.

Ese emulador es de código cerrado y tiene una versión de pago, además posiblemente es muy dependiente del API de Windows CE.

< - >

Entonces usando float a pelo ya tiene soporte hardware?
Si compilas con el SDK oficial de GPH parece que si.

< - >

Me suena muy raro todo lo que estais contando...

....
Y ahi dice que --with-float=soft --without-fp

O sea que no cuadra con el hecho de que compileis con VFP, ya que parece que todas las librerias se compilaron con soft-float.
¿El SDK para Linux es diferente?

Solo he probado con el SDK de windows y muy pocas puebas, pero lo miraré con detenimiento.

[Franxis]

Es el Psx4Wiz, pero aún con esa mejora de velocidad sigue siendo más lento que la versión de zodttd. Por eso no he dicho nada. Me parece que el código que uso tiene el HLE a medio implementar. HLE ejecuta funciones sin usar la bios y hace que vuele.

El PSX4ALL de Zodttd es un port del PCSX. Debería de liberar el código fuente, pero en fin... El HLE que usa Zodttd seguro que lo ha cogido del PCSX-R:
http://pcsxr.codeplex.com/

De hecho este PCSX-R le da mil vueltas a PSX4ALL en temas de velocidad y compatibilidad. Habría que portar el PCSX-R a WIZ (por supuesto incluyendo en él el recompilador dinámico). Es el proyecto que siempre quiero empezar pero nunca me animo...

< - >


Solo he probado con el SDK de windows y muy pocas puebas, pero lo miraré con detenimiento.


Hardy, ¿como compilas con el SDK de Windows?. Yo cada vez que lo intento me da "Error 1" y no sé como arreglarlo. ¿Que PATHs utilizas? ¿has instalado algo adicional? ¿tienes algun makefile de ejemplo para poder ver como lo haces funcionar?

Salu2

[Rivroner]

Pues Franxis, aprovecha ahora y lánzate que ya hay un peazo bote para el concurso, igual en 3 meses que faltan ya tienes un peazo emu mejor que el actual. :)

Ya sé que esto no se hace por el money si no por el placer pero bueno, así al menos tendrías apoyo "moral" :D

[hardyx]

Bueno pues tienes razón Franxis, el SDK está generando coma flotante por software, me había liado con la librería opengles que está compilada distinta. Debe ser el compilador que optimiza mejor o el runtime, tendré que investigar más.

Ya había leído algo sobre que el Psx4All estaba basado en el PCSX, habrá que mirarlo a ver, aunque seguro que será un trabajo de titanes portarlo.

[nintiendo1]

El PSX4ALL de Zodttd es un port del PCSX. Debería de liberar el código fuente, pero en fin... El HLE que usa Zodttd seguro que lo ha cogido del PCSX-R:
http://pcsxr.codeplex.com/

De hecho este PCSX-R le da mil vueltas a PSX4ALL en temas de velocidad y compatibilidad. Habría que portar el PCSX-R a WIZ (por supuesto incluyendo en él el recompilador dinámico). Es el proyecto que siempre quiero empezar pero nunca me animo...

< - >


Hardy, ¿como compilas con el SDK de Windows?. Yo cada vez que lo intento me da "Error 1" y no sé como arreglarlo. ¿Que PATHs utilizas? ¿has instalado algo adicional? ¿tienes algun makefile de ejemplo para poder ver como lo haces funcionar?

Salu2

Un emulador de PSX hecho por Franxis tiene que ser impresionante. Capaz es de correr juegos de PS2 xD

[Franxis]

Bueno pues tienes razón Franxis, el SDK está generando coma flotante por software, me había liado con la librería opengles que está compilada distinta. Debe ser el compilador que optimiza mejor o el runtime, tendré que investigar más.

Ya había leído algo sobre que el Psx4All estaba basado en el PCSX, tendré que mirarlo a ver, aunque seguro que será un trabajo de titanes portarlo.

El SDK DE GPH utiliza GCC 4.0.2 que a mi es el que me genera ejecutables más rápidos (es precisamente el mismo GCC que tiene el DEVKITGP2X). Yo compilo el MAME con DEVKITGP2X.

PSX4ALL es practicamente igual que PCSX. No es un trabajo muy complicado integrar en PSX4ALL las mejoras de PCSX-R (de hecho Zodttd ya lo ha hecho en privado).

< - >

Pues Franxis, aprovecha ahora y lánzate que ya hay un peazo bote para el concurso, igual en 3 meses que faltan ya tienes un peazo emu mejor que el actual. :)

Ya sé que esto no se hace por el money si no por ek placer pero bueno, así al menos tendrías apoyo "moral" :D

Es precisamente lo que tenía pensado... Pero no me comprometo a nada, soy muy pero que muy perro. Hablo mucho y hago poco. A ver si me animo...

< - >
Por si a alguno le interesa:

- PCSX-Reloaded: Se pueden bajar hasta las ultimísimas modificaciones realizadas en marzo de este año (un coordinador que sube los parches que manda la gente). Tiene histórico de cambios, parches, foros, fallos conocidos, etc... Parece que esta basado en PCSX-df.
http://pcsxr.codeplex.com/
http://pcsxr.codeplex.com/SourceControl/list/changesets (histórico de cambios)
http://pcsxr.codeplex.com/SourceControl/PatchList.aspx (parches algunos pendientes por subir)

- PCSX-df: Otro proyecto con muchos avances con respecto a PCSX (aunque ultimamente anda un poco parado, pero activo hasta final del 2009 con varios desarrolladores).
Igual que el anterior proyecto también parece que tiene de todo...
http://sourceforge.net/projects/pcsx-df/
http://sourceforge.net/projects/pcsx-df/develop (progreso)
http://sourceforge.net/tracker/?group_id=204268&atid=988933 (parches algunos pendientes por subir)

- PCSX-rr: Y otro más, este parece solo un port, pero he visto correcciones bastante evidentes de cosas del PCSX. Quizas tenga algo más que ver.
http://code.google.com/p/pcsxrr/

- PCSX: También ha habido actividad en el PCSX original en el último año.
http://sourceforge.net/projects/pcsx/

Además he visto el código fuente del AdriPSX que no me sonaba haber descargado en el pasado...
http://www.zophar.net/psx/adripsxile.html

[nintiendo1]

Es precisamente lo que tenía pensado... Pero no me comprometo a nada, soy muy pero que muy perro. Hablo mucho y hago poco. A ver si me animo...

Ya nos has hypeado, ahora viviré feliz esperando de nuevo el emu de PSX :)

Saludos.

[hardyx]

Hardy, ¿como compilas con el SDK de Windows?. Yo cada vez que lo intento me da "Error 1" y no sé como arreglarlo. ¿Que PATHs utilizas? ¿has instalado algo adicional? ¿tienes algun makefile de ejemplo para poder ver como lo haces funcionar?

He copiado el directorio MinSys (un pequeño cygwin) que venía con el SDK de GP2X para compilar en línea de comandos. He añadido en el fichero msys.bat la línea: set PATH = D:\GphSdk\tools\gcc-4.0.2-glibc-2.3.6\arm-linux\bin;%PATH%. El SDK nuevo lo tengo en D:\GphSdk.

Y para compilar uso este makefile (simplificado). Espero que te sirva:


RM = rm
CC = arm-linux-gcc
CXX = arm-linux-g++
AS = arm-linux-gcc
AR = arm-linux-ar
STRIP = arm-linux-strip
INCS = D:/GphSdk/tools/gcc-4.0.2-glibc-2.3.6/arm-linux/arm-linux/sys-include
INCS += -ID:/GphSdk/include -LD:/GphSdk/lib/target
INCS += -ID:/GphSdk/DGE/include -ID:/GphSdk/DGE/include/SDL -LD:/GphSdk/DGE/lib/target
LD = arm-linux-g++
LDFLAGS= -lSDL -lz -lts -lpng

NAME = nombre_programa.gpe
PROG = $(NAME)

CFLAGS = -march=armv5te -mtune=arm926ej-s -DWIZ -I$(INCS) -msoft-float -O3 -ffast-math
CPPFLAGS = $(CFLAGS)

#all: $(PROG)

OBJS = \
main.o \
modulo.o

%.o: %.cpp
${CXX} ${CFLAGS} -c -o $@ $<

%.o: %.s
${CXX} ${CFLAGS} -c -o $@ $<

%.o: %.c
${CC} ${CFLAGS} -c -o $@ $<

all: ${OBJS}
${LD} -O3 ${CFLAGS} ${OBJS} -o ${PROG} ${LDFLAGS}
# ${STRIP} ${PROG}

clean:
$(RM) $(PROG) $(OBJS)

[Anarchy]

Es precisamente lo que tenía pensado... Pero no me comprometo a nada, soy muy pero que muy perro. Hablo mucho y hago poco. A ver si me animo...Te hago un monumento. [wei5]

[nintiendo1]

Te hago un monumento. [wei5]

Solo con lo que ha dicho Franxis, seguro que GPH ha subido un 30 % en la bolsa xDD

[Rivroner]

Venga gente, que si llegamos pronto a 2000 eurelios de nada igual a más de uno se le quita la perrería :quepalmo:

Sería genial un nuevo emu de PS que de salida fuera mejor que el que tenemos, cosa chunga pero posible, y aunque fuera igual pero con sonido bueno ya valdría la pena, y más para juegos 2D. Los cuales van a 35-40 frames a día de hoy y sin frameskip, vamos que con un frameskip que rule irían a velocidad original y al menos a 30 frames, algo genial. :)