encore une chtite question - Page 21

i.e. ?

PpHd :
>Compatibilité des nouveaux programmes avec les anciens kernels. Sous TeOS, ils planteront même s'ils utilisent tes RAM_CALLs! Je sens que je vais sortir une nelle version de Teos avec ca de corriger...

Ça ne changera toujours rien pour les vieilles versions de TeOS.

>Notamment, le bogue de ROM_base avec 0x600000 se trouve dans tous les programmes kernel en C avec niveaux de gris compilés avec une vieille release de TIGCC. Ca existe ?

Peut-être...

> S'il est capable d'installer un kernel, il est aussi capable d'utiliser un patcheur, ce n'est pas plus compliqué. Si! Car il faut donner des arguments.

>Avec mon entrée de FAQ, ça passe très bien. Mmm. C'est pour ca que l'on recoit tant de messages sur les forums ?

Ils n'ont pas lu la FAQ. Si je leur mets le lien vers la FAQ, en général, ça suffit.

>On n'avait pas de choix. Comme je viens de le dire sur ticalc.org:
>As far as TIGCC is concerned, the Titanium is just a TI-89 HW3. J'ai jamais dit que vos arguments etaient faux. Je pense juste que les miens sont plus importants.

Le problème quand on discute avec toi, c'est que tu ne changes jamais d'avis...

> C'est aussi pour ça que je ne t'ai pas contacté pour te demander ton avis:
> je savais qu'on n'avait pas le choix pour TIGCC quoi qui se passe et je pensais donc même qu'il était évident que CALCULATOR allait valoir
>0 sur Titanium, j'ai été évitré quand j'ai appris que tu allais mettre -1. Ben c'est une nouvelle calculatrice. Donc un nouvelle valeur pour CALCULATOR.

Sauf qu'avec la définition "Zero on TI-89, non-zero on TI-92 Plus.", je vois mal comment tu veux trouver une nouvelle valeur égale à zéro. Et -1 ne l'est visiblement pas.

>Bah, et nous on se fout de ce que tu fais maintenant...
C'etait pas le cas avant ?

