Programmation C/ASM on calc

[Lionel Debroux]

Je viens de regarder rapidement avec TIEmu, en important un AMS 2.09 patché et resigné sur HW1 simulé (HWPB indiquant HW1).

Avec un data breakpoint sur le word à 0x360000, je confirme la présence d'un bug précédemment inconnu, faute de tests sur les rares HW1, qui déclenche l'effacement des secteurs non utilisés jusqu'à 0x390000. Ca se passe assez tôt dans le processus de boot, avant que l'installation des FlashApps ait lieu.
Avant reboot, 640 KB de mémoire archive sont utilisables, mais après reboot, cette quantité baisse !

Je dois donc:
* commencer par te faire mes plus plates excuses pour les pertes de données;
* te remercier pour le bug report indirect;
* te confirmer qu'il faut utiliser un OS standard en attendant que je comprenne et corrige ce qui ne va pas;
* me plonger dans MaxMem (ouin... autant HW3Patch est mal protégé, autant HW2Patch et MaxMem sont chiants) pour vérifier les opérations d'écriture qu'il déclenche dans l'OS. S'il n'y en a qu'une, à l'endroit bien connu modifié par amspatch et XPand, alors MaxMem est incomplet.

[Bruno83]

Tiens, étonnant, avec l'os 2.09 standard je ne peux pas lancer l'ide, je pensais que la limitation en taille des fichiers asm ne s'appliquait qu'aux HW2 ?

EDIT : Pas de pb Lionel, je n'ai rien perdu d'important, juste un peu de temps ! lol
Merci pour cette analyse

EDIT2 : Oups, il reste la limitation logicielle sur la taille des fichiers ASM bien sûr.. Est-ce qu'il existe un patch qui dispense de l'utilisation d'un kernel ?

[Bruno83]

Avec OS2.09 std + FlashAppy + PreOS : Pas de plantage de GTC pour l'instant.

Aurais-je du installer PreOS également avec l'os patché tiosmod ?

EDIT : Premier plantage GTC sur un include d'un header inconnu : zone historique figé, reboot, et je retrouve bien les fichiers archivés

[Lionel Debroux]

La suppression de la limitation de taille des programmes ASM est traditionnellement réalisée par un programme ASM avec une partie TSR, type KerNO ou PreOS.
Un AMS patché avec tiosmod+amspatch a moins besoin de PreOS qu'un AMS standard.

