Bon ben j'ai échoué :-(

J'ai essayé de définir ces constantes das le fichier cfg, dans le makefile (pour l'option -D), et il n'y a que dans le source que ça marche.

Pour ce qui est des options, j'ai essayé tout un tas de combinaisons et d'ordre qui me sont passées par la tête.

cl65 -t telestrat -c --create-dep obj/telestrat/gl65_s.d -Wa -D SCREEN_WIDTH=40 -Wa -D SCREEN_HEIGHT=26 -o obj/telestrat/gl65_s.o src/gl65_s.s
cl65.exe: Don't know what to do with 'SCREEN_WIDTH=40'

cl65 -t telestrat -c --create-dep obj/telestrat/gl65_s.d -Wa -D SCREEN_WIDTH=40 -D SCREEN_HEIGHT=26 -o obj/telestrat/gl65_s.o src/gl65_s.s
cl65.exe: Don't know what to do with 'SCREEN_WIDTH=40'

cl65 -t telestrat -c --create-dep obj/telestrat/gl65_s.d -Wa SCREEN_WIDTH=40 -Wa SCREEN_HEIGHT=26 -o obj/telestrat/gl65_s.o src/gl65_s.s
ca65: Don't know what to do with 'SCREEN_HEIGHT=26'

cl65 -t telestrat -c --create-dep obj/telestrat/gl65_s.d -Wa SCREEN_WIDTH=40 SCREEN_HEIGHT=26 -o obj/telestrat/gl65_s.o src/gl65_s.s
cl65.exe: Don't know what to do with 'SCREEN_HEIGHT=26'

De toute manière, l'idée c'était de pouvoir renseigner ces valeurs au moment du link pour pouvoir livrer gl65 sous forme de lib. Mais ça je n'y crois pas. Pour moi ces constantes sont valorisées par le préprocesseur ou l'assembleur. Ce ne sont pas des labels que le linker pourrait valoriser au moment du link.

En tout cas merci pour ton aide .. j'ai appris des choses grâce à toi.

Et merci aussi pour l'astuce qui permet de générer le fichier de symboles pour pouvoir débugguer en symbolique sur Oricutron:

C'est Jede qui m'a filé le tuyaux en me disant bien que cela venait de toi .. alors merci .. c'est cool ;-)

A vérifier, mais il est probable qu'à partir du moment où tu mets -Wa toutes les options qui suivent sont destinées à l'assembleur.

Par défaut le -D s'appliquer au pré-processeur C qui n'est pas appelé pour un programme en asssembleur.

Tu peux aussi utiliser -Wl pour des options detinées au linker et -Wc pour le compilateur

Ce qu'il faut vérifier c'est si le -Wa doit précéder chaque option pour l'assembleur ou si il reste valable jusqu'au prochain -Wc ou -Wl

Donc dans ton cas, si tu veux définir un symbole à la fois pour le C et l'assembleur, il faut le définir 2 fois.

J'ai essayé de définir les symbol grâce à un -D et cela fonctionne pour le C. Mais il me met une erreur pour l'assembleur.

$ make TARGETS=telestrat
cl65 -t telestrat -c --create-dep obj/telestrat/gl65_c.d -D SCREEN_WIDTH=40 -D SCREEN_HEIGHT=26 -o obj/telestrat/gl65_c.o src/gl65_c.c
cl65 -t telestrat -c --create-dep obj/telestrat/main.d -D SCREEN_WIDTH=40 -D SCREEN_HEIGHT=26 -o obj/telestrat/main.o src/main.c
src/main.c(271): Warning: Constant is long
cl65 -t telestrat -c --create-dep obj/telestrat/gl65_s.d -D SCREEN_WIDTH=40 -D SCREEN_HEIGHT=26 -o obj/telestrat/gl65_s.o src/gl65_s.s
src/gl65_s.s(667): Error: Range error
make: ***  Erreur 1

à la ligne 667 du fichier gl65_s.s , j'essaie d'utiliser une des constantes:

@jibe #iflused c'est pour xa, le but était de pouvoir simuler à l'assemblage l'équivalent de l'utilisation d'un fichier librairie mais au niveau du source du programme.

Du coup, à quel moment tu fais le choix de la version en C ou de celle en ASM, c'est le makefile ou dans le source du programme de test en incluant un fichier plutôt qu'un autre?

J'ai un fichier config.h dans lequel je définie, entre autre, les fonctions C ou ASM que je veux utiliser.

C'est ici.

par exemple si je veux utiliser la version ASM de la fonction zplot. Alors je définie:

et si je veux utiliser la version C de la fonction zplot. je définie:

Du coup, à quel moment tu fais le choix de la version en C ou de celle en ASM, c'est le makefile ou dans le source du programme de test en incluant un fichier plutôt qu'un autre?