On a même rajouté le support pour ton format "kernel v6". (Ce n'est pas de notre faute que tu as repoussé son support dans PreOs à temps indéterminé quand le support dans TIGCC était déjà complété depuis des semaines. )

>De toute façon, pour nous, le flag Titanium n'existe pas (pour nous, la Titanium est une TI-89), donc ce sera couvert par ton système
>"lie about CALCULATOR" que tu appelles prétentieusement "émulation". Tant pis si PreOs ruine les programmes en les patchant,
>la solution sera "utilisez Iceberg qui ne patche pas les programmes sans vous demander votre avis". Ben si Tigcc est pas foutu de faire des Kernel Programs pour Titanium, c'est son probleme. Pas le mien.

On pourrait mettre ton flag Titanium si tu ne violais pas notre documentation (CALCULATOR==0 sur Titanium) quand on le met.

> mais en supprimant ou réversant tous les changements néfastes que tu y as apportés (autopatcheur, flag Titanium, CALCULATOR==-1, peut-être aussi le RAM_CALL GHOST_SPACE qui ne devrait vraiment pas exister, peut-être même les RAM_CALLs de TSRs) Du moment que tu es propre a ce niveau la, pas de probleme (ie ne remplace la signification d'une RAM_CALL par une autre).

En fin de compte, je vais probablement être plus ou moins obligé de laisser ces RAM_CALLs. Apporter des incompatibilités gratuites entre les kernels n'est pas une bonne idée, aussi mauvais qu'ait été leur ajout. Mais je vais dresser une liste de RAM_CALLs obsolètes à ne pas utiliser que je mettrai dans la doc (il n'y aurait pas que GHOST_SPACE, mais aussi Heap etc.).

>correction du stack leak dans l'anticrash _nostub dont je me suis plaint il y a des années et que tu as refusé de corriger, ?? Tu veux dire les 4 octets de moins dans l'user stack ?? Je t'ai explique pourquoi je le laissait, et tu avais l'air d'etre d'accord.

C'est une mauvaise idée, et ça fait foirer Auto Alpha-Lock Off. Essaye (sur une TI-89):
1. autoaoff()
2. preos()
3. [CATALOG][ 7 ] -> Il sautera vers la première fonction commençant par "G", parce que alpha-lock n'est volontairement pas désactivé dans le catalogue (il était activé même par AMS 1).
4. [ESC]+[ON]
5. [CATALOG] -> Alpha-lock est désactivé, [ 7 ] ne marchera plus sans appuyer sur [alpha] avant.

> Pourquoi ne peux-tu pas discuter avec nous avant de changer des valeurs en commun entre nos projets comme CALCULATOR?!
Parce que vous n'ecoutez pas

Ah, parce que toi, tu écoutes?

>> Rappelle moi la valeur de hardwareID sur Titanium ?
>gateArray==3. C'est la valeur testée par AMS quand on lui demande la version matérielle, donc c'est ça que doit contenir HW_VERSION. Tu confondrais pas gateArray et HardwareID ?

Ah, je vois ce que tu voulais dire. Oui, elle a un ID différent. Maintenant, est-ce une raison suffisante de changer CALCULATOR? Les valeurs de CALCULATOR ne correspondent de toute façon pas à celles de TI.

>Pourquoi veux tu pouvoir faire un if (TI89_TITANIUM)?
>a. Touches, écrans? -> Pas besoin, la TI-89 est identique.
>b. Protection, ghost spaces, USB, matériel horloge? -> C'est lié à HW_VERSION. Parce que c'est une nouvelle calculatrice.

Mais pourquoi changer CALCULATOR s'il n'y a pas de raison valable d'utiliser CALCULATOR pour savoir laquelle c'est?

> Tu vas fouiller directement dans les variables globales privées de AMS au lieu d'appeler les ROM_CALLs faits pour. Oui et ? Vous faites pareil

>"Has Been", "Has Been", "Has Been", tu n'en as pas d'autres?
>C'est surtout PreOs qui sera "Has Been" si je sors Iceberg 2.00.
Oue Preos 0.70 sera Has Been par un kernel qui ne fait que reprendre ces sources

Bah, toi, tu as bien repris les sources de TeOS au départ aussi.

>Je pense que PpHd devrait accepter les problèmes de compatibilité de preOS (graphlib, CALCULATOR) Le probleme de graphlib est un faux probleme: Pour faire marcher SMQ et mario92 avec Titanick, Kevin a du les patcher. Il a aussi du recompiler graphlib en modifiant le systeme de bank switching (ie ne pas recopier tout l'ecran) car une partie de l'ecran sert comme tranpoline pour faire la communication inter-libraries.

Non. Elle sert pour contenir le code de l'interruption. Les trampolines de déprotection sont justement trop lents pour les interruptions.

Preos 0.70 fait fonctionner SMQ et Mario92 directement. Pour faire fonctionner les versions patchers, il suffit d'utiliser graphlib fournit avec Titanick.

La version fournie avec Iceberg plutôt...
Celle de TitaniK n'est pas compatible avec les programmes standard.
Et tu vas mettre ma dernière graphlib:
* compatible on-calc avec tous les modèles
* compatible avec les programmes TitaniK sur TI-89 et Titanium
dans le prochain PreOs? Je te l'envoie tout de suite si c'est oui.

> J'avoue que je ne comprends pas trop pourquoi PpHd a choisi -1 comme valeur de CALCULATOR pour TI-89 Titanium
Parce que c'est le plus rapide a patcher. Une valuer > 4 aurait pose de gros problemes dans les programmes assembleurs.

Pour avoir le moins de problèmes, la valeur idéale aurait été 0.

Tandis que que -1 permet de faire migrer un code:
tst.b CALCULATOR
bne.s \92p
en
tst.b CALCULATOR
bge.s \92p Simplement.

0 aurait permis de le faire migrer sans rien changer.

PpHd :
>pourquoi en tant qu'auteur de Iceberg (et co-auteur de PreOs, même, d'ailleurs!) je serais moins important que les auteurs de DoorsOS, TeOS et Universal OS auxquels il a demandé leur avis (même si c'était juste pour avoir la confirmation qu'ils s'en foutent et qu'ils lui donnent carte blanche)? Ben ton avis importe. Mais moins que le mien.

Vive ta disponibilité à la discussion...

>Dites-donc, vous avez lu au moins la doc pour savoir de quoi je parle, tous les deux? GHOST_SPACE est un RAM_CALL visé
>à permettre de continuer ce hack affreux:
>move.l foo,GHOST_SPACE+0x64
>au lieu d'utiliser la méthode propre:
>bclr.b #2,0x600001
>move.l foo,0x64
>bset.b #2,0x600001 Rien ne dit que la seconde methode soit plus sure a l'avenir que la premiere...

Elle est documentée dans la doc de TIFS contrairement à la première.

>Et évidemment, PpHd utilise ça dans la graphlib de PreOs 0.70 au lieu d'utiliser la méthode propre comme je l'ai fait dans Iceberg. Plus rapide a modifier.

Bah, je peux t'envoyer la version que j'ai déjà modifiée (cf. ./602). Elle gère tous les modèles maintenant, pas seulement les 89 HW2 et Titanium comme celle de Iceberg 1.00.

>S'il y avait un moyen fiable de détecter un kernel dépassé comme on le fait pour les AMS dépassés, ça se discuterait, mais là, on ne peut rien faire à part ne pas utiliser le RAM_CALL si on ne veut pas que ça plante. Qu'est-ce que tu proposes ?

Bah, un truc comme ce que tu as proposé pour le kernel v6: flipper le sign bit de 0x34.

>Et tu veux arranger les choses en faisant un kernel incompatible avec PreOS 0.70 ? Nan juste sans les nouvelles ramcalls.

Plutôt sans autopatcheur, sans flag Titanium (CALCULATOR==0 et c'est tout), avec les patches de Iceberg 1.00 et la graphlib de Iceberg. Et peut-être avec des changements dans l'anti-crash:
* Si le programme n'a pas planté, les leaks de mémoire et les interruptions non restaurées sont reportées à l'utilisateur, qui a le choix de les corriger ou pas. Il y aurait donc des routines de restauration différentes pour le cas "normal" et le cas "plantage".
* L'anticrash sera appliqué aux programmes _nostub ne portant pas de flags d'incompatibilité à travers une redirection du trap #11 et un default kernel stub dans le kernel (portant le flag 2, cf. ci-dessous).
* L'écran sera toujours sauvegardé pour les programmes kernel ne portant pas le flag 2, même s'ils sont appelés depuis un autre programme kernel. Cela pour faire marcher les ttstart-titanium originaux correctement malgré le default kernel stub.

>Quel est l'avantage d'utiliser une section BSS plutôt qu'un handle en mémoire? Pas de gestion de l'allocation / desallocation. Puis le segment est mis a 0 automatiquement aussi.

Sauf que TIGCC 0.95 ne fait pas confiance au kernel parce que les vieux ne le faisaient pas, et appelle memset lui-même.

Pollux :
Franchement, je comprends pas l'intérêt PRATIQUE de séparer CALCULATOR entre 89 et 89t

Entièrement d'accord.
Il y a une seule personne ici qui pense qu'il soit une bonne idée de mettre -1...

>c'est qu'aucun des aspects de la calc n'a été séparé de CALCULATOR et que si une nouvelle calc apparaissait, il n'y avait aucun moyen de savoir
>quelles propriétés elle avait : il aurait fallu définir des pseudo-constantes SCREEN89, KEYBOARD89, ROMADDR89, etc... Tu devrais relire les ramcalls. SCREEN89 et ROMADDR89 existent.

On attend tjs un header qui permette d'utiliser les ramcalls tout en utilisant tigcclib

Pas mal de RAM_CALLs, dont ROM_base, LCD_HEIGHT et LCD_WIDTH, sont définis dans compat.h.

Link :
PpHd, finalement, comment tu vas gérer ceux qui font "CALCULATOR ? a : b" ? En patchant les programmes comme tu l'a montré au ./594?

Les programmes en C ne mettront pas son flag Titanium, tout simplement. On a documenté CALCULATOR==0, on le fait respecter.

PpHd :
>Mais si tu as my_table[CALCULATOR], ou si tu as (my_calc=CALCULATOR, my_calc?x:y) ? Ben c'est au developpeur de le porter. Pas dur du tout.

Le tableau C qui commence à -1, tu me le montreras...

>Franchement, je comprends pas l'intérêt PRATIQUE de séparer CALCULATOR entre 89 et 89t Ben c'est une autre calculatrice.

Et?

>On attend tjs un header qui permette d'utiliser les ramcalls tout en utilisant tigcclib Alors que Tigcclib evite de foutre la merde avec les ramcalls, et je pourrais m'inclure proprement.

TIGCCLIB fait quoi qui ne te plaît pas?

PpHd :
>Ben moi ça me semblerait plus logique de prendre la même valeur que sur 89, et ça éviterait de se prendre la tête pour un chgt inutile... Ben c'est ton point de vue. Mais helas le debat a ete clos avant de commencer. Donc ca sert a rien.

Bah, tu peux toujours remettre CALCULATOR==0 dans une mise à jour rapide de PreOs et déclarer la valeur -1 comme un bogue de PreOs 0.70. Si tu le fais rapidement, il n'y aura pas trop de dégâts. De toute façon, Iceberg 2.00 mettra 0 quoi qu'il arrive, et TIGCC ne changera pas non plus, alors PreOs 0.70 est celui qui utilise la "mauvaise" valeur.

Kevin Kofler :
et déclarer la valeur -1 comme un bogue de PreOs 0.70.

>Le problème quand on discute avec toi, c'est que tu ne changes jamais d'avis...
Mais si, mais si. J'ai souvent change d'avis. Il ne faut pas desespere.

>Sauf qu'avec la définition "Zero on TI-89, non-zero on TI-92 Plus.", je vois mal comment tu veux trouver une nouvelle valeur égale à zéro.
>Et -1 ne l'est visiblement pas.
Ben oui forcement avec cette definition, on est mal.

>On a même rajouté le support pour ton format "kernel v6". (Ce n'est pas de notre faute que tu as repoussé son support dans PreOs
>à temps indéterminé quand le support dans TIGCC était déjà complété depuis des semaines. )
C'est vrai.

>On pourrait mettre ton flag Titanium si tu ne violais pas notre documentation (CALCULATOR==0 sur Titanium) quand on le met.
La vie est mal faite

> En fin de compte, je vais probablement être plus ou moins obligé de laisser ces RAM_CALLs. Apporter des incompatibilités gratuites
> entre les kernels n'est pas une bonne idée, aussi mauvais qu'ait été leur ajout. Mais je vais dresser une liste de RAM_CALLs obsolètes
> à ne pas utiliser que je mettrai dans la doc (il n'y aurait pas que GHOST_SPACE, mais aussi Heap etc.).
La je suis d'accord.

>C'est une mauvaise idée, et ça fait foirer Auto Alpha-Lock Off. Essaye (sur une TI-89):
>1. autoaoff()
>2. preos()
>3. [CATALOG][ 7 ] -> Il sautera vers la première fonction commençant par "G", parce que alpha-lock n'est volontairement pas désactivé
>dans le catalogue (il était activé même par AMS 1).
>4. [ESC]+[ON]
>5. [CATALOG] -> Alpha-lock est désactivé, [ 7 ] ne marchera plus sans appuyer sur [alpha] avant.
Pourquoi ca ne marche pas ?

>Ah, parce que toi, tu écoutes?
Plus maintenant. La vie est belle.

>Ah, je vois ce que tu voulais dire. Oui, elle a un ID différent. Maintenant, est-ce une raison suffisante de changer CALCULATOR?


> Les valeurs de CALCULATOR ne correspondent de toute façon pas à celles de TI.


>Mais pourquoi changer CALCULATOR s'il n'y a pas de raison valable d'utiliser CALCULATOR pour savoir laquelle c'est?
Pour afficher le bon nom de la calculatrice par exemple.

>Bah, toi, tu as bien repris les sources de TeOS au départ aussi.
A dans ce cas, je t'en repris.
Je crois que la seule chose qui reste de TeOS est la ligne declarant les ramcalls pour 89 / 92+

>Non. Elle sert pour contenir le code de l'interruption. Les trampolines de déprotection sont justement trop lents pour les interruptions.
Aussi.

>La version fournie avec Iceberg plutôt...
Si tu veux.

>Et tu vas mettre ma dernière graphlib:
>* compatible on-calc avec tous les modèles
>* compatible avec les programmes TitaniK sur TI-89 et Titanium
>dans le prochain PreOs? Je te l'envoie tout de suite si c'est oui.
Bon la c'est ok. Par contre, Preos n'a pas de nouvelle release de prevu avant un petit moment.

>Pour avoir le moins de problèmes, la valeur idéale aurait été 0.


> Vive ta disponibilité à la discussion...
Ben c'est pas vrai ce que je raconte ?

>Elle est documentée dans la doc de TIFS contrairement à la première.
A dans ce cas, ils n'auront qu'a tout casser dans les ports IO comme d'habitude


>Bah, un truc comme ce que tu as proposé pour le kernel v6: flipper le sign bit de 0x34.
Ok

>Plutôt sans autopatcheur, sans flag Titanium (CALCULATOR==0 et c'est tout), avec les patches de Iceberg 1.00 et la graphlib de Iceberg.
Ok.

> Et peut-être avec des changements dans l'anti-crash:
>* Si le programme n'a pas planté, les leaks de mémoire et les interruptions non restaurées sont reportées à l'utilisateur, qui a le choix de les
> corriger ou pas. Il y aurait donc des routines de restauration différentes pour le cas "normal" et le cas "plantage".
>* L'anticrash sera appliqué aux programmes _nostub ne portant pas de flags d'incompatibilité à travers une redirection du trap #11
>et un default kernel stub dans le kernel (portant le flag 2, cf. ci-dessous).
>* L'écran sera toujours sauvegardé pour les programmes kernel ne portant pas le flag 2, même s'ils sont appelés depuis un autre programme kernel.
> Cela pour faire marcher les ttstart-titanium originaux correctement malgré le default kernel stub.
Hum. Bon courage pour tout faire rentrer en 8K.

>Sauf que TIGCC 0.95 ne fait pas confiance au kernel parce que les vieux ne le faisaient pas, et appelle memset lui-même.


>Il y a une seule personne ici qui pense qu'il soit une bonne idée de mettre -1...
Ah. Qui ca ?

>Les programmes en C ne mettront pas son flag Titanium, tout simplement. On a documenté CALCULATOR==0, on le fait respecter.
Ben le programmeur fera ce qu'il veut.

>Le tableau C qui commence à -1, tu me le montreras...
Trop dur d'ajouter 1 a l'index du tableau

>Et?
Rien. C'est une autre calculatrice, donc une autre valeur pour CALCULATOR.

>TIGCCLIB fait quoi qui ne te plaît pas?
Il definit pas toutes les ramcalls

>Bah, tu peux toujours remettre CALCULATOR==0 dans une mise à jour rapide de PreOs et déclarer la valeur -1 comme un bogue de PreOs 0.70.
J"ai d'autres mises a jour a faire.

>Si tu le fais rapidement, il n'y aura pas trop de dégâts. De toute façon, Iceberg 2.00 mettra 0 quoi qu'il arrive, et TIGCC ne changera pas non plus,
>alors PreOs 0.70 est celui qui utilise la "mauvaise" valeur.
Ben tant pis.

PpHd-> J'ai du mal à comprendre à quoi sert le flag titanium si c'est déja différencié par calculator...

Pour éviter des problèmes, on ne pourrait pas utiliser juste le flag titanium pour différencier la tita d'une 89, et mettre calculator à zéro ce qui éviterai pas mal de problèmes?

Edit: appui intempestif sur TAB puis espace...

>PpHd-> J'ai du mal à comprendre à quoi sert le flag titanium si c'est déja différencié par calculator...
Le flag sert a dire: "Ce programme a ete compilee comme fonctionnant directement pour Titanium".

PpHd :
>Elle est documentée dans la doc de TIFS contrairement à la première.
A dans ce cas, ils n'auront qu'a tout casser dans les ports IO comme d'habitude

Je ne vois pas de port qu'ils ont documenté (faut dire y'en a pas beaucoup ) qui a changé de comportement depuis.
Continuer à utiliser les ghost spaces directement dans les programmes "standards" (ie autre chose que des kernels/h220xtsr/patches/proofs of concept/...) est suicidaire, c'est écrit noir sur blanc dans l'AMS3 que celui de la RAM risque de disparaître (cf ma doc sur la Titanium).

PpHd :
>C'est une mauvaise idée, et ça fait foirer Auto Alpha-Lock Off. Essaye (sur une TI-89):
>1. autoaoff()
>2. preos()
>3. [CATALOG][ 7 ] -> Il sautera vers la première fonction commençant par "G", parce que alpha-lock n'est volontairement pas désactivé
>dans le catalogue (il était activé même par AMS 1).
>4. [ESC]+[ON]
>5. [CATALOG] -> Alpha-lock est désactivé, [ 7 ] ne marchera plus sans appuyer sur [alpha] avant. Pourquoi ca ne marche pas ?

Parce que Auto Alpha-Lock Off compare le EVENT * qu'on lui passe avec une adresse sur la pile pour savoir si on est dans le event loop principal ou pas. Si on est dans un dialogue, on n'est pas dans l'event loop principal. Donc Auto Alpha-Lock Off ne fait rien si on est dans l'event loop principal, parce que ça veut dire qu'on n'est pas dans un dialogue. Or, si le niveau de la pile change, le EVENT * ne sera plus le bon. (Il dépend de la version de AMS aussi, mais Auto Alpha-Lock Off détecte la version d'AMS pour ça.)

>Mais pourquoi changer CALCULATOR s'il n'y a pas de raison valable d'utiliser CALCULATOR pour savoir laquelle c'est? Pour afficher le bon nom de la calculatrice par exemple.

C'est sûr que l'utilisateur va mourir s'il y a écrit "TI-89" au lieu de "TI-89 Titanium"... Surtout s'il y a écrit "Hardware version 3" juste en dessous (ce qui sera le cas sous tout shell sérieux qui affiche les informations techniques).

>Non. Elle sert pour contenir le code de l'interruption. Les trampolines de déprotection sont justement trop lents pour les interruptions. Aussi.

Euh non, les trampolines, eux, ne sont pas sur LCD_MEM, mais à la fin des programmes (après la fin de la variable vue par AMS).

>Bah, un truc comme ce que tu as proposé pour le kernel v6: flipper le sign bit de 0x34. Ok

Attention, il faudrait réfléchir si c'est vraiment le bon moment, et si oui, si le bit en question est vraiment le bon dans ce cas-ci. Je pense que tu devrais attendre que le format kernel v6 soit géré pour flipper le sign bit de 0x34, sinon il y aura encore un bordel.

Hum. Bon courage pour tout faire rentrer en 8K.

Bah, je n'ai pas encore décidé mon MIN_AMS... Si j'ai besoin de plus de 8 KO, je mettrai un 2.04 minimum et c'est tout. Je ne vais certainement pas dépasser les 24 KO.

>Il y a une seule personne ici qui pense qu'il soit une bonne idée de mettre -1... Ah. Qui ca ?

Toi.

>Les programmes en C ne mettront pas son flag Titanium, tout simplement. On a documenté CALCULATOR==0, on le fait respecter. Ben le programmeur fera ce qu'il veut.

Il y a quand-même un truc qu'on pourrait faire, c'est de redéfinir CALCULATOR en kernel de la manière suivante:
#define CALCULATOR ((signed char)_CALCULATOR[ 0 ]>0?_CALCULATOR[ 0 ]:0)
Avec l'optimisation de GCC, peut-être que ça ne se fera même pas remarquer avec les utilisations courantes. Je vais tester. Cela nous permettrait de mettre ton flag (avec la même méthode qu'on a utilisé pour le flag V200 sous TIGCC 0.94, c'est-à-dire un asm(".xdef _flag_6");).

PpHd :
>TIGCCLIB fait quoi qui ne te plaît pas?
Il definit pas toutes les ramcalls

Ben, tu rajoutes ceux qu'elle ne définit pas.

Link :
PpHd-> J'ai du mal à comprendre à quoi sert le flag titanium si c'est déja différencié par calculator...
Pour éviter des problèmes, on ne pourrait pas utiliser juste le flag titanium pour différencier la tita d'une 89, et mettre calculator à zéro ce qui éviterai pas mal de problèmes?

Le "flag Titanium" est un flag mis dans le header kernel des programmes qui indique que le programme est "compatible Titanium" de la manière voulue par PpHd, c'est-à-dire:
* ignoré par l'autopatcheur. (Et sous PreOs, être ignoré par l'autopatcheur signifie aussi qu'on ne peut pas utiliser les définitions d'origine de doorsos::font_small et doorsos::font_large, on est obligé d'utiliser les nouveaux RAM_CALLs. C'est une différence par rapport au système GhostBuster+Iceberg, dans lequel ce problème est géré dans le code de relogement de Iceberg, donc les définitions originales peuvent être utilisées même si on ne patche pas le programme. Comme le doorsos.h de TIGCC contient les définitions originales, c'est un truc duquel il faut tenir compte. En C, ces RAM_CALLs ne sont pas du tout déclarés par compat.h, donc ce n'est pas un problème en C.)
* CALCULATOR vaut -1 sur Titanium. Si le flag n'est pas mis, PreOs "émule une TI-89", ce qui veut dire en des termes plus précis qu'il dit aux programmes qu'ils sont sur TI-89 en mettant CALCULATOR à 0. C'est pour ça que je parle du flag Titanium dans la discussion sur CALCULATOR.

>Bah, je n'ai pas encore décidé mon MIN_AMS... Si j'ai besoin de plus de 8 KO, je mettrai un 2.04 minimum et c'est tout. Je ne vais certainement pas dépasser les 24 KO.
D'un côté tu plaides une compatibilité maximale et tu n'appliques pas toi-même, faudra m'expliquer.

>Je ne vois pas de port qu'ils ont documenté (faut dire y'en a pas beaucoup ) qui a changé de comportement depuis.
Je leur fait confiance.

>Continuer à utiliser les ghost spaces directement dans les programmes "standards" (ie autre chose que des kernels/h220xtsr/patches/proofs of concept/...) est suicidaire, c'est écrit noir sur blanc dans l'AMS3 que celui de la RAM risque de disparaître (cf ma doc sur la Titanium).
Bah. Rien que pour ca, ca me donne envie de continuer



>Parce que Auto Alpha-Lock Off compare le EVENT * qu'on lui passe avec une adresse sur la pile pour savoir si on est dans le event loop principal
>ou pas. Si on est dans un dialogue, on n'est pas dans l'event loop principal. Donc Auto Alpha-Lock Off ne fait rien si on est dans l'event loop
>principal, parce que ça veut dire qu'on n'est pas dans un dialogue. Or, si le niveau de la pile change, le EVENT * ne sera plus le bon.
>(Il dépend de la version de AMS aussi, mais Auto Alpha-Lock Off détecte la version d'AMS pour ça.)
Ben ca c'est une bonne raison pour que je corrige la pile.

>C'est sûr que l'utilisateur va mourir s'il y a écrit "TI-89" au lieu de "TI-89 Titanium"...
Pauvre utilisateur. Il va envoyer un mail pour dire qu'il ne comprend pourquoi ce programme affiche "TI-89" au lieu de "TI-89 Titanium".

>Euh non, les trampolines, eux, ne sont pas sur LCD_MEM, mais à la fin des programmes (après la fin de la variable vue par AMS).
Desole. J'avais oublie.

>Attention, il faudrait réfléchir si c'est vraiment le bon moment, et si oui, si le bit en question est vraiment le bon dans ce cas-ci. Je pense que tu devrais attendre que le format kernel v6 soit géré pour flipper le sign bit de 0x34, sinon il y aura encore un bordel.
Ok

>Bah, je n'ai pas encore décidé mon MIN_AMS... Si j'ai besoin de plus de 8 KO, je mettrai un 2.04 minimum et c'est tout. Je ne vais certainement pas dépasser les 24 KO.
C'est sur que la il y a de la marge.

>Toi.
La vie est bien faite quand meme.

Il y a quand-même un truc qu'on pourrait faire, c'est de redéfinir CALCULATOR en kernel de la manière suivante:
#define CALCULATOR ((signed char)_CALCULATOR[ 0 ]>0?_CALCULATOR[ 0 ]:0)
Avec l'optimisation de GCC, peut-être que ça ne se fera même pas remarquer avec les utilisations courantes. Je vais tester. Cela nous permettrait de mettre ton flag (avec la même méthode qu'on a utilisé pour le flag V200 sous TIGCC 0.94, c'est-à-dire un asm(".xdef _flag_6").

extern unsigned char _CALCULATOR[];

#define CALCULATOR ((signed char)_CALCULATOR[ 0 ]>0?_CALCULATOR[ 0 ]:0)

int f()
{
  return CALCULATOR ? 1 : 2;
}

#undef CALCULATOR
#define CALCULATOR _CALCULATOR[0]

int g()
{
  return CALCULATOR ? 1 : 2;
}

f:
        tst.b _CALCULATOR
        sle %d0
        ext.w %d0
        moveq.l #1,%d1
        sub.w %d0,%d1
        move.w %d1,%d0
        rts
        .even
        .globl  g
g:
        tst.b _CALCULATOR
        seq %d0
        ext.w %d0
        moveq.l #1,%d1
        sub.w %d0,%d1
        move.w %d1,%d0
        rts

>Ben, tu rajoutes ceux qu'elle ne définit pas.
Oui mais j'ai pas le droit de toucher a ces variables. Elles sont reservees au systeme

Le "flag Titanium" est un flag mis dans le header kernel des programmes qui indique que le programme est "compatible Titanium" de la manière voulue par PpHd, c'est-à-dire:
* ignoré par l'autopatcheur. (Et sous PreOs, être ignoré par l'autopatcheur signifie aussi qu'on ne peut pas utiliser les définitions d'origine de doorsos::font_small et doorsos::font_large, on est obligé d'utiliser les nouveaux RAM_CALLs. C'est une différence par rapport au système GhostBuster+Iceberg, dans lequel ce problème est géré dans le code de relogement de Iceberg, donc les définitions originales peuvent être utilisées même si on ne patche pas le programme. Comme le doorsos.h de TIGCC contient les définitions originales, c'est un truc duquel il faut tenir compte. En C, ces RAM_CALLs ne sont pas du tout déclarés par compat.h, donc ce n'est pas un problème en C.)
* CALCULATOR vaut -1 sur Titanium. Si le flag n'est pas mis, PreOs "émule une TI-89", ce qui veut dire en des termes plus précis qu'il dit aux programmes qu'ils sont sur TI-89 en mettant CALCULATOR à 0. C'est pour ça que je parle du flag Titanium dans la discussion sur CALCULATOR.

>D'un côté tu plaides une compatibilité maximale et tu n'appliques pas toi-même, faudra m'expliquer.
S'il peut en moins, il le fera. Sinon tant pis. C'est tout.

PpHd :
>Parce que Auto Alpha-Lock Off compare le EVENT * qu'on lui passe avec une adresse sur la pile pour savoir si on est dans le event loop principal
>ou pas. Si on est dans un dialogue, on n'est pas dans l'event loop principal. Donc Auto Alpha-Lock Off ne fait rien si on est dans l'event loop
>principal, parce que ça veut dire qu'on n'est pas dans un dialogue. Or, si le niveau de la pile change, le EVENT * ne sera plus le bon.
>(Il dépend de la version de AMS aussi, mais Auto Alpha-Lock Off détecte la version d'AMS pour ça.) Ben ca c'est une bonne raison pour que je corrige la pile.

C'est sérieux ou c'est ironique là?

>C'est sûr que l'utilisateur va mourir s'il y a écrit "TI-89" au lieu de "TI-89 Titanium"...
Pauvre utilisateur. Il va envoyer un mail pour dire qu'il ne comprend pourquoi ce programme affiche "TI-89" au lieu de "TI-89 Titanium".

Et je lui répondrais que c'est pour économiser les 16 octets de la chaîne de caractères (14+\0+padding). Le nom de la calculatrice est trop long.

[Ton exemple de code.]

Ça promet bien, mais ce n'est pas la seule utilisation possible à tester. Je vais faire des tests plus poussés avant de tirer ma conclusion.

PpHd :
>D'un côté tu plaides une compatibilité maximale et tu n'appliques pas toi-même, faudra m'expliquer. S'il peut en moins, il le fera. Sinon tant pis. C'est tout.

Et je précise aussi que mon idée de système anticrash nécessitera déjà AMS 2.00 minimum. (Ben oui, il n'y a pas de fonction de déprotection à intercepter sous AMS 1. D'ailleurs, si TI vire un jour leur protection, il faudra que je trouve autre chose. )

Bon, voilà:

#define USE_KERNEL
#include <tigcclib.h>

void foo(void);

#undef CALCULATOR 
#define CALCULATOR ((signed char)_CALCULATOR[ 0 ]>0?_CALCULATOR[ 0 ]:0) 
 
void f1(void)
{ 
  if (TI89) foo();
} 
 
void f2(void)
{ 
  if (TI92PLUS) foo();
} 
 
void f3(void)
{ 
  if (V200) foo();
} 
 
void f4(void)
{ 
  if (!TI89) foo();
} 
 
void f5(void)
{ 
  if (!TI92PLUS) foo();
} 
 
void f6(void)
{ 
  if (!V200) foo();
} 
 
void f7(void)
{ 
  if (CALCULATOR) foo();
} 
 
void f8(void)
{ 
  if (!CALCULATOR) foo();
} 
 
#undef CALCULATOR 
#define CALCULATOR _CALCULATOR[0] 
 
void g1(void)
{ 
  if (TI89) foo();
} 
 
void g2(void)
{ 
  if (TI92PLUS) foo();
} 
 
void g3(void)
{ 
  if (V200) foo();
} 
 
void g4(void)
{ 
  if (!TI89) foo();
} 
 
void g5(void)
{ 
  if (!TI92PLUS) foo();
} 
 
void g6(void)
{ 
  if (!V200) foo();
} 
 
void g7(void)
{ 
  if (CALCULATOR) foo();
} 
 
void g8(void)
{ 
  if (!CALCULATOR) foo();
}

	.file	"test.c"
#NO_APP
	.text
tigcc_compiled.:
#APP
	.xdef _ti89
	.xdef _ti92plus
	.xdef _v200
	.xdef __ref_all___startup_code
	.set _A_LINE,0xA000
	.xdef __ref_all___kernel_format_data_var
	.xdef __ref_all___kernel
	.set MT_TEXT,0x8000
	.set MT_XREF,0x9000
	.set MT_ICON,0xA000
	.set MT_CASCADE,0x4000
#NO_APP
	.text
	.even
	.globl	f1
f1:
	link.w %a6,#0
	tst.b _RAM_CALL_0
	jbgt .L1
	jbsr foo
.L1:
	unlk %a6
	rts
	.even
	.globl	f2
f2:
	link.w %a6,#0
	cmp.b #1,_RAM_CALL_0
	jbne .L3
	jbsr foo
.L3:
	unlk %a6
	rts
	.even
	.globl	f3
f3:
	link.w %a6,#0
	cmp.b #3,_RAM_CALL_0
	jbne .L5
	jbsr foo
.L5:
	unlk %a6
	rts
	.even
	.globl	f4
f4:
	link.w %a6,#0
	tst.b _RAM_CALL_0
	jble .L7
	jbsr foo
.L7:
	unlk %a6
	rts
	.even
	.globl	f5
f5:
	link.w %a6,#0
	cmp.b #1,_RAM_CALL_0
	jbeq .L9
	jbsr foo
.L9:
	unlk %a6
	rts
	.even
	.globl	f6
f6:
	link.w %a6,#0
	cmp.b #3,_RAM_CALL_0
	jbeq .L11
	jbsr foo
.L11:
	unlk %a6
	rts
	.even
	.globl	f7
f7:
	link.w %a6,#0
	tst.b _RAM_CALL_0
	jble .L13
	jbsr foo
.L13:
	unlk %a6
	rts
	.even
	.globl	f8
f8:
	link.w %a6,#0
	tst.b _RAM_CALL_0
	jbgt .L15
	jbsr foo
.L15:
	unlk %a6
	rts
	.even
	.globl	g1
g1:
	link.w %a6,#0
	tst.b _RAM_CALL_0
	jbne .L17
	jbsr foo
.L17:
	unlk %a6
	rts
	.even
	.globl	g2
g2:
	link.w %a6,#0
	cmp.b #1,_RAM_CALL_0
	jbne .L19
	jbsr foo
.L19:
	unlk %a6
	rts
	.even
	.globl	g3
g3:
	link.w %a6,#0
	cmp.b #3,_RAM_CALL_0
	jbne .L21
	jbsr foo
.L21:
	unlk %a6
	rts
	.even
	.globl	g4
g4:
	link.w %a6,#0
	tst.b _RAM_CALL_0
	jbeq .L23
	jbsr foo
.L23:
	unlk %a6
	rts
	.even
	.globl	g5
g5:
	link.w %a6,#0
	cmp.b #1,_RAM_CALL_0
	jbeq .L25
	jbsr foo
.L25:
	unlk %a6
	rts
	.even
	.globl	g6
g6:
	link.w %a6,#0
	cmp.b #3,_RAM_CALL_0
	jbeq .L27
	jbsr foo
.L27:
	unlk %a6
	rts
	.even
	.globl	g7
g7:
	link.w %a6,#0
	tst.b _RAM_CALL_0
	jbeq .L29
	jbsr foo
.L29:
	unlk %a6
	rts
	.even
	.globl	g8
g8:
	link.w %a6,#0
	tst.b _RAM_CALL_0
	jbne .L31
	jbsr foo
.L31:
	unlk %a6
	rts

Donc je peux effectivement utiliser cette définition. Ne reste plus qu'à faire avaler le patch à Sebastian...

> C'est sérieux ou c'est ironique là?
Serieux.

>Donc je peux effectivement utiliser cette définition. Ne reste plus qu'à faire avaler le patch à Sebastian...
Est-il corruptible ?

Kevin Kofler :
Ne reste plus qu'à faire avaler le patch à Sebastian...

Tu pourrais lui donner autre chose que des patchs à manger quand meme... le pauvre.

Voilà mes patches proposés:

--- compat.h_	Sun Sep  5 18:16:46 2004
+++ compat.h	Tue Sep 14 13:46:52 2004
@@ -132,7 +132,8 @@
 #ifdef DOORS
 
 #define ROM_base _ram_call (3,const void*)
-#define CALCULATOR (_CALCULATOR[0])
+/* PreOs 0.70 says CALCULATOR is -1 on the Titanium. We don't. */
+#define CALCULATOR ((signed char)_CALCULATOR[0]>0?_CALCULATOR[0]:0)
 
 #undef LCD_WIDTH
 #define LCD_WIDTH _ram_call (1,unsigned long)

--- default.h_	Sun Sep  5 18:16:52 2004
+++ default.h	Tue Sep 14 13:48:18 2004
@@ -26,6 +26,9 @@
 
 #ifdef USE_TI89
 asm (".xdef _ti89");
+#if defined(USE_KERNEL) || defined(DOORS)
+asm (".xdef _flag_6"); /* PreOs 0.70 Titanium flag */
+#endif
 #if !defined (USE_TI92PLUS) && !defined (USE_V200)
 #define _TI89_ONLY
 #define _ONE_CALC_ONLY

Je vais les proposer à Sebastian.

Merci Kevin

Patch envoyé à Sebastian.
Bon, je crois que la discussion au sujet de la valeur de CALCULATOR est close. Encore un patch de moins pour Iceberg 2.00. Je me demande si je vais vraiment passer mon temps à faire Iceberg 2.00 après tout, j'ai l'impression que mes plans convergent de plus en plus vers PreOs 0.70 (ou 0.71 si tu vas y mettre ma graphlib).

pourquoi preos devrait passer en 0.71 juste à cause d'un chgt de lib ?

Il ne va pas la mettre à jour tout de suite, il va le faire pour la prochaîne mise à jour seulement.

Au fait, voilà le document que j'ai rédigé pour les RAM_CALLs:

IMPORTANT NOTICE ABOUT RAM_CALLS:
=================================

Just because some RAM_CALLs are supported by Iceberg doesn't mean they should be used. (In fact, I
recommend against using kernel mode for new programs at all. But read the following if you are
going to write a new kernel-based program anyway.) Many RAM_CALLs are obsolete (for example because
there are ROM_CALLs doing the same thing in a cleaner way) and supported by Iceberg for
backwards-compatibility only. Others suffer from the opposite problem: they are a portability
nightmare because they require a very recent version of PreOs or Iceberg and won't work with any
other kernel. And others shouldn't have been introduced in the first place.

Only the following RAM_CALLs are safe and appropriate to use: CALCULATOR, LCD_WIDTH, LCD_HEIGHT,
ROM_base, LCD_LINE_BYTES, KEY_LEFT, KEY_RIGHT, KEY_UP, KEY_DOWN, KEY_UPRIGHT, KEY_DOWNLEFT,
KEY_DIAMOND, LCD_SIZE, KEY_SHIFT, ROM_VERSION (WARNING: ROM_VERSION needs an AMS 2 kernel). As
for HW_VERSION, it was a good addition, but unfortunately it was added only in Universal OS 1.14.

I. Badly-designed RAM_CALLs - avoid these at all costs!
-------------------------------------------------------

The following RAM_CALLs are really badly designed. They don't quite serve their intended purpose,
so it is very unwise to use them. Don't.

+----------------+---------------------------------------------------+---------------------------+
| Name           | Badly designed because                            | Use instead               |
+----------------+---------------------------------------------------+---------------------------+
| RegisterVector | Kernel mode is not a good choice for TSRs. If you | _nostub mode              |
|                | use any "function RAM_CALLs" in your kernel-based |                           |
|                | TSRs, they will unavoidably either crash or get   |                           |
|                | forcefully uninstalled (leaking memory) when the  |                           |
|                | kernel gets uninstalled. This also affects the    |                           |
|                | conditional lib RAM_CALLs, so you can't use any   |                           |
|                | libraries. So why are you using kernel mode in    |                           |
|                | the first place?                                  |                           |
+----------------+---------------------------------------------------+---------------------------+
| GHOST_SPACE    | This RAM_CALL is supposedly intended to make      | bclr.b #2,$600001         |
|                | programs more portable. This is a joke! Not only  | set NON-GHOSTED interrupt |
|                | does this require very recent kernels (see III.), | bset.b #2,$600001         |
|                | but most importantly using it makes it much more  |                           |
|                | likely to make the programs fail on future        |                           |
|                | hardware versions than using the clean method     |                           |
|                | suggested at the right. Thus, NEVER use this! If  |                           |
|                | you are adapting old programs to the Titanium, do |                           |
|                | it properly and cleanly.                          |                           |
+----------------+---------------------------------------------------+---------------------------+

II. Obsolete RAM_CALLs - don't use these for new programs!
----------------------------------------------------------

The following RAM_CALLs are obsolete. They were introduced at a time where very few was known about
the native ROM_CALLs, and it was customary practice to hack around in private AMS globals.
(font_small and font_large were technically introduced only later as actual RAM_CALLs, but they
existed in the form of obsolete font_medium+offset hacks which don't work properly on the
Titanium, even though this is worked around by Iceberg.) This practice is nowadays frowned upon.
Don't mess around with private operating system variables, call the supported API instead!

+-------------------------------------+--------------------------------------------------+
| Name(s)                             | Use the following ROM_CALLs instead              |
+-------------------------------------+--------------------------------------------------+
| font_medium, font_small, font_large | DrawStr, DrawChar, DrawClipChar, DrawStrWidth    |
+-------------------------------------+--------------------------------------------------+
| kb_globals                          | kbd_queue (moveq.l #6,d0; trap #9) and OSdequeue |
+-------------------------------------+--------------------------------------------------+
| Heap (including the DEREF macro)    | HeapDeref                                        |
+-------------------------------------+--------------------------------------------------+
| FolderListHandle, MainHandle        | Sym* VAT handling functions                      |
+-------------------------------------+--------------------------------------------------+

III. Unportable RAM_CALLs - try avoiding their use
--------------------------------------------------

The following RAM_CALLs require high versions of PreOs or Iceberg to work. Only the first 3
are supported by one previous kernel (Universal OS, which introduced them). Some of them aren't
supported by TitaniK either. (For the ones supported by Iceberg 0.90, the code is there in TitaniK
0.12 too, but it doesn't work because of the execution protection.) So try to avoid them whenever
possible.

+----------------------+---------+---------+------------+-----------------------------------------+
|                      | Minimum | Minimum | Supported  |                                         |
| Name                 |  PreOs  | Iceberg | by TitaniK | Possible alternatives                   |
|                      | version | version |   0.12?    |                                         |
+----------------------+---------+---------+------------+-----------------------------------------+
| Idle (from UniOs)    |  0.52   |  0.90   |    Yes     | idle ROM_CALL, move.b #x,$600005        |
+----------------------+---------+---------+------------+-----------------------------------------+
| Exec (from UniOs)    |  0.52   |  0.90   |  Yes (*)   | userlib::exec (* for some kernels)      |
+----------------------+---------+---------+------------+-----------------------------------------+
| HW_VERSION (UniOs)   |  0.52   |  0.90   |    Yes     | __get_hw_version in TIGCCLIB            |
+----------------------+---------+---------+------------+-----------------------------------------+
| Ptr2Hd               |  0.52   |  0.90   |    Yes     | HeapPtrToHandle                         |
+----------------------+---------+---------+------------+-----------------------------------------+
| Hd2Sym               |  0.52   |  0.90   |    Yes     | SymFindFirst and SymFindNext            |
+----------------------+---------+---------+------------+-----------------------------------------+
| LibsBegin            |  0.52   |  0.90   |    No      | Avoid conditional libraries. Instead,   |
| LibsEnd              |  0.52   |  0.90   |    No      | either just link the library, or if it  |
| LibsCall             |  0.52   |  0.90   |    No      | actually isn't a library at all, but    |
| LibsPtr              |  0.52   |  0.90   |    No      | just a data file, open it as a data     |
| LibsExec             |  0.52   |  0.90   |    No      | file, don't abuse the library system.   |
+----------------------+---------+---------+------------+-----------------------------------------+
| HdKeep               |  0.52   |  0.90   |    Yes     | Don't use kernel mode for TSRs.         |
+----------------------+---------+---------+------------+-----------------------------------------+
| ExtractFromPack      |  0.62   |  0.90   |    No      | Don't use PreOs archive packs. You      |
| ExtractFile          |  0.62   |  0.90   |    No      | can use the TICT ExePack tech instead.  |
+----------------------+---------+---------+------------+-----------------------------------------+
| LCD_MEM              |  0.62   |  0.90   |    Yes     | $4c00                                   |
+----------------------+---------+---------+------------+-----------------------------------------+
| font_small           |  0.62   |  0.90   |    Yes     | See II. But do NOT use the old font_    |
| font_large           |  0.62   |  0.90   |    Yes     | medium+x hack, it's even less portable. |
+----------------------+---------+---------+------------+-----------------------------------------+
| SYM_ENTRY.name       |  0.62   |  0.90   |    Yes     | 0                                       |
+----------------------+---------+---------+------------+-----------------------------------------+
| SYM_ENTRY.compat     |  0.62   |  0.90   |    Yes     | 8                                       |
+----------------------+---------+---------+------------+-----------------------------------------+
| SYM_ENTRY.flags      |  0.62   |  0.90   |    Yes     | 10                                      |
+----------------------+---------+---------+------------+-----------------------------------------+
| SYM_ENTRY.hVal       |  0.62   |  0.90   |    Yes     | 12                                      |
+----------------------+---------+---------+------------+-----------------------------------------+
| SYM_ENTRY.sizeof     |  0.62   |  0.90   |    Yes     | 14                                      |
+----------------------+---------+---------+------------+-----------------------------------------+
| ExtractFileFromPack  |  0.64   |  0.90   |    No      | Don't use archive packs. See above.     |
+----------------------+---------+---------+------------+-----------------------------------------+
| exit                 |  0.70   |  2.00?  |    No      | Use the portable TIGCCLIB               |
| atexit               |  0.70   |  2.00?  |    No      | implementations instead.                |
+----------------------+---------+---------+------------+-----------------------------------------+
| RegisterVector       |  0.70   |  2.00?  |    No      | Don't use kernel mode for TSRs. See I.  |
+----------------------+---------+---------+------------+-----------------------------------------+
| GHOST_SPACE          |  0.70   |  2.00?  |    No      | bclr.b #2,$600001. See I.               |
+----------------------+---------+---------+------------+-----------------------------------------+
| KERNEL_SPACE         |  0.70   |  2.00?  |    No      | HW_VERSION==2 ? 0x40000 : 0 (**)        |
+----------------------+---------+---------+------------+-----------------------------------------+
Note that the minimum PreOs versions shown are the minimum public releases. Private betas are not
counted.

(*) support for running kernel programs only!
(**) but see above for use of the actual HW_VERSION RAM_CALL

>pourquoi preos devrait passer en 0.71 juste à cause d'un chgt de lib ?
Parce que graphlib, parce que probleme de stack et parce que je dois desinstaller les TSR kernel avant de desinstaller PreOS

>Exec (from UniOs) | 0.52 | 0.90 | Yes (*) | userlib::exec (* for some kernels)
Faux. Preos minimum. UniOs ne l'a pas en tant que RAM_CALL.

PpHd :
>Exec (from UniOs) | 0.52 | 0.90 | Yes (*) | userlib::exec (* for some kernels) Faux. Preos minimum. UniOs ne l'a pas en tant que RAM_CALL.

Je corrigerai ça alors. (Universal OS ne documente même pas correctement les ajouts. )
[EDIT: La 1.30 les documente, mais pas la version dans laquelle ça a été rajouté.]

Au fait, pour:

- Intercept always the idle trap.

je me rappelle que tu m'avais parlé d'un problème avec h220xTSR dû à ça. Est-ce que c'est résolu depuis? (J'avais dit à l'époque que la solution correcte est de ne pas intercepter le trap #0 en permanence, mais tu ne m'as visiblement pas écouté, donc je demande où ça en est.)

J'ai aussi trouvé 2 commentaires qui ne sont plus corrects dans svector.asm, un de toi:

; This code is usefull for HW2 without HW2TSR
;	ie HW2 with Hw2patch

Il faudrait mettre plutôt:
This code is useful for HW2 with ROM-resident HW2Patch. It won't work with RAM-resident HW2Patch, and it is not needed for h220xTSR and HW3Patch.
et un de moi:

		move.l	a7,a2			; the convention requires a2 to hold the address of
						; the EVENT structure - while we are not worring about
						; TeOS here, unfortunately, some versions of XtraKeys for
						; the TI-92+ (including the latest released version) rely
						; on this too (because the move.l 64(a7),a2 got forgotten
						; by mistake)

Il faut supprimer "(including the latest released version)", c'est corrigé depuis la version 2.30.

Ensuite, ce n'est pas "panick", mais "panic".

Et enfin, une chose qui me chagrine toujours est ton choix de ne chercher les librairies que dans certains répertoires. Les autres kernels sont passés de ce système au système de recherche dans tous les répertoires qui est plus pratique, toi, tu fais un retour en arrière.

>Et enfin, une chose qui me chagrine toujours est ton choix de ne chercher les librairies que dans certains répertoires. Les autres kernels sont passés de ce système au système de recherche dans tous les répertoires qui est plus pratique, toi, tu fais un retour en arrière.
Pas tout a fait. La je regarde dans 3 dossiers differents: celui de l'executable, celui courant et celui systeme.

LCD_MEM | 0.62 | 0.90 | Yes | $4c00

Ca te fais pas peur ça comme "alternative" ? (bon ok ça serait facile à patcher... mais bon... on n'est plus sûr de rien).
Même remarque pour les SYM_ENTRY

Au fait, il y a une fonction de UniOs qui n'est toujours pas implémentée dans PreOs (listée aussi dans les "missing features" de PreOs):

- userlib::KbdMgr equ userlib@0012 :

  En entrée, elle demande dans a0 l'adresse d'une fonction, qui sera
  appelée par KbdMgr avec un paramètre dans d0.l :
  - d0.l > 0 : code de la touche qui a été pressée
  - d0.l = 0 : temps spécifié écoulé
  Cette fonction peut agir en conséquence et doit répondre à travers
  d0.l :
  - d0.l >= 0 : KbdMgr quitte avec cette valeur
  - d0.l < 0 : ~d0.l (~ = not) indique un délai en ms (millisecondes)
    Le délai est compté à partir du dernier appel avec d0.l, ce qui
    signifie que si lors appui a lieu au bout de 0.1 s d'attente,
    retourner ~1000 rendra le contrôle 0.9 s plus tard. La gestion du
    clavier ne perturbe donc pas le timer. Si vous voulez quand même que
    KbdMgr rende rappelle la fonction 1 s plus tard, il faut d'abord
    retourner ~0.
  L'APD est supporté. Idle est utilisée. KbdMgr est réentrante. En cas
  d'erreur, d0.l < 0.

  Registres d1-a6 : KbdMgr n'en détruit aucun, et ils sont passés à la
  fonction spécifiée lors de l'appel à KbdMgr.

  Tout comme userlib/util::idle_loop, cette fonction repose sur l'AI1 du
  tios.

Ça, c'est de la spec saugrenue... Quel coup de sadisme de la part de JM... Regardez-moi ces contraintes:
* fonction callback
* passage par registres utilisant le sign bit des registres comme des paramètres supplémentaires
* interaction absurde timer-clavier
* "L'APD est supporté. Idle est utilisée. KbdMgr est réentrante." La dernière est particulièrement lourde, ça rend presque impratiquable d'utiliser les timers AMS.
* "Registres d1-a6 : KbdMgr n'en détruit aucun, et ils sont passés à la fonction spécifiée lors de l'appel à KbdMgr." Argh! Convention d'appel non-standard, donc inimplémentable en C (alors que le C serait le seul moyen d'implémenter cette fonction complexe en un temps raisonnable), et en plus des contraintes ridicules sur les registres (ils doivent passer tous intacts au callback).
* "Tout comme userlib/util::idle_loop, cette fonction repose sur l'AI1 du tios." Si on compte respecter ça, c'est encore une contrainte sur l'implémentation.

Qui a envie de se lancer là-dedans? Ou alors on fait comme pour les niveaux de gris?

Ximoon :
LCD_MEM | 0.62 | 0.90 | Yes | $4c00

Ca te fais pas peur ça comme "alternative" ? (bon ok ça serait facile à patcher... mais bon... on n'est plus sûr de rien). Même remarque pour les SYM_ENTRY

Tous les programmes _nostub utilisent ces constantes, tous les programmes kernel en C aussi. (Et autant on pourrait utiliser le RAM_CALL pour LCD_MEM, autant il est pratiquement impossible d'utiliser des RAM_CALLs pour les offsets dans les structures.) De plus, la structure SYM_ENTRY fait partie de l'API officielle de TI (tiams.h), donc elle ne changera pas, et LCD_MEM est documenté dans la doc du SDK: 0x004C00-0x005AFF LCD Buffer.