Seuls les membres ayant 30 points peuvent parler sur le chat.

Forum Casio - Projets de programmation


Index du Forum » Projets de programmation » gint : un noyau pour développer des add-ins
LephenixnoirEn ligneAdministrateurPoints: 15732 Défis: 136 Message

gint : un noyau pour développer des add-ins

Posté le 20/02/2015 17:30

Les SDKs classiques pour écrire des add-ins sont le fx-9860G SDK de Casio avec fxlib (pour Graph monochrome) et le PrizmSDK avec libfxcg (pour Prizm et Graph 90+E). Voici mon alternative : le fxSDK avec gint, pour toutes les plateformes.

Contrairement à fxlib et libfxcg, qui appellent les fonctions de l'OS pour faire leur travail, gint est un noyau indépendant de l'OS qui exploite seul le matériel et le met à disposition de votre add-in. Il vous offre plus de finesse sur le contrôle du matériel, notamment le clavier, l'écran et les horloges, de meilleurs performances sur le dessin, les drivers et la gestion de interruptions, et des choses entièrement nouvelles comme le moteur de gris.

Toutes les sources de gint sont publiques et accessibles sur la forge de Planète Casio :

» Dépôt Gitea Lephenixnoir/gint «

Voici plus précisément ce que gint vous offre de nouveau :

• Un contrôle détaillé du clavier pour les jeux, parfait pour les combos !
• Des timers avec une précision de 60 ns, d'autres à 30 µs
• Toutes vos images converties automatiquement sans code à copier (plus de Sprite Coder)
• Des polices personnalisées
• Des fonctions de dessin, d'images et de texte fulgurantes et optimisées la main
• Mesurer les performance de votre code à la microseconde près (avec libprof)
• Le contrôle du matériel et des interruptions
• Plein de petites choses pratiques comme dprint(1, 1, "x=%d", x)

• (Graph monochrome) Un moteur de gris pour faire des jeux en 4 couleurs !
• (Graph monochrome) La compatibilité SH3 et SH4, avec le même fichier g1a.

• (Graph 90+E) Une nouvelle police de texte, plus lisible et économe en espace
• (Graph 90+E) Le dessin en plein écran, sans les bordures blanches et la barre de statut !
• (Graph 90+E) Un driver écran capable de triple-buffering

Le coût de tout ceci, c'est que vous avez une copie du code de gint dans votre add-in. Cela prend environ 20 ko de place (selon la quantité de fonctions que vous utilisez), soit à peu près comme le sprintf() de fxlib qui fait 18 ko !

Et voici quelques photos et captures d'écran !





Tester gint sur votre machine

La fin du portage vers la Graph 90+E signera la sortie de gint v2. L'add-in de test de l'application est désormais gintctl :

» Dépôt Gitea Lephenixnoir/gintctl «

En plus de tester les fonctionnalités de gint, cet add-in contient quelques outils permettant d'inspecter la machine, la mémoire, et les registres. Je le développe au fur et à mesure, et je posterai un protocole de test complet avec la sortie de la v2 !

Utiliser gint pour développer des add-ins

Normalement, vous avez besoin du fxSDK pour développer avec gint. Le fxSDK est compatible avec Linux et Mac OS, et on peut réfléchir à un portage sous Windows s'il y a vraiment des intéressés. Il faut l'installer en premier (et avoir un cross-compilateur GCC).

La procédure de compilation et d'installation de gint est décrite sur le README du dépôt, c'est du configure - make tout à fait banal.

Une fois que gint est installé sur votre système, voyez les tutoriels de développement pour avoir un aperçu de son fonctionnement. La plupart des choses sont expliquées dans les en-têtes (fichiers .h) de la bibliothèque que vous pouvez consulter en ligne, sur votre copie locale du dépôt, ou dans les dossiers d'installation du compilateur.

Obtenir la dernière version de gint après une mise à jour

