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

[critor]

Bien!

[Lionel Debroux]

Merci :

Je n'ai plus beaucoup d'idées simples pour faire évoluer le patchset pour TI-68k :
De plus, je ne m'y connais pas assez pour me lancer dans la gestion des OS TI-Z80, et je suis d'autant moins chaud que Brandon pense que ça n'est pas facile. Sans support TI-Z80, la diffusion de ce patcher qui se voudrait générique, si possible, sera plus limitée...


Autre chose à  documenter publiquement: AMS 2.05 pour 89 et 92+ (et peut-être d'autres versions) pourraient amplement fournir 704 KB de mémoire archive utilisable (768 KB d'après l'écran MEM, dont 64 KB inutilisables; 704 KB d'après getConfg() ). Pour ça, il suffirait d'utiliser les 44 KB gaspillés par AMS dans les zones ROM_base + [environ 0x13000] - ROM_base + 0x17FFF et ROM_base + 0x1A000 - ROM_base + 0x1FFFF. C'est très difficile à  faire pour nous par patching binaire (voir, dans le source, le nombre de lignes nécessaires pour le déplacement de quelques centaines d'octets, alors imaginez pour plus de 16 KB composés de petits morceaux - certes, on pourrait réduire un peu en faisant une copie en bloc et des updates juste là  où il faut, mais c'est moins lisible et plus difficile à  debugger s'il y a un problème dans le patchset), ça serait en revanche facile pour TI de le faire.
J'imagine qu'ils ont voulu limiter au maximum la quantité de code qui s'exécute depuis les zones à  partir desquelles la Protection peut être désactivée. Mais vu qu'il y a un exploit non corrigeable dans le boot code, ça ne sert à  rien de limiter la quantité de code dans ROM_base + 0x12000-17FFF et ROM_base + 0x1A000-1FFFF...
PedroM utilise entièrement ces zones, et PpHd a bien raison !

Depuis une paire de versions, tiosmod-....zip contient les diffs binaires rassemblés dans leur propre ZIP, pour faciliter la distribution (TI ne peut pas attaquer les diffs binaires, pour autant que je sache : ).

[critor]

Sous quel format gères-tu les patchs ?


Parce que cela ne me semble pas compliqué de faire un diff entre un OS z80 original et sa version modifée, d'écrire ce diff et de resigner le tout à la fin...

[Lionel Debroux]

Sur TI-68k, l'OS est stocké en binaire pur, non paginé, prêt à  l'emploi (il est transféré tel quel à  la calculatrice). Après avoir patché l'OS (ici avec un patcher + patchset écrit en C, utilisant des adresses absolues ou du moins des offsets fixes par rapport à  ROM_base - mais on peut écrire tout ça en un autre langage ou même faire l'édition hexa à  la main), on peut utiliser n'importe quel algorithme de diff binaire.


Sur TI-Z80, l'OS n'est pas stocké en binaire pur, mais la conversion n'est pas compliquée: c'est un format hexa annoté avec des indications de l'adresse, à  savoir de l'Intel Hex.
Il est paginé: il faut bien faire attention à  ne pas déborder des pages et à  ne pas référencer des pages qui ne seraient pas, à  ce moment-là , chargées dans les 4 banks de 16K.
Mais ce qui est à  mon avis le plus embêtant, c'est que le format de stockage n'est pas prêt à  l'emploi. Il y a quelque part (cà´té ordinateur, c'est sûr qu'il y en a une, voir tifiles_file_read_flash dans libtifiles, mais peut-être aussi cà´té calculatrice) des transformations non triviales pour obtenir l'OS qui tourne réellement sur la calculatrice.

Ce dernier aspect est visible dès les premiers octets d'un .8xu, ici l'OS 2.41 pour 84+:

Code: Tout sélectionner

800F00000000 80110A 802102 80312B 80A103 808112 807F00000000

