1er programme pour HP39gII : calcul mental

→ **MyCalcs** profile · de **zorglub13** » 28 Sep 2014, 18:49

Toute remarque est bonne à étudier et puis chacun peut avoir son avis. À+

→ **MyCalcs** profile · de **zorglub13** » 11 Oct 2014, 20:33

Bonjour,

J'ai fait un petit tour sur le ti basic 68k (émulateur voyage 200 sur Android) avec les affichages graphiques, les barres de menu, menus déroulant, fonctions, procédures. Y a pas photo, c'est suffisamment stable, facile et structuré pour de petits programmes (on est sur des calculatrices ne l'oublions pas). Je n'ai pas eu les mêmes sensations que sur la HP 39gII ie des bugs insensés, toutes mes erreurs de code sur la TI étaient normales (étourderies). À l'époque, TI parlait d'un langage type Turbo Pascal 3 et ce n'est pas faux... C'est un vrai regret de ne pas avoir eu connaissance des possibilités de ces calculatrices lors de leurs sorties (plus d'une quinzaine d'années). Ceux qui ont acheté dans le passé une voyage 200 n'ont pas du le regretter...

On se demande vraiment pourquoi sur les Nspire on ne peut pas dessiner sur l'ecran, ni gérer le clavier comme sur les ti89 ou voyage 200... C'est incompréhensible !!!

En tout cas sur smartphone (Android ou ios), je ne connais pas d'outils qui me permettent de faire des programmes avec interface graphique aussi facilement. Bien sûr, sur smartphone, tout est plus beau, tout est plus rapide mais il faut quand même bien comprendre le SDK avant de pouvoir faire quoi que ce soit... Et c'est loin d'être aussi facile...

À+

→ **MyCalcs** profile · de **Lionel Debroux** » 12 Oct 2014, 10:09

Le BASIC des TI-68k est en effet très stable, si on excepte quelques bêtises d'implémentation (plusieurs opérations, dont DelVar, ne gèrent pas du tout les variables locales). Il n'est pas rapide, mais il existe FLib et Vertel pour améliorer sa puissance et sa vitesse tout en restant dans le cadre BASIC.

On se demande vraiment pourquoi sur les Nspire on ne peut pas dessiner sur l'ecran, ni gérer le clavier comme sur les ti89 ou voyage 200... C'est incompréhensible !!!

Les Nspire sont destinées à la consommation de contenu éducatif proposé par les enseignants, plutôt que des machines de bidouillage et d'apprentissage par soi-même.
C'est un choix fondamental du système éducatif moderne (et donc de société): baisser le niveau de façon continue. C'est pourtant de producteurs éduqués dont le monde a besoin pour avancer efficacement... Mais bon, on sait très bien qu'il y a la petite parie des "élites" d'un côté, qui se reproduisent, et le reste de la population.

→ **MyCalcs** profile · de **zorglub13** » 14 Oct 2014, 19:49

Bonjour,

C'est vrai que le ti basic est un peu lent surtout dans les opérations graphiques comme circle. Mais faire des menus, des quizz est d'une facilite déconcertante... Par contre si Flib et Vertel permettent d'améliorer les traitements graphiques (ligne, cercles, carrés, rectangles, cercles pleins), il va falloir que je les regarde mieux. Quelqu'un connaît-il les qualités et défauts de ces deux librairies ? Facilité d'installation, stabilité, rapidité... À+

→ **MyCalcs** profile · de **Lionel Debroux** » 14 Oct 2014, 20:00

Flib se présente en deux programmes ASM flib et flib2 de moins de 8 KB, pour pouvoir être lancés même sous AMS 2.00-2.03 qui ont par défaut une stupide limite de taille à 8 KB pour les programmes ASM et chaînes Exec. Pas besoin d'installation autre que le transfert. Stable, et rapidité doublement limitée par l'OS: chargement - déchargement du programme (le chargement comprend une copie en RAM si le programme est archivé) et fonctions graphiques lentes.
Je connais mal Vertel, mais elle a forcément quelque chose que Flib n'a pas.

J'ai fait un tout petit peu de BASIC augmenté par Flib au printemps 2001... avant de passer au C, puis C+ASM dès l'été 2001, pour m'affranchir des limitations techniques du BASIC.

→ **MyCalcs** profile · de **zorglub13** » 16 Oct 2014, 17:58

2001, cela ne nous rajeuni pas comme disais l'autre... Et la, tout d'un coup, la TI89 passe dans le rayon des antiquités... Je vais peut être refaire un peu de C. Pour Tigcc, vaut-il mieux travailler avec la dernière bêta ou la dernière stable ? La gestion des toolbar, menus déroulant, affichages graphiques sont-ils gérés par des librairies intégrées au Tigcc ? Merci

→ **MyCalcs** profile · de **Lepzulnag** » 16 Oct 2014, 18:16

Flib et Vertel permettent d'exécuter des commandes graphiques vraiment rapidement. Flib est un peu plus simple à comprendre que Vertel, mais également un peu plus lent.

Il y a 3 versions de Vertel, et la plus rapide est sans conteste la 2e.

→ **MyCalcs** profile · de **Lionel Debroux** » 16 Oct 2014, 18:31

La dernière beta de TIGCC aura 8 ans à la fin de ce mois-ci. La dernière release est encore bien plus vieille, et à éviter car elle a moins de features et plus de bugs. Ca fait plusieurs années qu'il n'y a plus aucune maintenance sur TIGCC, pas même la correction de bugs reportés qui crashent les machines.

GCC4TI a moins de bugs, plus de features (principalement issues de contributions à TIGCC effectuées en 2002-2003 mais jamais traitées), plus d'optimisations (librairie de base, dont SAVE_SCREEN, optimisations et améliorations des routines de sprite effectuées en 2002, 2003 et 2005 mais jamais traitées).
Le système de build de GCC4TI est moins nul, c'est à dire qu'il s'arrête à la première erreur plutôt que de laisser silencieusement un build incomplet se produire, il fonctionne sur MacOS X et FreeBSD, et permet de cross-compiler les exécutables Windows (hors Delphi) depuis Linux, ce qui réduit la difficulté de production d'une nouvelle release pour Windows.
Les gcc et binutils de GCC4TI sont préfixés, comme dans toute bonne cross-toolchain, ce qui fait qu'on peut ajouter $TIGCC/bin dans le PATH avant /usr/bin sans masquer gcc, as et les binutils du sytème hôte. Ah, le tigcc.exe de GCC4TI fonctionne bien sous Vista et ultérieur, aussi...

Tu ne sera pas surpris si j'écris que la plupart des programmeurs TI-68k "actifs" ces dernières années sont passés à GCC4TI. Mais je ne travaille que très peu sur GCC4TI (et TIEmu, d'ailleurs), tout simplement parce qu'il y a très peu d'utilisateurs, encore moins que pour libti*/gfm/tilp.

