Empezando con SDCC

[ronaldo]

Ah, se me olvidaba la parte de usar símbolos en C. Los símbolos globales, para poder usarlos en C tienes que usar la convención de variables globales ANSI. En ANSI C, los símbolos internos de las variables globales deben llevar un subrayado delante. Así pues, imagina que tienes una variable en tu librería que quieres que sea accesible desde C. Tienes que definir la variable como global, y el símbolo (el identificador) tiene que tener un subrayado delante:

Código: Seleccionar todo

_mapa_de_tiles:: .ds 40*50

En este fichero ensamblador se define un array de tiles, de tamaño 40x50. Ahora, para poder acceder a él desde C, debemos declararlo donde vaya a ser usado, para que el compilador sepa que este símbolo existe y de qué tipo es:

Código: Seleccionar todo

extern unsigned char mapa_de_tiles[40*50];

Y el linker ya se encargará de que enlazar ambos símbolos, permitiéndonos acceder a la variable definida en ensamblador desde C. Fíjate que en C la defino sin el subrayado delante: el símbolo real lleva subrayado y C lo buscará así por ser un símbolo global. La cláusula extern le dice a C que sólo estamos declarando la existencia de un símbolo, que está ubicado en otro sitio y que no lo debe definir (reservar el espacio en memoria) porque ya existe. Es importante darle bien el tipo a C, ya que aceptará lo que le pongamos. En este caso, C entiende que hay 40*50 bytes consecutivos (unsigned chars). Si le hubieramos puesto que son unsigned ints, creería que son 40*50 valores de 16-bits y lo trataría como tal, produciendo errores en el código en C.

[Artaburu]

Perfecto, Ronaldo.
Con tus ecplocaciones estoy entendiendo cosas que hacía pero no sabía cómo funcionaban.
Además creo que me va a ayudar a dejarlo todo más limpio y sin necesidad de recompilar la librería si hay cambios de constantes.
Muchas gracias otra vez.

[ronaldo]

No hay de qué, para eso estamos .

Sigo pensando que no puedes impedir que se recompile la librería (o, al menos, la parte afectada) cuando cambias constantes. Cambiando variables, sin problema. De hecho, eso se puede hacer en tiempo de ejecución. De todas fornas, si se te ocurre algún uso interesante de las constantes, ya nos contarás .

Por cierto, al final tenemos solución para el problema original de este hilo? @na_th_an sigues ahí?

[Artaburu]

Le estoy dando vueltas a las constantes, es más complejo que meter el valor y ya está porque dependiendo de la función en el módulo, el valor de la constante está modificado por otro valor fijo y ahí da problema en la compilación. Se podría meter una definición de constante por cada valor pero va a ser un cristo.

De na_th_an no se sabe nada...
Ya dará señales.

[na_th_an]

Perdonad, tengo unos días a full y apenas me he conectado desde que hice la pregunta En cuanto pueda sigo con esto Gracias a todos.

[na_th_an]

Bueno, la verdad es que ando bastante perdido

Doy más datos: como quiero empezar un nuevo proyecto para CPC y he decidido usar SDCC con la última versión de CPCRSLIB/CPCWYZLIB me he puesto a portar un juego ya (prácticamente) terminado.

El juego está compilado con Z88DK y usa CPCRSLIB/CPCWYZLIB; compila y funciona perfectamente. Me llama mucho la atención de que el linker no encuentre main, porque main te aseguro que hay

Código: Seleccionar todo