Les longueurs 00000000 des champs certificate 8000 et 8070 sont clairement des placeholders. Et puisque ces longueurs sont 00000000 et non pas FFFFFFFF (valeur de la Flash après erase d'un secteur), une transformation spéciale est appliquée à  ce binaire avant l'écriture en Flash (sinon, vu que l'écriture en Flash ne peut qu'effacer les bits, on ne pourrait pas écrire la vraie longueur à  la place de 00000000).
Comparons avec AMS, ici 3.10 pour 89T:

Code: Tout sélectionner

800F00155C3E 801109 80210E 80320053 80A102 804D1D["Advanced Mathematics Software", 29 octets] 0326090410125E31 020D40[signature du MD5 du timestamp, 64 octets] 807F00155BC0

Brandon avait l'air d'indiquer que regénérer un fichier au format Intel Hex à  partir d'un binaire flat (qui serait quand même, à  mon avis, plus commode pour la modification, puisqu'il y aurait moins à  se soucier des pages !), obtenu à  partir du .8xu au format Intel Hex, n'est pas si simple que cela.
Mais peut-être y a-t-il d'autres moyens plus simples :

[Lionel Debroux]

Nouvelle version, http://tict.ticalc.org/beta/tiosmod-0.2.4.zip .
* correction d'un très vieux bug, documenté dans http://www.technicalc.org/buglist/bugs.pdf , de la gestion du contraste: destruction de la valeur de deux registres processeur, d3 et d4, qui ne devraient pas être détruits. Ca ne changera probablement rien pour personne, vu que le bug est contourné depuis des années dans TIGCC, et donc GCC4TI.
* AMS 2.08 pour 92+ et V200 sont maintenant supportés (trouvé une copie dans TI-Connect 1.2 grâce à  TI-Bank : ), après test.


Pas de support des OS TI-Z80 pour le moment, mais Kerm Martian semblerait motivé, d'après le topic frère sur Cemetech.

[critor]

* AMS 2.08 pour 92+ et V200 sont maintenant supportés (trouvé une copie dans TI-Connect 1.2 grâce à TI-Bank )

[Lionel Debroux]

Nouvelle version, qui désactive en théorie la protection d'exécution en Flash sur les HW1 aussi, et remet OSVRegister/OSVFreeTimer + le code nécessaire dans le code de reset et le handler d'interruption, c'est à  dire les timers vectorisés que TI avait enlevés dans AMS 2.04. Ces timers avaient été réimplémentés indépendamment d'AMS par Zeljko Juric dans la librairie de TIGCC (et donc de GCC4TI).

Comme d'habitude, et bien que l'OS tourne avec succès des tests des fonctions ajoutées sur une de mes calculettes physiques, utilisez le patcher+patchset ou les diffs binaires à  vos risques et périls :

[Lionel Debroux]

Déplacement d'une discussion depuis yAronet, après encore une nouvelle occurrence des pollutions agressives habituelles de Kevin Kofler, qui ruinent le topic... Ce déplacement est rendu possible par le fait que Folco, à  qui je réponds, a déjà  un compte ici; sinon, je ne me serais pas permis.

 

Show/Hide spoilerAfficher/Masquer le spoiler

Ce patcheur d'OS est, d'après lui, explicitement plus utile que mon boulot habituel, à  savoir l'élévation de GCC4TI depuis le mauvais niveau de qualité hérité de TIGCC, ou bien encore les bugfixes et extensions de libti*/gfm/tilp et tiemu, qu'il ne prend pas le temps de faire depuis plus de deux ans, et qu'il n'a de toute façon pas le moyens de faire puisqu'il indique ne pas vouloir se procurer le matériel nécessaire...
Ca, c'était la première pollution de la journée, il y en a eu une deuxième dans un autre topic, envers le boulot de Folco. Pas étonnant que je n'aie pas posté moi-même à  propos de tiosmod sur yAronet, je connais tellement bien Kofler que je savais qu'il allait tuer le topic par une de ses pollutions agressives habituelles...
La section TI-68k/Nspire de yAronet est passée en moins d'un an du statut de "un endroit où des choses inédites se passent" (ex: création incrémentale de la liste des fonctions des OS Nspire), au statut de "un endroit où on cross-poste un sous-ensemble des choses inédites qui se passent ailleurs" (ex: l'émulateur NES pour Nspire, avec un spoiler très explicite d'ExtendeD sur le fait que la communauté s'installe où elle se sent bien). Qui s'en étonne encore ?

