Forum TI-Planet.org

Update Cesium v1.1:

Téléchargement: https://tiplanet.org/forum/archives_voir.php?id=320019

(Source)

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. Mais au moins la compétition convaincra sans doûte chaque auteur d'améliorer encore plus leurs shells respectifs. 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.

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

Décidément, je me demande comment il fait pour aller aussi vite dans son développement, je veux bien améliorer mon shell encore plus, encore faut-il l'avoir fini
Par contre j'ai remarqué que Cesium détruisait la partie de la RAM où était stocké le hook de PHASM. Ils ne sont donc pas compatibles et je dois donc m'y coller (faut bien que quelqu'un le fasse entre nous deux). Mais où le mettre, ça je ne sais pas.

Arf.
J'ai légèrement édité la news alors.

Bonne chance pour ce bugfix
(Il parait qu'il faut le mettre juste après le programme, le hook, mais comment en pratique, je sais pas)

Ouais mais les programmes ça n'arrête pas de bouger dans la RAM (il suffit d'une édition de programme), je ne vois pas comment je pourrait faire pour donner une adresse fixe à l'OS :-/

Le mettre dans une appvar ?
Au moins tu peux savoir où il est, même s'il bouge.

C'est exactement la même chose que de le mettre dans un programme

Et où est le problème?

Le problème c'est que ton hook, tu le définis avec une adresse qui pointe évidemment vers du code. Et même s'il se contente de lancer du code qui peut se trouver à une adresse variable, ce premier code là doit se trouver à une adresse fixe. Or les appvars et les programmes bougent...