Cesium: le 1er Shell pour TI-84 Plus CE / TI-83 Premium CE

[DoOmnimaga]

En gros, Kerm n'aurait pas du attendre après la clef RSA de TI avant de commencer Doors CSE 9. Maintenant, il se fait damer le pion et il va y avoir plusieurs shells au lieu d'un.

Voilà. Mateo a brisé l'immobilisme contre-productif de Kerm.

Mais au moins la compétition convaincra sans doûte chaque auteur d'améliorer encore plus leurs shells respectifs.

Oui, c'est un avantage.

Ma seule inquiétude c'est que chaque shell utilise ses propre librairies ASM/C et que la compatibilité de chaque jeux et programmes entre chaque shell soit en jeu, comme ça s'est produit avec MirageOS, Ion, Doors CS, etc.

Pour l'instant, il est englué dans le portage des parties existantes de DoorsCS, à commencer par la partie graphique (plus facile) et l'intégration à la VAT, mais je pense que Kerm va devoir suivre (intégrer) le boulot de création de l'infrastructure pour les programmes ASM/C que Mateo fait. Bien sûr, ça ne l'empêchera pas de proposer et contribuer des améliorations - c'est même souhaitable qu'il le fasse, pour éviter la fragmentation.

J'avais pointé Mateo vers l'infrastructure TI-68k/AMS existante (PreOS, evHk / TSRlib), parce qu'il y a déjà eu du travail de conception, codage et documentation sur TI-68k, et un certain nombre d'idées de cette infrastructure TI-68k s'appliquent complètement sur TI-eZ80. Autant que l'expérience "des générations passées" puisse servir à quelque chose. C'est le cas: il a repris pas mal de choses à son compte, c'est bien

Personellement, j'aimerais mieux que les librairies BASIC restent identiques en général à celles de la CSE, afin que les programmeurs hybrides ne soient pas obligés de tout recommencer à zéro.

[Lionel Debroux]

Personellement, j'aimerais mieux que les librairies BASIC restent identiques en général à celles de la CSE, afin que les programmeurs hybrides ne soient pas obligés de tout recommencer à zéro.

Tout à fait, dans la mesure du possible.

Ce vers quoi j'ai pointé Mateo ne s'applique pas à la programmation TI-Basic
PreOS et evHk / TSRLib fournissent des couches pour la programmation C/ASM: loader de librairies avec dépendances transitives (Mateo l'a fait), convention pour essayer d'éviter que les event hooks tiers ne se marchent dessus + abstraction de la manipulation des handlers d'interruptions et d'exceptions, éventuellement format des librairies (Mateo n'aurait pas pu le garder tel quel, ne serait-ce que parce que la taille des pointeurs est différente),

Ce que tu écris me fait penser qu'il y aurait peut-être des idées utiles de FLib ou Vertel, qui n'existeraient pas dans les libs BASIC de DCSE 8, mais qui s'appliqueraient sur TI-eZ80. Je n'ai simplement pas regardé.

[DoOmnimaga]

Sinon il y aurait toujours Axe Parser pour 84+CE, mais Runer112, le successeur de Quigibo pour le projet Axe monochrome, ne semble pas trop intéressé étant donné que le C est possible sur cette platforme. C'est dommage, car beaucoup de gens, à l'époque d'Axe, trouvaient le C et l'ASM trop compliqués pour y faire le saut directement à partir du TI-BASIC ou du TI-BASIC avec bibliothèque. Donc à moins d'un miracle où le projet de Cumred_Snektron verrait le jour sous une forme similaire au TI-83 BASIC et les parties de haut niveau du langage Axe, une catégorie complète de programmeurs potentiel TI-83 Premium CE vient d'être éliminée (la catégorie de gens tentant en vain d'apprendre l'ASM ou le C après avoir frappé un mur avec la lenteur du BASIC).

[Ti64CLi++]

Bonjour, j'ai vu dans la description de Cesium, que l'on pouvait modifier les icônes, mais je ne sais pas comment.
Est-ce que quelqu'un pourrait m'aider?
Merci d'avance

[critor]

Si tu parles des icônes incluses dans les programmes, elles sont au format Doors CS 8.
Voici un éditeur oncalc : https://www.cemetech.net/programs/index ... dcs8ic.zip

[Ti64CLi++]

Merci beaucoup critor

[Epharius]

J'ai réfléchi au probleme de compatibilité et j'ai eu deux idées :
La première serait de tout simplement détecter quand l'user lance césium avec mon hook et de l'exécuter comme un programme assembleur.
La deuxième serait de mettre mon hook à la fin de pixelshadow2 mais avec le risque que cesium arrive jusqu'à mon hook à un moment où à un autre.

Je pense choisir la première solution. Mais l'avantage de la deuxième est que ça préviendrait aussi le problème de "l'user lance PACMAN avec la commande Asm(.Le hook n'est donc pas sollicité et il efface PHASM".

[Hayleia]

Je n'ai pas tout compris à la deuxième solution. Comment ça "Cesium arrive à ton hook à un moment ou à un autre" ?
Et déjà, il est où le hook de Cesium, et le tien en ce moment ?

[Epharius]

Mon hook est stocké dans pixelshadow2, emplacement de la RAM que cesium utilise aussi. Ce qui est bien avec cet emplacement c'est que L'OS ne l'utilise pas.

Ce que je voulais dire c'est que cesium ne doit pas utiliser tout le pixelshadow2 et que je pourrais mettre mon hook à la fin de cet emplacement pour que quand cesium s'exécute, il n'ecrase pas mon hook.

[Hayleia]

Ok ok.
Je dirais que la seconde est plus rapide à faire donc en tant que solution temporaire, ça serait déjà bien...
Et que même une fois la deuxième faite, ça ne t'empêchera pas de mettre la première solution en oeuvre