Forum

Je me permets d'intervenir rapidement sur ce sujet, étant un habitué de Cemetech de plus longue date que cakeisalie5
Sur des sujets techniques: il y a une certaine concentration de gens compétents techniquements sur Cemetech. Maintenant, les habitués des années précédentes ont vieilli et sont moins actifs.
Sur des sujets non techniques: un abondant linge sale, pas toujours visible, qui concerne notamment la Prizm.

- "features utiles" c'était quoi ? On bave !

Je me souviens de "Ptr2Hd" (retrouver l'éventuel HANDLE d'allocation à partir d'un pointeur même s'il ne pointe pas au début du bloc, feature fournie par les "kernels" depuis des années), des fread et fwrite plus rapides que celui de TIGCC (qui sont eux-mêmes beaucoup plus rapides que les terribles merdes moins puissantes embarquées par TI dans AMS 2.xx et 3.xx). Il devait y avoir quelques autres features non transcendantes mais elles aussi réclamées par plusieurs personnes au fil des années, et refusées abruptement ("ne sert à rien" était une phrase courante). GCC4TI a Ptr2Hd mais pas ce qui a été connu sous le nom de "fread/fwrite_fast".
Parmi les choses qui n'étaient pas explicitement refusées mais dont l'intégration n'a pas été faite pendant environ 7 ans, jusqu'à GCC4TI, il y avait par exemple les routines de sprite. Aucune justification valable pour l'absence d'intégration: côté non technique, ça n'aurait pas pris beaucoup de temps, et côté technique, la version améliorée était à la fois plus petite et plus rapide, tout en gérant un mode supplémentaire de dessin (RPLC) !

- "un but considéré comme déraisonnable" c'était quoi ??

Se débarrasser ASAP de l'IDE Delphi pour Windows et le remplacer, même sous Windows donc, par l'IDE basé sur l'énorme framework KDE 4, parce que "KDE 4 fonctionne sous Windows" et qu'il voulait se débarrasser d'un environnement propriétaire. Non seulement ça aurait fait télécharger des centaines de MBs de dépendances exotiques aux utilisateurs de TIGCC sous Windows, mais surtout, KDE 4 fonctionnait encore beaucoup plus mal sous Windows que sous Linux, ce qui n'était pas peu dire. KDE 4 n'a pas été utilisable avant 4.3 au plus tôt (donc une bonne année après 4.0), quoi que cet extrémiste de KDE ait pu en penser.
Presque 9 ans plus tard, KDE 5 - dont l'API est encore différente, elle changeait de toute façon même de 4.x à 4.(x+1) - fonctionne vraisemblablement moins mal sous Windows... mais pour autant, ça reste toujours vrai, comme nous le prévoyions (ça n'était pourtant pas difficile), que presque personne ne l'utilise sous Windows !

- TILP : j'ai tenté mais un truc a bloqué (je ne sais plus quoi), il y a peut-être moyen de packager tout pour rendre l'installation facile ? Je réessaierai.

TILP est packagé par Debian, Arch, Fedora, openSUSE et j'en passe.
Et pour avoir la version de développement qui a toujours plus de features et moins de bugs, le script d'installation https://ti-pla.net/tilpinst fournit les listes complètes de dépendances de build pour 6 familles de distro Linux. L'auto-détection de la distro et l'installation des dépendances de build en fonction de ce qui a été détecté est plus que chiante, donc la commande prête à l'emploi est déjà un excellent compromis