asm_maroutine.s (contenant l'assembleur avec un  .proc _maroutine/.endproc)

ex :

.export _maroutine

.proc _maroutine

; bla

  rts

.endproc

et un

maroutine.c (contenant l'équivalent de ta fonction maroutine  mais en C)

Dans ton Makefile, tu vas assembler asm_maroutine.s où tu auras asm_maroutine.o et dans une autre partie tu vas compiler pour avoir un objet maroutine.o

Au link, tu as besoin de spécifier soit asm_maroutine.o soit maroutine.o mais la référence sera la même car dans les 2 fichiers tu auras le label _maroutine exporté.

Cela résoud le pb des fonctions, mais pas des buffers.

@jibe

Est-ce que tes variables comme _zbuffer, _fbuffer, doivent être obligatoirement être déclarées dans glOric ou est-ce qu'elles peuvent être déclarées dans le programme qui utilise glOric?

Tu peux tout à fait utiliser un -D en ligne de commande pour définir les valeurs de SCREEN_HEIGTH et SCREEN_WIDTH.

Je ne comprends pas ce que tu entends par

Posté par: @jibe

Je cherche un moyen de pouvoir switcher facilement d'une version à l'autre d'une fonction (du C vers l'ASM ou de l'ASM vers le C) sans avoir à mettre en commentaire / décommenté la version que je n'utilise pas.

Est-ce que tu as des fonctions qui ont le même nom mais qui sont définies en C et en ASM dans le même fichier?

Pas dans le même fichier mais oui j'ai des fonctions qui ont le même nom en C et en ASM .. Par exemple, je vais avoir une version C et une version ASM de la fonction glDrawLines()

Si je veux revoir l'algorithme de glDrawLines pour tester une autre approche, je voudrais pouvoir switcher vers la version C et prototyper l'idée en C .. et une fois que j'ai une version C de l'algo qui me donne satisfaction, je reporte sur la version assembleur et je switch sur la version  assembleur à la compilation.

C'est comme ça que j'ai fait sur OSDK .. et ça m'a vraiment aidé .. du coup je me demandais s'il était possible d'obtenir ce genre de confort dans l'environnement cc65/ca65 ..

Au pire je mettrais en commentaire les fonctions que je ne veux pas utiliser .. mais ton idée de #iflused est très intéressante .. je ne connaissais pas .. ça fonctionne avec cc65/ca65 ou avec cpp/xa65 ?

Concernant les buffers évoqués zbuffer et fbuffer, ce sont des buffers interne à gOric .. je ne sais pas si ce serait intéressant de reporter sur le programme utilisateur la responsabilité de les définir ..

Est-ce que tes variables comme _zbuffer, _fbuffer, doivent être obligatoirement être déclarées dans glOric ou est-ce qu'elles peuvent être déclarées dans le programme qui utilise glOric?

Tu peux tout à fait utiliser un -D en ligne de commande pour définir les valeurs de SCREEN_HEIGTH et SCREEN_WIDTH.

Je ne comprends pas ce que tu entends par

Posté par: @jibe

Je cherche un moyen de pouvoir switcher facilement d'une version à l'autre d'une fonction (du C vers l'ASM ou de l'ASM vers le C) sans avoir à mettre en commentaire / décommenté la version que je n'utilise pas.

Est-ce que tu as des fonctions qui ont le même nom mais qui sont définies en C et en ASM dans le même fichier?

L'astuce avec #iflused permet de n'inclure que les fonctions qui sont appelées par le programme.

Par exemple, si dans le programme il y a:

jsr fonctionxxx
jsr fonctionyyy

et dans glOric:

#iflused fonctionxxx
fonctionxxx:
        lda #$10
        ...
        rts
#endif

#iflused fonctionyyy
fonctionyyy:
       lda #$11
       ...
       rts
#endif

#iflused fonctionzzz
fonctionzzz:
       lda #$11
       ...
       rts
#endif

Lors de l'assemblage, xa ajoutera le code de fonctionxxx et fonctionyyy mais pas celui de fonctionzzz

Merci pour ta réponse

En regardant la doc de ld65, je constate qu'effectivement il y a une option -D sym=value, --define sym=value

Je ne m'attendais pas à trouver ce genre d'option au moment du link car cela relève généralement du préprocesseur. Il y a des quelques explications ici:

https://cc65.github.io/doc/ld65.html#SYMBOLS

Sur gl65, j'ai mis un fichier oric.cfg que j'ai récupéré du jeu d'échec qu'a porté ISS.

Et dans le fichier plateforme platOric.s, il est fait recours à des constantes définies dans le fichier de config.

Il me semble que c'est justement le principe qu'évoque Jede et je dois reconnaître que je ne connais pas bien ces aspects là .. j'ai repompé ce qu'a filé ISS.

Mais du coup je comprends un peu mieux maintenant comment fonctionne ce passage de paramètre au link.

Mais il reste à savoir s'il est possible d'utiliser ce genre d'astuce pour dimensionner un tableau en mémoire.

NB: je réalise que j'ai codé en dur la taille comme un gros porc ..

Mais l'idée c'est de remplacer le 1040 par SCREEN_HEIGTH*SCREEN_WIDTH en ayant ces deux valeurs définies soit par un -D au moment du link .. soit par édition du fichier .cfg

Je dois pouvoir faire l'essai moi même, je te tiendrai au courant.

Concernant la solution pour le switch entre les versions C et ASM, je ne suis pas certain de  bien comprendre.

Actuellement, ce que j'ai sur glOric que je compile avec OSDK, c'est que j'ai les deux versions C et ASM dans le code source. Et j'utilise des macro #define pour embarquer ou pas le code de la version C ou ASM.

Je cherche un moyen de pouvoir switcher facilement d'une version à l'autre d'une fonction (du C vers l'ASM ou de l'ASM vers le C) sans avoir à mettre en commentaire / décommenté la version que je n'utilise pas.

C'est pour pouvoir disposer des deux versions dans le code source, sans pour autant qu'il y ait d'erreur disant "symbol redifined"

Au lieu de mettre dans le programme principal des instructions:

#define USE_ASM_FUNCTIONxxx

et d'encadrer tes fonctions par:

#ifdef USE_ASM_FUNCTIONxxx
...
#endif

il suffit d'encadrer tes fonctions par:

#iflused functionxxx
....
#endif

ensuite tu ajoutes un include des sources glOric.

Au moment de l'assemblage, xa ajoutera automatiquement les fonctions utillisées dans ton programme

C'est ce que j'utilise avec ma librairie pour le ch376: ch376

Un exemple d'utilisation: cd

L'include de la librairie est à la fin du programme d'exemple.