Posté le 13/01/2020 11:03
?
Ecran (facile) Horloge (facile) Clavier (moyen) Timer & Interruptions ?
Planète Casio v4.3 © créé par Neuronix et Muelsaco 2004 - 2024 | Il y a 161 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 13/01/2020 11:06 | #
Hmm, eh bien gint ne fait rien de particulier du point de vue d'un émulateur (pas plus que Jetpack Joyride si tu veux). La question d'avoir un émulateur pour gint revient à celle d'avoir un émulateur générique, ce qui n'est pas plus mal.
L'émulateur Graph 35+E II officiel de Casio peut totalement faire tourner gint. Un émulateur sur Linux n'est pas impossible avec QEMU... limite pas impossible du tout. Mais il y a un peu de travail, c'est sûr.
Après tu as toujours l'approche de ne pas émuler le matériel et d'émuler à la place les primitives de gint, par exemple en recompilant ou en reliant sur la SDL avec une version de gint codée pour Linux. Ça peut se faire aussi. C'est un peu moins générique et un peu plus facile, je pense. Dans ce cas ce n'est pas un émulateur à proprement parler, mais ça remplit sans doute la tâche que tu t'imagines ?
Citer : Posté le 13/01/2020 11:14 | #
pour la seconde approche, il me semble avoir vu passer un projet similaire pour la fxlib il y a longtemps.. Ça dit quelque chose à quelqu'un ??
Citer : Posté le 13/01/2020 11:50 | #
Ouai alors personnellement comme je code sous windows avec mon image docker, je peux facilement lancer le code sous l'émulateur officiel, avec un macro de raccourcis clavier que j'ai bricolé je lance l'exécution en 3 secondes
Mais quand je code sous Linux (au taf quand y'a personne chuuuut
Tu as relevé ce que je pensais, mais j'étais pas sûr, effectivement comme c'est des add-in gint exclusivement y'a p'tet moyen de faire le truc avec les primitive et la SDL là
Tu penses que c'est faisable ça, en terme technique et tout etc... ?
Citer : Posté le 13/01/2020 11:54 | #
Genre avec la SDL, oui, ce serait pas très difficile. La gestion du clavier on peut modifier le driver pour prendre la SDL en entrée, la gestion de l'écran on peut bourriner à l'aveugle, le DMA y'en a pas besoin, l'horloge on prend celle de Linux, et il reste que les timers.
Il faut faire attention au fait que les timers de la SDL ne sont pas aussi précis que ceux de la calculatrice. Mais on peut utiliser ceux de Linux.
Je pense que c'est à la portée de tout programmeur SDL/Linux avec un peu d'expérience.
Citer : Posté le 13/01/2020 14:02 | #
C'est à dire modifier les drivers ? Tu dis à gint de compiler pour tel drivers ou alors c'est autrement ?
L'écran c'est genre quand on a la fonction qui affiche, on récupère la vram et on l'affiche sur l'ordi ?
Citer : Posté le 13/01/2020 17:22 | #
Actuellement le driver clavier de gint accède à du matériel sur la puce qui est branché au clavier. Ce matériel n'existe pas sur ton PC. Mais donc on peut modifier le code pour remplacer l'accès à ce matériel par un accès à la SDL. D'où "modifier le driver de gint".
Oui, la fonction dupdate() devrait être modifiée. C'est probablement la plus facile de toutes les modifications. La plus compliquée c'est la reproduction des interruptions.
Citer : Posté le 14/01/2020 11:06 | #
J'ai mis à jour le post principal pour répertorier l'éventuel travail, attention je ne dis pas que je vais travailler dessus
Mais au moins on aura une base si quelqu'un (ou moi) le tentera un jour, après je ne pense pas avoir le niveau requis en C pour bosser sur un truc comme ça.
Même si en soit j'avais pensé à un émulateur qui transformerait le code en Javascript, mais bon là c'est une autre histoire.
Les interruptions c'est quoi exactement ? C'est la détection d'un appuis de touches ? Ou juste les exceptions ?
Citer : Posté le 14/01/2020 11:16 | #
Merci pour le répertoire ! Quelques infos de plus :
Les interruptions, c'est un mécanisme matériel par lequel le processeur s'interrompt lorsqu'un événement se produit. Par exemple, l'horloge atteint l'heure réglée pour une alarme, une touche du clavier est pressée, ou un timer arrive à expiration. Dans gint, seuls les timers sont vraiment orientés interruptions.
La SDL possède aussi des timers qui fonctionnent sur le même principe, mais ne sont pas du tout aussi précis. Quand le timer arrive à expiration, une fonction de notre choix est appelée (depuis un thread différent du programme principal généralement, donc faut faire gaffe).
Citer : Posté le 14/01/2020 11:25 | #
Ah super ces précisions, je mettrai au propre plus tard
Okay donc faudrait vraiment refaire un système d'interruptions custom, ça semble assez compliqué, car je me souviens que t'avais déjà passé un certain temps pour le système d'interruption de base.
Quand tu dis les différences de thread, sur la Casio y'en a qu'un ça simplifie déjà les choses non ? Que veux-tu dire par ça ?
Aussi je pense aux fonctions qui manque à gint pour l'instant, genre le système de fichiers, car on utilise encore BFile non ?
Est-ce que la compilation devra changer aussi ? On pourrait lancer le .g2a directement, ou faudrait un format différent ?
Comme c'est sous Linux je vois bien un extension de fxsdk, genre fxsdk run avec une option pour lancer un test sur l'émulateur gint (parce que je crois que t'as déjà une commande similaire pour lancer un transfert sur la calto).
Citer : Posté le 14/01/2020 11:32 | #
Non non, il ne faut pas recoder les interruptions, il faut juste essayer d'attraper les timers par les APIs existantes qui de toute façon utilisent déjà des interruptions et appellent des callbacks.
Justement, il y aura deux threads si on utilise les timers SDL. Donc ça ne se comportera pas pareil que la calto. Avec les signaux de Linux, peut-être pas.
Pour l'instant c'est toujours BFile oui, et il n'y a pas moyen de faire autrement - on peut cacher BFile derrière un truc plus élégant, mais ultimement ce sera toujours BFile.
Comme c'est sous Linux je vois bien un extension de fxsdk, genre fxsdk run avec une option pour lancer un test sur l'émulateur gint (parce que je crois que t'as déjà une commande similaire pour lancer un transfert sur la calto).
Oui il faudra relinker avec une autre version de gint. Rien de bien méchant, le fxSDK supporte déjà la compilation pour Graph mono et Graph 90 donc rajouter une variante n'est pas un problème. Le fichier résultant ne serait pas du tout un g1a ou un g3a, mais un exécutable normal lancé normalement.
Citer : Posté le 14/01/2020 11:39 | #
Okay donc tous les ajouts du code seront dans gint, et dans le compilateur de gint, pour faire un exécutable ?
Parce que je pensais qu'il fallait coder un interpréteur ou un truc du genre, enfin un autre logiciel quoi.
Ah ouai BFiles est déjà opti
Citer : Posté le 14/01/2020 11:43 | #
BFiles est pas optis, c'est juste le seule moyen de faire des trucs avec les fichiers sans risquer de briquer ta caltos
Citer : Posté le 14/01/2020 11:53 | #
Okay donc tous les ajouts du codeseront dans gint, et dans le compilateur de gint, pour faire un exécutable ?
Parce que je pensais qu'il fallait coder un interpréteur ou un truc du genre, enfin un autre logiciel quoi.
Pas forcément, il suffit de définir une nouvelle plateforme cible pour gint et de la compiler avec le compilateur natif.
Comme Kouhai l'a bien fait remarquer, BFile c'est le cancer et c'est bourré de limitations insupportables, mais c'est le SEUL moyen d'écrire dans la ROM.