Ver la versión completa : Compilando SDL4gp32 y EABI
D_Skywalk
23/05/2007, 23:07
Buenas compas, ando compilando las librerias de CHUI que usaban SDL en GP32, por aquello de actualizar un poco mi devkit...
Bueno el problema me ha venido cuando he empezado a compilar las librerias especificas de gp32...
src/x_gp32_grafik.c:22: error: invalid lvalue in assignment
La linea en concreto hace lo siguiente:
(unsigned int*) rLCDSADDR2 = (LCDBASEL<<0);
Esa variable esta definida en el include x_gp32.h:
#define rLCDSADDR2 (*(volatile unsigned *)0x14a00018)
Bueno mi arreglo por el momento ha sido:
rLCDSADDR2 = (unsigned int*) (LCDBASEL<<0);
Pero obtengo este bonito warning que no se si me está avisando de que esa asignación quizás no se va a hacer correctamente...
src/x_gp32_grafik.c:22: warning: assignment makes integer from pointer without a cast
Alguien tiene alguna sugerencia? me gustaría subir un nuevo devkit, que incluyera el SDL de gp32 actualizado :)
Un Saludo [reflotada]
Pd: otra opción es simplemente quitar el (unsigned int*), y de esta forma parece no quejarse :?
anibarro
24/05/2007, 01:41
Si haces otro tutorial como el primero pero actualizado, seria la caña :D
Respecto a lo que comentas, al casting que has hecho yo no le veo problema, seguramente "LCDBASEL" es la direccion 0x14a00018 tambien. Con que en rLCDSADDR2 dejes esa direccion ya deberia funcionar no?
Me parece haber leido que el LCD de la GP32 soportaba hasta 3 buffers "por hardware", supongo que esa sera la direccion en la que empieza el segundo
A.r.R.c.H.E.r
24/05/2007, 01:46
ums << no era para hacer desplazamientos de bit? intentas desplazar 0 posiciones? ( no me hagas mucho caso que tengo mucho sueño xD )
que yo sepa ha habido un par de personas a lo largo de los ultimos meses intentando lo mismo que tu, yo uno de ellos pero sin exito.
si consigues refrescar el entorno de programacion de gp32, te pongo un piso en madrid :D :brindis:
Aiken
Salustian
24/05/2007, 10:09
(unsigned int*) rLCDSADDR2 = (LCDBASEL<<0);
Creo haber leído que el problema es que los nuevos devkitarm usan GCC 4, y es más restrictivo.
Sé que se habló de ello en otro hilo, no sé si aquí o en gp32x.com, he estado buscando pero no lo encuentro :confused:
Un saludo y espero que lo consigas, ¡ánimo!
D_Skywalk
24/05/2007, 10:10
EL SDL ya está funcionando en la blanquita con el devkitARM 20 :)
El problema está siendo el SDL_mixer, que parece no chutar bien xD
Luego lo probaré con más detalle pero todas mis demos gráficas funcionan perfectamente :?
Probaré esta tarde con más tranquilidad a ver si doy con el fallo ^^_
Por cierto, al final lo dejé así que no se quejaba:
rLCDSADDR2 = (LCDBASEL<<0);
Un Saludo!
Salustian
24/05/2007, 10:12
Enhorabuena tío, :brindis:
Por cierto, ¿has dormido esta noche? :D
D_Skywalk
24/05/2007, 10:25
Enhorabuena tío, :brindis:
Por cierto, ¿has dormido esta noche? :D
:D
Pues con la tontería y el encabezonamiento me he acostado a las 4, y bueno a las 8am ha sonado el put-frgfrggg despertador xDD
Estoy pensando que el problema del SDL_mixer sea por que la parte de audio necesitaba las cabeceras del devkit oficial de Gph, luego miraré si por ahí está el fallo :?
Un Saludo :lovegps:
anibarro
24/05/2007, 10:25
Muuuchas gracias, que crack! :O ¿Se puede programar en C++ con el devkit que estas montando o habra que esperar? :P
kidchaos2k5
24/05/2007, 12:09
Hola!
Me alegra mucho saber de la noticia. Por el momento estoy dedicado a un proyecto de la Dreamcast, pero todavía no me he rendido con la GP32!!!
Por si alguien no lo sabia, hace unos meses conseguí portar parte del beat2X a la GP32 (con un FPS bastante bajo y el soporte de SDL sobre ogg sonaba como una caca), pero el principal problema para mi se resume en un palabra: devkitpro, por varias razones:
1) Las clases STL no funcionan correctamente, no se si cuando se portó las SDL iban correctamente, pero a mi nunca me llegaron a funcionar.
2) El debug: Podría debugar el código con el cable USB, en las versiones elf con GDB, pero para EABI, había que modificar el código del GDB stub y ni idea, vamos...
3) Las "actualizaciones": Cada vez que había una, aparecian extraños problemas de compilación que tenía que hablar con la gente del DevkitARM y siempre habian pasado por alto el "arreglillo" en la GP...
4) Personalmente (igual me equivoco), las SDL me parecieron un poco lentas para la GP, no se si porque la consola tampoco era tan rápida para soportarlo, o bien, porque soy un programador bastante malo (mas de esto seguramente) y quería centrarme mas en hacer un juego antes que en dedicarme a revisar SDK's...
Hice algunas pruebas con el SDK oficial y conseguí recompilar las SDL, pero tampoco me llegó a servir de nada... El plan que tenía era quedarme con la ultima version del dkARM con soporte elf para seguir con el proyecto adelante... espero que dentro de un tiempo pueda volver a ello...
Por cierto, por gp32x hay el código fuente para un libreria mini-mp3, intenté añadirle el soporte mp3 para las SDL's pero creo que me petaban... Por si a alguien le interesa saberlo...
Saludos,
@B^)>
D_Skywalk
24/05/2007, 12:47
Hola kidchaos :)
Bueno pues no estaría mal no repetir curro, yo al devkitARM no lo veo problemas mas que en el mixer, que seguramente el cansancio habrá hecho de las suyas ;)
Si quieres que unamos esfuerzos, dos cabezas piensan mejor que una, heheh ^_^'
Ahora estoy en el currele pero a la tarde le hecharé un ojo a todo esto, entonces dices que me olvide del devkitARM 20?
Un Saludo!
Estoy pensando que el problema del SDL_mixer sea por que la parte de audio necesitaba las cabeceras del devkit oficial de Gph, luego miraré si por ahí está el fallo :?
La ultima version de Chui, no fue que elimino todas las dependencias al devkit oficial?
Aiken
< - >
4) Personalmente (igual me equivoco), las SDL me parecieron un poco lentas para la GP, no se si porque la consola tampoco era tan rápida para soportarlo,
pues por lo que te veo hablar de librerias ogg y mp3, no me extraña que te vaya lento. La gp32 para los juegos siempre se han usado mods de musica no mp3 u ogg porque la pobre no puede con las dos cosas a la vez (musica mp3/ogg mas juego)
Aiken
< - >
EL SDL ya está funcionando en la blanquita con el devkitARM 20 :)
El problema está siendo el SDL_mixer, que parece no chutar bien xD
la ultima version que consegui que funcionara (creo que era la r14) tambien me pasaba lo mismo, al inicializar el mixer petaba la aplicacion.
Nota mental: Uhm ahora que pienso, creo esa version fue en la que Chui supuestamente quito las dependecias al devkit oficial. Lo mismo por eso no funcionaba el mixer.
Aiken
Salustian
24/05/2007, 14:10
la ultima version que consegui que funcionara (creo que era la r14) tambien me pasaba lo mismo, al inicializar el mixer petaba la aplicacion.
Nota mental: Uhm ahora que pienso, creo esa version fue en la que Chui supuestamente quito las dependecias al devkit oficial. Lo mismo por eso no funcionaba el mixer.
Aiken
Yo he probado el mixer en la última versión del devkitarm para elf, con el último SDL de Chui (sin el SDK oficial) y funcionaba perfectamente.
D_Skywalk, ¿qué versión del SDL de Chui estás compilando? Imagino que es la última, la que está programada sin el SDK oficial, ¿no?
Un saludo y muy buen trabajo.
Yo he probado el mixer en la última versión del devkitarm para elf, con el último SDL de Chui (sin el SDK oficial) y funcionaba perfectamente.
a mi creo que me daba problemas al compilar, porque parece que las libc del devkitarm estaban sin sofwareFP y las sdl de chui las habia compilado sin ello o al reves.
Si pudieras pasarnos en un Zip/Rar todo el entorno que tienes instalado para ir probando, mientras de Skaiwalk nos pasa su version mas reciente, te lo agradeceria muchisimo ;)
Aiken
kidchaos2k5
24/05/2007, 14:50
pues por lo que te veo hablar de librerias ogg y mp3, no me extraña que te vaya lento. La gp32 para los juegos siempre se han usado mods de musica no mp3 u ogg porque la pobre no puede con las dos cosas a la vez (musica mp3/ogg mas juego)
Aiken
Haciendo prubas diversas:
- La libreria GPTremor-svorbis (ogg en punto fijo) que desarrollaron svollie y djwillis (hace tres o cuatro años), pero sobre el SDK oficial, yo las recompilé a x_gp32 y creo que el player seguia funcionando bien, pero al pasarlo al SDL_mixer el frame rate bajaba un poco ... pero la musica se escuchaba con MUCHOS crujidos... DJWillis me dijo que ero un problema de signed versus unsigned (¿¿¿¿????? no se si tenía algo que ver con los buffers de sonido) A ver si busco la demo...
- La otra prueba que hice con las mini-mp3 sin SDL también era decente (creo que utilizaba un función gp2xmemcpy que usaba el mmuhack ¿?), haciendo doble buffer y pintando los fps, me iba bien, pero parece que pasaba algo con la caché, por que al rato de escucharse la musica, crujia todo unos segundos y volvia a sonar otra vez desde el principio pero acababa bien! (rarisimo!!!).
- En cuanto al tema del DKarm, comento mis impresiones: Tal y como recomienda chui en la pagina de SDL4GP32, él compila su propio toolchain cruzado para la GP (creo que en la Dreamcast hace cosas parecidas)... Recuerdo que cuando salió, yo hacía poco que había empezado con la GP y seguí el tutorial de David para preparar el entorno con el DKArm (gracias por atrasado) y no recuerdo bien porqué pero no me funcionaba bien (inexperiencia mas que nada) ... Pero como coincidió con el lanzamiento de la GP2x se notó bastante la fuga de programadores de Gp...
Por cierto, la principal razón por la que DKARM pasó a eabi, fué porque sus desarrolladores decían que hubo una "mala interpretación" del formato elf desde el principio (¿¿¿¿???? no se si lo entendí bien, pero es lo que me pareció leer en la página oficial del devkitpro) creo que ese fué el nacimiento del famoso problema de soft-float vs hard-float por el que mucha gente se daba de cabezazos con el DKArm.. otra cosa es que creo que el soporte eabi es exclusivamente para la NDS (otro cacao en el que también ando metido)... El proyecto personal en el que ando metido ahora para Dreamcast utiliza un "custom" toolchain con soporte elf que no da ningún problema...
David, me encantaría aclarar cosillas, pero no se como estaré a la tarde, quieres que te pase mi messenger y pruebas a ver si estoy luego?
Saludos,
Salustian
24/05/2007, 17:33
a mi creo que me daba problemas al compilar, porque parece que las libc del devkitarm estaban sin sofwareFP y las sdl de chui las habia compilado sin ello o al reves.
Ahora me haces dudar... pero creo que sí me funcionaban... Espero tener algún ratito esta noche en casa para comprobarlo y mañana te cuento.
Si pudieras pasarnos en un Zip/Rar todo el entorno que tienes instalado para ir probando, mientras de Skaiwalk nos pasa su version mas reciente, te lo agradeceria muchisimo ;)
Mañana traeré el entorno de casa (estoy en el curro), no tengo ningún problema en mandártelo.
Un saludo.
Mañana traeré el entorno de casa (estoy en el curro), no tengo ningún problema en mandártelo.
pues no sabes cuanto te lo agradezco, me pone de los nervios gastar el poquito tiempo libre que tengo en pelearme con el entorno en lugar de en programar jueguecillos ;)
Aiken
D_Skywalk
24/05/2007, 22:45
Bueno yo he compilado todas las SDL de Chui de 0, no se si hay algún problema (que lo normal es que lo haya) entre la versión antigua (elf) y la nueva (eabi).
Yo también tengo intención de hacer alguna chorradilla para NDS es una de las razones de emperrarme un poco con esta nueva versión, pero vamos que si me da muchos quebraderos de cabeza con la GP, uso la r18 para GP32 y la r20+ para la nintendo y chutando xD
He probado ya varios cambios con el SDL_mixer y todo acaba igual, petando. Estoy por mirar si el SDL audio normal funciona dandole un WAV, por que soy capaz de arrastrar el problema desde ahí ;)
Voy a ir mirando esto y luego sus cuento ^^_
Un Saludo y si quereis subo el diff de lo que llevo hecho con el SDL de chui, pero vamos lo suyo sería esperar a ver si funciona todo :?
< - >
Hecho, ya tengo un ejemplo funcinando con SDL_mixer :)
Un Saludo!
< - >
He encontrado varios problemas, por ahora:
- SDL_mixer y SDL_image se pelean cuando están juntos :?
- SDL_Delay() pausa la consola indefinidamente :?
- SDL_mixer solo funciona perfecto.
- SDL_image solo... estoy en ello xD
- Un simple binario de ejemplo con todas las librerias (mixer, gfx, image) ocupa 2MB, se me antoja demasiado grande :? (sin usar strip y con optimizacion -O3).
Un Saludo :)
< - >
Bueno, ya he hecho algunas cosas bien pero esto es un mareo tios...
Voy a intentar contactar con chui, por que he descubierto que fopen y demás no funcionan, por sí mismos... Yo creo que tiene algo que ver con la libreria x_gp32 que ocupa demasiado y si vemos la antigua versión incluye referencias a fopen oO_
Desde luego en el Makefile no se ve nada, acerca de como unió libc.a y libx_gp32.a
Para hacer pruebas he hecho este pequeño code, por si acaso alguna funciona, pero nada...
fp = fopen("test1.txt","w");
fclose(fp);
fp = fopen("/gpmm/test2.txt","w");
fclose(fp);
fp = fopen("gp:\\test3.txt","w");
fclose(fp);
fp = fopen("gp:\\gpmm\\test4.txt","w");
fclose(fp);
Un Saludo y mañana más ;)
kidchaos2k5
24/05/2007, 23:04
hmmm, recuerdo que me pasaba lo mismo en el beat2x...
prueba
./gpmm
...
me he dado cuenta, que en su momento lo que hice fue parchear la libreria de mirko para usar las funciones de entrada de mirko, que a saco!...
Para mirko era con dev0:\\gpmm\\ ....
@B^)>
prueba
./gpmm
me he dado cuenta, que en su momento lo que hice fue parchear la libreria de mirko para usar las funciones de entrada de mirko, que a saco!...
Para mirko era con dev0:\\gpmm\\ ....
@B^)>
muy cierto, recuerdo que las viejas con elf yo usaba rutas tipo gp:\\gpmm\\archivo.png
y las pruebas que hice con las nuevas tuve que cambiar las rutas a /gpmm/archivo.png (o algo asi)
Aiken
D_Skywalk
25/05/2007, 10:52
La cuestión es que las funciones que incorpora libx_gp32.a están llamadas asi: _close, _seek, _open. En lugar de fopen, fclose, etc... Supongo que las llamó así para que no se chocaran o algo, pero lo que no se ve por ningún lado es la libc.a modificada que fue la que sirvio para unir ambas librerías :?
¿de que forma está modificada libc.a para que al usar fopen llame al _open de la gp32?
Por lo pronto he corregido un par de cosas más de las SDL para hacerlas (esta vez si) totalmente independientes del SDK de GPH, también he corregido otros problemas que causaban las x_gp32. Sólo me queda saber como hizo la mezcla de librerías Chui, para sacar una release compatible con eabi :D
Por lo pronto mientras Chui tiene tiempo de respondernos puedo sacar un diff, con todos los cambios que llevo hechos al sdl4gp32 :)
Un Saludo, si no hay respuesta del autor lo publico esta tarde y asi probáis cosas ;)
anibarro
25/05/2007, 11:12
Estaremos esperando ;)
kidchaos2k5
25/05/2007, 11:51
David,
No estoy muy seguro, pero creo que los nombres de las funciones _open, _close, etc... YA SON las standards de la libc, es decir, la propia libreria x_gp32 ya es la misma libc, y de alguna manera ya se linka automaticamente con las funciones fopen y demás...
Cuando estuve haciendo las pruebas de portar las SDL's al SDK oficial con soporte EABI tuve el mismo problema... y chui en las primeras versiones del sdl de la GP lo que hacía era crear una nueva stdio.h donde redefinia algunas de las funciones de gestión de fcheros y ignoraba las librerias standard del compilador...
@B^)>
¿de que forma está modificada libc.a para que al usar fopen llame al _open de la gp32?
en versiones mas antiguas habia unos includes .h que hacian de wrappers para las funciones de ficheros. Vamos que basicamente redefinian las funciones fopen etc.
Aiken
D_Skywalk
25/05/2007, 12:49
Siento llevaros la contraria pero lo que hace Chui, al menos en la última versión es unir una libc.a (supuestamente modificada) con la libx_gp32.a, se ve de dos formas muy simples:
- Compilando (Con sus mismos flags) sólo libx_gp32.a se ve que ocupa 120Kb aprox. la precompilada antigua ocupa unos 800Kb aprox.
- Con la herramienta de librerías puedes ver el contenido de las funciones de la vieja libc.a y se ven tanto funciones propias de la librería como las de x_gp32, como las funciones de la tarjeta, glob, etc...
Un Saludo compadres y si, siempre podemos tirar de un wrapper, pero la solución que dió Chui es mucho más elegante, tanto que nunca me fijé que hizo esto ;)
Siento llevaros la contraria pero lo que hace Chui, al menos en la última versión es unir una libc.a (supuestamente modificada) con la libx_gp32.a, se ve de dos formas muy simples:
si yo solo he oido campanadas, aqui los que controlais sois vosotros :D ;)
Aiken
D_Skywalk
26/05/2007, 11:16
Ya está compañeros para aplicar el parche necesitaréis bajar los fuentes de Chui, que está en su web:
http://sdl-gp32.sourceforge.net/#Downloads (Source Code)
Descomprimidlos en un directorio, bajad el parche que he subido a este post y descomprimidlo también en el mismo directorio. Finalmente con hacer:
patch -p1 < ../sdl4gp32_update-v1.diff
Este parche añade:
- Parcheados los makefiles para eabi: SDL-1.2.8, x_gp32, SDL_flic, SDL_gfx, SDL_image-1.2.4, libpng-1.2.8, zlib, SFont, SDL_mixer-1.2.6
- Añade una librería no incluida: jpeglib y la parchea.
- Añade un par de ejemplos para ir testeándola :)
Problemas conocidos:
- SDL_mixer y SDL_image, dan problemas cuando se unen (por separado SDL_mixer funciona a la perfección).
- SDL_Delay parecía fallar en las primeras versiones, pero ahora parece solucionado (habrá que volver a comprobarlo).
- x_gp32, le faltan las librerías C parcheadas, por lo tanto no permite hacer directamente un simple "fopen".
Espero que Chui nos pueda ayudar y disculpad la tardanza ayer por la tarde me engancharon para celebrar "el día del friki" xD
Un Saludop :)
Pd: Por supuesto también tendréis que tener instaladas las devkitARM20, en mi entorno las tengo ubicadas en "/opt/gp32/current", podeis cambiar esta ruta para windomizarla o adaptarla a vuestro entorno, simplemente editando la variable "GPPATH" en las cabeceras de los "Makefile.gp32"
kidchaos2k5
26/05/2007, 11:44
Genial!
A ver cuando les puedo echar un vistazo... Por cierto david, lo haces todo sobre linux o trabajas con el entorno msys del devkitpro?
Probaste a abrir un fichero con la ruta .\fichero.txt o .\gpmm\fichero.txt (siempre absoluto)? estoy seguro que te debería de funcionar...
Saludos!
D_Skywalk
26/05/2007, 12:33
Pues hace ya muchos años (3, ¿4? o asi) que pasé completamente a Linux, por que no estaba de acuerdo con algunas filosofías de M$ (supongo que no habrá muchos en esa época con un WinXP original muerto de risa xD), pero vamos, que nada que no sepas a día de hoy ;)
Si miras arriba probé todas esas posibilidades y ninguna funcionó, la opción que dices no la he probado pero sigo pensando que el problema está en que nos falta la libc.a modificada :?
Un saludo, no obstante luego la pruebo y os cuento :D
Espero que Chui nos pueda ayudar y disculpad la tardanza ayer por la tarde me engancharon para celebrar "el día del friki" xD
disculpad? pero tio! si esto cada uno lo hace por hobby ;) gracias por tu curro.
Me preocupa lo de sdlmixer y el sdlimage, porque lo mas probable es que la mayoria de los proyectos usen los dos a la vez :( yo tengo mis sprites en png (uso el sdlimage) y para el sonido pues tendria que usar el sdlmixer.
Bueno al menos lo tenemos en EABI r20, gracias de nuevo tio! gracias por tu currele! :brindis:
Aiken
D_Skywalk
27/05/2007, 21:08
Bueno, esto no es una release refinitiva, al menos para mi, tenemos que intentar dejar esto mejor o sino pasarnos a r18. Por que no tiene sentido tener un Devkit que no funciona ;)
disculpad? pero tio! si esto cada uno lo hace por hobby ;) gracias por tu curro.
Vaya, no es muy normal leer estas cosas :brindis:
Sobretodo cuando por ahí veo comentarios recordando el fday a rili, hay peña verdaderamente muy lamenteibol, por suerte son los menos ;)
La cuestion era que me gusta cumplir las cosas que digo, al menos en la medida de lo posible, y sobretodo la disculpa venia por si alguno pasó la tarde esperandome :p
Un Saludo compañero y vamos a ver si rematamos la tarea ;D
... sólo libx_gp32.a se ve que ocupa 120Kb aprox. la precompilada antigua ocupa unos 800Kb aprox. Que barbaridad, eso no puede estar bien, esa lib recuerdo que eran 4 fuentes.
Con la herramienta de librerías puedes ver el contenido de las funciones de la vieja libc.a y se ven tanto funciones propias de la librería como las de x_gp32, como las funciones de la tarjeta, glob, etc...Si, lo que intentaba era hacer un toolchain SDL sin dependencias, por tanto tiene su propia newlib (libc) usando la x_gp32 como base para acceder tanto a la SMC como al audio, por ejemplo.
Desconozco que hace exactamente los ultimos DevKits para acceder al HW de la GP32 y que newlib usará pero me temo que no será totalmente compatible con los drivers SDL que preparé en su dia.
Tambien usaba mi propio linker script para GCC/LD y mi entrada crt0.s; quizas este petando algo por ahi con GCC-4.
kidchaos2k5
28/05/2007, 11:23
Yupi! Que no muera la GP!!
Chui,... Recomendarias entonces compilar el toolchain desde cero? Aunque no lo he probado a fondo... Crees que sería mas recomendable pasar al formato eabi para la GP32 o dejarlo en el elf?
Otra cosa mas, en estos dias estoy trabajando con la Dreamcast con el entorno Kallistios-Tiki, por lo que he estado viendo, Tiki es parecido a SDL, pero no utiliza estructuras intermedias como SDL_surface y parecidos... y además tiene soporte de base para threads, jpeg/png, ogg, y opengl... En el código he visto que tiene soporte para la GP2x usando las librerias de ryleh. Me pasó por la cabeza hacer lo miso usando la libreria x_gp32, pero no lo veo muy claro si me va a coger demasiado tiempo,... No se si me liaria mucho :loco: ... Ya miraré...
Saludos,
@B^)>
Yupi! Que no muera la GP!!
Chui,... Recomendarias entonces compilar el toolchain desde cero? Aunque no lo he probado a fondo... Crees que sería mas recomendable pasar al formato eabi para la GP32 o dejarlo en el elf? Yo siempre recompilo todo, pero no tengo ni futa idea de que va el formato eabi ese.
Otra cosa mas, en estos dias estoy trabajando con la Dreamcast con el entorno Kallistios-Tiki, por lo que he estado viendo, Tiki es parecido a SDL, pero no utiliza estructuras intermedias como SDL_surface y parecidos... y además tiene soporte de base para threads, jpeg/png, ogg, y opengl... En el código he visto que tiene soporte para la GP2x usando las librerias de ryleh. Me pasó por la cabeza hacer lo miso usando la libreria x_gp32, pero no lo veo muy claro si me va a coger demasiado tiempo,... No se si me liaria mucho :loco: ... Ya miraré... El Tiki ese tiene buena pinta, pero lo cierto es que ni tan siquiera lo he probado.
kidchaos2k5
28/05/2007, 13:00
Ya me imagino, ya... Pues un par de preguntas finales, y te dejo tranquilo:
1) Como decía David, cual es el secreto que te montaste para convertir la x_gp32 en la libc?... Estoy mirando las fuentes del SDL de tu página y he visto que en el Makefile activas el flag -DDISABLE_STDIO... si eliminas el include stdio.h de la libreria standard supongo que con los includes de dirent.h, fnmatch.h y glob.h es donde haces la asociación con la x_gp32 para E/S, pero no consigo verlo en el código, está en xgp32_glob_xxx?...
2) Para el sonido, tengo varios códigos diferentes para el mixer (el que usas en SDL, y otro para una libreria independiente de mp3), se parecen bastante, pero hay dos cosas que no veo claras: No me entero de las IRQ, he visto usar el del timer y el de la interrupcion de video (no se si uno es el 8 y el otro el 14)... Te acuerdas de cual usabas? Hay alguna interrupción para saber que se ha pulsado una tecla? ...
Otra cosa... Nunca he entendido bien que es el MMU, pero tengo una función llamada gp2x_memcpy hecha en ensamblador que suspuestamente es una versión mas rápida que lo aprovecha y que se utiliza para copiar los buffers de sonidos dentro de la interrupción...
3) Por último... Se podría portar la libreria pthread a la GP32? Mas que nada por curiosidad... ya vi que en las fuentes del SDL he visto que las SDL_thread no están acabadas de portar... Pero supuestamente el ARM de la GP32 soporta todo eso de los cambios de contextos...
No se, si tienes documentación o algo de código por ahí que lo explique,... Llevo algún tiempo intentando enterarme de estas cosas, pero no acabo de cuajarlo todo, ... En fin gracias, por lo que puedas contestar...
Saludos,
@B^)>
bueno ahora que ya no me entero de casi nada :D solo me queda daros animos!! ;) y estar aqui a la espectativa de lo que salga de esta iniciativa ;) ANIMO Chicos!!
que no muera la gp32! :brindis:
Aiken
1) Como decía David, cual es el secreto que te montaste para convertir la x_gp32 en la libc?... Estoy mirando las fuentes del SDL de tu página y he visto que en el Makefile activas el flag -DDISABLE_STDIO... si eliminas el include stdio.h de la libreria standard supongo que con los includes de dirent.h, fnmatch.h y glob.h es donde haces la asociación con la x_gp32 para E/S, pero no consigo verlo en el código, está en xgp32_glob_xxx?...La libx_gp32 contiene funciones para manejar el hw de la gp32, tales como leer ficheros de la SMC; luego solo hay que llamar a esas funciones desde el syscalls.c de la libc para usarlo.
2) Para el sonido, tengo varios códigos diferentes para el mixer (el que usas en SDL, y otro para una libreria independiente de mp3), se parecen bastante, pero hay dos cosas que no veo claras: No me entero de las IRQ, he visto usar el del timer y el de la interrupcion de video (no se si uno es el 8 y el otro el 14)... Te acuerdas de cual usabas? Hay alguna interrupción para saber que se ha pulsado una tecla? ...Que yo recuerde no uso IRQs de timer sino de DMA para el sonido, osea, se produce una interrupcion al final del chorro DMA y ahi es donde le doy mas datos al sonido.
Sobre la tecla no recuerdo bien, pero creo que solo habia que leer una posicion de memoria y con programar la IRQ del timer unas 18 veces por segundo para leer este valor, deberia bastar y sobrar.
Otra cosa... Nunca he entendido bien que es el MMU, pero tengo una función llamada gp2x_memcpy hecha en ensamblador que suspuestamente es una versión mas rápida que lo aprovecha y que se utiliza para copiar los buffers de sonidos dentro de la interrupción... El MMU es la parte de la CPU que permite el paginamiento de la memoria, de manera que virtualizas la direcciones de memoria que usas.
Suele ser muy muy util para sistemas operativos, memoria virtual a disco, proteccion de memoria en entornos multitarea/multiusuario y alguna historia mas, pero esa virtualización hace que la CPU gaste un poco de tiempo en traducir las direcciones de memoria virtualizadas a direcciones reales a la RAM.
3) Por último... Se podría portar la libreria pthread a la GP32? Mas que nada por curiosidad... ya vi que en las fuentes del SDL he visto que las SDL_thread no están acabadas de portar... Pero supuestamente el ARM de la GP32 soporta todo eso de los cambios de contextos...Es mas complicado de lo que parece, tendrias que hacer un minicore que te lo permita: por ejemplo programar bien bien la irq del timer para cambiar de tarea a la salida de la interrupcion si procede.
Es programación a muy bajo nivel C+ASM y no suele ser muy facil.
No se, si tienes documentación o algo de código por ahí que lo explique,... Llevo algún tiempo intentando enterarme de estas cosas, pero no acabo de cuajarlo todo, ... Yo suelo buscar la info por inet como todo hijo de vecino, por lo general, el manual de programacion del ARM de la GP32 es bueno para enterarte de las historias a bajo nivel.
D_Skywalk
28/05/2007, 17:30
Chui, supongo que me he explicado mal (respecto a lo de los 800kb) digo que la versión antigua de la libx_gp32.a ocupa tanto por que en su interior en realidad lleva la mezcla de x_gp32 y la libc.a. Por eso expliqué antes que compilando la libx_gp32.a solamente ocupa 120kb xD
(eso si no contamos con que hiciste una versión blu+ y otra normal, que se cambian activando un parámetro del makefile.gp32)
La idea Chui, si aun recuerdas como montaste las SDL, por que ya pasó mucho...
- ¿Existen aun esos fuentes de libc.a modificados para aplicarlos de nuevo al x_gp32?
- y sino ¿como montaste la libc.a para intentar hacer ese toolchain sin dependencias? de esta forma podemos aplicar tus experiencias a una nueva versión que use eabi.
Respecto a los linkers no te preocupes que ya los tengo adaptados a gcc4, solo nos falta saber ¿como montaste esa libc?
Si nos pudieras responder a eso, o llevarnos un poco de la mano... :D
Un saludo y esperamos no estar abusando mucho de ti, compañero ;)
[UPDATE]
Añado entonces una pregunta más despues de haberte leido, ¿existe aún ese syscalls.c modificado para gp32?
En los fuentes tienes la modificacion de la newlib (libc), que no es mas que añadir a la libc.a los modulos de x_gp32: src/x_gp32_buf.o + src/x_gp32_conf.o + src/x_gp32_fat.c + src/x_gp32_io.c + src/x_gp32_lpt.o + src/x_gp32_uni.o + src/syscalls.o + src/x_gp32_dir.o + src/x_gp32_font.o + src/x_gp32_grafik.o + src/x_gp32_fnmatch.o + src/x_gp32_glob.o + src/x_gp32.o
Tan solo tienes que sustituir tu newlib que tengas compilada como libc.a al directorio fuente de la x_gp32 como libx_gp32.a y darle al make; si todo va bien tendras una nueva libx_gp32.a.
kidchaos2k5
28/05/2007, 18:42
Muchisimas gracias por tomarte el tiempo para responder a mi interrogatorio... :brindis:
Que yo recuerde no uso IRQs de timer sino de DMA para el sonido
Sip, lo he estado revisando y tienes razón, es la nISR_DMA2 (IRQ-19-0x13), pero en la libreria del player mp3 utiliza la TIMER4IRQ (IRQ-14), puede ser que por eso no me funcionaba bien!! Tengo que probarlo!
Me estoy poniedo los dientes largos... A ver si puedo sacar algo de tiempo para hacer pruebas...[reflotada]
Muchas gracias a todos!!
@B^)>
D_Skywalk
28/05/2007, 19:33
Muchisimas gracias por tus respuestas, no me había fijado en el syscalls.c ya lo tengo claro, aunque en el makefile te aseguro que no viene nada sobre la libc.a, al menos no la versión que liberaste ;)
Ya lo tengo clarísimo, esta noche le doy a la gp y a ver que pasa xD
Un Saludo!!
Ya lo tengo clarísimo, esta noche le doy a la gp y a ver que pasa xD
uy uy! que esta noche se cuece algo bueno! jeje, bueno tampoco seas burro si hay que dormir se duerme ;)
Aiken
D_Skywalk
30/05/2007, 23:14
Buff, chicos esto no tiene ni pies ni cabeza, he estado mirando la libc.a del gcc 4.1.1 y no hay rastro del syscalls.o. Al final haciendo una busqueda he encontrado el syscalls en una libreria llamada: libgloss-linux.a
Lo que he intentado es, tal y como hizo Chui en la vieja libc.a, introducir toda la libreria x_gp32 en libgloss-linux.a y que además hay dos!!
Una es thumb y otra normal, ni idea :?
La cuestión es que he vuelto a compilar todo el SDL y el fopen sigue sin tirar y SDL_Delay como en la versión anterior tampoco da señales de vida, si la usas entras en un loop infinito :(
Si alguién quiere mirar donde está el fallo de SDL_Delay, esta función depende de:
/opt/gp32/current/lib/libSDL.a(SDL_systimer.o): In function `SDL_Delay':
SDL_systimer.c:(.text+0xd8): undefined reference to `x_gp32_NOP'
SDL_systimer.c:(.text+0xf4): undefined reference to `x_gp32_timer_counter'
Y fopen es que no consigo que utilice las funciones internas de la GP, se ve fácilmente que no busca esas dependencias quitándole la librería (-lgloss-linux) del makefile, que da como resultado:
sdltest.o: In function `main':
sdltest.c:(.text+0x4b8): undefined reference to `x_gp32_SetCPUSpeed'
/opt/gp32/current/lib/libSDL.a(SDL_systimer.o): In function `SDL_GetTicks':
SDL_systimer.c:(.text+0x10): undefined reference to `x_gp32_timer_counter'
/opt/gp32/current/lib/libSDL.a(SDL_systimer.o): In function `SDL_SYS_TimerQuit':
SDL_systimer.c:(.text+0x2c): undefined reference to `x_gp32_DisableIRQ'
SDL_systimer.c:(.text+0x38): undefined reference to `x_gp32_InstallSWIIRQ'
SDL_systimer.c:(.text+0x3c): undefined reference to `x_gp32_EnableIRQ'
SDL_systimer.c:(.text+0x4c): undefined reference to `x_gp32_timer_ISR'
/opt/gp32/current/lib/libSDL.a(SDL_systimer.o): In function `SDL_SYS_TimerInit':
SDL_systimer.c:(.text+0x58): undefined reference to `x_gp32_DisableIRQ'
SDL_systimer.c:(.text+0x64): undefined reference to `x_gp32_InstallSWIIRQ'
SDL_systimer.c:(.text+0x68): undefined reference to `x_gp32_EnableIRQ'
/opt/gp32/current/lib/libSDL.a(SDL_systimer.o): In function `_sdl_gp32_TimerInt':
SDL_systimer.c:(.text+0xb0): undefined reference to `x_gp32_timer_counter'
/opt/gp32/current/lib/libSDL.a(SDL_systimer.o): In function `SDL_Delay':
SDL_systimer.c:(.text+0xd8): undefined reference to `x_gp32_NOP'
SDL_systimer.c:(.text+0xf4): undefined reference to `x_gp32_timer_counter'
/opt/gp32/current/lib/libSDL.a(SDL_dmaaudio.o): In function `sdl_gp32_dma_audio_stop':
SDL_dmaaudio.c:(.text+0x44): undefined reference to `x_gp32_IsrUninstall'
/opt/gp32/current/lib/libSDL.a(SDL_dmaaudio.o): In function `sdl_gp32_dma_audio_start':
SDL_dmaaudio.c:(.text+0xc4): undefined reference to `x_gp32_ArmEnableCPSRInterrupt'
SDL_dmaaudio.c:(.text+0x120): undefined reference to `x_gp32_dma_MMUChange'
SDL_dmaaudio.c:(.text+0x174): undefined reference to `x_gp32_GetPCLK'
SDL_dmaaudio.c:(.text+0xd60): undefined reference to `x_gp32_IsrInstall'
/opt/gp32/current/lib/libSDL.a(SDL_gp32video.o): In function `SDL_gp32_SetColors':
SDL_gp32video.c:(.text+0x5a8): undefined reference to `x_gp32_XArmDisableInterrupt'
SDL_gp32video.c:(.text+0x610): undefined reference to `x_gp32_XArmEnableInterrupt'
/opt/gp32/current/lib/libSDL.a(SDL_gp32video.o): In function `SDL_gp32_SetVideoMode':
SDL_gp32video.c:(.text+0x734): undefined reference to `x_gp32_initFramebuffer'
/opt/gp32/current/lib/libSDL.a(SDL_gp32events.o): In function `SDL_gp32_PumpEvents':
SDL_gp32events.c:(.text+0xc): undefined reference to `x_gp32_ReadKeys'
SDL_gp32events.c:(.text+0xbc): undefined reference to `x_gp32_nKeys'
/opt/gp32/current/lib/libSDL.a(SDL_sysjoystick.o): In function `SDL_SYS_JoystickUpdate':
SDL_sysjoystick.c:(.text+0x40): undefined reference to `x_gp32_ReadKeys'
SDL_sysjoystick.c:(.text+0x17c): undefined reference to `x_gp32_nKeys'
collect2: ld returned 1 exit status
Vamos que no esta preguntando por las funciones de la SMC que se curró Chui :-/
Asi que a no ser que se os ocurra algo por donde intentar arreglar el problema del fopen, doy por terminado mi intento, no me queda mucho tiempo más :(
En lo único que he avanzado es que ahora SDL_mixer y SDL_image no se pelean :rolleyes:
Un Saludo, siento las malas noticias y estaré leyendo por si se os ocurre algo :_
En lo único que he avanzado es que ahora SDL_mixer y SDL_image no se pelean :rolleyes:
que no es poco, porque como te digo en muchos proyectos se utilizaran ambas a la vez.
A ver si Chui nos echa una mano ;)
PD. Se podria intentar y seria mas facil tener la ultima version elf? o la que habia ya era la ultima? creo que la que teniamos era la r18, lo mismo habria que revisarla porque creo que a mi me daba algun problema el mixer, aunque probe tantas cosass que ya no estoy seguro :)
Aiken
D_Skywalk
31/05/2007, 01:22
PD. Se podria intentar y seria mas facil tener la ultima version elf? o la que habia ya era la ultima? creo que la que teniamos era la r18, lo mismo habria que revisarla porque creo que a mi me daba algun problema el mixer, aunque probe tantas cosass que ya no estoy seguro :)
Justo ahora mismo estaba dandole a eso, ahora te cuento :)
Un Saludo :lovegps:
< - >
Actualizo, el tema de separar syscalls.o de libc.a viene desde el gcc 3.4.4 (devkitARM r12), asi que lo he hecho es ver si en la r11 funciona todo ok.
Pues bien después de aplicar unos cuantos cambios a la base que habiamos hecho para el eabi (como quitar el float por software), todo funciona perfectamente. He compilado mi test que usa SDL_image y SDL_mixer, todo perfecto :D
La cuestión ahora es ver como aplicar estos cambios para que funcione sin problemas las SDL de Chui en los gcc > 3.4.3 :?
He estado ojeando el r18, que es el último que usa elf y en esta versión no hay libgloss-linux.a, sino que el syscalls.o está en dos librerías llamadas librdimon.a y librdpmon.a :?
Supongo que se trata de usar estas librerías en lugar de libc.a, pero no creo que nos lo ponga tan fácil ¿alguien conoce alguna opcion de gcc que te cuente todo lo que hace y enlaza? un "verbose" brutal, vamos xD
Un Saludo y bueno al menos ya tenemos r11 full working, aunque no se si eso ya lo teníais ya, la mia al menos era un r6 ;) xDD
Pd: Por cierto, como dije la primera vez, en las SDL de Chui para abrir un fichero era simplemente: "/ruta/al/fichero/como/en/linux.jpg" :D
anibarro
31/05/2007, 11:06
¿alguien conoce alguna opcion de gcc que te cuente todo lo que hace y enlaza? un "verbose" brutal, vamos xD
No se si te valdra con la opcion -M, por ejemplo "gcc -M main.c", que te muestra las dependencias...
kidchaos2k5
31/05/2007, 11:59
Lo que he intentado es, tal y como hizo Chui en la vieja libc.a, introducir toda la libreria x_gp32 en libgloss-linux.a y que además hay dos!!
/opt/gp32/current/lib/libSDL.a(SDL_systimer.o): In function `SDL_Delay':
SDL_systimer.c:(.text+0xd8): undefined reference to `x_gp32_NOP'
SDL_systimer.c:(.text+0xf4): undefined reference to `x_gp32_timer_counter'
sdltest.o: In function `main':
sdltest.c:(.text+0x4b8): undefined reference to `x_gp32_SetCPUSpeed'
/opt/gp32/current/lib/libSDL.a(SDL_systimer.o): In function `SDL_GetTicks':
SDL_systimer.c:(.text+0x10): undefined reference to `x_gp32_timer_counter'
/opt/gp32/current/lib/libSDL.a(SDL_systimer.o): In function `SDL_SYS_TimerQuit':
SDL_systimer.c:(.text+0x2c): undefined reference to `x_gp32_DisableIRQ'
SDL_systimer.c:(.text+0x38): undefined reference to `x_gp32_InstallSWIIRQ'
SDL_systimer.c:(.text+0x3c): undefined reference to `x_gp32_EnableIRQ'
SDL_systimer.c:(.text+0x4c): undefined reference to `x_gp32_timer_ISR'
Estos errores me son familiares... Un par de recomendaciones, a ver si te valen:
- Algunas de las funciones x_gp32 no están en el syscall.c sino en un fichero ensamblador x_gp32_misc.s, por tanto las tienes que pasar por el ensamblador arm-xxx-as, y añadirlas a la libreria has compilado este fichero ademas de los fuentes .c? en el makefile de chui estan estas lineas:
src/x_gp32_misc.o: src/x_gp32_misc.s
$(CC) $(CFLAGS) $(OPTFLAGS) -o src/x_gp32_misc.o -c src/x_gp32_misc.s
OBJS = $(SRCS:.c=.o) src/x_gp32_misc.o
- El orden de las librerias tambien era importante a la hora de enlazar, me parece que yo tambien pasé por eso en su momento y me dediqué a mirar las fuentes del DKARM, pero lo solucioné en base al código de chui ... En el port del beat2x yo lo hacia así: Te pongo trozos del makefile a ver si te vale:
...
(En la compilacón usaba estos flags, igual alguno está de más pero se pasaban a las SDL y a mi programa)
CFLAGS = $(INCLUDES) -DOGG_MUSIC -DENABLE_GP32 -DGP32 -DTARGET_GP32
...
(Esto es para enlazar,no hagas caso de la libreria de mirko, por cierto )
LIBS = -Llib -lx_gp32 -lmirkoSDK -lm -lc
SDLLIBS = -lSDL_image -lpng -lz -ljpeg -lSDLx_mixer -lGpTremor -lSDL
...
$(PRG).elf: $(OBJS)
$(CC) -c -o obj/crt0.o $(CRT0)
$(LD) -nostartfiles -Wall -T $(LNKSCRIPT) obj/crt0.o -o obj/$(PRG).elf $(OBJS) $(LIBS) $(SDLLIBS)
...
Vamos que no esta preguntando por las funciones de la SMC que se curró Chui :-/
Asi que a no ser que se os ocurra algo por donde intentar arreglar el problema del fopen, doy por terminado mi intento, no me queda mucho tiempo más :(
En lo único que he avanzado es que ahora SDL_mixer y SDL_image no se pelean :rolleyes:
Un Saludo, siento las malas noticias y estaré leyendo por si se os ocurre algo :_
Espero ser de ayuda, yo tampoco puedo sacar tiempo... pero a ver si suenan las campanas...
Suerte!
@B^)>
D_Skywalk
31/05/2007, 14:23
Compañero, no tengo ningún problema de librerias<->dependencias xD
Si relees con calma el mensaje explico que lo que he hecho es forzar un error de dependencias para ver si busca las funciones de la SMC en la nueva librería libgloss-linux.a, por ejemplo tendría que intentar buscar la función sm_FATUpdate(), etc...
Y como se ve forzando el error, no busca nada de eso y ahí está el problema que las funciones de fopen y demás están usando dependencias estandar y no las especiales de gp32 :?
No se si ahora se ha quedado más claro ;)
Se anibarro! :D
Ok, compañero probaré aunque me suena que eso es para hacer un Mapa de dependencias, yo lo que quiero saber es todas las librerías con las que va enlazando en cada momento. A ver si saco de donde demonios está cogiendo las funciones de ficheros :?
Un Saludo y esta tarde probaré otro ratito, de todas formas ¿os interesa o no tener la r11?
Un Saludo y esta tarde probaré otro ratito, de todas formas os interesa o no tener la r11?
la r11? esa no es la que uso chui? interesaria la ultima que exista elf en todo caso si no se puede la r20. no se si la ultima es la r19 o la r18.
Aiken
D_Skywalk
31/05/2007, 14:29
la r11? esa no es la que uso chui? interesaria la ultima que exista elf en todo caso si no se puede la r20. no se si la ultima es la r19 o la r18.
Aiken
No, chui usó alrededor de la r6... aunque me suena que usaba un toolchain de dreamcast, pero no me hagas mucho caso, la cuestión es que usaba un gcc 3.4.1 con msoft. La r11 es un gcc 3.4.3 sin msoft (flotante por hardware).
Un saludo!
[UPDATE]
$ gcc -v -Wall hello.c
Reading specs from /usr/lib/gcc-lib/i686/3.3.1/specs
Configured with: ../configure --prefix=/usr
Thread model: posix
gcc version 3.3.1
/usr/lib/gcc-lib/i686/3.3.1/cc1 -quiet -v -D__GNUC__=3
-D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=1
hello.c -quiet -dumpbase hello.c -auxbase hello -Wall
-version -o /tmp/cceCee26.s
GNU C version 3.3.1 (i686-pc-linux-gnu)
compiled by GNU C version 3.3.1 (i686-pc-linux-gnu)
GGC heuristics: --param ggc-min-expand=51
--param ggc-min-heapsize=40036
ignoring nonexistent directory "/usr/i686/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/usr/include
/usr/lib/gcc-lib/i686/3.3.1/include
/usr/include
End of search list.
as -V -Qy -o /tmp/ccQynbTm.o /tmp/cceCee26.s
GNU assembler version 2.12.90.0.1 (i386-linux)
using BFD version 2.12.90.0.1 20020307 Debian/GNU
Linux
/usr/lib/gcc-lib/i686/3.3.1/collect2
--eh-frame-hdr -m elf_i386 -dynamic-linker
/lib/ld-linux.so.2 /usr/lib/crt1.o /usr/lib/crti.o
/usr/lib/gcc-lib/i686/3.3.1/crtbegin.o
-L/usr/lib/gcc-lib/i686/3.3.1
-L/usr/lib/gcc-lib/i686/3.3.1/../../.. /tmp/ccQynbTm.o
-lgcc -lgcc_eh -lc -lgcc -lgcc_eh
/usr/lib/gcc-lib/i686/3.3.1/crtend.o
/usr/lib/crtn.o
No era tan dificil... sería la noche xD
Un Saludo ;)
No, chui usó alrededor de la r6... aunque me suena que usaba un toolchain de dreamcast, pero no me hagas mucho caso, la cuestión es que usaba un gcc 3.4.1 con msoft. La r11 es un gcc 3.4.3 sin msoft (flotante por hardware).
Un saludo!
Juraria que el la ultima version que hizo, la que era independientemente del sdk oficial, uso la r11 o eso decian los tutoriales.
En cualquier caso la elf mas moderna cual seria? se podria hacer con la elf mas moderna? Y ya puestos, que version de gcc usa la elf mas moderna?
Aiken
D_Skywalk
31/05/2007, 14:48
Juraria que el la ultima version que hizo, la que era independientemente del sdk oficial, uso la r11 o eso decian los tutoriales.
En cualquier caso la elf mas moderna cual seria? se podria hacer con la elf mas moderna? Y ya puestos, que version de gcc usa la elf mas moderna?
Aiken
Bueno hacemos un nuevo repaso:
- r6-r8 (Chui) elf 3.4.1 (libc.a con syscalls.o) (Float por software)
...
- r11 elf 3.4.3 (libc.a con syscalls.o) (Float por hardware)
- r12 elf 3.4.4 (libc.a SIN syscalls.o) (Float por hardware)
...
- r18 elf 4.1.0 (syscalls dividido en múltiples librerias)
- r19 eabi 4.1.1 ( " )
- r20 eabi 4.1.1 ( " )
Espero que ahora haya quedado claro :)
Si se abre con un editor las librerías de Chui, se ven las cabeceras del gcc 3.4.1, asi que como ves es imposible que Chui compilara su sdl4gp32 en la r11 :)
En teoría el problema al que nos enfrentamos no tiene tanto que ver con que sean unos eabi y otros elf, sino que hay que buscar la forma de saber en las versiones posteriores a la r11 (da igual que sea la 12, la 18 o la 20) como suministrarle nuestras funciones especiales de trabajo con ficheros ;)
Un Saludo :D
Pd: Eso sin contar que hay que revisar las funciones "timer" de x_gp32 que parecen contener algún error que al usar SDL_Delay las hace entrar en un bucle infinito ¿alguien se anima a revisarlas? :confused:
anibarro
31/05/2007, 15:40
Si fuese solo cuestion de animarse... xD A mi me gustaria poder ayudar en algo, pero no me entero de la mitad :S
D_Skywalk
01/06/2007, 12:14
Bueno anoche me pegué otro tute con la r20... pero sin suerte :(
Estuve peleando con la libsysbase.a, que resulta que siempre es llamada por libc.a y contiene más o menos las mismas funciones que se incluyen en el syscalls.o (que es lo que necesitamos que use el compilador).
Pues no he conseguido que el compilador acepte nuestras funciones para abrir ficheros, se ve que las que se incluyen en libc.a tienen más prioridad que las incluidas en libsysbase.a, por cual nuestras funciones de gp32 son ignoradas...
Las funciones además dentro de libc.a están renombradas ahora la función para abrir ficheros no se llama internamente "_open", sino "_open_r", asi con todas... vamos que la única cosa que se me ocurre es renombrar las funciones de syscalls.o hechas por Chui y añadirles "_r" :-?
Si tengo tiempo después lo intento y sus cuento ;)
Un Saludo ^^
Salustian
01/06/2007, 14:43
Lamento no poder ayudarte, has llegado a unos niveles en los que no puedo seguirte.
Ánimo y suerte. Estás haciendo un trabajo magnífico. :brindis:
kidchaos2k5
19/06/2007, 09:46
Un Saludo ^^
Por si a alguien le interesa:
Conseguí compilar el example2 de las x_gp32 y me funcionó correctamente, si no recuerdo mal hice lo siguiente:
1) Usar el devkitpro updater para actualizar la instalación (la verdad ya es que no lo se ni a que versión ni me importa)...
2) Volví a bajar las fuentes de las SDL y recompilé las x_gp32 arreglando los errores y añadiendo el flag de CYGWINa las defs
DEFS= -DSDL_USE_PTHREADS -DNO_SIGNAL_H -DENABLE_GP32 -DDISABLE_STDIO -DGP32 -D__INSIDE_CYGWIN__
3) En el example2: a) el fichero tada.wav no es reconocido por el SDL, pero probé otro y funcionó, b) no se porqué pero después de llamar a SDL_init se pierden los valores de los SDL_Audiospec, por lo que justo despues y antes de iniciar el audio los vuelvo a inicializar... y c) PlaySound("./gpmm/fichero.wav"); d) funciona!
Por cierto lo he subido directamente a la consola sin probarlo en el geepee así que a saber...
- Sigo teniendo mis dudas y cada vez me parece mas extraño, en el devkitpro, ya no se utiliza ld sino el gcc para el linkado, y los scripts de .ld y .x parecen bastante correctos pero al volver a probar el example2, modificando todo el makefile a la opción -specs=gp32.specs parece que incializa la LCD pero no se ve ninguna fuente por pantalla...:confused:
A alguien se le ocurrió programar con el RTEMS para la gp32? :loco: Parecia bastante completito y el port del AW funcionó bastante bien...
@B^)>
D_Skywalk
19/06/2007, 12:32
1) Usar el devkitpro updater para actualizar la instalación (la verdad ya es que no lo se ni a que versión ni me importa)...
A mi si, si pones "gcc -v" te la dice, postéala anda :)
2) Volví a bajar las fuentes de las SDL y recompilé las x_gp32 arreglando los errores y añadiendo el flag de CYGWINa las defs
DEFS= -DSDL_USE_PTHREADS -DNO_SIGNAL_H -DENABLE_GP32 -DDISABLE_STDIO -DGP32 -D__INSIDE_CYGWIN__
Ok, esos flags están bien pero sería más interesante que nombraras las libs con las que enlazas, o directamente pegar el makefile completo :)
3) En el example2: a) el fichero tada.wav no es reconocido por el SDL, pero probé otro y funcionó, b) no se porqué pero después de llamar a SDL_init se pierden los valores de los SDL_Audiospec, por lo que justo despues y antes de iniciar el audio los vuelvo a inicializar... y c) PlaySound("./gpmm/fichero.wav"); d) funciona!
¿modificaste algo del syscalls.c?¿has añadido el x_gp32 a las libs?
No entiendo como te lee un fichero sin adaptar las funciones Fopen, etc...
Un Saludo y a ver si me puedes responder a todo esto y consigo replicar tu situación para hacer un tutorial/entorno actualizado para todo el mundo ;)
kidchaos2k5
19/06/2007, 13:05
A mi si, si pones "gcc -v" te la dice, postéala anda :)
$ arm-eabi-gcc -v
Using built-in specs.
Target: arm-eabi
Configured with: ../../gcc-4.1.1/configure --enable-languages=c,c++ --with-cpu=arm7tdmi --enable-interwork --enable-multilib --with-gcc --with-gnu-ld --with-gnu-as --disable-shared --disable-threads --disable-win32-registry --disable-nls --disable-debug --disable-libmudflap --disable-libssp --target=arm-eabi --with-newlib --prefix=e:/devkitPro/devkitARM
Thread model: single
gcc version 4.1.1 (devkitARM release 20)
Ok, esos flags están bien pero sería más interesante que nombraras las libs con las que enlazas, o directamente pegar el makefile completo :)
CC = arm-eabi-gcc
AR = arm-eabi-ar
AS = arm-eabi-as
LD = arm-eabi-gcc
TARGET = libx_gp32.a
all: $(TARGET)
DEFS= -DSDL_USE_PTHREADS -DNO_SIGNAL_H -DENABLE_GP32 -DDISABLE_STDIO -DGP32 -D__INSIDE_CYGWIN__
OPTFLAGS =-mtune=arm920 -march=armv4t -marm -mno-thumb-interwork -msoft-float -ffast-math -nostdlib -fno-common -ffreestanding -fno-builtin -fno-exceptions -mstructure-size-boundary=8 -O3 -fomit-frame-pointer -fstrict-aliasing -Wall
CFLAGS=-Iinclude -Isrc $(OPTFLAGS) $(DEFS)
#CFLAGS+=-DGP32_NEW_BLU
SRCS = \
src/x_gp32_buf.c \
src/x_gp32_conf.c \
src/x_gp32_fat.c \
src/x_gp32_io.c \
src/x_gp32_lpt.c \
src/x_gp32_uni.c \
src/syscalls.c \
src/x_gp32_dir.c \
src/x_gp32_font.c \
src/x_gp32_grafik.c \
src/x_gp32_fnmatch.c \
src/x_gp32_glob.c \
src/x_gp32.c
src/x_gp32_misc.o: src/x_gp32_misc.s
$(CC) $(CFLAGS) $(OPTFLAGS) -o src/x_gp32_misc.o -c src/x_gp32_misc.s
OBJS = $(SRCS:.c=.o) src/x_gp32_misc.o
clean:
rm -f $(OBJS)
$(TARGET) : $(OBJS)
$(AR) d $(TARGET) $(OBJS) exit.o
$(AR) rcs $(TARGET) $(OBJS)
¿modificaste algo del syscalls.c?¿has añadido el x_gp32 a las libs?
No entiendo como te lee un fichero sin adaptar las funciones Fopen, etc...
El makefile del example2
############# Generic Makefile
SYSTEMLIBS= -lSDLx -lx_gp32 -lc -lgcc
SCRIPT= arm-gp32bin.x
CC = arm-eabi-gcc
AR = arm-eabi-ar
AS = arm-eabi-as
LD = arm-eabi-ld
OBJCOPY= arm-eabi-objcopy
B2FXEC = b2fxec
INCDIR= ../include
SRCDIR= ./src
OBJDIR= ./obj
INCLUDES= -I$(INCDIR) -I../../SDL-1.2.8/include -I/opt/gp32/arm-elf/include/SDL
############### Program name
PROGRAM= example
#-fshort-enums
CFLAGS = -c -march=armv4t -marm -mno-thumb-interwork -msoft-float \
-ffast-math -nostdlib -fno-common -ffreestanding \
-fno-builtin -fno-exceptions -mstructure-size-boundary=8 -O3 \
-fomit-frame-pointer -Wall -DGP32
LDFLAGS = -Map $(PROGRAM).map -nostartfiles --script $(SCRIPT) \
-L../../ \
-L../ \
-L/c/devkitPRO/devkitARM/arm-eabi/lib \
-L/c/devkitPRO/devkitARM/lib/gcc/arm-eabi/4.1.1
#-L/opt/gp32/arm-elf/lib \
#-L/opt/gp32/lib/gcc/arm-elf/3.4.1\
CFLAGS+=$(INCLUDES)
OBJS= \
example.o
############### Rules to link
DOLINK = $(LD) $(LDFLAGS) crt0x_gp32.o $(OBJS) $(SYSTEMLIBS) -o $(PROGRAM).elf
############### Rules to build program
.PHONY: all clean $(PROGRAM)
all: $(PROGRAM).fxe
$(PROGRAM).gxb: $(PROGRAM).elf
$(OBJCOPY) -v -O binary $(PROGRAM).elf $(PROGRAM).gxb
clean:
rm -f $(OBJS) crt0x_gp32.o $(PROGRAM).elf $(PROGRAM).gxb $(PROGRAM).map $(PROGRAM).fxe
$(PROGRAM).elf: crt0x_gp32.o $(OBJS)
$(DOLINK)
$(PROGRAM).fxe: $(PROGRAM).gxb
$(B2FXEC) $< $@
$(OBJDIR)/%.o: $(SRCDIR)/%.c
$(CC) $(INCLUDES) $(CFLAGS) -c $< -o $@
$(OBJDIR)/%.o: $(SRCDIR)/%.s
$(CC) $(INCLUDES) $(CFLAGS) -c $< -o $@
send: $(PROGRAM).gxb
pclink -e $(PROGRAM).gxb
creo que no usa las de las x_gp32...
ME TENGO QUE IR, LUEGO LO COMPLETO!!!!!!
D_Skywalk
19/06/2007, 16:50
Pero compañero estoy viendo que estas usando los examples de la libreria x_gp32, no?
Es normal que esas librerias funcionen (esas ya me funcionaban a mi), lo que no me funciona son los ejemplos de SDL, algo que muestre una imagen que tenga que cargar del disco, etc... :?
Un Saludo y bueno como tampoco has podido terminar el post, ya me lo aclaras aluego xD
kidchaos2k5
19/06/2007, 17:12
Hola,
Sip, tenias razón, solo probé los ejemplos de la x_gp32 que cargaban wav y mods y que utilizan SDL/SDL_mixer en cada caso...
En el caso del ejemplo2 (cargar y reproducir un wav) de esta manera funciona linkando en el makefile así:
SYSTEMLIBS= -lSDLx -lx_gp32 -lc -lgcc
y en el código:
PlaySound("./gpmm/start.wav");
carga el wav y lo reproduce pero puede ser que utilice las funciones open de las libc del DKArm (creo)
SYSTEMLIBS= -lSDLx -lx_gp32 -lm -lg -lgcc
Si hago el linkado de esta manera, tambien compila correctamente, pero me da error al cargar el wav probando de todas las maneras (dev0:\\, gp:\\, .\)
Otra cosa que tampoco veo claro es el asunto de seguir usando los arm-gp32bin.x y crt0x_gp32.s, creo que sería mejor usar el -specs=gp32.spec al linkar, pero tambien hice pruebas que no funcionaron :(...
En fin... Que sigo sin enterarme... :loco:
Saludos,
@B^)>
kidchaos2k5
21/01/2008, 21:20
Buenas a todos!
Voy a reflotar un poco este tema...
Por si a alguien le interesa: Ya he conseguido hacer funcionar la versión de CHUI con la última versión del DevkitARM!!!!!!!!!!!!! [wei5]
Aun estoy haciendo pruebas, pero espero tener algo un poco mas completito antes de avanzar mas...
Si quereis preguntar,... adelante, sin miedo!! :lovegps: (donde está mi icono favorito??)
@B^)>
Buenas a todos!
Voy a reflotar un poco este tema...
Por si a alguien le interesa: Ya he conseguido hacer funcionar la versión de CHUI con la última versión del DevkitARM!!!!!!!!!!!!! [wei5]
Aun estoy haciendo pruebas, pero espero tener algo un poco mas completito antes de avanzar mas...
Si quereis preguntar,... adelante, sin miedo!! :lovegps: (donde está mi icono favorito??)
@B^)>¡Enhorabuena! :brindis:
Yo estoy bastante interesado, ya que hace poco he actualizado mi entorno a una versión muy reciente del DevKitArm, con las librerías de GamePark actualizadas, y estoy teniendo que usar dos entornos alternativos según que use SDL o GPSDK. Me vendría muy bien unificarlo todo en uno.
kidchaos2k5
22/01/2008, 00:49
Sip, a mi tambien me daba mucho dolores de cabeza de pensar en cruzar las librerias... Finalmente solo utilizo las x_gp32 de chui que vienen en las SDL y que voy recompilando desde cero paso a paso...
Doy algunas notas pa entrar en calor[wei6]:
A la hora de compilar las x_gp32 darle esta opcion al gcc
-DREENTRANT_SYSCALLS_PROVIDED tambien utilizo -specs=gp32.specs (y NO uso crt0x_gp32.o ni los .x)
y en syscalls cambié todas las funciones _xxxx por _xxxx_r (ed _read por _read_r, _write por _write_r, etc...)...
en cualquier main que vaya a utilizr añado esto, que sacas de cualquier crt0x_gp32.s de los ejemplos de x_gp32:
void initGP()
{
asm volatile(" \n"
" bl SmcInit \n"
" mov r1, #8 \n "
" mov r2, #50 \n "
" mov r0, #208666624 \n "
" add r0, r0, #737280 \n "
" bl x_gp32_initFramebuffer \n"
" mov r0, #208666624 \n "
" add r0, r0, #737280 \n "
" bl x_gp32_SetLcdBuffer \n "
" mov r0, #208666624 \n "
" add r0, r0, #737280 \n "
" bl x_gp32_SetPrintBase \n "
" bl x_gp32_init_timer \n "
" \n"
:
:
:"r0", "r1", "r2");
}
int main (int arg_len, char ** arg_v)
{
x_gp32_SetCPUSpeed_133();
initGP();
MImain();
}
y voilà!! He probado los ejemplos de timer/audio/video/ficheros y todo funciona a la perfección.
Para abrir un fichero la ruta se indica con una barra "/", por ejemplo
Mix_LoadMUS("/ogg/sexy.ogg"); [wei2]
La otra cosa para programar comodamente es utilizar el gdbstub.cpp de mithris y el arm-eabi-insight del devkitarm. Es bastante comodo poner el marcha el programa en la consola, y debugar usando el cable USB standard!! :D
Si alguien lo prueba ya me dirá que tal!!
@B^)>
Edit: Como todavía estoy haciendo pruebas, ahora mismo todas las librerias están infladas con las opciones de gdb y sin ninguna optimización,... Así que si saco tiempo el finde o así intentaría montarlo mejor... Sorry!
Por si a alguien le interesa: Ya he conseguido hacer funcionar la versión de CHUI con la última versión del DevkitARM!!!!!!!!!!!!! [wei5]
¡Eres un fistro pecador! :lol:
Si es posible, te agradecería que subieras un fichero con todo listo para compilar que tengo mono de GP32 coding :lovegps:
< - >
La otra cosa para programar comodamente es utilizar el gdbstub.cpp de mithris y el arm-eabi-insight del devkitarm. Es bastante comodo poner el marcha el programa en la consola, y debugar usando el cable USB standard!! :D
¿Puedes explicar eso más detalladamente? ¿Es posible depurar sólo con el cable USB? ¿He perdido multitud de horas de mi vida usando printfs?
kidchaos2k5
22/01/2008, 01:45
¡Eres un fistro pecador! :lol:
¿Puedes explicar eso más detalladamente? ¿Es posible depurar sólo con el cable USB? ¿He perdido multitud de horas de mi vida usando printfs?
Jaaaaarrr!!
No te creas, las mismas que yo he perdido intentando montar todo este tinglado.
Lo del gdb está mas o menos aquí:
http://gp32.misantrop.org/Down.php
(Aunque mithris se quejó de que nadie utilizó este sistema nunca en la gp :confused:)...
Necesitas la gp con el MultiFw instalado, el gp32gdb.exe (yo tengo una versión que no recuerdo de donde la baje) y el gdbstub.cpp...
Lo que has de hacer es compilar el gdbstub, linkarlo con tu programa (compilado con la opcion -ggdb) y con algunas librerias del sdk oficial(adapatadas al EABI), y en tu programa generar una interrupción que pare el programa... Luego conectas el gp32stub en windows, abres el insight/gdb lo "targeteas" a localhost:2334 y verás como te sale todo el código y podras debugar paso por paso, ver variables y demás... Al principio es mucho montaje y la verdad que el USB se me cuelga mas de lo debido, pero cuando la cosa tira bien, poder ver en el hardware como tira todo bien es un lujo!!
En fin,... Todo esto mereceria una bonita web y algunos archivos, pero de momento es lo que hay,.. esto la hacemos por amor!! :lovegps: (me encanta)...
@B^)>
Necesitas la gp con el MultiFw instalado, el gp32gdb.exe (yo tengo una versión que no recuerdo de donde la baje) y el gdbstub.cpp...
Está en la página de Rattboi pero parece que está caída. Menos mal que desde Internet Archive (http://web.archive.org/web/20050311232702/http://info2.info.tampere.fi/~teoarsa/Rattboi/Downloads/gp32gdb/gp32gdb.html) podemos acceder :)
Como el invento funcione, me va a venir de perlas.
Muchas gracias por la info.
Hola
Sip, a mi tambien me daba mucho dolores de cabeza de pensar en cruzar las librerias... Finalmente solo utilizo las x_gp32 de chui que vienen en las SDL y que voy recompilando desde cero paso a paso...Me has animado y estoy intentando repetir las cosas que comentas...
A la hora de compilar las x_gp32 darle esta opcion al gcc
-DREENTRANT_SYSCALLS_PROVIDED tambien utilizo -specs=gp32.specs (y NO uso crt0x_gp32.o ni los .x)Duda: ¿esto lo hiciste sólo para compilar x_gp32, o lo haces para cada proyecto que hagas?
Gracias y un saludo
kounch
kidchaos2k5
24/01/2008, 22:42
Hola
Me has animado y estoy intentando repetir las cosas que comentas...
Eso, eso que se anime la escena un poco!
Duda: ¿esto lo hiciste sólo para compilar x_gp32, o lo haces para cada proyecto que hagas?
Gracias y un saludo
kounch
Mirate todo el hilo, porque este asunto ya hace tiempo que estaba pendiente...
Si no me equivoco, la opción del SYSCALLS hace que el compilador busque las funciones standard de ficheros en las propias librerias x_gp32 en vez de en las DKARM (que creo que no estan implementadas :loco:)...
En cuanto al crt0, estuve comparando las del DKARM y las de chui y las del DKARM hacen una inicialización de la memoria de la gp, pero no llama a las funciones que activan los timers, video, etc. Por eso es necesario en cada ejecutable ejecutar esa función InitGP desde tu programa antes que nada...
Resumiendo a la hora de compilar el programa hay que usar las opciones de -specs=gp32.specs (que usan el crt0 del DKARM), en vez de las -nostartfiles,linkscripts, ... Recompilar todas las librerias es un poco laborioso, pero no mucho, yo lo hago así de momento para debugar todo el código de las SDL de chui,...
Mi problema es que quiero que las SDL soporten ogg y ahora funciona pero se oye fatal y no acabo de ver si el problema es del mixer de las SDL o de las librerias GPTremor (que tiran bien pero solo con el SDK oficial)...
@B^)>
Lizardos
04/10/2008, 03:59
Hola!
Perdonad el reflote, pero estoy muy interesado en el tema. ¿Tenemos nuevas sdl? ¿Qué versión del devkitarm se puede utilizar?
Saludos
kidchaos2k5
04/10/2008, 14:57
Buenas,
Revisa el post con calma, creo que estaba todo explicado... Creo que con cualquier versión reciente del dkpro que ya incluirá el dkarm-eabi... Y en cuanto al SDL puedes utilizar la versión que hizo chui con los cambios que comentaba en este post, aunque hice algunas modificaciones en el mixer para soportar la libreria de ogg y tambien conseguí meter una versión de pthreads que encontré por la página del freesci de la gp, aunque quedó en el aire ...
Ves probando y comenta tus dudas...
Suerte!
@B^)>
Powered by vBulletin® Version 4.2.5 Copyright © 2026 vBulletin Solutions Inc. All rights reserved.