Je pousse régulièrement des mises à jour de gint sur le dépôt du projet. Pour les télécharger, tapez git pull, puis recompilez et réinstallez gint avec make et make install.


Fichier joint


Pages : Précédente1 ... , 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, ... 25Suivante
LephenixnoirEn ligneAdministrateurPoints: 15732 Défis: 136 Message

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 :
Zezombye a écrit :
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.

Zezombye a écrit :
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 stockage (ROM) à 4 octets
.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 :

extern void f(void);
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 !
NinestarsHors ligneMembrePoints: 2253 Défis: 22 Message

Citer : Posté le 18/04/2018 18:34 | #


J'ai pas compris ce que tu veux avec le .data ALIGN(4) : ALIGN (4)
LephenixnoirEn ligneAdministrateurPoints: 15732 Défis: 136 Message

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.
NinestarsHors ligneMembrePoints: 2253 Défis: 22 Message

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)
LephenixnoirEn ligneAdministrateurPoints: 15732 Défis: 136 Message

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 ALIGN(4) : ALIGN(4) {    # Déclare la section .data et aligne
    *(.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.
NinestarsHors ligneMembrePoints: 2253 Défis: 22 Message

Citer : Posté le 18/04/2018 19:30 | #


Ok, c'est bien complexe tout ça
Merci pour l'explication, détaillée comme toujours
LephenixnoirEn ligneAdministrateurPoints: 15732 Défis: 136 Message

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...
LephenixnoirEn ligneAdministrateurPoints: 15732 Défis: 136 Message

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 !
YatisEn ligneMembrePoints: 435 Défis: 0 Message

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
LephenixnoirEn ligneAdministrateurPoints: 15732 Défis: 136 Message

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.
Dark stormEn ligneMembre d'honneurPoints: 10825 Défis: 176 Message

Citer : Posté le 19/04/2018 18:15 | #


Si ça c'est pas la belle vie ! o/
Finir est souvent bien plus difficile que commencer. — Jack Beauregard
Páranÿe quetë Quendya
NemhardyHors ligneGrand maître des Traits d'EspritPoints: 1235 Défis: 54 Message

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 !
N'attendez pas qu'il n'y ait plus de miel : スススススススススススススススススススススススススス養蜂家スススススススススススススススススススススススススススススススススススス蜂家
LephenixnoirEn ligneAdministrateurPoints: 15732 Défis: 136 Message

Citer : Posté le 19/04/2018 18:55 | #


[...] 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 ?

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!
Cakeisalie5Hors ligneMembre de CreativeCalcPoints: 1750 Défis: 10 Message

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

Promotion ordinaire sur les inscriptions sur Planète Casio : en ce moment, c'est gratuit !
Besoin d'utilitaires de transfert vers et depuis la calculatrice sous GNU/Linux ?
LephenixnoirEn ligneAdministrateurPoints: 15732 Défis: 136 Message

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.
Cakeisalie5Hors ligneMembre de CreativeCalcPoints: 1750 Défis: 10 Message

Citer : Posté le 21/04/2018 20:34 | #


Pourquoi retirer ça de gint ? Oo

Promotion ordinaire sur les inscriptions sur Planète Casio : en ce moment, c'est gratuit !
Besoin d'utilitaires de transfert vers et depuis la calculatrice sous GNU/Linux ?
LephenixnoirEn ligneAdministrateurPoints: 15732 Défis: 136 Message

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.
DisperseurHors ligneMembrePoints: 1495 Défis: 0 Message

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...
Planetarium

√(2+2-2+2-2+2+2-2-2-2) = 0
LephenixnoirEn ligneAdministrateurPoints: 15732 Défis: 136 Message

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 !
YatisEn ligneMembrePoints: 435 Défis: 0 Message

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).
LephenixnoirEn ligneAdministrateurPoints: 15732 Défis: 136 Message

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.
Pages : Précédente1 ... , 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, ... 25Suivante

Planète Casio v42 © créé par Neuronix et Muelsaco 2004 - 2019 | Il y a 89 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