TIOSMOD: un patcher pour OS de TI-68k (pour le moment)...

[critor]

Je ne veux bien sûr pas te priver de poster une news, mais que penses-tu d'attendre quelques jours (hopefully), que le rétrécissement d'AMS 2.09 pour 89, qui est plus intéressant que 2.08 (je dirais que c'est uniquement dans AMS 2.09 que la commande "delete file" a été ajoutée au link) soit lui aussi codé et testé ?

Nous t'attendons donc tous!

Je suis complètement d'accord que ça serait super de gérer les OS TI-Z80, mais apparemment (discussion sur #ti un soir il y a quelques semaines, faudra que je retrouve dans mes logs), à cause de la pagination et de la façon dont ils sont stockés, c'est le bazar

C'est un format entièrement différent, mais c'est loin d'être impossible!
Il y a juste un format à respecter, alors qu'avec les OS 68k tu stockes tout en brut.

De mémoire on peut citer:
* patch pour lancer un OS TI-83+ sur une TI-73
* patch pour lancer un OS TI-73 sur une TI-83+
* patch pour lancer un OS TI-84+ 2.30 et ultérieur sur une TI-83+
* patch corrigeant le bug Xlib de l'OS 2.53MP
* patch corrigeant le bug de représentation graphique des suites sur les OS 2.21 et 2.22
* patch désactivant les fonctionnalités PressToTest sur les OS 2.40 et ultérieurs
* patch corrigeant le bug de fuite de mémoire des boucles TI-Basic (news in progress...)

Sans un patcheur générique, ça commence à devenir un véritable enfer...

[Lionel Debroux]

J'ai retrouvé le log: http://netham45.org/irc/EfNet/view.php?log=ti.20100822 , à  partir de 13h29 heure du bot de Netham45 / 21h29 en France.

Code: Tout sélectionner

[13:34] BrandonW But I think it's a mistake to try to mash together z80 and 68k.
[13:34] BrandonW That's what causes problems later on.
[13:34] BrandonW Honestly I think they should be separate patchers.
[13:35] BrandonW Or at least different cores in that respect.
[13:36] BrandonW You also have OS header and validation data mess to deal with.
[13:36] BrandonW Which reside on page 0x1A.
[13:37] BrandonW What's there doesn't necessarily match what's earlier in the 8XU.
[13:37] BrandonW There's just a lot of crap with an 8XU that you can't just strip out and then recreate.
[13:37] BrandonW Not when it comes to making a potentially-minor patch to one, anyway.
[13:38] BrandonW Paging is also an important thing to keep in mind when making patches.
[13:38] BrandonW Like finding free space on specific pages.

[Lionel Debroux]

Je viens d'uploader une nouvelle version, qui rétrécit également AMS 2.09 pour 89
ATTENTION ATTENTION ATTENTION: seuls des tests légers ont été réalisés - je poste une version de test avant d'aller me coucher :;):
Pas de news pour le moment, Xavier :

[Lionel Debroux]

En relisant mon précédent message, je me dis qu'un "STP" n'aurait pas été de trop. Excuse-moi Xavier :


J'ai créé le repository Git pour tiosmod, at http://github.com/debrouxl/tiosmod . Mais je n'ai pas testé plus à  fond le rétrécissement d'AMS 2.09 pour 89, et je n'aurai pas le temps ce soir.

[critor]

En relisant mon précédent message, je me dis qu'un "STP" n'aurait pas été de trop. Excuse-moi Xavier

Je ne l'avais pas mal pris.
Il était tard, tu étais fatigué.

J'ai créé le repository Git pour tiosmod, at http://github.com/debrouxl/tiosmod . Mais je n'ai pas testé plus à fond le rétrécissement d'AMS 2.09 pour 89, et je n'aurai pas le temps ce soir.

Je peux tester en newsant ?

[Lionel Debroux]

J'ai créé le repository Git pour tiosmod, at http://github.com/debrouxl/tiosmod . Mais je n'ai pas testé plus à  fond le rétrécissement d'AMS 2.09 pour 89, et je n'aurai pas le temps ce soir.

Je peux tester en newsant ? langue#:

Si tu veux, mais le test prend un certain temps, car il consiste 1) à  vérifier, une par une, sur TIEmu, les mises à  jour des références absolues et la vraisemblabilité du code alentour, puis 2) à  activer tous les chemins de code / dialogs / menus sur émulateur ou sur 89 physique :

[EDIT 20100916: j'ai maintenant transféré l'AMS 2.09 rétréci vers ma calculette de test, et certaines opérations dans l'écran Graph ne produisent pas le résultat attendu, voire corrompent la mémoire et déstabilisent la calculatrice. N'utilisez pas l'AMS 2.09 rétréci avant que ceci soit corrigé !]

[Lionel Debroux]

Uploadé la v0.2.3a, dont le changement principal est la correction du bug mentionné dans l'edit du post précédent. Il est chaudement recommandé de mettre à  jour :

[critor]

Uploadé la v0.2.3a, dont le changement principal est la correction du bug mentionné dans l'edit du post précédent. Il est chaudement recommandé de mettre à jour

Est-ce que c'est enfin une version que l'on peut annoncer au monde entier ?

[Lionel Debroux]

A priori, oui :
Comme d'habitude, tout flashage de device comporte des risques. J'ai mis un disclaimer dans le README.

[Lionel Debroux]

Uploadé la v0.2.3b, qui remplace une des traps d'AMS (~software interrupt) par quelque chose d'utile, de manière à  corriger un gros bug d'AMS: cette trap pointe sur une fonction normale, accessible par d'autres méthodes, qui a une convention d'appel et de retour de fonction normale - mais les traps ne sont pas des fonctions normales...

Même si la différence de convention d'appel peut être résolue en écrivant les arguments à  un endroit excessivement étrange (avec la valeur par défaut du pointeur de pile superviseur, c'est dans la zone de l'écran : ), la différence de convention de retour ne peut pas être résolue par des moyens normaux (peut-être avec le bit Tracing, mais je ne suis pas sûr que ce bit, que je n'ai jamais utilisé, survive au passage en mode superviseur déclenché par la trap), et la calculatrice va crasher en retournant de la fonction... En résumé, la trap #3 d'AMS est tout simplement complètement inutilisable.

Le code qui remplace la trap #3 buggée de TI est celui qui est fourni depuis de nombreuses années par UniOS et PreOS: un HeapDeref (quand on lui donne un HANDLE, retourne l'adresse absolue du bloc de mémoire correspondant) avec la convention d'appel et de retour qui va bien.