- "libhpcalcs... tout le monde se fout..." détrompes-toi ça m'intéresse, cependant comme l'outil HP officiel est gratuit (Casio, tu m'entends ???) et permet l'édition de programmes sur le GroPécé (TI tu m'entends ???), le public sera plus limité. Si tu as un bel éditeur avec coloration sytaxique, bibliothèques à copier-coller, ben j'achète !

Non, libhpcalcs vise purement à gérer des fichiers et de la communication avec les HP Prime. C'est l'effort communautaire le moins mauvais existant pour ce faire, mais ça ne veut pas dire qu'il fonctionne super bien. Faute d'utilisateurs, je n'ai pas pris le virage des transferts compressés que permettent les OS modernes, pas plus que du code de transfert d'OS (aussi bien sur les vieilles machines que sur les nouvelles). Et puis il n'y a aucune interface graphique.
Il y a eu un beau logiciel de transfert tiers pour PC, en C# spécifique à Windows, avec éditeur fournissant la coloration syntaxique, doc des commandes HP PPL, et tout. Et il est vite tombé dans l'oubli parce que le mainteneur s'est concentré sur ces fonctionnalités visibles, même jolies, et a oublié le fondamental du fonctionnel d'un logiciel de communication (sans même parler, non-fonctionnellement, de l'architecture monolithique, de la complète non-portabilité et non-interopérabilité de son code, que je lui ai signalées): il n'a implémenté qu'une façon bizarre et moins puissante de communiquer avec la machine... façon presque tout de suite enlevée par HP. Je ne l'ai jamais implémentée par libhpcalcs parce que ce n'est pas ce que faisait le CK officiel de HP dans son mode normal, et bien m'en a pris.

- "TIGCC et par suite GCC4TI gèrent en effet le debug symbolique, mais pas avec VTI"
Oulà en lisant entre les lignes on a l'impression que c'est un gros bazar... j'abandonne.

En théorie, c'est très simple: il faut compiler avec les infos de debug (-g avec GCC), et faire charger à TIEmu+GDB un binaire qui a les infos de debug, ou importer plus tard les infos de debug, je ne sais même plus.
En pratique, il faut composer avec les limitations et bugs de TIEmu+GDB que j'ai détaillés précédemment.

- GCC4TI plus facile à builder que TIGCC : qui builde ses outils de nos jours ?

Les développeurs encore

Il faut aller sur Git ou Sourceforge,

Pas très compliqué

il faut une machine Linux

C'est de moins en moins vrai, avec des choses comme Conan ou vcpkg pour Windows, et brew pour MacOS X. Mais c'est un fait que Linux est davantage fait pour les devs que Windows et MacOS X.

il y a sans cesse des dépendances qui sont obsolètes / incompatibles etc... Vive les librairies statiques !

Dépendances obsolètes et incompatibles, ça arrive à certains projets, oui. Moins à des toolchains comme GCC4TI qui, justement, ont peu de dépendances.
En revanche, clairement, aux chiottes les librairies statiques, en général. Sur ordinateur comme sur embarqué, comme les gens ne les mettent pas à jour, c'est une terrible source de failles de sécurité, donc c'est plus néfaste qu'autre chose

Après si c'est plus facile, très bien, mais est-ce FACILE ?
Genre un zip à charger, quelques commandes à passer et go ?

Ben... pour TIGCC, pas du tout, mais pour GCC4TI, oui, comme l'indique le README affiché sur ce qui est de fait une page officielle à https://github.com/debrouxl/gcc4ti/ : 4 commandes sans le clonage du repo, mais on peut se passer du clonage en utilisant la "feature" de Github permettant de télécharger un ZIP

"jouer sur les flags passés à la toolchain" ça fait un peu peur... on n'est pas à 10 Ko près souvent,

Sur ordinateur, non, clairement. Mais sur la calculatrice, carrément. 10 KB, c'est plus de 5% de la RAM utilisable sur TI-68k !

par contre tourne/tourne pas ça compte.

Justement, je ne t'ai donné que les flags les plus sûrs pour la toolchain qui génère des programmes pour calculatrice (pas pour la (cross-)toolchain permettant de compiler la toolchain, bien sûr)

Je plaide pour le béotien (moi...). Pourquoi pas deux versions, une packagée sans choix possible qui marche dans 99.999% des cas et une autre avec les tripes à l'air, les version qui changent tout le temps etc etc...?

Hmm... je ne comprends pas de quoi tu parles, là. De la toolchain ordinateur, peut-être ?

- GTC : très alléchant, je n'ai pas regardé.

Ce qui est le plus alléchant dans GTC, c'est la compilation on-calc. C'est à la fois plus puissant et moins instable que les vieux cc/as on-calc, même si ça n'est pas parfait (il faut laisser le maximum de RAM libre pour minimiser les problèmes). Sur PC, GTC est une toolchain plus datée que GCC4TI - en particulier, pas le linker spécial avec optimisation de TIGCC 0.95+ et GCC4TI, pour autant que je sache. GTC ne pourrait pas compiler tels quels un certain nombre de programmes de TICT, dans lesquels j'ai trafiqué le code avec des spécificités de GCC non toutes implémentées dans GTC, pour plus d'optimisations.

Apparemment il manque un moyen de faire connaître le projet, et avec les TI68K poussées dans le fossé obstinément par TI depuis 10 ans, ce n'est pas gagné.

Tu sembles encore raisonner comme s'il y avait quelque chose à faire pour la communauté TI-68k... Ca fait 10 ans qu'elle est morte, et plus de 8 ans que j'ai pris conscience qu'il n'y avait déjà plus rien à faire (quand la sortie de GCC4TI avec un modèle de développement plus ouvert n'a rien déclenché).

- "lancement dynamique d'autres morceaux de code exécutables" ok je vois, quels exemples d'utilisation (concrets) ?

Ben... tout simplement émuler une V200 ou une 89T, aussi
Trois des bugs et manques d'émulation de VTI (bits non existants dans le SR, GIGO sur l'instruction nbcd, absence d'émulation du micro-pipeline) sont utilisés pour empêcher l'exécution directe de HW3Patch sur VTI. Mais après ça, les protections anti-reverse-engineering de HW3Patch sont très faibles, un simple décodeur XOR (ou NOT, je ne sais plus, mais NOT est un XOR avec la pattern de 1). HW2Patch par JM était plus difficile à comprendre.

Sinon dans le domaine émulateurs etc, que penses-tu de celui disponible en ligne sur Cemetech ?

Du mal, comme toi.

Impossible de récupérer une version qui tourne de façon autonome sur un PC non connecté.

Ca va même plus loin que ça: le code est fait de telle sorte qu'on ne puisse pas l'utiliser sur un autre site, à la fois par la façon dont il fonctionne et par l'obscurcissement intentionnel du code, qui est un effet de bord pratique du minimiseur de JS. Et puis techniquement, il a été fait bien avant qu'asm.js existe (maintenant, WebAssembly), et il est donc un représentant de la mauvaise façon de développer du JS de nos jours: à la main (il n'y avait pas le choix à l'époque), plutôt qu'en utilisant Emscripten pour compiler du C/C++ en ciblant WebAssembly. Il faudrait le reprendre à zéro.
J'avais travaillé sur un émulateur de TI-68k en JS, non lié à un quelconque site, en modifiant lourdement le travail créé par Patrick Davidson. Mais j'ai abandonné à la fois par manque de temps et parce qu'écrire à la main n'était pas la bonne approche.
Il y a eu des protos de CEmu et Firebird, respectivement émulateurs de TI-eZ80 et Nspire, tous les deux écrits en C++, ciblant WebAssembly.

En d'autres termes, tout ce que tu fais est en ligne visible par... on ne sait pas qui. Dommage, est-ce pour ne pas indisposer TI ? J'ai de la peine à le croire.

Ne pas indisposer TI et avoir une grande gloire pour lui et Cemetech (quitte à tenter de salir gravement, à tort et heureusement sans succès, la réputation des autres auxquels il doit pourtant beaucoup) sont en effet manifestement des buts de l'admin principal de Cemetech et de certains de ses copains. La phrase précédente montre que ça aussi est un sujet sur lequel il y a du linge sale à déballer, mais je vais bien sûr m'en abstenir

Pareil pour le truc qui permet de créer des PDF lisibles sur Nspire (ok ok mauvais choix, mais bon) disponible sur TI Planet.

Convertir du texte simple ou légèrement formatté (type syntaxe txtrider) en un format texte lisible par un lecteur on-calc, c'est facile, et faisable en JS côté client.
Convertir des images et des PDF, dans un format de stockage raisonnablement efficace côté calculatrice, et en particulier pour les Nspire, s'adapter au format de fichiers complètement tordu qu'elles utilisent... je peux te dire que c'est beaucoup moins simple qu'un convertisseur de texte simple ou légèrement formatté, et aussi qu'un émulateur en ligne
Je peux aussi te dire, parce que ça correspond à notre expérience, qu'installer un logiciel côté client dépasse la compétence de beaucoup d'utilisateurs du convertisseur en ligne, et qu'un tel convertisseur en ligne gagne du temps à tout le monde. C'est triste, mais c'est ainsi. Et oui, bien sûr, il pourrait y avoir un problème de confidentialité si ceux qui ont accès au serveur regardaient les documents... ce qui n'est évidemment pas le cas en pratique, pour plusieurs raisons, dont, d'ailleurs, le volume dû à la popularité de l'outil !

TI-Planet fournit aussi un Project Builder, avec fonctionnalité de compilo en ligne et IDE collaboratif temps réel, principalement pour TI-(e)Z80. Il a toujours été prévu d'ouvrir le code de celui-là, d'autant que l'architecture modulaire permettrait de l'étendre à d'autres plate-formes - mais faute de revue sécurité (ça, c'est partiellement de ma faute... il faut pouvoir y passer du temps), ça n'est toujours pas fait.