Par recherche de 0x00390000 dans AMS 2.09 pour 89, et modification manuelle du PC quand c'est nécessaire, je peux faire en sorte que sur une HW1 émulée, en présence de FlashApps, l'OS n'efface pas bêtement les données entre la fin des FlashApps et ROM_base + 0x190000. C'est ce code-là que MaxMem (sur les versions 2.01-2.05, il n'existe pas sur 2.08-2.09) modifie.
En relisant le code d'amspatch, je vois que je m'y suis pris différemment (suppression de l'appel à la routine qui limite artificiellement la quantité de mémoire disponible), et bien entendu, ça fonctionne dans le cas le plus utilisé... mais ce n'est peut-être pas suffisant

EDIT: je confirme que ce n'est pas suffisant, et je comprends bien pourquoi MaxMem est fait comme il est fait. L'historique du repo tiosmod+amspatch montre que j'ai commencé à vouloir faire comme il faut, puis j'ai pensé qu'il devrait y avoir plus simple. Plus simple, certes, mais incorrect ^^

[s0r00t]

J'utilise tiosmod/amspatch sur ma 92+ HW2, avec des FlashApps (Commander Plus de tête pour le désassembleur), et je n'ai jamais eu de perte de données comme ça. Sauf une fois, mais c'était Einstein le fautif.

Sinon, question: on peut faire du C/de l'ASM on-calc de façon stable??? Ca serait super pratique (même si j'ai mon environnement de dev sur mon PC avec GCC4TI).

[Lionel Debroux]

on peut faire du C/de l'ASM on-calc de façon stable???

En gros, non, on ne peut pas...

Seules les 89 HW1, les 92+ HW1 et les V200 (HW2, donc) sont affectées par le bug reporté et analysé hier. Et le fait d'utiliser des FlashApps est un facteur aggravant.

[Bruno83]

Est-ce qu'il existe une version plus récente que la beta .02 du guide fourni par TI : TI-89 / TI-92 Plus Developer Guide ?

[Lionel Debroux]

Non, ça doit être la version la moins ancienne. J'ai la même.

Pour info, à part pour les aspects peu utilisés de la programmation TI-68k/AMS comme les FlashApps et le graphing, sdk8992pguide.pdf est considéré comme une doc inférieure à celle de GCC4TI. Etant le mainteneur de GCC4TI et un contributeur significatif à la doc de GCC4TI et de son ancêtre obsolète et non maintenu, je ne suis pas neutre, mais le fait est que:
* la partie documentation du matériel de sdk8992pguide.pdf est indigente par rapport à la doc de référence http://tict.ticalc.org/docs/J89hw.txt , qui n'est d'ailleurs pas complète: on sait des choses sur les ports HW3+ à 7100xx, mais ça n'a jamais été mis en format pour une intégration dans J89hw.txt, faute d'utilisateurs;
* GCC4TI fournit un certain nombre de fonctions utiles, exportées par l'OS, non décrites dans sdk8992pguide.pdf. Certaines fonctions présentes dans l'OS mais non exportées dans les vieilles versions sont quand même rendues accessibles par GCC4TI au moins des Address / Value Hacks (*1). Sans parler des fonctions de lib: qsort (l'implémentation de GCC4TI est plus rapide et plus petite), bsearch (l'implémentation de GCC4TI fonctionne...), Sprite* (plus rapides, plus petites, 1 mode de dessin en plus dans GCC4TI), Ptr2Hd, etc.

*1: il existe davantage d'Address / Value Hacks que ce que GCC4TI fournit. En 2009+, 10+ ans après la dernière version 1.xx d'AMS, ça n'avait plus de sens de faire une nouvelle review préalable à intégration de tout mon propre travail de 2002-2003 (3-4 ans après AMS 1.05), jamais traité dans l'ancêtre de GCC4TI - comme d'ailleurs une bonne partie des contributions ou des idées apportées à partir de 2002.

[Bruno83]

Merci pour tout ces détails technico-historique
Dommages que de telles contributions aient était écarté à l'époque, quand on sait la difficulté et le travail de fourmi pour lever les secrets d'un système !

Effectivement, je croise les infos de ta doc en ligne de GCC4TI avec le pdf de TI, et je me demandais comment vous avez pu nommer les fonctions non documentées, la liste complète des symboles du TIOS ont été publiés à une époque ? Ou vous avez 'inventé' les noms de fonctions ?

[Lionel Debroux]

Effectivement, je croise les infos de ta doc en ligne de GCC4TI avec le pdf de TI, et je me demandais comment vous avez pu nommer les fonctions non documentées,

Ce n'est pas un secret, et le top management de TI EdTech est au courant: par désassemblage, obtention / examen du callgraph, examen des structures de données, etc.

la liste complète des symboles du TIOS ont été publiés à une époque ? Ou vous avez 'inventé' les noms de fonctions ?

Un mélange des deux:
* TI avait publié la liste des ROM_CALLs d'AMS 1.xx, sans les prototypes de fonction;
* pour les trous d'AMS 2.xx, des noms inventés sont effectivement utilisés. Par exemple, ROM_CALL_3CF EM_GetArchiveMemoryBeginning, ROM_CALL_3D2 OO_GetEndOfAllFlashApps ou ROM_CALL_477 OO_GetFlashAppSize, trois fonctions utiles que je n'ai jamais compris que TI ne documente pas, alors que bien des fonctions moins utiles sont (semi-)documentées.

Je sais que pour EM_GetArchiveMemoryBeginning, je n'ai pas deviné le nom juste. Dans le début des années 2000, sur un autre forum qui est mort depuis longtemps, il y avait un programmeur très doué, et qui avait accès, sous NDA, à ce qui est connu comme un header privé de TI. Il avait posté que ça n'était pas le nom officiel de ce ROM_CALL. Il avait aussi participé à l'optimisation de je ne sais plus quelle FlashApp, il avait contourné la terrible inefficacité des fonctions d'entrée-sortie fichier F* (files.h).
La table des ROM_CALLs d'une version du fork amélioré de VTI par JM, et par suite de TIEmu qui en est un sur-ensemble, contient une petite liste de noms d'origine inconnue pour les trous d'AMS 2.xx. Tous ceux que j'ai regardés sont corrects, et quelques-uns, comme push_dense_poly_eval (je mentionne celui-là parce qu'il se trouve que son code source est dans sdk8992pguide.pdf ^^), sont trop peu évidents pour avoir été inventés de toutes pièces.
Le header privé n'a jamais été divulgué, naturellement. Et c'est dommage.