gint : un noyau pour développer des add-ins
Posté le 20/02/2015 17:30
Ce topic fait partie de la série de topics du fxSDK.
En plus des options de programmation intégrée comme le Basic Casio ou Python, la plupart des calculatrices Casio supportent des
add-ins, des programmes natifs très polyvalents avec d'excellentes performances. Les add-ins sont généralement programmés en C/C++ avec l'aide d'un ensemble d'outils appelé SDK.
Plusieurs SDK ont été utilisés par la communauté avec le temps. D'abord le
fx-9860G SDK de Casio avec fxlib pour Graph monochromes (plus maintenu depuis longtemps). Puis le
PrizmSDK avec libfxcg pour Prizm et Graph 90+E (encore un peu actif sur Cemetech). Et plus récemment celui que je maintiens, le
fxSDK, dont gint est le composant principal.
gint est un unikernel, ce qui veut dire qu'il embarque essentiellement un OS indépendant dans les add-ins au lieu d'utiliser les fonctions de l'OS de Casio. Ça lui permet beaucoup de finesse sur le contrôle du matériel, notamment la mémoire, le clavier, l'écran et les horloges ; mais aussi de meilleures performances sur le dessin, les drivers et la gestion des interruptions, plus des choses entièrement nouvelles comme le moteur de gris sur Graph monochromes.
Les sources de gint sont sur la forge de Planète Casio :
dépôt Gitea Lephenixnoir/gint
Aperçu des fonctionnalités
Les fonctionnalités phares de gint (avec le fxSDK) incluent :
- Toutes vos images et polices converties automatiquement depuis le PNG, sans code à copier (via fxconv)
- Un contrôle détaillé du clavier, avec un GetKey() personnalisable et un système d'événements à la SDL
- Une bibliothèque standard C plus fournie que celle de Casio (voir fxlibc), et la majorité de la bibliothèque C++
- Plein de raccourcis pratiques, comme pour afficher la valeur d'une variable : dprint(1,1,"x=%d",x)
- Des fonctions de dessin, d'images et de texte optimisées à la main et super rapides, surtout sur Graph 90+E
- Des timers très précis (60 ns / 30 µs selon les cas, au lieu des 25 ms de l'OS), indispensables pour les jeux
- Captures d'écran et capture vidéo des add-ins par USB, en temps réel (via fxlink)
Avec quelques mentions spéciales sur les Graph monochromes :
Un moteur de gris pour faire des jeux en 4 couleurs !
La compatibilité SH3, SH4 et Graph 35+E II, avec un seul fichier g1a
Une API Unix/POSIX et standard C pour accéder au système de fichiers (Graph 35+E II seulement)
Et quelques mentions spéciales sur les Graph 90+E :
Une nouvelle police de texte, plus lisible et économe en espace
Le dessin en plein écran, sans les bordures blanches et la barre de statut !
Un driver écran capable de triple-buffering
Une API Unix/POSIX et standard C pour accéder au système de fichiers
Galerie d'add-ins et de photos
Voici quelques photos et add-ins réalisés avec gint au cours des années !
Arena (2016) — Plague (2021)
Rogue Life (2021)
Momento (2021)
Communication avec le PC (cliquez pour agrandir)
Utiliser gint pour développer des add-ins
Les instructions pour installer et utiliser gint sont données dans les divers tutoriels recensés dans le
topic du fxSDK. Il y a différentes méthodes de la plus automatique (GiteaPC) à la plus manuelle (compilation/installation de chaque dépôt). Le fxSDK est compatible avec Linux, Mac OS, et marche aussi sous Windows avec l'aide de WSL, donc normalement tout le monde est couvert
Notez en particulier qu'il y a des
tutoriels de développement qui couvrent les bases ; tout le reste est expliqué dans les en-têtes (fichiers
.h) de la bibliothèque que vous pouvez
consulter en ligne, ou dans les ajouts aux changelogs ci-dessous.
Changelog et informations techniques
Pour tester les fonctionnalités et la compatibilité de gint, j'utilise un add-in de test appelé gintctl (
dépôt Gitea Lephenixnoir/gintctl). Il contient aussi une poignée d'utilitaires d'ordre général.
Ci-dessous se trouve la liste des posts indiquant les nouvelles versions de gint, et des liens vers des instructions/tutoriels supplémentaires qui accompagnent ces versions.
Anecdotes et bugs pétés
Ô amateurs de bas niveau, j'espère que vous ne tomberez pas dans les mêmes pièges que moi.
TODO list pour les prochaines versions (2023-04-03)
gint 2.11
- Changements de contextes CPU. À reprendre du prototype de threading de Yatis pour permettre l'implémentation d'un véritable ordonnanceur. Demandé par si pour faire du threading Java.
- Applications USB. Ajouter le support de descripteurs de fichiers USB. Potentiellement pousser jusqu'à avoir GDB pour debugger.
- Support de scanf() dans la fxlibc. Codé par SlyVTT, plus qu'à nettoyer et fusionner.
Non classé
- Regarder du côté serial (plus facile que l'USB) pour la communication inter-calculatrices (multijoueur) et ultimement l'audio (libsnd de TSWilliamson).
- Un système pour recompiler des add-ins mono sur la Graph 90+E avec une adaptation automatique.
- Support des fichiers en RAM pour pouvoir utiliser l'API haut-niveau sur tous les modèles et éviter la lenteur de BFile à l'écriture quand on a assez de RAM.
Citer : Posté le 17/04/2018 17:17 | #
À vrai dire j'ai enfin pu pointer un vrai bug, clair et fixe, dans les sources de l'autre jour. Une sombre histoire où les registres de priorité des interruptions - ceux qui me servent à désactiver les interruptions - ont un espacement interne. Je n'en tenais pas compte, et du coup il y avait encore des interruptions...
J'ai aussi rencontré des System ERROR quand je me suis rendu compte que j'arrivais à appeler memcpy() sans l'implémenter grâce à de la magie noire du compilo. Ça n'explique pas tout ceux que j'avais (surtout une fois gint en place), mais c'est déjà ça.
Ajouté le 17/04/2018 à 17:18 :
Ah, je vois. Mais du coup tu ne redéfinis pas les fonctions graphiques pour le scaling (c'est juste que le syscall utilisé pour le Locate utilise toujours 7x21 caractères et fait donc du scaling).
Disons que c'est l'équivalent Prizm de Locate, donc il affiche selon les standard de la Graph 90.
Du coup tu fais comment par exemple pour le test de gris (celui avec les sprites des épées) ?
J'en suis pas encore là. Mais pour le coup je mettrai d'autre images dans le test, et y'aura pas l'histoire de gris. Les seules vraies différence entre la monochrome et la Graph 90 !
Ajouté le 18/04/2018 à 18:20 :
Juste pour signaler que j'ai résolus d'autres bugs qui traînaient dans ma première tentative de portage vers la Graph 90, tentative qui avait fini par tout casser même sur les monochromes.
Il y avait de sombres subtilités d'alignement dans le linker script, en particulier :
.data : ALIGN(4) {...} # Aligne l'adresse de travail (RAM) à 4 octets
.data ALIGN(4) : ALIGN(4) {...} # Ce que je voulais
J'ai aussi réglé un truc sale lié au fait que pour le compilateur C, quand vous écrivez symbole, ça veut dire pour lui « la donnée qui est à l'adresse donnée par _symbole ». Ce qui n'est pas le cas pour les fonctions puisque quand f est une fonction, f et &f sont la même chose (il prend automatiquement l'adresse). Et donc vous n'avez pas la même chose dans les deux cas suivants :
print_hexa((uint32_t)f); # Affiche l'adresse de f
extern void (*f)(void);
print_hexa((uint32_t)f); # Affiche les deux premières instructions de f
Ces choses étant résolues, j'avance progressivement sur les drivers et les interruptions. Actuellement je n'active pas les interruptions, mais je mets en place les drivers en commençant par celui de l'écran sur la monochrome, le plus simple. Il a l'air de marcher sur les fonctionnalités de base ; je m'occupe actuellement du contraste et du rétroéclairage puis je passe à des trucs plus subtils, probablement les timers et le clavier.
Je tenterai d'écrire un driver clavier plus sérieux qu'avant, mais ce n'est pas dit que j'y arrive... il se passe beaucoup d'effets bizarres avec le clavier. Je maintiendrai ce thread à jour dans tous les cas !
Citer : Posté le 18/04/2018 18:34 | #
J'ai pas compris ce que tu veux avec le .data ALIGN(4) : ALIGN (4)
Citer : Posté le 18/04/2018 18:47 | #
Je veux que les données que je m'apprête à copier dans la RAM pour initialiser l'add-in soient alignées sur une adresse multiple de 4 pour que je puisse les lire avec un pointeur de type int * par paquets de 4 octets.
Je veux de plus que l'adresse de destination soit aussi multiple de 4 pour que je puisse écrire les données que j'ai lues avec un pointeur de type int *, toujours par paquets de 4 octets donc.
Et en plus, je contrains la section à être d'une longueur multiple de 16 pour pouvoir faire les lecture/écritures par paquets de 4 * 4 octets sans avoir à vérifier que j'ai atteint la taille de la section (dans la condition de la boucle) à chaque fois.
Et c'est significativement plus rapide comme ça.
Citer : Posté le 18/04/2018 19:01 | #
D'accord, en fait l'ordre des "arguments" de :data est ROM; RAM.
Et du coup ceci fonctionne aussi ?
.data ALIGN(4) :
.data : ALIGN(16)
Citer : Posté le 18/04/2018 19:10 | #
Ce n'était peut-être pas clair, mais la syntaxe complète est quelque chose dans ce genre :
*(.data) # On met des choses dedans
*(.data.*) # ...
. = ALIGN(16); # Taille multiple de 16
} > ram AT> rom # Stocké en ROM, alloué en RAM
Comme tu peux le voir, .data c'est le nom de la section sur laquelle je travaille et tout ce qui se trouve entre ce nom et l'accolade ouvrante sont des propriétés de la section. .data n'est pas une directive assembleur ni une « fonction ».
Les deux lignes que tu as écrites, indépendamment, sont donc toutes les deux valides (si elles sont suivies d'une accolade ouvrante et des détails sur les contenus...), et ne contraignent qu'un alignement. Par contre tu ne peux pas les mettre toutes les deux dans le même linker script puisque ça déclarerait deux fois la section de sortie.
Citer : Posté le 18/04/2018 19:30 | #
Ok, c'est bien complexe tout ça
Merci pour l'explication, détaillée comme toujours
Citer : Posté le 18/04/2018 20:11 | # |
Fichier joint
Expliquer les enjeux réels du linker script nécessite de détailler l'ensemble du processus de linkage. Si tu as besoin d'un renseignement plus précis, tu peux trouver l'immense majorité des choses dans la doc de ld :
https://sourceware.org/binutils/docs/ld/
Ajouté le 18/04/2018 à 22:52 :
Je commence à triturer un peu l'écran de la Graph 90. La doc de SimLo et le WikiPrizm de Cemetech contiennent quelques infos ; la doc de SimLo est la plus abondante en éléments précieux :
fxCG20_DisplayDriver.htm (bible.planet-casio.com)
Le contrôleur est un R61524 ; un truc customisé (la spécialité de Casio semble-t-il) qui est assez proche du R61509. J'arrive à confirmer l'identité de R61524 en faisant quelques opérations d'entrée/sortie.
Basiquement, j'envoie des ordres de lecture à l'écran et je regarde comment le système a configuré l'affichage. La doc trouvée dans la bible de TeamFX me permet d'interpréter les paramètres et je croise avec la doc de SimLo pour vérifier que j'ai bien lu ce qu'il fallait. Parfois je trouve quelques différences.
Je m'attends à tomber assez rapidement sur un point crucial : l'écran fait 396×224 mais l'OS n'utilise qu'une région de taille 384×216. Les quelques pixels perdus ne sont pas colossaux mais il reste des bandes pas terribles sur les bords.
Mon objectif est double : je souhaite d'une part utiliser la totalité de l'écran, ce qui ne serait jamais perdu pour les add-ins ; et d'autre part mettre en oeuvre un système de double buffering qui permet à l'add-in de continuer de calculer pendant que les données transitent de la RAM à l'écran. Ce système peut déjà être utilisé mais possède des restrictions un peu lourdes. Il permet cependant de gagner significativement en performance. Je détaillerai plus un peu plus tard...
Citer : Posté le 19/04/2018 10:30 | # |
Fichier joint
J'ai l'immense plaisir de vous annoncer le premier add-in Prizm/Graph 90 capable d'utiliser l'intégralité de l'écran !
... et aussi le premier à emmerder sérieusement le système par ce moyen
Ajouté le 19/04/2018 à 10:41 :
Pour ceux qui ne connaissaient pas le principe : l'OS limite tous les affichages à la zone qui est sur fond blanc dans la deuxième photo. Si vous prenez Gravity Duck par exemple, il affiche le jeu dans cette zone et une bordure noire autour (tout ce que l'OS nous laisse faire c'est changer la couleur de la bordure).
Évidemment c'est con de pas utiliser tous les pixels ! En réécrivant un bout de driver pour l'écran, j'ai réussi à obtenir la première image, où on peut afficher des couleurs partout. C'est plus agréable à voir et ça coûte pas cher !
Ensuite sur la deuxième photo, j'ai affiché du texte par les moyens habituels de l'OS (les syscalls), et on peut voir qu'il a reconfiguré l'écran sur sa surface réduite et n'a affiché que dans le cadre initial. Quand je dis « emmerder l'OS », c'est une référence au fait que la bordure ne ressemble maintenant plus à rien parce que l'OS ne l'a pas recoloriée. (NB : Quand on revient au menu principal, il recolorie tout.)
La deuxième photo est donc la suite normale de mon add-in et nullement un message d'erreur !
Citer : Posté le 19/04/2018 10:50 | #
Quel intérêt de limiter l’écran de la part de Casio ?
A part ça si j'ai bien comprit avec gint il vas générer deux add-in ?
1 pour Prizm/Graph 90 et un autre pour les monochrome ?
En tout cas c'est le GG pour l’écran
Citer : Posté le 19/04/2018 10:57 | #
Je sais pas trop pourquoi Casio a fait ça. Tout ce que je peux dire c'est que l'écran réduit fait 384 × 216 soit 16 × 9 * 24 et qu'ils voulaient peut-être obtenir ce ratio. (?)
Alors voilà comment ça va se passer. gint existe actuellement en deux versions :
- Quand on configure avec -fx9860g, une version pour développer des add-ins sur les monochromes ;
- Quand on configure avec -fxcg50, une version pour développer des add-ins sur les couleur.
gint ne peut pas créer deux add-ins à la fois pour plein de raisons. Que faire sur la G85 quand vous demandez de dessiner un bitmap en couleur ? Quand l'affichage déborder de l'écran ? Que faire sur la G90 quand on utilise un syscall de la G85 qui n'a pas d'équivalent ? etc etc.
Par contre gint définit deux macros, FX9860G et FXCG50, qui indiquent la plateforme actuelle. En vous servant de ces macros, vous pouvez ajuster le code qui est spécifique à la plateforme et compiler un g1a et un g3a à partir des mêmes sources !
Par exemple, l'add-in que vous voyez au-dessus, qui est l'add-in de contrôle de gint (ou du moins son début parce que je suis en train de le réassembler pièce par pièce), je le compile pour les deux modèles en même temps : sur G85, il lance le driver T6K11 (écran monochrome), joue avec le contraste et le rétroéclairage, et sur G90, il lance le driver R61524 (écran couleur), et affiche les choses que vous voyez sur mes photos !
Donc, de base, vous utilisez une seule version de gint pour faire un seul add-in. Mais si vous voulez assurer la compatibilité avec très peu de changements sur les sources, eh bien, la lib' fera de son mieux pour vous y aider.
Citer : Posté le 19/04/2018 18:15 | #
Si ça c'est pas la belle vie ! o/
Citer : Posté le 19/04/2018 18:26 | #
Beau boulot sur les bandes du bord de l'écran ! 0/
Mine de rien ça va faire un peu de données supplémentaires à traiter à chaque frame, tes pistes pour le driver de l'écran s'intègre⋅nt⋅ront bien avec le chip qui permet de lancer des vrais transferts DMA ? Il va aussi falloir trouver de la RAM pour manipuler cet écran étendu (et deux fois même si on part vers du double buffering !), tu as des pistes à ce niveau là également ? Enfin, c'est peut être pas la priorité tout de suite non plus c'est vrai…
En tout cas le support simultané des deux familles de machines est bien prometteur aussi !
Citer : Posté le 19/04/2018 18:55 | #
C'est le prochain truc à étudier côté Graph 90. À vue de nez : ça va marcher tout seul.
Le plus gros problème c'est la RAM. Pour faire du triple buffering avec la méthode du DMA il faut deux buffers de 177k pour un total de 355k environ. Le seul endroit où ça tient c'est l'énorme zone utilisateur qui s'étend sur 512k. Pour des raisons très pragmatiques du genre « je vais pas me mettre n'importe où dans la RAM », gint sera aussi dans cette zone de RAM. Comptons 370k maxi, mais ça fait déjà plus de la moitié de la région.
Il resterait à l'utilisateur 142k de RAM statique, 128k de tas mais à utiliser avec précaution, et 165k à piquer dans la VRAM du système qui ne sera, du coup, pas utilisée.
L'autre solution serait d'accepter de couper la VRAM en deux morceaux. Niveau dessin ce n'est pas optimal, mais le gain qui découle de l'utilisation du DMA devrait compenser. Si j'implémente bien, ça resterait plus rapide que le système, donc rentable. Dans cette situation, on aurait ~200k de RAM statique utilisés (fin de la VRAM + copie de la VRAM + gint), ce qui laisse une marge raisonnable.
Ajouté le 19/04/2018 à 19:25 :
J'ai un peu plus de haute voltige qui me vient à l'esprit mais il faut des hypothèses sur le moteur de rendu utilisé par l'application. Il faut que je voie dans quelle mesure ce modèle est viable, mais je pense partir sur la méthode suivante :
- On fait du triple buffering et le module de dessin suppose la VRAM coupée en deux.
- Le premier buffer est sur la VRAM système + 5544 octets qui dépassent, le second sur la RAM statique.
- En prenant une petite marge pour le poids de gint, il reste environ 300k de mémoire utilisateur.
Je suis obligé d'espérer que l'utilisateur s'en sortira avec cette quantité. Le problème c'est que même Gravity Duck, un jeu qui n'amasse pas abusivement les sprites, en a pour 140k. Je pense qu'une façon viable d'utiliser le tas est d'y charger les sprites qui doivent rester dans la mémoire pendant toute l'exécution pour rentabiliser la zone sans casser le gestionnaire mémoire, mais... ça reste short.
En tous cas il faudra une option pour désactiver le triple buffering. Une autre solution est de ne pas faire le rendu pendant le transfert DMA mais d'attendre qu'il s'arrête (presque comme avant, sauf qu'on s'autorise à faire autre chose que du dessin pendant le transfert) ; ça dépend vraiment de la durée du transfert.
Après il reste la haute voltige. Un mix des deux : on n'utilise qu'une seule VRAM et on surveille le DMA pour ne pas dessiner sur ce qui n'a pas été transféré. Ainsi, quand une opération de dessin est demandée :
- Si la zone a déjà été transférée, on dessine sans se poser de questions.
- Si la zone est en attente, on attend que le DMA avance suffisamment pour dessiner.
Vous voyez que si l'add-in dessine ses frames de haut en bas, on peut dessiner pendant le transfert. Ce n'est peut-être pas négligeable comme gain. J'ai encore d'autres variations en tête pour résoudre les cas où ça ne marcherait pas bien, mais ça devient compliqué.
Les pistes de recherche à explorer que je vois pour cette question sont les suivantes :
- Quel est la durée du transfert DMA par rapport à un 30 Hz idéal pour une application gourmande ?
- Quelle quantité de mémoire une application utilise-t-elle typiquement pour ses données (sprites) ?
- Peut-on faire tout et n'importe quoi pendant le transfert DMA (probablement oui sous gint, mais cf. la doc) ?
- Quel genre de borne inférieure a-t-on sur la durée de rendu d'un frame ?
Je vais essayer d'explorer tout ça quand j'aurai implémenté les timers. Je suis en train de le faire ; ça devrait me donner une très grande précision de mesure pour les tests de performance. Ensuite je me pencherai sur la question.
Plus que sur la monochrome, je crois que la question du dessin est doublement cruciale sur la Graph 90 : en temps et en mémoire. Des beaux défis de programmation en perspective ! o/
Ajouté le 19/04/2018 à 19:30 :
J'ai oublié de mentionner que bien sûr plein de sprites peuvent rester dans la ROM s'ils sont utilisés occasionnellement, mais ça pose d'autres problèmes. Pour faire simple, tant que gint tourne, il ne peut y avoir que 220k de ROM mappée à chaque instant.
Donc chaque fois qu'on veut accéder à une autre partie de l'add-in, il faut quitter temporairement gint pour demander au système de mapper les pages associées. Oui, je pourrais le faire moi-même, mais je refuse de toucher au TLB et au MMU en l'état.
J'ai commencé à envisager des solutions pour faire ce genre d'opérations de façon performante, mais ça reste encore à étudier. En tous cas, une grosse application aura sans doute intérêt à laisser de ses données dans la ROM parce que le code lui-même ne fera probablement pas 220k ; donc même de base, une partie de la ROM peut être utilisée pour les sprites.
Autre piste de recherche :
- Mesurer la différence de vitesse d'accès (pour un rendu de bitmap) entre la RAM et la ROM.
Ajouté le 20/04/2018 à 22:17 :
Je viens de faire un peu de désassemblage en me servant du travail de SimLo sur les timers supplémentaires ajoutés au MPU par Casio.
J'ai réussi à étendre les informations qu'il y a dans sa doc avec des choses plus concrètes. En gros je devrais pouvoir me servir de ces timers, même si je ne sais pas encore à quelle vitesse ils vont tourner. Un peu d'expérimentation devrait me le dire.
Une fois que j'aurai ces timers je pourrai attaquer tout plein de mesures de vitesse dont j'ai besoin pour choisir mon angle d'attaque pour les aspects graphique, en particulier sur Graph 90.
Stay tuned!
Citer : Posté le 20/04/2018 23:36 | #
Ivre, il désassemble l'OS de CASIO. Ce qu'il y trouve le révulse bien évidemment. Mais il le fait car il le peut.
Good job 'til now. Tu sais que je suis le projet de toute façon
Mon blog ⋅ Mes autres projets
Citer : Posté le 21/04/2018 20:33 | #
Voici la situation. En poussant le rétro-engineering un peu plus loin, j'ai obtenu les dernières informations qui me manquaient, et bien que je n'ai pas encore testé je pense que ça va se passer comme ça.
Timers disponibles sur SH3 (par extension : sur monochrome)
- 3 timers précis à ~0.1 µs sont disponibles pour l'utilisateur
- L'un deux est inutilisable quand le moteur de gris fonctionne
- 1 timer précis à ~30 µs est utilisé par gint [je peux le libérer si c'est nécessaire]
Timers disponibles sur SH4 (en particulier : sur Graph 90)
- 3 timers précis à ~0.1 µs sont disponibles pour l'utilisateur
- L'un deux est inutilisable quand le moteur de gris fonctionne (Graph monochrome uniquement !)
- 1 timer précis à ~30 µs est utilisé par gint [je peux le libérer si c'est nécessaire]
- 5, peut-être 6 autres timers précis à ~30 µs sont disponibles pour l'utilisateur
Je pense que ça suffira pour la plupart des applications ; pour les autres j'ai le système de timer virtuels qui permet d'en donner une quasi-infinité ; je le retire de gint mais j'en ferai une lib à part en cas de besoin.
Citer : Posté le 21/04/2018 20:34 | #
Pourquoi retirer ça de gint ? Oo
Mon blog ⋅ Mes autres projets
Citer : Posté le 21/04/2018 20:35 | #
Parce que c'est assez bloated en fin de compte. Je suis en train de batailler avec la place que prend gint en mémoire, qui est en particulier limitée sur Graph 90, et je me rends compte que 99% des utilisateurs n'en auront pas besoin.
Après quand tu veux l'utiliser ce n'est pas plus compliqué que -lvtimers par exemple. Mais le mettre partout par défaut, je crois pas que ce soit profitable.
Ajouté le 29/04/2018 à 15:28 :
News time!
J'avance tranquillement sur les timers. Sur ma Graph 75 SH4 j'arrive à compter à 40 Hz en utilisant un timer. Il me reste des ajustements à faire mais le principal est là !
Prochains objectifs :
– Vérifier que tous les timers fonctionnent bien
– Écrire le code pour utiliser les 1 (SH3) à 6 (SH4) timers supplémentaires ajoutés par Casio
– Refaire une passe sur le code pour la compatibilité SH3 (que je ne pouvais pas vérifier avant)
– Mesurer le temps d'exécution de tout et n'importe quoi ; j'adore faire ça.
Citer : Posté le 29/04/2018 16:20 | #
Bonne chance pour le reste des améliorations. Moi qui commence sur le sdk j'ai hâte de voir ce qui pourrais m'être utile...
-Planétarium 2
Citer : Posté le 29/04/2018 18:18 | #
Les choses les plus utiles sont dans le post principal. Si tu penses à autre chose, il y a peut-être moyen de l'ajouter !
Du reste, j'ai fait marcher les timers de la Graph 90. C'est une preuve que le principe de gint est viable sur cette machine
Le portage n'a jamais pris autant de substance. J'ai de bons espoirs de réussir à monter un environnement de développement complet pour cette nouvelle calculatrice !
Citer : Posté le 30/04/2018 20:04 | #
Je me suis amusé à chercher l'address du contraste sur 2 OS différent donc voilà:
OS: 02.05.2210 (Graph75+e)
DateO: 2015.0207.1639
DateA: 2011.0531.1709
OS sum: C434
ABS sum: A78D
Address: 0x8800b93c
Valeur min. : 0x14
Valeur max. :0x2c
Valeur ini. : 0x20
Valeur min. (mode diagnostic): 0x11
Valeur max. (mode diagnostic): 0x2F
OS: 02.04.2210 (Graph75+)
DateO: 2014.0121.1705
DateA: 2011.0525.1010
OS sum: CB05
ABS sum: A781
Address: 0x8800b904
Valeur min. : 0x14
Valeur max. :0x2c
Valeur ini. : 0x20
Valeur min. (mode diagnostic): 0x11
Valeur max. (mode diagnostic): 0x2F
/!\IMPORTANT/!\
Pour trouver ses address j'ai utilisé le diagnostic de Casio (OPTN+EXP+AC, F1, 9) pour trouver la valeur de base du contraste.
L'une de mes deux calots avait une dizaine d'add-in et après avoir exit le mode diagnostic tout va bien.
L'autre de mes calots avait une trentaine d'add-in et après avoir exit le mode diagnostic tout les add-in avaient disparus.
Ils n'étaient pas supprimés car encore en mémoire seulement plus détecté comme add-in.
FA-124 les détectent bien on peut le back-up.
Seulement Impossible de lire de nouveau add-in, de transférer un programme.
La solution est...le reset complet de la mémoire supprimant tout les add-in, programme basique etc.
(Perso je m'en fous j'ai plein de back-up mais faite attention quand même : E).
Citer : Posté le 30/04/2018 20:22 | #
Merci de ton aide !
Le problème de disparation des add-ins est connu même s'il n'y a pas de solution claire. Je m'y suis frotté à plusieurs occasions, notamment quand j'ai utilisé une mauvaise zone de RAM sur les premières versions SH4 de gint [#133735]. J'ai déjà réussi à le résoudre en optimisant la mémoire de stockage. Il y a peut-être d'autres solutions ; le reset complet est définitivement la plus brutale.