Voir ma signature pour le téléchargement. Si tu es sous Windows, j'ai fait un build cette année pour quelqu'un d'autre: http://tiplanet.org/beta/gcc4ti-win.zip , http://tiplanet.org/beta/tigcc.exe , http://tiplanet.org/beta/tigcc.chm (documentation).
Utilisation de ces fichiers:
1) installer GCC4TI 0.96 Beta 10;
2) décompresser le contenu de gcc4ti-win.zip vers le répertoire où tu auras installé GCC4TI (attention, il faut prendre le contenu du sous-répertoire gcc4ti-win, ou demander à ton décompresseur d'éliminer le préfixe gcc4ti-win, s'il sait faire);
3) copier tigcc.exe à la racine du répertoire d'installation et/ou dans le sous-répertoire bin (enfin, là où il existe déjà, quoi);
4) copier tigcc.chm dans doc.

→ **MyCalcs** profile · de **zorglub13** » 19 Oct 2014, 07:13

Bonjour

Merci pour ces informations...

Je cherche quand même un environnement de programmation stable (je ne veux pas passer du temps a essayer de comprendre un bug si celui-ci provient du compilateur)...

Qu'en est-il au niveau des possibilités des librairies accompagnant gcc4ti dans le domaine de l'interface utilisateur ? J'ai vu qu'il y a des sprites, mais pour la gestion des menus déroulant, les barres de menus, les boites de dialogue ?

Bon Dimanche

→ **MyCalcs** profile · de **Lionel Debroux** » 19 Oct 2014, 07:41

Je cherche quand même un environnement de programmation stable (je ne veux pas passer du temps a essayer de comprendre un bug si celui-ci provient du compilateur)...

Les bugs de génération de code sont rares avec TIGCC/GCC4TI (beaucoup moins avec la toolchain de merde de TIFS, le SDK officiel pourri). Mais de toute façon, même si tu rencontrais un de ces improbables bugs (et il y en a un de moins dans GCC4TI que dans TIGCC), la seule solution serait d'écrire ton code légèrement différemment

La toolchain utilisée dans GCC4TI est un fork des vieux binutils 2.16 et GCC 4.1.2. Forward porter les changements à GCC est une quantité importante de boulot de codage, et encore plus de tests, d'autant qu'on sait qu'il y aurait des régressions avec des versions plus modernes ( https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40454 ), tout ça pour quasiment zéro utilisateurs. Recréer une nouvelle toolchain a déjà été évoqué par certains, par exemple une cross-toolchain m68k-elf (donc incompatible avec tous les binaires existants, qui sont COFF ou AmigaOS). Cependant, ça ne s'est jamais matérialisé, car s'il n'est pas difficile de compiler une cross-toolchain m68k-elf, la rendre compatible avec les spécificités de la toolchain de TIGCC/GCC4TI - condition préalable pour que la nouvelle toolchain ait une chance d'être utile et donc utilisée - représente également beaucoup de boulot.
Certains des changements du fork de GCC inversent purement et simplement des changements incompatibles réalisés dans GCC qui entraînaient des régressions, donc ils n'auraient pas pu être contribués à GCC. D'autres parties auraient en revanche pu (dû ?) l'être en 2004-2006, bien avant GCC4TI, quand il était encore temps, mais ça n'a pas été fait.

J'ai vu qu'il y a des sprites, mais pour la gestion des menus déroulant, les barres de menus, les boites de dialogue ?

Voir les docs des headers dialogs.h et menus.h. Ces fonctionnalités utilisées dans AMS lui-même, et fournies en BASIC, sont également accessibles directement en code natif

AMS 2.05 et versions ultérieures exposent plus de 1500 ROM_CALLs dans la jump table, voir TIOS_entries. La majorité de ces entrées sont documentées, surtout dans GCC4TI, qui intègre la documentation de dizaines d'entrées supplémentaires, contribuées à TIGCC en 2002 et 2003 principalement, mais jamais traitées, comme un certain nombre de contributions à TIGCC.