void main (void) {

Según os leo, el tema de tilemapconf es peliagudo y diferente, y está claro que mi problema viene de ahí. Arta me ha pedido el proyecto para verlo y ya se lo he hecho llegar - pero me gustaría ver qué pasa entre bambalinas porque la idea es poder hacer mis cosuelas a partir de ahora en SDCC.

Ya te digo que ando muy perdido porque el linker se queja de que no encuentra esos tiestos, pero sin embargo aquí están definidos, al principio de tilemapconf.s (probablente mal, por supuesto ):

Código: Seleccionar todo

.globl _tiles
.globl _pantalla_juego
.globl _tiles_tocados
.globl _posiciones_pantalla
.globl _posiciones_super_buffer

.globl _posicion_inicial_area_visible
.globl _posicion_inicial_superbuffer
.globl _ancho_pantalla_bytes
.globl _alto_pantalla_bytes
.globl _ancho_pantalla_bytes_visible

.globl _tile_0

.globl mascara1
.globl mascara2

Ya os digo que algo tengo que estar haciendo MUY MAL (probablemente algún ensamblador en linea), porque el archivo .rel del módulo pincipal apenas ocupa medio Kb.

[Artaburu]

Hola

El tilemap.conf de z88dk ahora se llama tilemap.h y se compila con la librería. He probado con el tuyo añadiendo una serie de constantes y variables que faltaban y lo he compilado con cpcrslib sin problema.

El error del _main te da porque alguno de los includes no está bien definido para SDCC, el sound.h, por ejemplo. Define mal los bytes con $ y tiene que ser con #

En cuanto a la dirección de ejecución, se define en crt0_cpc.s no veo en qué dirección compila pero es un mal menor. A ver si compilamos la base que tenemos y avanzamos a partir de ahí.

[na_th_an]

Vale, te he preguntado en el mail justo lo que respondes aquí, así que ignóralo. Seguimos por aquí. Voy a ver si me dejan un rato y pruebo todo esto.

¡Gracias!

[Artaburu]

Mas cosas. Los bloques __asm .. __endasm tienen que ir dentro de una función.
Incbin no funciona con el ensamblador de SDCC. Hace un tiempo estuve mirando pero creo que sigue igual.

[na_th_an]

Vaya, pues quejarse, no se queja. Eso sí que es una lata, tener que andar convirtiendo a código e insertando a manaca. Detesto el trabajo manual :-/ Voy a tener que crear una aplicación para ello e insertar usando #include o algo que se me ocurra. No quiero estar copiando y pegando números cada vez que cambie un pixel o retoque un valor del mapa, la verdad.

Ahora mismo aún sigo sin poder compilar, más que nada porque he estado reparando todos los bloque __asm... Y ahora me surgen las dudas.

Yo usaba muchas construcciones así para tener los datos fácilmente accesibles desde las partes asm y C, o para obtener punteros a sitios específicos del binario. Por ejemplo:

Código: Seleccionar todo

extern unsigned char clevel0 [0];
extern unsigned char clevel1 [0];
__asm
_clevel0:
BINARY "level0c.exo"
_clevel1:
BINARY "level1c.exo"
__endasm;
unsigned char *clevels [] = {
clevel0, clevel1
};

¿Esto funcionaría tal cual en SDCC? (Bueno, es tontería, si tampoco puedo usar BINARY ni nada parecido para meter datos externos, da igual).

Otro problema que veo es que la función cpc_PutTile2x8 ya no existe ¿cómo la sustituyo? ¿cpc_SetTile es equivalente?

Gracias por todo.

EDITO: Va a ser que no, cpc_SetTile aparece en la sección de tilemap y yo cpc_PutTile2x8 lo estaba usando para imprimir números en el marcador, fuera del tilemap. ¿Alguna idea?

[Artaburu]

Dejame que mire lo de la función que te falta, probablemente olvidé meterla en la librería para SDCC. Cuenta con ella.

No incbin, e imagino que no binary

[ronaldo]

En SDCC no hay ninguna instrucción para introducir binarios como se haría en Z88DK. Para eso, yo utilizo un script de shell que convierte cualquier binario a un array de C para poder insertarlo cómodamente. Lo podéis ejecutar directamente en Linux y MacOSX, y en Windows bajo Cygwin.

Si queréis utilizarlo, os hace falta también la librería de funciones de shell que utiliza. Podéis poner ambos archivos en una misma carpeta y modificar esta línea en el primero:

Código: Seleccionar todo

## Bash Include files
source $(dirname $0)/lib/bash_library.sh

Por esta otra:

Código: Seleccionar todo

## Bash Include files
source bash_library.sh

Para que os lo incluya estando en la misma carpeta. Espero que os sea útil

[FloppySoftware]

Igual os sirve esta utilidad para CP/M (aunque se puede adaptar a cualquier SO, ya que incluye el código fuente):

http://www.floppysoftware.vacau.com/bintoasm.zip

La hice para mi propio uso, para poder incluir en mis proyectos en MESCC, datos desde ficheros con contenido binario como imágenes, fuentes, etc. como datos en ensamblador.

Genera un archivo de texto del tipo:

Código: Seleccionar todo

DEFB 015, 000, 009, 000, 000, 000, 000, 000
DEFB 000, 000, 000, 000, 000, 000, 000, 000
DEFB 000, 000, 000, 000, 000, 000, 000, 000
DEFB 001, 006, 063, 063, 000, 000, 010, 106
DEFB 093, 214, 255, 255, 000, 000, 170, 171
DEFB 218, 173, 255, 255, 000, 000, 170, 085
DEFB 182, 170, 255, 255, 000, 000, 170, 085
DEFB 213, 173, 255, 255, 000, 000, 170, 085
DEFB 170, 091, 255, 255, 000, 000, 171, 085

Pero vamos, que es fácilmente modificable la salida, con otro formato de código en ensamblador, o C, etc.

Y, o bien se inserta luego en el código C con un #include, o se copia / pega directamente.

Yo lo hago así.

Echadle un vistazo, igual os sirve.

[na_th_an]

Ese es el problema: al final hay que estar continuamente haciendo trabajo manual. Entre que con los años me he vuelto vago y que no tengo ni un segundo que malgastar, me gusta poder ahorrarme todos los pasos posibles. En mis proyectos para otras plataformas (principalmente Spectrum o NES) lo tengo todo montado para ejecutar un .bat y no tener que hacer nada más si quiero cambiar un trozo del mapa, un gráfico, o lo que sea. En un desarrollo normal el mapa y otros datos se cambian mil veces.

Creo que, mientras intento hacerme con SDCC y echar esto a andar, voy a currarme algún tipo de preprocesador que prepare los fuentes interpretando los INCBIN o algo por el estilo. Tengo un par de ideas y creo que nos vendría bien a todos

Por ejemplo - tener los fuentes en archivos .hp o .cp (p de "para preprocesar"). Tener un preprocesador.exe que escanée el directorio, vaya abriendo todos los .hp o .cp, encuentre lineas INCBIN, abra el binario en cuestión, genere código fuente, y escriba todo en una salida .h o .c con el mismo nombre del archivo.

Meter la ejecución de preprocesador.exe al principio de nuestro .bat y luego seguir con la compilación normalmente nos quitaría toneladas de trabajo manual.

[Artaburu]

Pues sí, yo te lo compro