Forum TI-Planet.org

En mars 2017, Texas Instruments a commencé à assembler la 13^ème version matérielle de la TI-83 Premium CE, la révision matérielle I.
Ces toutes nouvelles versions commencent donc à apparaître dans les rayons pour cette rentrée 2017.

Mais hélas, il y a cette fois-ci un problème. Cette nouvelle version a visiblement changé quelque chose par rapport aux interruptions, notamment ceux relatifs à la gestion des touches du clavier tels qu'utilisés par certains programmes basés sur la toolchain communautaire, et pour la toute première fois depuis le lancement du modèle casse la compatibilité.
En effet, des programmes en langage machine ne réagissent plus à la pression de touches claviers, et tu n'as plus que la solution du bouton 'reset' pour remettre ta machine en état de marche.
Cela inclut notamment à ce jour les programmes utilisant les interrupts de la toolchain, en particulier le remarquable et extrêmement populaire Mario Oiram CE, et peut-être même des programmes assembleur conçus avec d'autres outils...

A ce jour, les développeurs de la communauté ne disposent pas de calculatrice en révision matérielle I, et les corrections à apporter demeurent donc difficiles à entreprendre.
[Edit: MateoC en a désormais une - voir ici pour la conclusion des choses]

Pour connaître la révision matérielle de ta machine il te suffit de consulter le timbre à date gravé au dos à droite du numéro de série.
Ci-contre, L-0816E se traduit en usine L, août 2016, révision matérielle E.

Bien évidemment, c'est quelque chose que tu ne peux pas faire avant achat en magasin.
Toutefois, si tu souhaites éviter ces inconvénients et pouvoir bénéficier dès ton achat de l'intégralité de l'immense logithèque de la TI-83 Premium CE, tu peux te baser sur les emballages, et dans la mesure du possible éviter ceux portant la mention "Approuvé par les familles 2017".


Source : https://github.com/mateoconlechuga/oiram/issues/2 via https://codewalr.us/index.php?topic=158 ... 7#msg58887

Bon moi je vais lancer un tipee pour acheter ces calculatrices là et les redonner au développeurs après j'pense.

Tu peux aussi verser directement à notre association - mine de rien on sert à ça.

On l'a déjà fait lorsque TI a cassé la compatibilité Ndless des TI-Nspire CX (révisions W+ avec le nouvel écran), et c'est loin d'être la seule fois où on a acheté/payé des choses pour la communauté.

Mais là le problème, c'est que ce n'est pas parce qu'un emballage porte la mention 2017 qu'il est forcément en révision matérielle I.
Il pourrait très bien renfermer une révision G ou H, à notre connaissance non affectée par le problème.

Attention tout de même, ça concerne (jusqu’à preuve du contraire) les programmes utilisant les interrupts par exemple via ce que donne intce.h, pas l’ensemble des programmes utilisant les libs, non plus

Il faut savoir que la toolchain faisait des choses un peu tricky/hacky au niveau des interrupts et apparemment c’était un peu trop dépendant du hardware (pas assez générique?) et de sa configuration. Même Mateo savait et disait que c’était sale, mais bon, difficile de prévoir des changements matériels...

Et en effet, l’association pourrait recueillir des donations spécifiques pour acheter une rev I, mais c’est pas facile d’obtenir une révision en particulier.... On verra d’ici fin août par exemple chez notre partenaire Jarretty pour savoir s’il en a des comme ça...

J'espère que vous en aurez bientôt une sous la main, et que le problème sera vite réglé

Maintenant que je suis sur ordi, je me suis permis de légèrement éditer la news pour être plus en accord avec le vrai problème (c'est pas le clavier, le soucis, mais la gestion des interrupts - qui, c'est vrai, sont utilisés par la toolchain pour le clavier par exemple).

Mais il y a aussi du nouveau - Mateo pense savoir ce qui pourrait clocher, et avec Runer112, ils ont apparemment une piste exploitable que les possesseurs de révisions "I" pourront tester une fois le développement du "correctif" effectué Il s'agirait en fin de compte d'une histoire de quelques octets, mais ce sont quelques octets critiques...

Donc si ça marche, pas "besoin" de se crever à trouver et acheter une rev I pour les aider, même si ça ne ferait pas de mal au cas où il y ait d'autres surprises...

RDV sur #ez80-dev pour les détails techniques...

(Et au passage, un autre report, sur Cemetech, d'une L-0517I)

Merci.

Nouveaux rebondissements, après multiples tests, il s'avèrerait que les hacks/tricks utilisés par la toolchain pour les interrupts fonctionnerait toujours en eux-mêmes... mais que c'est "tout simplement" (devrais-je dire "carrément" ?) les interruptions en mode im 2 qui ne fonctionnent plus... et on ne sait pas vraiment pourquoi TI a changé/cassé ça.
Un bug ? (ils ne l'auraient pas vu, TI ne l'utilisant pas dans l'OS etc.). Une protection supplémentaire (puisqu'on pouvait s'en servir pour des trucs un peu "underground") ?

Mateo wrote:Nothing appears to be wrong with the regions of memory used to lock the interrupt vector addresses or the jump location stored in the sha256 chip.
Rather, it appears as if mode 2 interrupts don't work properly.

La suite bientôt, avec un ultime test pour savoir si c'est bel et bien ce qu'on craint, en espérant que ça se passe pour le mieux, même si ça va être compliqué...

Au passage, calc84 qui a refait surface ces derniers jours sur IRC, est soulagé par le fait que son TI-Boy CE utilise le mode 1 et n'est donc, pour autant qu'on sache, pas affecté par ce problème.

Et moi je suis aussi très soulagé de voir que ce n'est pas la zone SHA256 qui a été touché, gLib aurait pris un sacré coup dans l'aile niveau perf

Par contre, avoir cassé le mode im 2, là chez TI ils font très fort o.o

Mateo a pu s'acheter une TI-84 Plus CE Space Grey, et il a été suffisamment chanceux pour que ce soit une L-0517I
Ca va donc aller mieux pour pouvoir essayer de comprendre et tester des choses bien plus efficacement.