cc65 compilation

Je souhaite générer un executable (tape) à partir d'un petit programme "hello world":

Code:

cl65 -O -t atmos hello2.c  -o hello2.tap

Déjà ça génère un gros fichier j'ai l'impression pour un "hello world":

Code:

16/01/2017  23:25             2 476 hello2.tap
               1 fichier(s)            2 476 octets

Mais j'ai le message suivant sous oricutron 1.2:

Code:

This tape image seems invalid (header indicates larger than tape image )

help :|

Tu as quelle version de cc65?

j'ai installé le package cc65-2.13.3-1.exe  trouvé sur http://cc65.atarinet.com/

assinie a écrit:Tu as quelle version de cc65?

C'est une ancienne version et il y a un problème dans la librairie atmos, plus précisément dans le fichier crt0.s.
L'adresse de fin du programme est incorrecte et quand oricutron calcule la taille du programme, il trouve une valeur supérieure à la taille du fichier généré.

Il y a eu pas mal de modification depuis et le fichier .tap n'est plus généré de la même façon (il y a même un bout de programme BASIC au début qui fait un CALL vers l'adresse de démarrage du programme si j'ai bien tout suivi).

Sur cette page il y a un lien pour charger une archive avec les binaires Windows de la version en cours de développement.
Atention, il s'agit d'un fichier .zip contenant toute l'arborescence et non un programme d'installation.

Je vais récupérer la dernière version des sources de cc65 et faire un test sur mon PC, par contre je ne suis pas sous Windows.

J'en profiterai aussi pour vérifier les source d'Oricutron parce que chez moi il n'indique pas d'erreur mais le CLOAD ne rend pas la main. Je pense que ce test a du être supprimer à un moment.

Merci Assinie!! c'est bon ça fonctionne, même si le tap est toujours volumineux (2,47ko)
Il y a effectivement un call dans le fichier Tape. Mais ça n'a pas l'air super stable, parfois le run fait planter l'Oric...

Code:


LIST

752 CALL#50D

Tu es sous linux ?

assinie a écrit:C'est une ancienne version et il y a un problème dans la librairie atmos, plus précisément dans le fichier crt0.s.
L'adresse de fin du programme est incorrecte et quand oricutron calcule la taille du programme, il trouve une valeur supérieure à la taille du fichier généré.

Il y a eu pas mal de modification depuis et le fichier .tap n'est plus généré de la même façon (il y a même un bout de programme BASIC au début qui fait un CALL vers l'adresse de démarrage du programme si j'ai bien tout suivi).

Sur cette page il y a un lien pour charger une archive avec les binaires Windows de la version en cours de développement.
Atention, il s'agit d'un fichier .zip contenant toute l'arborescence et non un programme d'installation.

Je vais récupérer la dernière version des sources de cc65 et faire un test sur mon PC, par contre je ne suis pas sous Windows.

J'en profiterai aussi pour vérifier les source d'Oricutron parce que chez moi il n'indique pas d'erreur mais le CLOAD ne rend pas la main. Je pense que ce test a du être supprimer à un moment.

Bonsoir tout le monde,

J'ai relancé mon CC65 (en mode cmd). C'est la version 2.15 que j'avais téléchargé l'été dernier.

Sur mon code :

Code:

#include <stdio.h>
// --------------------------------------------------------------
// Variables et fonctions en mode text ROUT_TEXT.S
int main(void)
{
   printf("Hello, World\n");  
   return 0;
}


Je n'ai pas de soucis, le code est exécuté. Le seul défaut est le passage au debugger à la fin du programme.
Sans doute ma sortie n'est elle pas propre.

Voila c'était ma première étape l'été dernier.
J'avais prévu de refaire un article avec les passages de parametres mais je n'avais pas eu trop de le temps de le réaliser. En attendant, ci-dessous ma routine avec appel d'assembleur et la ligne de génération du tap.

Le code C :

Code:

#include <stdio.h>
// --------------------------------------------------------------
// Variables et fonctions en mode text ROUT_TEXT.S

extern void ColorText();                  
int main(void)
{
//   __asm__ ("brk");
   ColorText();
     printf("Hello, World\n"); 
     return 0;
}


et le source assembleur :

Code:

;
; -------------------------------------------------------------------
; This is a simple display module
; called by the C part of the program
; We define the adress of the TEXT screen.

    .export _ColorText
_ColorText:
   lda   #$12               ; color vert
   sta $BB80
   lda #$11               ; color rouge
   sta $BB82
   lda #$13
   sta $bb84
   rts


le Link :
cl65 -O -t atmos hellotest.s helloric.c -o helloword.tap

.. je sais, cela ne sert à rien mais au moins le fonctionnement est vite vu.
faut que je me remette au passage de parametres

La taille du programme peut en effet suprendre surtout si tu regardes le source assembleur généré qui ne contient que 5 instructions
C'est tout à fait normal, un simple printf() nécessite pas mal de code même si on ne s'en sert que pour afficher une simple chaine de caractères.

Tu peux toujours commencer un programme en C et ensuite repartir du code assembleur généré par cc65 et l'optimiser pour finir par n'avoir qu'un programme assembleur sans le runtime C donc potentiellement moins volumineux et plus rapide.

Oui, je suis sous Linux  

Merci Didier pour tes exemples et Assinie pour tes remarques.

J'ai l'impression que le code généré par lcc65 est moins volumineux ...

Si quelqu'un sait comment paramétrer cc65 si visual studio je suis preneur

j'aimerais avoir un bon IDE de dev ou pouvoir paramétrer un editeur genre sublime text..

Assinie si tu as un environnement complet de développement sous linux ça m’intéresse !

Si tu es sous Vmware serait-il possible m'envoyer ta VM complète  :o  ?