En lisant ton post je vois beaucoup de critiques, reproches et autre amertume.

Difficile d'expliquer un certain état de fait sans tomber dans le linge sale de la communauté. C'est valable pour presque toutes les communautés humaines de façon générale

Tu perds ton temps je pense, dommage.

C'est devenu exceptionnel que je parle de ce linge sale-là (auquel j'ai donc participé), en fait. Je pense que ça fait une bonne année que je ne l'avais pas fait
Et même avant, j'étais beaucoup moins systématique en attaques personnelles que l'autre, qui recourait de plus au mensonge, en particulier contre moi. Sans résultats durables (hormis le fait de décourager certaines personnes de participer à la communauté) puisque les faits sont les faits, et qu'à l'époque, les alternative facts étaient moins à la mode.

Les bugs et le debugging me passent au-dessus de la tête, peut-être à tort.

L'aspect néfaste des bugs et limitations des outils obsolètes est qu'ils peuvent te faire perdre du temps pour rien, ce qui est toujours dommage.
Avec VTI en particulier, certains cas d'utilisation comme le lancement dynamique d'autres morceaux de code exécutables (le nombre de ceux, en particulier débutants, qui ont essayé n'est pas négligeable) semblent beaucoup plus simples qu'ils ne sont en réalité. Les machines réelles (et TIEmu) disposent de protections non émulées par VTI, et des programmes qui semblent fonctionner avec VTI crashent tout simplement les vraies machines, avec pertes de données.
Un autre bug de TIGCC corrigé dans GCC4TI s'avère pénible à l'utilisation pour une proportion significative du peu d'utilisateurs, mais si tu étais dans les conditions d'utilisation qui le déclenchent (il suffit d'avoir une machine Windows Vista ou ultérieur avec l'UAC activé, et un nom d'utilisateur de plus que quelques caractères), tu t'en serais déjà rendu compte

Est-il nécessaire qu'un outil basé sur des trucs qui ne bougent pas depuis 15 ans, reçoive des mises à jour incessantes ?

Nécessaire, non. Mais s'il y a une communauté significative d'utilisateurs, à mon avis souhaitable, oui.
Par exemple, avoir une toolchain plus moderne que les forks assez lourdement patchés de GCC 4.1.2 + binutils 2.16.1 utilisés par GCC4TI et son ancêtre mort donnerait accès à des versions plus modernes du langage C, et habituellement un code généré un peu plus optimisé... bien que sur les plate-formes secondaires ou tertiaires, un upgrade de GCC ne soit pas toujours exclusivement bénéfique de ce point de vue. Le dernier gros upgrade de GCC, 3.4 -> 4.0/4.1, avait été plutôt bénéfique, une fois les gros bugs initiaux du portage corrigés et une passe d'ajustements réalisée.

Bref, ce qu'il nous faut ce serait de l'aide pour la mise en oeuvre, des exemples à un niveau faible qui est le mien, des conseils. Si tu pouvais expliquer simplement ce que sont les divers trucs dont tu parles, pourquoi ils sont intéressants, ce qu'ils font, comment les utiliser ?

Suivant ce que tu appelles "divers trucs", j'en ai peut-être mentionné pas mal dans mon message. Et il est parfaitement évident pour moi que tu attends beaucoup mieux que l'irrespectueux et contre-productif "tu n'as qu'à lire le manuel !", dans la mesure de mes connaissances bien sûr. Connaissances qui sont basses pour l'utilisation pratique de GTC, Newprog / GFA-Basic / presque tous les langages alternatifs.
Donc - sur quels aspects voudrais-tu que je me concentre plus particulièrement ?

Quelques notes en attendant... dis-moi si je tombe complètement à côté:
* pour la simplicité d'utilisation, l'IDE Delphi Windows et de son format natif de projets "TIGCC Projects" (TPR) qu'il utilise est la bonne façon de démarrer. C'est ainsi que les exemples fournis sont packagés, et c'est suffisant pour beaucoup de projets. Pour des utilisations plus avancées, j'ai vite rejoint l'avis d'utilisateurs à l'époque plus expérimentés, qui avaient posté qu'ils n'aimaient pas du tout, mais sans expliquer d'une manière que j'avais pu voir ou comprendre, donc j'avais passé certains programmes vers les TPRs avant de me prendre les limitations dans la figure.
* si tu préfères écrire des makefiles ou des scripts de build, le front-end est "tigcc". Appeler directement les gcc, as, etc. internes (leur nom est préfixé dans GCC4TI, comme dans toute cross-toolchain bien élevée, plutôt que de créer des conflits avec les exécutables du système) n'est pas vraiment prévu.
* pour optimiser ton code pour la plate-forme TI-68k, en jouant sur les flags passés à la toolchain: dans les options du projet, tu peux presque toujours utiliser toutes les optimisations du linker, jouer sur les types de tables de relocation, et pour le compilo C, -mregparm=5 -fomit-frame-pointer -ffunction-sections -fdata-sections -Wa,-l. Souvent, on peut également passer -mpcrel au compilo C. Pour plus de détails et de finesse à la fois sur les flags et sur certaines façons d'écrire du code plus petit et/ou plus rapide (par exemple, presque toujours, éviter les BSS inefficaces sur cette plate-forme), tu pourras jeter un coup d'oeil au tutorial "S1P9" téléchargeable depuis http://tict.ticalc.org/ .
* pour la communication avec les vraies machines, il y a deux solutions: TI-Connect 4.0 officiel (pas la version CE, qui ne gère plus les TI-68k; pour Windows + MacOS X) ou TILP II non officiel, pour Windows + MacOS X + Linux + certains BSDs.

Oui le Forth est certainement mort, disons qu'on peut s'amuser à en faire un.

Ah, mais tout à fait
Je voulais surtout signifier que les solutions existantes Ultra Pascal et Forth n'étaient à ma connaissance pas finies.

Alors, dans l'ordre:

* à peu de choses près, tous les programmeurs en C sur TI-68k ont utilisé TIGCC, ou de nos jours, son fork un peu moins obsolète GCC4TI;

* disons tout de suite que je ne suis pas neutre sur le sujet TIGCC / GCC4TI, étant un des co-créateurs en 2008 et le mainteneur de GCC4TI. Mais je vais baser mon argumentation sur des faits vérifiables que j'ai déjà utilisés à de nombreuses reprises par le passé, je ne crains absolument pas une éventuelle vérification si vous avez vraiment du temps à perdre.
Le fork a eu lieu pour des raisons à la fois techniques (refus nets d'intégration de features utiles pour des motifs discutables, non traitement des contributions, annonce par le mainteneur comme priorité d'un but considéré par tout un groupe d'utilisateurs comme non prioritaire et déraisonnable à l'époque, et d'ailleurs toujours déraisonnable 9 ans plus tard, etc.) et non techniques (le mainteneur de TIGCC est un empoisonneur au sens psychologique du terme, et reste une des personnalités les plus détestées de la communauté, même encore des années après qu'il ait cessé de participer, parce que les anciens se souviennent encore bien des dégâts; il s'est également fait remarquer en mal dans d'autres communautés libres beaucoup plus importantes et actives, donc ce n'est pas seulement nous qui posons problème);

* inutile de suivre TIGCC de près: il n'est plus maintenu. Aucune release de TIGCC n'a été produite depuis plus de 10 ans, plus de 2 ans avant la publication de la première version de GCC4TI début 2009;

* peu utile également de suivre GCC4TI de près: il ne s'y passe pas grand chose non plus. Non pas que ça ne m'aurait pas amusé davantage que la maintenance de libti*/gfm/tilp à une époque, mais soyons réalistes: ceux-là (seule vraie implémentation non TI du code de communication avec les calculatrices graphiques de TI, tous modèles confondus; modèle dont je me suis très lourdement inspiré pour faire libhpcalcs, ayant le même but pour la HP Prime, et dont tout le monde se fout notamment parce que pas grand monde ne s'intéresse à la Prime, malgré ses qualités matérielles) ont bien plus d'utilisateurs (pardon, "bien moins peu d'utilisateurs") qu'une toolchain lourdement obsolète ciblant une plate-forme dont la communauté était quasi-morte depuis plus d'un an et demi avant la création de GCC4TI.

* TIGCC et par suite GCC4TI gèrent en effet le debug symbolique, mais pas avec VTI;

* VTI est un vieil émulateur, présentant un certain nombre de bugs bien connus, et incapable d'émuler un tant soit peu fidèlement les TI-68k du 21ème siècle: la gestion des HW1 n'est déjà pas parfaite, et depuis environ 1999, il n'y a plus que des HW2 et ultérieures. Les V200 sont HW2, les 89T sont HW3/HW4, et les deux, qui apportent des changements significatifs, sont bien postérieures à VTI. Ca ne veut pas dire que VTI soit inutilisable en pratique, puisqu'on peut faire un certain nombre de choses en se limitant aux 89/92+ HW1; il faut juste être conscient de ses limitations.

* le seul émulateur qui gère le debugging symbolique est la version GDB de TIEmu. L'intégration de GDB a été responsable d'une complexification et d'une salissure massive de la base de code et du système de build, qui a largement contribué à rendre in-maintenable le projet. Sans parler à la fois du ralentissement de l'exécution et de la baisse de fiabilité. J'ai coutume de décrire TIEmu+GDB comme un mélange fou d'event loops et de forks patchés de versions lourdement obsolètes de divers logiciels libres, collé ensemble par un système de build fragile, qu'à ma connaissance, personne n'a testé depuis des années. Oui, c'est moi aussi qui suis censé être le mainteneur de ce b*, et pour le coup, je ne maintiens plus rien depuis des années, à cause de la complexité immense et du nombre d'utilisateurs ridiculement bas.
Bref... si tu arrives à faire fonctionner le build Windows obsolète de TIEmu+GDB 3.02, tant mieux pour toi, mais je conseille très fortement le build Windows de TIEmu-GDB 3.03, qui a moins de bugs et plus de features. Si tu arrives à builder le projet, même sans GDB, tant mieux pour toi aussi... même si je suppose que la situation n'est en réalité pas si horrible que ça, TIEmu étant toujours packagé par Debian et les distros dérivées. Heureusement que le créateur et précédent mainteneur de TIEmu a toujours insisté pour que la version sans GDB reste utilisable, même si faire ainsi a augmenté la complexité de la base de code: au moins, des années après, il reste une version utilisable.

* GTC n'est pas une version on-calc des énormes GCC+binutils, c'est un effort indépendant de développement par l'excellent Paul "Pollux" Froissart, qui fonctionne on-calc et on-computer (avec un peu plus de capacités pour cette dernière version, bien entendu). Le projet n'a jamais recontré le succès que le travail correspondant aurait mérité: c'est du boulot de faire un compilo C avec intégration ASM fournissant autant de features sur une plate-forme aussi limitée. Pourquoi, me direz-vous ? Largement à cause de gros bâtons non techniques lancés par le mainteneur de TIGCC dans les roues de Pollux... On a toujours pensé qu'il voyait tout concurrent de TIGCC comme une menace, et il n'a d'ailleurs pas essayé d'agir autrement avec GCC4TI.

* inutile d'utiliser des ROMs, les OS upgrades disponibles en téléchargement gratuit depuis le site de TI conviennent pour tous les usages autres que, en gros, désassembler et debugger le code de transfert de l'OS. Ce qu'environ 2 personnes de la communauté ont dû faire en plus de 20 ans (si on compte les TI-92).

* le Forth ou l'Ultra Pascal ont rencontré encore moins de succès que divers langages plus ou moins custom faits par des tiers pour les TI-68k: Newprog, GFA-Basic, et d'autres (certains ayant souffert des attaques du mainteneur de TIGCC). Des portages expérimentaux de Lua et Python-on-a-chip (p14p) avaient été réalisés, mais ils ont vraiment zéro utilisateurs


Vous pouvez tout à fait continuer à utiliser TIGCC... c'est juste que vous aurez moins de features et plus de bugs connus qu'avec GCC4TI qui a bénéficié de travaux de:
* portabilité, automatisation et fiabilité du système de build: l'original ne fonctionnait (presque) bien que sous Linux, ne s'arrêtait pas à la moindre erreur (donc produisait des builds incomplets, ce dont l'utilisateur peut ne se rendre compte que bien plus tard), ne gérait pas la cross-compilation, et autres problèmes majeurs. Et d'ailleurs, les sources de TIGCC dans CVS (...) sont tout simplement incomplets, ça va bien que le morceau manquant était dans un tarball de release...
* correction de bugs connus, certains (dans du code rarement utilisé) crashant les machines - ou même des choses aussi simples que les exemples de code fournis qui ne compilaient pas ou dont les noms on-calc entraient en collision;
* intégration de vieilles contributions pourtant utiles (enfin... moins 7-9 ans plus tard et après la mort de la communauté de programmeurs, forcément... d'ailleurs, elles n'ont pas toutes été intégrées) mais jamais processées. Largement mes propres contributions, parce qu'elles étaient parmi les plus abondantes; j'aurais aimé pouvoir ne pas être être juge et partie;
* optimisation de la librairie, par exemple -16 octets sur le morceau le plus fréquemment utilisé et donc le plus dupliqué du code de startup;
* ajout de quelques features mineures, dont des choses dans le linker pour faciliter la production de l'OS tiers libre PedroM, ou encore quelques fonctionnalités pour faciliter le portage de programmes ANSI C vers les TI-68k (quand j'ai repris les vieux travaux de portage de Lua 5.0.x et que j'ai essayé de porter p14p).

Avec TIGCC, vous n'aurez personne à qui reporter les bugs. En 2009, c'est déjà moi qui ai corrigé dans GCC4TI des bugs reportés à TIGCC, les fixes n'ont pas été reportés dans TIGCC...

Il n'y a certes pas eu de nouvelle release de GCC4TI depuis 2009, mais pour les non-Windows, le code compile directement depuis Git en enchaînant environ 3 commandes, et pour Windows, un ZIP overlay (à utiliser après installation de GCC4TI 0.96 Beta 10) a été publié notamment sur TI-Planet. Cause: manque de temps de ma part, et manque d'utilisateurs. Nous avions correctement identifié le système de build comme un gros point noir de TIGCC, qui emmerdait à la fois les utilisateurs et les mainteneurs... et si nous n'avons fait qu'une fraction des idées que nous avions, nous avons au moins préparé le projet pour la phase "mort lente" dans de meilleures conditions, contrairement à l'original non maintenu.


Bouh, quel vilain pavé. On va arrêter là pour ce soir

Les procédures de sortie des modes PTT des diverses machines sont documentées par TI sur Internet
Pour la Nspire, il faut transférer un fichier, de contenu quelconque (y compris vide), avec le nom adéquat. Ce comportement permet de transférer des documents utiles à l'examen, et/ou des questionnaires à remplir par les étudiants (certains enseignants font leurs contrôles ainsi, surtout en Amérique du Nord), après activation du mode PTT.
Les 83PCE et 84+CE(-T), par exemple, ne se comportent pas ainsi: elles sortent des modes PTT usuels quand on essaie de transférer des fichiers, quels qu'ils soient.
Bien sûr, les étudiants ne sont pas censés pouvoir transférer des fichiers à leur machine depuis la salle d'examen.

Oui. La famille Classpad est beaucoup trop chère au tarif normal, le tarif enseignant est nettement plus honnête. La fx-CP400+E n'est qu'une évolution mineure de la FX-CP400, elle-même pas une révolution par rapport aux CP300 et CP330 d'il y a plus de 10 ans...
Un grand écran couleur tactile, certes, mais toujours cette lenteur à l'usage malgré un matériel a priori puissant. Les utilisateurs de Nspire CX (CAS) et de Prime ne souffrent pas ainsi en usage normal.
Le bridage par défaut des applications utilisateur est commun aux modèles haut de gamme des trois principaux constructeurs, mais les Nspire CX (CAS) sont plus populaires et les gens se soucient donc de les ouvrir de force, et la Prime est une machine ouverte, comme l'ont montré les expériences sur le firmware officiel trafiqué et les deux firmwares tiers full custom, donc les Classpad sont en pratique plus fermées.

Le 68000 est en effet bien plus sympa à programmer que le Z80 (et l'eZ80, d'ailleurs), grâce à beaucoup plus de registres, de modes d'adressage et d'instructions avancées (multiplication 16x16->32, division 32/16->16, move multiple, etc.).
Les ARM7, pourtant RISC, ont eux aussi des move multiple et des modes d'adressage prédécrémenté / postincrémenté, par exemple.

Le triplet 83PCE/84+CE/84+CE-T muni d'un eZ80 est justement un gros changement par rapport aux TI-Z80.
Mais c'est clair qu'ils auraient pu faire beaucoup mieux, en utilisant de la RAM et de la Flash de vitesses plus proches de celle du CPU, et en augmentant les quantités de RAM et de Flash.

Les 83PCE / 84+CE / 84+CE-T adoptent quelques éléments des TI-68k, tels que:
* l'espace d'adressage 24 bits à plat, grâce à l'eZ80 utilisé en mode eZ80, ce qui est la même chose que le 68000 possédant un PC 32 bits mais un bus d'adresses 24 bits;
* la quantité totale de RAM: 256 KB;
* la quantité utilisable de RAM, avec ~154 KB indiqués, un peu moindre de celle d'une TI-68k sur laquelle on peut habituellement compter sur 170-180 KB sous AMS;
* le format de FlashApps, maintenant contiguës et avec le même format de champs certificate et de relocations que les FlashApps TI-68k/AMS;
* quelques morceaux faits en C, avec une convention d'appel en C. L'eZ80 est moins mauvais pour la programmation en C que le Z80, même s'il est très loin d'être aussi adapté que le 68000, qui était vraiment fait pour depuis l'origine: beaucoup de registres pour l'époque, 16/32 bits, instructions type lea et pea.

La 83PCE offre un moteur de calcul exact, absent des 84+CE(-T), ce qui est bien sûr nettement moins bien qu'un CAS, mais adapté à l'usage scolaire de plus en plus basique qui est fait de la calculatrice, en France en particulier. Et l'écran couleur est maintenant un must pour les nouveaux designs, depuis les Casio Prizm et Nspire CX (CAS) en développement simultané en 2010-2011.

Les TI-eZ80 sont actuellement gréées pour pouvoir évoluer vers 8 MB de Flash sans changement significatif de l'espace d'adressage. Les 89T l'étaient aussi, et leur boot code + OS sont capables de gérer 8 MB, mais aucune 89T équipée de 8 MB de Flash n'est hélas connue.

La 89T reste une bonne machine, même si elle est hélas vendue à des tarifs délirants.
Ses avantages par rapport à la 89 sont en effet, comme le mentionne BubbleBobble:
* le double de mémoire Flash totale, donc plus de 4x plus de mémoire FlashApp / archive utilisable (comme la V200);
* le port mini-USB, avec un contrôleur capable host (forcément, puisqu'il y a des transferts de machine à machine), qui permet des transferts plus rapides (assez rapides, mêmes), évite d'avoir à se procurer un SilverLink à 20-30€, et peut être utilisé pour faire tout à fait autre chose que le protocole de communication "standard" de TI: des choses comme clavier HID, souris HID, MSD de ~2 MB (assez pour embarquer un kernel Linux x86 + NTPasswd), port série type PL2303, ou encore un des jailbreaks de la PS3 à l'époque, ont été codées.
La vitesse n'est pas vraiment différente de celle d'une 89.

Fait amusant: l'espace d'adressage, le boot code et l'OS des 89T sont prévus pour gérer des chips de 8 MB de Flash. Aucune 89T réelle connue n'en dispose, hélas...

le logiciel de communication "HP Connectivity kit", avec son protocole de communication propriétaire, obligatoirement sous Windows, me donne envie de vomir. Actuellement, il ne se connecte plus à ma calculatrice.

Il existe libhpcalcs ( https://github.com/debrouxl/hplp , https://tiplanet.org/forum/viewtopic.php?f=69&t=13337 , http://www.hpmuseum.org/forum/thread-52.html ), logiciel portable (Windows, MacOS X, Linux et FreeBSD, comme il se doit) et interopérable (écrit en C, bien sûr), que certains ici connaissent, mais il va probablement te donner envie de vomir aussi ^^

Pour commencer, il n'y a pas d'interface utilisateur graphique, parce que la Prime, presque tout le monde s'en fout, et je passe donc beaucoup plus de temps sur libti*/gfm/tilp, l'original pour calculatrices graphiques TI, duquel j'ai dérivé libhpcalcs.
Ensuite, le protocole de transfert de firmware n'est pas correctement documenté - la seule doc est a priori mon travail partiel publié sur le hpwiki TI-Planet - donc ce genre d'opérations sensibles n'est bien entendu pas implémenté, ce qui fait qu'on ne peut de toute façon pas se passer du CK de HP.

Pourrait mieux faire, Casio...

La communication des Prizm avec l'ordinateur, sur une base USB Mass Storage Device, est une exception sur le marché des calculatrices graphiques.
La Prime est une autre machine qui n'a pas besoin de drivers additionnels (*), mais elle utilise, pour son mode normal, la classe Human Interaction Device, avec ses avantages (plus flexible que MSD, qui est orienté transfert de fichiers: on peut faire passer du remote control, du screenshot, et autres, sur HID) et ses défauts (lent et peu fiable, surtout sous Windows). Le transfert de firmware, en mode recovery, est fait avec une sorte de MSD trafiqué.

*: les drivers additionnels Windows sont une source d'emmerdements pour les fabricants et les utilisateurs, et donc de coûts, à cause de ces histoires de signature toujours plus contraignantes, qui rendent TILP - comme cas particulier de programme nécessitant des drivers d'un tiers - de plus en plus pénible à installer sous Windows. Sur les autres OS, on peut simplement utiliser libusb sans que l'OS se mette en travers du chemin.

libhpcalcs reste le seul logiciel tiers (au demeurant portable et interopérable) capable de remplir la fonction principale d'un logiciel de communication avec la calculatrice, à savoir transférer des fichiers. Cependant, en effet, libhpcalcs ne sait pas mettre à jour le firmware de la machine, parce que le processus n'a jamais été complètement documenté (*).

Le README visible dans le tarball et à https://github.com/debrouxl/hplp décrit comment installer libhpcalcs, dont la seule vraie dépendance est hidapi, qui s'installe également en 3-4 commandes.

*: personne ne s'intéresse réellement à la Prime, et c'est très dommage. Les travaux et manips qui sortent de l'ordinaire sont issus de personnes connues principalement pour leurs activités sur les calculatrices graphiques TI.

Des infos officielles sur la 83PCE ont maintenant paru.
* mêmes caractéristiques principales que la 84+CE: écran couleur 320x240, 150 KB de RAM utilisable, ~3 MB de Flash utilisable. Ca reste misérable dans l'absolu, mais c'est une amélioration en relatif. Et ça ne nous dit toujours pas quel processeur la paire 83PCE / 84+CE utilise, même si au cas où cet espace d'adressage de 150 KB soit contigu, ce n'est pas un Z80 de base comme dans les TI-Z80 depuis plus de 20 ans.
* présence d'une fonctionnalité importante pour l'éducation française, mais interdite dans de nombreux examens internationaux (et donc absente de la 84+CE): un moteur de calcul exact, donc beaucoup moins qu'un CAS, mais déjà un complément au pur mode numérique, d'autant qu'il est intégré dans plusieurs parties de l'OS, pas seulement l'écran HOME des calculs. Le clavier de la 83PCE est légèrement différent du clavier de la 84+CE. Il est donc certain que les OS 83PCE et 84+CE ne seront pas (directement) interchangeables.
* gestion explicite de l'ASM en plus du Basic;
* existence de TI-Connect CE, avec éditeur de programmes;
* confirmation de l'existence d'une version 5.0 de l'OS, comme inféré de la version 5.0 de la FlashApp EasyData;
* sans surprise, existence d'une version 83PCE de TI-SmartView, émulateur côté ordinateur (là, ce n'est pas une version ordinateur de la même base de code, comme les logiciels ordinateur Nspire et Prime, c'est bien un émulateur de processeur + matériel), avec un redesign;
* mention explicite d'un mode examen (!!), et c'est une info très importante. Si TI intègre ce genre de choses dans des modèles spécifiques à la France, et communique dessus (contrairement à la 83+.fr USB il y a 2 ans), c'est que l'utilisation du mode examen va, hélas, arriver dans les examens français importants. Jusqu'à présent, ce n'était que des informations, certes crédibles, à l'intérieur du système éducatif - maintenant, c'est un des principaux fabricants de calculatrices qui écrit la même chose;
* disponibilité indiquée "Mai 2015".