Seulement, si le support de l'architecture SuperH est relativment "natif" pour GCC, le support des librairies et des parties spécifique aux calculatrices Casio l'est beaucoup moins. Ainsi, si il est possible de récupérer les fonctions correspondants à "fxlib.h" dans un format utilisable par GCC, la librairie C standard fournie par casio dans le SDK ne semble pas aussi simple à récupérer (voire irrécupérable
? ).
Le plus simple est je pense de "réecrire" une bibliothèque standard C.
A mon avis, il pourrait aussi être intéressant d'essayer de s'affranchir de la bibliothèque "fxlib" fournie par Casio, toujours en la réecrivant (c'est à dire simplement refaire les appels de Syscalls pour la plupart des fonctions, "fxlib" étant majoritairement basée sur les Syscalls), mais en travaillant sur certains points et avoir d'emblée une compatibilité SH4 par exemple. On "enlèverait" aussi la plupart du code propriétaire de Casio (bien qu'il reste les syscalls, mais bon...
).
Ce qui concerne "fxlib" n'est que mon point de vue étant donné qu'on peut très bien conserver le fichier de Casio, j'amorce juste une réflexion à ce niveau là ;).
Quoi qu'il en soit, ce topic est là pour permettre de réfléchir sur le projet ,c'est à dire la réimplémentation d'une bibliothèque C à peu près standard (en s'appuyant sur les syscalls déjà existants, va faloir sortir la doc
) pour fonctionner sur GCC de manière correcte, voire plus intéressante que sur le SDK de Casio (pourquoi pas implémenter des fopen(...) par exemple, là encore, simple suggestion à cogiter
).
C'est aussi pour voir si il y a des gens qui seraient intéressés pour travailler là dessus, et voir vos idées sur la manière de travailler dessus.
Je pense qu'à la longue, un dépot git (ou autre) sur gitorious ou quelque chose du même style pourrait servir, qu'en dites vous ? Enfin, le projet semble intéressant, d'autant plus qu'un GCC bien fonctionnel pour compiler des add-ins, ça serait cool ! :D.
Donc n'hésitez pas à mettre vos idées pour commencer et avancer !
).
Citer : Posté le 17/06/2014 14:13 | #
oui
Citer : Posté le 17/06/2014 14:14 | #
?Je crée un repo MonochromeLib et Mode7?
Citer : Posté le 17/06/2014 14:14 | #
Vas y, il me semble que t'as les droits
Ajouté le 17/06/2014 à 14:14 :
Au passage, on en profitera pour résoudre les bugs de Mlib
Citer : Posté le 17/06/2014 14:15 | #
Héhé, le seul truc est que le M7 dépend de ML, c'est sa seule dépendance il me semble.
Ajouté le 17/06/2014 à 14:47 :
https://gitorious.org/fx-community-libraries
Il y a déjà ML et M7
Ajouté le 17/06/2014 à 16:11 :
N'hésitez pas à passer vos identifiants pour que je vous ajoute.
Citer : Posté le 17/06/2014 16:12 | #
"LePhenixNoir".
Tu peux mettre un g1a de test pour M7 ?
Citer : Posté le 17/06/2014 16:14 | #
"LePhenixNoir".
Tu peux mettre un g1a de test pour M7 ?
Ca sera à faire.
Ajouté le 17/06/2014 à 16:15 :
Leffe, quel projet?
Citer : Posté le 17/06/2014 16:16 | #
C'est-à-dire ?
Citer : Posté le 17/06/2014 16:17 | #
J epeux pas ajouter la collaboration sur l'intégralité du projet visiblement, tu penses modifier quels projets?
Citer : Posté le 17/06/2014 16:18 | #
Ben ajoute dans chaque dépot au pire, c'est plus simple ;).
Citer : Posté le 17/06/2014 16:19 | #
Je tenterais bien quelques optimisations sur ML, si tenté que ce soit possible.
Après, j'aurai probablement mes propres projets à mener, mais je ne suis pas sûr que ça ait sa place sur ce git ?
Citer : Posté le 17/06/2014 16:21 | #
Au pire, tu fais une branche, et une fois que tu as fait des optimisaitons, tu me proposes un pull request que je puisse avoir une notif quand tu as fini.
Citer : Posté le 18/06/2014 17:03 | #
Je viens de penser à quelque chose !
Si le SDK refuse de lancer un add-in qu'il n'a pas lui-même compilé -- ce qui est probable ca ça expliquerait pourquoi on ne peux pas lancer les applications systèmes --, le fichier doit être "marqué". Et comme ça ne peut pas être dans le code, ça doit être... dans l'en-tête !
Citer : Posté le 18/06/2014 17:04 | #
Donc, il suffirait de patcher le G1A-wrapper !
Coïncidence ? Je ne pense pas.
Citer : Posté le 18/06/2014 17:04 | #
Ou alors, le SDK trace une foultitiude de fichiers en rapport avec l'addin qu'il compile et le debugger, voyant que ce n'est pas le même fichier, envoie au SDK un refus de le faire démarrer.
Citer : Posté le 18/06/2014 17:06 | #
Je ne pense pas car on peut lancer un addin en le transférant de puis la carte sd virtuelle :oops:.
Citer : Posté le 18/06/2014 17:08 | #
Alros, faut tester le transfert d'un addin GCC depuis la carte SD.
Et concerant les "addins officiels", c'est juste que Casio a bridé la machine afin d'éviter d'refiler une calto gratuite à tout le monde.
Citer : Posté le 18/06/2014 17:09 | #
Oui, mais peut-être que CASIO a bridé les add-ins système tout en bridant les autres compilos... ce serait tellement simple pour eux. Je regarde dans l'en-tête, et du coup oui, il suffirait de recompiler le g1awrapper.
Citer : Posté le 18/06/2014 17:11 | #
Ya quoi à modifier donc?
Citer : Posté le 18/06/2014 17:12 | #
Je fais des tests en me basant sur les sources du g1awrapper et d'un add-in de chaque compilo.
Laisse-moi quelques minutes d'abord, c'est des octets en pagaille.
Citer : Posté le 18/06/2014 17:13 | #
Pas tellement, si je me souviens bien, le code d el'adin commence en 0x200.
Citer : Posté le 18/06/2014 17:15 | #
C'est ça. Je te laisse constater les 0x200 premiers octets d'un add-in de gcc.
Ajouté le 18/06/2014 à 17:16 :
Non, il n'y a pas un checksum ?
Ajouté le 18/06/2014 à 17:19 :
Putain, j'ai eu une "Copy protection ERROR".
Ajouté le 18/06/2014 à 17:22 :
Sinon, "Data ERROR" si je copie entièrement le header depuis un add-in du SDK, donc je me demande s'il n'y a pas un checksum...