Je n'ai pas constaté de plantage particulier ni de retour par le debugger d'Oricutron mais je n'ai probablement pas la même version d'Oricutron parce que je le recompile directement depuis le dépot github.

Je n'ai pas bien compris pourquoi ils ont ajouté la ligne de BASIC, peut-être pour pouvoir retourner plus facilement au BASIC à la fin du programme...

Au fait le numéro de la ligne BASIC correspond à la version de cc65, si si...

752 décimal égale 02 F0 en héxa (pour la version 2.15, à un décalage prés)

@gweg:
Je n'ai pas vraiment d'environnement particulier, juste mon PC avec une distribution Linux.
Pour l'édition j'utilise vi ou pluma qui est un fork pour MATE de gedit.
Pour le reste, quelques scripts maison.

Cela étant, je peux regarder sublime et/ou kate et voir comment on peut les paramétrer.
Je pense qu'il existe une version Windows de submime .
Ensuite, en fonction du résultat, je peux fournir le paramétrage à faire ou créer une petite VM utilisable avec VirtualBox qui fonctionne sous Linux et Windows et peut être importée avec VMware.

Je te tiens au courant des résultats.

Merci

Oui ça serait super d'avoir une VM linux de dev qu'on pourrait se copier...

Vi c'est puissant mais j'ai du mal sans la souris.... ça date un peu :-/ lol

assinie a écrit:@gweg:
Je n'ai pas vraiment d'environnement particulier, juste mon PC avec une distribution Linux.
Pour l'édition j'utilise vi ou pluma qui est un fork pour MATE de gedit.
Pour le reste, quelques scripts maison.

Cela étant, je peux regarder sublime et/ou kate et voir comment on peut les paramétrer.
Je pense qu'il existe une version Windows de submime .
Ensuite, en fonction du résultat, je peux fournir le paramétrage à faire ou créer une petite VM utilisable avec VirtualBox qui fonctionne sous Linux et Windows et peut être importée avec VMware.

Je te tiens au courant des résultats.

J'ai installé Sublime Text sur mon et PC et j'ai bricolé rapidement un fichier pour la coloration syntaxique du BASIC de l'Oric; pour  l'assembleur 6502 j'en ai trouvé un sur le net qu'il faudra peut-être modifier un peu.

Depuis Sublime Text, j'arrive à taper un programme BASIC, générer un fichier .tap et lancer Oricutron avec chargement automatique de ce fichier  
Je pense que faire la même chose avec un programme C ou Assembleur ne devrait pas poser de problèmes particuliers

Pour le moment, j'utilise mes propres outils et je n'ai pas utilisé de fichier Makefile, mais ce n'est pas forcément une bonne idée...

Reste également à voir si il vaut meiux avoir une VM pré-configurée avec une distribution Linux à déterminer, ou essayer de faire une une procédure d'installation pour Linux et une pour Windows.

Tiens, j'ai trouvé pourquoi mes tap compilés avec cc65 ne revenaient pas au basic.
Tout est dans le fichier cfg et il faut virer les 2 lignes permettant l'inclusion du segment bashdr (voir .s dans les librairies sources). En effet, ce fichier ajoutait une ligne basic.
Autant dire que si l'adresse de chargement changeait, le plantage etait assuré avec des lignes de programmes 6502 plutot étranges.

En résumer, pour maitriser son fichier crée, on a interet à ce que le fichier cfg soit nickel et bien adapté à la compilation recherchée.

Pour les amateurs de cc65, sait on choisir un fichier cfg lors de la compilation / link ?

Attached are my cfg files.
atmosa.cfg - for pure assembler projects
atmosc.cfg - for mixed C+ASM projects
With these CFG files the result is plain binary (no header, no basic stub).
I add the tap header with the tool from OSDK than I use tap2dsk .

Thanks a lot iss, up to date, i've only deleted the bashdr include (beurk) but it's a good solution to compile, link and use OSDK tools to finish the job.

You've made 2 cfg files. that means that you can compile -t atmosa and -t atmosc ?
Is there's another thing to change to define different targets ?

In the attached file you can find:
1. testa (asm + tap) = plain assembler example
2. testc (c + tap) = C example
3. dsk = it contains TESTA and TESTC (no auto run, after booting type manualy which program to run)

On your question:
To build assembler example I use:

Code:

cc65 -E -I/cc65/asminc -I/cc65/include --standard cc65 -DSTART_ADDRESS=1536 testa.asm -o testa.i
ca65 -I/cc65/asminc -DASSEMBLER -DSTART_ADDRESS=1536 -D__CC65__  -v -U -t atmos -l testa.lst testa.i
ld65 -o testa -C /cc65/atmosa.cfg testa.o -L/cc65/lib /cc65/lib/atmos.lib -D__START_ADDRESS__=1536

/osdk/bin/header testa testa.tap 1536

To build C example:

Code:

cc65 -I/cc65/include -D__ATMOS__ --standard cc65 -DSTART_ADDRESS=1536 -Oirs --codesize 500 -T -g -t atmos testc.c -o testc.i
ca65 testc.i
ld65 -o testc -C /cc65/atmosc.cfg testc.o -L/cc65/lib /cc65/lib/atmos.lib -D__START_ADDRESS__=1536

/osdk/bin/header testc testc.tap 1536

And the final DSK:

Code:

/osdk/bin/tap2dsk2 -n"TESTS" testa.tap testc.tap tests.dsk
/osdk/bin/dsktool tests.dsk

Importamt options for Linker are:
-D__START_ADDRESS__=1536 => this sets program start addres 1536 (or $600)
-C /cc65/atmosa.cfg => for assembler use atmosa.cfg
-C /cc65/atmosc.cfg => for C use atmosc.cfg

I hope this helps .