OVERLAYS : est-ce accessible avec LCC65

Bonjour,

J'ai enfin testé la configuration de base (extrait du mag d'été) de zodiac et de michel b alias kiwilevrai.
L'editeur est sympa et la possibilité de générer le tap en direct est super pratique. Bravo pour l'intégration.

En installant, j'étais persuadé d'installer cc65 et je viens de découvrir et comprendre qu'il y a 3 compilateurs c pour 6502 : osdk, cc65 et lcc65. Ce dernier me parait etre le plus exotique : OSDK regne sur l'Oric depuis quelque temps avec les développements du "groupe defence-force", CC65 semble lui tres utilisé dans la communauté C64 et Apple 2.

Usuellement, les programmes peuvent avoir la structure suivante, et je pars du principe que le soft est sur disk :
+---------------------------------+
: Pages 0....4 : Oric :
+---------------------------------+
: Programme C principal :
: ou assembleur :
! avec ses variables :
+---------------------------------+
: Zones diverses de la mémoire :
: utilisées ou non avec des datas :
: chargés depuis la mémoire de :
: masse :
+---------------------------------+
: zone ecran, caracteres ... :
+---------------------------------+
: rom / overlay disk :
+---------------------------------+
Dans ce cas, lors de la compilation, le soft en C (avec ou sans assembleur connait toutes les adresses, les labels. Pas de soucis.

Je voudrais faire un "petit" développement et je voudrais savoir si LCC65 est capable de cette configuration que j'ai cru comprendre accessible avec CC65 :
+---------------------------------+
: Pages 0....4 : Oric :
+---------------------------------+
: Programme C principal :
! avec ses variables globales :
: et chargeant les segments :
: nécessaires :
+---------------------------------++---------------------------------++---------------------------------+
: Segment C ou Assembleur (1) :: Segment C ou Assembleur (2) :: Segment C ou Assembleur (3) :
: chargé en fonction de l'appel :: chargé en fonction de l'appel :: chargé en fonction de l'appel :
: du programme principal :: du programme principal :: du programme principal :
: et utilisant les var. globales :: et utilisant les var. globales :: et utilisant les var. globales :
: et ses variables propres :: et ses variables propres :: et ses variables propres :
+---------------------------------++---------------------------------++---------------------------------+
: Zones diverses de la mémoire :
: utilisées ou non avec des datas :
: chargés depuis la mémoire de :
: masse :
+---------------------------------+
: zone ecran, caracteres ... :
+---------------------------------+
: rom / overlay disk :
+---------------------------------+

L'explication pour CC65 est à l'adresse : http://www.paytonbyrd.com/BlogEngine.Web/post/2012/01/22/The-Random-Rants-Version-30.aspx
Bien sur, le bloc "segment" secondaire également appelé overlays peut etre chargé à une autre adresse par exemple dans la mémoire overlay de l'oric   

Cela suppose également que le portage de LCC65 integre les fonctions de gestion de la disquette.
Merci d'avance, Didier

Bonjour à tous,

@didierv: Excuse moi pour le retard à te répondre, je n'avais pas percuté ton message.

Au sujet de l'osdk, c'est sûr qu'il y a un suivi et qu'il est très largement utilisé par la communauté oricienne et c'est normal c'est un très bon produit mais il faut savoir que lorsque je me suis intéressé au C sur Oric, le premier compilateur était LCC65 de Fabrice Frances. Alors pour me faciliter la tâche avec Euphoric, je l'ai intégré à un environnement. Et en ce qui concerne mes conversions, LCC65 m'a donné entière satisfaction, mais ce n'est pas pour cela que j'ai ignoré ODSK et CC65 sur ORIC, d'ailleurs, j'ai écris en C sur ces deux environnements pour ORIC.
A l'époque j'avais fait des tests sur la vitesse d'exécution du code entre LCC65, CC65 et OSDK avec un résultat relativement identique pour LCC65 et OSDK, donc je suis resté sur LCC65. Par contre CC65 sur ORIC était largement devancé par les deux autres. Même sur Apple II, le code produit par CC65 est relativement lent comparé aux autres compilateurs C sur Apple.

En ce qui concerne l'accès aux disquettes et aux commandes du SED:
Il me semble que dans le répertoire lib, il existe un fichier entête SEDORIC.S, mais même de toute façon on peut créer une des fonctions SED sous forme de fichiers entête à ajouter dans la librairie des fonctions.
De mémoire j'ai déjà exécuté  des commandes de SED depuis le C. Quand à l'accès aux différentes variables je ne pense pas que se soit un problème. Je prend une copie de ton mail et après les vacances j'essaierai de te concocter des exemples et répondre à tes questions dans la mesure du possible.


A bientôt

Merci pour ta proposition.
J'ai déjà testé les fonctions disquette SEDORIC avec OSDK qui beneficie d'une maintenance et d'echanges avec des coders oric hors pair.

Je voyais un interet à passer sur CC65 pour son aptitude à la segmentation et la portabilité du code avec les autres machines (dont l'apple2)
Ta remarque sur la rapidité du code généré m'inquiete (en plus du probleme d'avoir un environnement oric à jour sur CC65)

Didier

PS : Sinon, j'ai un peu testé LCC pendant mes vacances. l'éditeur intégré est super sympa.
(mais depuis que j'ai repris le travail, j'ai de nouveau du mal à faire quelque chose)   

Zodiac a écrit:Au sujet de l'osdk (...) il faut savoir que lorsque je me suis intéressé au C sur Oric, le premier compilateur était LCC65 de Fabrice Frances. (...)
A l'époque j'avais fait des tests sur la vitesse d'exécution du code entre LCC65, CC65 et OSDK avec un résultat relativement identique pour LCC65 et OSDK, donc je suis resté sur LCC65.

C'est un peu normal que les résultats entre LCC65 et OSDK soient "relativement identiques" vu que le OSDK est aussi basé sur le compilateur originel de Fabrice

http://www.osdk.org/index.php?page=documentation&subpage=copyright
http://miniserve.defence-force.org/svn/public/pc/tools/osdk/main/compiler/sources/

Pour ce qui est de la gestion overlay, ca n'a rien a voir avec le compilo utilisé, c'est juste une question de:
- poker la bonne valeur en page 3 pour activer ou pas la RAM OVERLAY
- avoir les bonnes addresses en haut de mémoire pour pointer sur une routine d'interruption valide (sinon a la première IRQ ca va partir n'importe ou)

