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
![Content :)](./images/smilies/sg3agg29g.gif)
:
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
![Pas content! :#](./images/smilies/sg3agg23g.gif)
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
![Content :)](./images/smilies/sg3agg29g.gif)
:
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
![Content :)](./images/smilies/sg3agg29g.gif)
:
= 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
![Déçu :(](./images/smilies/sg3agg28g.gif)
: ), mais encore faut-il que ça ne conduise pas à un crash...
En effet
![Rigole! :D](./images/smilies/sg3agD.gif)
:
- 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
![Image](http://www.yaronet.com/v31/gfx/s3/trilove.gif)