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.