Posté le 21/06/2014 07:26
Planète Casio v4.3 © créé par Neuronix et Muelsaco 2004 - 2024 | Il y a 96 connectés | Nous contacter | Qui sommes-nous ? | Licences et remerciements
Planète Casio est un site communautaire non affilié à Casio. Toute reproduction de Planète Casio, même partielle, est interdite.
Les programmes et autres publications présentes sur Planète Casio restent la propriété de leurs auteurs et peuvent être soumis à des licences ou copyrights.
CASIO est une marque déposée par CASIO Computer Co., Ltd
Citer : Posté le 21/06/2014 08:01 | #
Il existe une version modifiée de ML compatible SH4. Il existe même deux tutos pour créer du code SH4.
-- Rendre compatibles les addins avec les SH4
Ce tutoriel modifie le syscall utilisé dans ML et ajoute un code de compatibilité.
-- Rendre compatible le SDK avec les SH4
Cette deuxième manipulation modifie le dossier "Default" des données du SDK dans "Program Files" pour que les projets créés comportent automatiquement le code de compatibilité du tutoriel précédent.
Et surtout, ce qui est le plus utilisé, c'est le SH4 Compatibility Tool (ou SH4 CT) qui prend les fichiers g1a générés par le SDK et en modifie en Assembleur le contenu. Il remplace le code des fonctions SH3 par un code qui s'adapte au processeur. Il a bien démontré son efficacité et sa fiabilité et est utilisé... partout ou presque.
Le problème c'est que jusqu'ici, il considérait à l'exécution, que si l'OS est 2.02 la calculatrice est SH4, sinon elle est SH3. Or avec la sortie de la version 2.04 de l'OS -- qui ajoute par ailleurs les vecteurs --, cela n'est plus possible (car il peut être installé sur toutes les calculatrices).
Il y aurait deux manières de corriger cela. La première serait de forcer le code SH4, en perdant la compatibilité SH3, ce qui nous mènerait à deux addins compilés par programme. Là n'est pas le problème, il s'agit des échanges réalisés directement entres deux calculatrices qui pourraient foirer une fois sur deux. Sinon, il faudrait trouver un moyen de reconnaître une calculatrice SH4, par exemple en provoquant une erreur sur le processeur qui ne s'applique qu'aux SH4.
Comme tu peux le voir dans le premier tutoriel, les syscalls ne s'appellent plus de la manière, mais existent toujours et peuvent encore être utilisés -- même si on a parfois un peu de mal...
Citer : Posté le 21/06/2014 09:02 | #
Ok merci, j'ai une SH3 et une SH4 donc je vais faire mes tests
Escape prison
Bloxorz
Free wheel
QR code
Nombre en or
RayCasting Engine
Mario Party
Zelda
et Planète Casio
Citer : Posté le 21/06/2014 11:45 | #
J'ai un moyen de reconnaître la calto sans le nom de version, allez voir sur ça casiopeia, je l'implementerais dans le sh4ct quand j'aurais le temps
Citer : Posté le 21/06/2014 16:44 | #
Juste pour savoir, les adresses mémoire dépendent bien de l'OS ? Sinon, il est facile de comparer l'adresse brute définie pour les SH3 pour la VRAM (par exemple) à celle retournée par le syscall.
Citer : Posté le 21/06/2014 18:37 | #
Qu'est-ce que tu appel adresse mémoire ? Genre si je veux écrie sur l'écran, j'écris à une certaine adresse, cette adresse n'est pas géré par l'OS c'est pas le truc dont j'ai plus le nom, mais c'est lui qui s'en charge. Sauf que ça change pas grand chose, toutes les adresses ne changent pas (encore heureux), et pour celles qui change, si on les tests, il y aura une erreur comme quoi elle n'existe pas, et donc le programme s'arrete. C'est pas le but recherché.
Mais SimLo a trouvé comment faire, si tu veux savoir, va voir dans la fxreverse (pas le pdf, le fichier aide) ou casiopeia dans mon dernier topic.
Citer : Posté le 21/06/2014 18:40 | #
Je parlais par exemple de l'adresse de le VRAM. Dépend-elle de l'OS, ou du proco ?
Sinon, je vais voir sur Casiopeia.
Citer : Posté le 21/06/2014 18:46 | #
L'adresse de la VRAM dépend de l'OS car c'est juste un endroit fixe dans la mémoire réservé à ça. Mais c'est pas parce qu'elle dépend de l'OS qu'elle change suivant les OS, ils peuvent décider de garder la même.
Citer : Posté le 21/06/2014 18:47 | #
Donc ça ne fonctionnerait pas. C'était juste pour savoir, on avais un doute avec DS tout à l'heure.
Sinon, j'ai regardé sur Casiopeia. Donc vous décidez ça à partir d'une adresse dans la RAM ?
Citer : Posté le 21/06/2014 18:59 | #
En fait il utilise des différences de fonctionnement entre les cpu. De mémoire, tu écris à un endroit puis tu le lit. Suivant le cpu, ça va correspondre ou non à quelquechose (une sortie il me semble), et donc tu pourra le lire et récupérer ta valeur que tu as mis alors que dans l'autre cas la valeur sera lue sera 0.
Donc non, c'est pas la ram, c'est des registres de config du cpu.
Citer : Posté le 21/06/2014 19:02 | #
Ok, donc là il s'agit bien d'un moyen fiable de reconnaître le CPU. C'est cool alors, on va avoir des add-ins adaptés à tous les modèles. On va pouvoir implémenter directement tes fonctions dans la lib par défaut pour la compilation gcc, comme ça on aura des addins puissants et nativement compatibles SH4.
Citer : Posté le 21/06/2014 19:05 | #
Bah après on a plus qu'a prié que les prochaines versions hardware ne se comportent pas pareil avec des specs différentes.
Pour que ce soit le plus rapide possible pendant l'execution, il faudra qu'au chargement de l'addin, la version soit détecté et stocké dans une variable globale, mais je sais pas trop si c'est faisable dans votre lib gcc.
Citer : Posté le 21/06/2014 19:08 | #
Bien sûr que si, on fait ce qu'on veut.
Certaines fonctions d'initialisation sont appelées au lancement de l'add-in (fonction en 0x00300000), donc il nous suffit de la modifier pour appeler ton code (elle est dans le crt0.s).
Citer : Posté le 21/06/2014 19:10 | #
Ok, en effet, j'avais pas pensé à le mettre dans le code d'init de l'addin, je réfléchissait purement en "lib" et pas en systeme de compilation complet. Quand j'aurais le temps, je développerais le keydown plutot rapide et compatible toute calto (il sera sans doute fait en assembleur par contre)
Citer : Posté le 21/06/2014 19:12 | #
De tout façon, crt0.s c'est de l'asm donc pas de problème. Il faut juste je crois, qu'on pense à les appeler ces fonctions.
Mais en y réfléchissant, rien dans le code de l'add-in n'indique qu'il faut appeler la fonctions INIT_ADDIN_APPLICATION() (définie dans les pragma), donc j'ai tendance à penser qu'elle est appelée par défaut si elle existe. Je ferai des tests, et si cela s'avérait vérifié, on n'aurait qu'à la créer et appeler ce qu'on veut dedans.
Citer : Posté le 21/06/2014 19:16 | #
Si tu compiles sous GCC, tu met pas de INIT_ADDIN_APPLICATION, je vois pas le rapport. En assembleur t'appel pas de fonction, t'appel une adresse et l’adresse de cette fonction change selon le programme. C'est juste que quand le compilateur du sdk fait l'addin, il fait en sorte que ce soit la fonction appelé à la fin du chargement. Mais si tu est sous GCC, tu fais ce que tu veux, puisque c'est toi qui fait le wrapper g1a, tu peux très bien décider de lancer n'importe quel code avant le jump sur la fonction main.
Citer : Posté le 21/06/2014 19:20 | #
Non, car le code appelé est à l'adresse 0x0030000, et on n'a pas forcément la place de coller du code là.
Je pense que la fonction INIT_ADDIN_APPLICATION() est appelée par l'OS de la calculatrice au lancement de l'application, voilà le rapport. Sinon, on sera obligé d'écrire "initialize();" au début de chaque add-in, et c'est moche.
Citer : Posté le 21/06/2014 19:24 | #
Un OS ne peut pas appeler une fonction dans ton programme c'est impossible car il ne peut appeler qu'une adresse, et une fonction n'a pas toujours la même adresse suivant la compilation. L'OS lui il jump sur l'adresse de début du binaire dans l'addin qui est 0x00300200, et après il lui laisse la main. Tu fait ce que tu veux, la suite tu peux la décaler pour avoir plus de place. C'est du binaire, la seule chose que l'OS peut faire une fois avoir jumpé sur l'adresse c'est faire des interruptions. Après je sais pas ce qu'il y a dans le wrapper g1a, lui peut décider quelle fonction commence, mais c'est pas l'OS. Et puis lui tu peux le modifier et décaller le reste si tu as envie.