Repassons à  des choses plus utiles que les conneries destructives habituelles de "KK".

Je suis très partisan d'un PreOS en flash évidemment, en tant que flash apps, mais l'implantation ne sera certainement pas aisée...

En effet.

Question : un programme peut-il présumer que l'AMS sur lequel il tourne a été TIOSMODé ?

On ne peut pas empêcher les programmeurs de le faire :

Sinon, comment le détecter ?

Actuellement, par des moyens indirects uniquement, exactement de la même façon qu'on détecte depuis longtemps des choses comme HW2/3Patch ou MaxMem:
Parmi les changements spécifiques à  cet amspatch, citons par exemple le fait que la trap #3 ne pointe plus vers OSenqueue, ou bien encore que OSVRegisterTimer et OSVFreeTimer ne pointent plus vers un 0xA000+ER_ROM_ROUTINE_NOT_AVAILABLE.

Peut-on avoir une série de flag à  un endroit de la ROM (une adresse inutilisée sous tous les AMS) permettant de savoir quels sont les patches installés ? Tu pourrais fournir un header tiosmo[d].h, définissant cette adresse et les bits correspondant aux patches implantés lors du patch de la ROM ?
Ou alors il faudrait un autre moyen ?

Dans le cas d'un seul patchset, on pourrait s'en sortir à  peu près avec un numéro de version (type "amspatch-debrouxl-v", présent dans amspatch.c mais pas dans l'OS) + bit field extensible, écrit à  un endroit conventionnellement fixé en Flash, et le header correspondant bien sûr. En espérant que l'auteur n'oublie pas d'incrémenter le numéro de version, qu'il n'y ait pas de copier-coller-pasmodifier et autres broutilles de ce genre (que celui qui n'a jamais fait ça me jette la première pierre non#: ).
Ceci étant dit, la vérif du type de patch + du bitfield est suffisamment lourde en code+data pour ne devenir vraiment compétitive avec les vérifs indirectes individuelles que si le programme dépend de plusieurs modifs effectuées par le patchset :

Mais le patcheur se voudrait générique, la séparation patcher/patchset facilitant la création de patches multiples indépendants. Ce qui pose d'autres problèmes:
* lourdeur de la gestion, dans les programmes utilisateur, de multiples patches fournissant un sous-ensemble non vide de modifs en commun (si c'est ce patch-là  ou bien ce patch-là  et que les bits appropriés, qui peuvent être différents, sont dans le bon état, c'est OK. Sinon, on ne sait pas);
* alternativement, et en admettant qu'elle soit souhaitable (??), lourdeur de la centralisation de la gestion de la compatibilité entre patches. Ce n'est pas pour ce genre de choses que j'ai utilisé le DSCM Git au lieu d'utiliser le [C]SCM SVN :

= s'il y a plusieurs patches indépendants, il faudra de toute façon repasser à  la détection individuelle des changements.

D'autres idées ?

Parce que pouvoir faire un trap #3 sous AMS, c'est génial (PreOS n'embarque pas cette feature malheureusement : ), mais encore faut-il que ça ne conduise pas à  un crash...

En effet :

Code: Tout sélectionner

 pea Str(pc)
 bsr printf
 addq.l #4,sp
 jsr tios::ngetchx
 movea.w d3,a0
 trap #3
 pea Str2(pc)
 bsr printf
 addq.l #4,sp
 ...
Str: dc.b "Attention, si ça crash sévère, allez TIOSMODer votre ROM. Appuyez sur une touche et serrez très fort les fesses...",0
Str2: dc.b "Vous avez le cul bordé de nouilles !",0

[jacques]

Merci pour ce déplacement, surtout que je n'arrive plus à surfer sur yAronet depuis un certain temps.

[Folco]

Bonjour à tous.

Merci Lionel pour la réponse. A vrai dire, la complexité m'avait traversé l'esprit évidemment.

Je crois que le plus simple reste de regarder si le vecteur du trap 3 est l'adresse de OSenqueue. Ca se vérifie facilement avec $C8, ça se fait en 4/5 lignes.
A condition bien sûr que ça soit valable pour tous les AMS.