Dbug a écrit:

Zodiac a écrit:Au sujet de l'osdk (...) il faut savoir que lorsque je me suis intéressé au C sur Oric, le premier compilateur était LCC65 de Fabrice Frances. (...)
A l'époque j'avais fait des tests sur la vitesse d'exécution du code entre LCC65, CC65 et OSDK avec un résultat relativement identique pour LCC65 et OSDK, donc je suis resté sur LCC65.

C'est un peu normal que les résultats entre LCC65 et OSDK soient "relativement identiques" vu que le OSDK est aussi basé sur le compilateur originel de Fabrice

http://www.osdk.org/index.php?page=documentation&subpage=copyright
http://miniserve.defence-force.org/svn/public/pc/tools/osdk/main/compiler/sources/

Pour ce qui est de la gestion overlay, ca n'a rien a voir avec le compilo utilisé, c'est juste une question de:
- poker la bonne valeur en page 3 pour activer ou pas la RAM OVERLAY
- avoir les bonnes addresses en haut de mémoire pour pointer sur une routine d'interruption valide (sinon a la première IRQ ca va partir n'importe ou)

Concernant la ram overlay, dans cc65, il existe le concept de "em" qui est dans certaines "targets" de cc65. Ce n'est pas codé ni dans la partie atmos, ni dans la partie telestrat. Cela pourrait se faire

+