Caluler la RAM utilisée par un programme (suite) - Page 1

Désolé, la fermeture de topic me gêne généralement.
Les topics sont souvent off-topics mais pas toujours ininteressants (et suffit de pas le lire si son contenu ne plait pas).

XDanger
: Pour moi, le kernel est le seul responsable de sa disparition de la communauté internationale, je ne parle pas de la communauté française. Dans les vieux kernels, jusqu'en 1999, il y a des définitions absolument horribles qui montrent un amateurisme effarant... Dans le genre, utilisation d'adresses absolues pour des trucs aussi simples que MainHandle ou HomeHandle (qui sont tous deux, ainsi que d'autres informations, dans pSymPG - désolé d'y faire encore référence - qui peut être wrappé très facilement à partir de la plupart des fonctions de la VAT sous AMS).

Attention, il faut se replacer dans le contexte : personne n'avait jamais vu ni imaginé de mise-à-jour de l'OS à l'époque. Et ça avait été fait comme ça pendant des années sans problèmes avec Fargo.
Et de toute façon le kernel n'a plus rien a voir avec ça maintenant, ça ne sert plus à rien de ramener ça au front (ni aucune caractéristique des kernels qui ne sont plus mis à jour).

ExtendeD
: Attention, il faut se replacer dans le contexte : personne n'avait jamais vu ni imaginé de mise-à-jour de l'OS à l'époque.

Et à leur avis, elle servait quoi la FlashROM??? À dire "ouah, super, on a de la FlashROM"??? C'était annoncé dès le départ par TI (cf. les premiers manuels) qu'il allait y avoir des mises à jour!

Et ça avait été fait comme ça pendant des années sans problèmes avec Fargo.

En effet, je ne comprends pas comment ce genre de trucs:
FOLDER_LIST_HANDLE equ tios::globals+$194C ; word (handle)
utilisés par Fargo ait fonctionné avec toutes les ROMs TI-92. C'est probablement parce que la ROM de la TI-92 n'a pas changé beaucoup parce que TI ne voulait pas rajouter des fonctionnalités à la ROM non-flashable des TI-92 pour ne pas vendre des calculatrices fondamentalement différentes avec le même numéro de modèle.

En tout cas, ces offsets ont changé énormément entre AMS 1 et AMS 2 (même plus qu'entre la TI-92 et AMS 1), ce qui a dû en surprendre certains, mais ce qui était certainement prévisible. Je ne comprends pas comment quelqu'un d'expérimenté en assembleur puisse croire qu'une séquence de 6476 octets en variables globales (cf. l'offset ci-dessus - bon d'accord, 2636 octets si on part de la fin de LCD_MEM) puisse rester totalement inchangée à travers des mises à jour du système d'exploitation, d'autant plus que ce système d'exploitation est codé en C (et ça fait longtemps que les "experts", dont les auteurs des kernels, étaient au courant de ça). C'est totalement naïf comme pensée.

Et de toute façon le kernel n'a plus rien a voir avec ça maintenant, ça ne sert plus à rien de ramener ça au front (ni aucune caractéristique des kernels qui ne sont plus mis à jour).

Plus rien à voir? Le kernel exporte toujours des RAM_CALLs qui encouragent l'accès direct aux structures internes de AMS (et donc la programmation sale) plutôt que l'utilisation des ROM_CALLs prévus pour.

ExtendeD :
Désolé, la fermeture de topic me gêne généralement. Les topics sont souvent off-topics mais pas toujours ininteressants (et suffit de pas le lire si son contenu ne plait pas).

C'est pas compliqué de créer UN topic qui s'appellerait "Débat PedroM" ?

[Edit] Dommage que Kevin ait posté sans quoi ce topic aurait été détruit...

Cela n'a rien a voir avec PedroM mais avec les kernels.
Et les ramcalls c'est pas sale du tout.

Les RAM_CALLs de fonts ne sont pas sales, non, en effet (je parle bien entendu des kernels, PedroM n'est pas concernée)... Faut-il que je me répète encore une fois sur tous leurs défauts ? J'en ai déjà mis une couche de façon implicite par mini-message...

> Je te parle du caractere technologique, pas de la qualite, ni du reste
J'ai déjà dit que le kernel avait des trucs que le _nostub n'avait pas... Mais pour la technologie, ça dépend des trucs. Les RAM_CALLs de fonts sous les kernels sont faits de façon très peu technologique, brute-force, très lente, et ils ne respectent même pas le choix possible de l'utilisateur (bon, OK, c'est plus ou moins dans la spécification du truc, mais ça n'est pas bon à mon avis).


> C'etait parfaitement valable si ca ne devait fonctionner que sous AMS 1.00.
Oui, mais comme Kevin l'a bien dit, il était impensable qu'il n'y ait pas d'updates...

> Et la plupart des kernels des autres calcs font +/- la meme chose.
Peut-être, mais ça n'est pas pour ça que c'est bien, sûr, propre. Il n'y a qu'à voir ce qui s'est passé en 1999, quand on est passé à AMS 2.xx.
Et puis Kevin a dit que ça n'était pas exactement la même chose, que c'était mieux fait et plus sûr sur d'autres machines.

>> En sachant que ce CAS n'aurait un intérêt réel que s'il était plus performant que celui d'AMS, au niveau de celui de la HP-49 par exemple (bon courage...)
> On peut reprendre les sources de celui de la 49
Ils sont disponibles ?


>> Dans le genre, utilisation d'adresses absolues pour des trucs aussi simples que MainHandle ou HomeHandle
> Adresses absolues? Sûr? Si je me rappelle bien, ce sont des numéros de handles constants, pas des adresses absolues, qui sont utilisées. Mais le résultat est le même.
Sûr. Je posterai un extrait d'une documentation ©ACZ 1999 en édit (je poste d'abord, car je n'ai pas envie de perdre le message, et j'ai l'impression que mon PC va planter).
[EDIT: mon PC n'a d'ailleurs pas manqué de planter...]
L'extrait est ci-dessous. Je trouve qu'ils ont été laxistes, ne serait-ce que parce qu'ils auraient très bien pu se rendre compte que le handle de la EStack et l'adresse de début du handle de la EStack étaient à proximité de top_estack, et mettre des adresses absolues pour ces variables aussi... Et il y a bien d'autres trucs dont ils auraient pu se rendre compte, qu'ils auraient transformés en adresses absolues, avec des résultats catastrophiques...

;******************************************
;TI-89 equates and macros
;Assembly Coder's Zenith 1999
;******************************************


LCD_MEM equ $4c00 ;ends $5aff
_LCD_MEM equ $4c00
main_lcd equ $4c00
globals equ $4c00
_APD_INIT equ $5b10 ;.l, initial APD value
_APD_TIMER equ $5b14 ;.l, current APD value
_APD_FLAG equ $5b42 ;set if APD terminated

MaxHandles equ $7578
TopHeap equ MaxHandles+$a
Heap equ MaxHandles+$16
GETKEY_CODE equ MaxHandles+$1e
kb_globals equ $759e
kb_vars equ kb_globals
KEY_PRESSED_FLAG equ kb_globals+$1c
ST_flags equ $75a6
HomeEntryHandle equ $7708
ReturnValue equ $770e

FolderListHandle equ $7a18
MainHandle equ $7a16
DefTempHandle equ $7a14

_ram_call_000 equ $7ba4
_ram_call_02f equ $7474
_ram_call_109 equ $76fc
_ram_call_10b equ $6554
_ram_call_10c equ $6558
_ram_call_2a3 equ $7444




> Je te rappelle qu'il y a d'autres méthodes encore plus propres sur AMS 1.
Oui, c'est vrai... En revanche, à ma connaissance, il n'y en a pas de plus propre pour d'autres champs de pSymPG.

>>Grossièrement faux... Tu donnes des nombres qui sont n'importe quoi.
99,99%, ça veut dire 9999 ROM_CALLs sur 10000. Il n'y en a que 0x607=1543, et il y a bien plus d'un ROM_CALL d'AMS 2.xx qui est utilisé à grande échelle ou qui va l'être à assez court terme (quelques mois).
>Ok j'exagere. 99% des fonctions utilisees.
Eh non. Kevin a fait une liste de 23 ROM_CALLs sur moins de 700, c'est à dire un peu moins de 3%. Ajoutons les ROM_CALLs que j'utilise dans tthdex, qui seront bientôt utilisés dans TIGCCLIB (fonctions de FlashApps pour les fonts sous AMS 2.xx...) et on arrive à plus de 30 ROM_CALLs. ExtendeD utilise dans FlapHider plusieurs autres ROM_CALLs de FlashApps dont on ne connaît pas le nom. primary_tag_list est utilisé par d'autres programmes, un a été posté récemment sur notre forum. Ajoutons à cela l'utilisation de fonctions de Progress Bars, un programme qui les utilise a été releasé aujourd'hui sur ticalc.org.
A moyen terme, des fonctions void(void) qui par exemple pushent juste l'entier 0, 1, -1 sur la EStack, seront utilisées aussi. C'est plus petit que toute autre méthode. On peut même le faire en F-Line sans souci, vu que la plupart des programmes de CAS nécessitent AMS 2.04+ de toute façon.
Tu es convaincu, ou faut-il qu'on en rajoute encore et que tu t'enfonces un peu plus dans ta mauvaise foi ?

>>>Il y a au moins trois fonctions de FlashApps dans la nouvelle version du support de fonts - pour être compatible avec toutes les versions d'AMS, sans faire des trucs lents et pas sûrs (sous AMS 2.xx, une recherche de sprite ne reflète pas le choix possible de l'utilisateur qui peut redéfinir les fonts).
>>Hum. DrawStr fonctionne tres bien.
>Pour une fois, on est d'accord. (Pourquoi réimplémenter les ROM_CALLs dans les programmes?)
Pour avoir plus de vitesse quand on en a besoin, au détriment bien entendu de la taille. Tu avais dit toi-même que la réimplémentation était envisageable si on allait 10 à 100 fois plus vite, ce qui est le cas sous AMS 2.xx.



>>>Citons aussi certains ROM_CALLs de la Flash qui seront utilisées par l'un ou l'autre des file-explorers, notamment le ROM_CALL qui renvoie le début de l'archive - ça va remplacer un gros bloc de code lourd qui fait la même chose ou même moins (le bloc peut ne pas tenir compte des FlashApps et donner un résultat erroné, par exemple). Et c'est parfaitement intégré dans le système, parfaitement propre, l'appeler prend moins de 10 octets...
>>Super utile.
>Ben oui, c'est utile.
PpHd, ça n'est pas parce qu'à toi, ça paraît complètement saugrenu, que ça n'est pas utile. Je me sers de cette fonction dans ttcinfo, ça marche parfaitement. Ca a remplacé un bloc de plus de 200 octets qui en plus, je l'ai su quand AMS 2.08 a été releasé, ne supportait pas AMS 2.08 et 2.09 89. Il me semble qu'il ne supportait pas les FlashApps non plus. A comparer avec les moins de 10 octets nécessaires pour l'appeler, surtout si on utilise des ROM_CALLs en F-Line.

>Les RAM_CALLs de fonts ne sont pas sales, non, en effet (je parle bien entendu des kernels, PedroM n'est pas concernée)... Faut-il que je me répète encore une fois sur tous leurs défauts ? J'en ai déjà mis une couche de façon implicite par mini-message...
Tu gueules sans arret sur le fait que ca soit soit-disant lent a trouver, et que le pauvre utilisateur ne peut pas utiliser une Flash Application introuvable pour changer les fonts.
A part ca ?

>J'ai déjà dit que le kernel avait des trucs que le _nostub n'avait pas... Mais pour la technologie, ça dépend des trucs. Les RAM_CALLs de fonts sous les kernels sont faits de façon très peu technologique, brute-force, très lente, et ils ne respectent même pas le choix possible de l'utilisateur (bon, OK, c'est plus ou moins dans la spécification du truc, mais ça n'est pas bon à mon avis).
A la rigueur elle pourrait le faire. Tu confonds la norme Kernel v5 et la facon de s'y approcher.

>Oui, mais comme Kevin l'a bien dit, il était impensable qu'il n'y ait pas d'updates...
Et alors ? J'y peux rien !

>Peut-être, mais ça n'est pas pour ça que c'est bien, sûr, propre. Il n'y a qu'à voir ce qui s'est passé en 1999, quand on est passé à AMS 2.xx.
Il a fallu tout repartir a zero. Ok ?

>Et puis Kevin a dit que ça n'était pas exactement la même chose, que c'était mieux fait et plus sûr sur d'autres machines.
Bof.

>Ils sont disponibles ?
Erable est sous licence GPL. Bonne chance pour le porter quand meme.

C'est quoi ce truc d'equates sans queue ni tete ?

>Oui, c'est vrai... En revanche, à ma connaissance, il n'y en a pas de plus propre pour d'autres champs de pSymPG.
Mais on n'a pas besoin d'y acceder !

>Tu es convaincu, ou faut-il qu'on en rajoute encore et que tu t'enfonces un peu plus dans ta mauvaise foi ?
Non. Ca fait tres peu dans les programmes cites, et encore moins par rapport aux programmes publics.

>Tu avais dit toi-même que la réimplémentation était envisageable si on allait 10 à 100 fois plus vite, ce qui est le cas sous AMS 2.xx.
J'ai dit que la reimplantation etait correcte si ca allait plus vite de 5% et si c'etait necessaire. (Par exemple 5% de pas grand chose font un truc tout petit).

Mais ttcinfo est aussi super utile.

Désolé, la fermeture de topic me gêne généralement. Les topics sont souvent off-topics mais pas toujours ininteressants (et suffit de pas le lire si son contenu ne plait pas).

Bah t'aurais au moins du en profiter pour trouver un nom qui corresponde au débat

Plus rien à voir? Le kernel exporte toujours des RAM_CALLs qui encouragent l'accès direct aux structures internes de AMS (et donc la programmation sale) plutôt que l'utilisation des ROM_CALLs prévus pour.

A l'époque ou ca a été créé c'était un très bon format. Aujourd'hui il sont plus la pour la compatibilité. C'est sur que aujourd'hui, je déconseille de les utiliser mais ca permet une compatibilité la plus correcte avec les anciens programmes.

Les RAM_CALLs de fonts ne sont pas sales, non, en effet (je parle bien entendu des kernels, PedroM n'est pas concernée)... Faut-il que je me répète encore une fois sur tous leurs défauts ? J'en ai déjà mis une couche de façon implicite par mini-message...

Idem.
et certains RAMCALLs comme les LCD_WIDTH,... sont très utiles.

Peut-être, mais ça n'est pas pour ça que c'est bien, sûr, propre. Il n'y a qu'à voir ce qui s'est passé en 1999, quand on est passé à AMS 2.xx. Et puis Kevin a dit que ça n'était pas exactement la même chose, que c'était mieux fait et plus sûr sur d'autres machines.

Bah il ya aussi eu des problèmes avec les prog nostubs.
et le Kevin a dit si tu peut pas l'expliciter un peu plus ca vaut pas grand chose

PpHd :
>Les RAM_CALLs de fonts ne sont pas sales, non, en effet (je parle bien entendu des kernels, PedroM n'est pas concernée)... Faut-il que je me répète encore une fois sur tous leurs défauts ? J'en ai déjà mis une couche de façon implicite par mini-message...
Tu gueules sans arret sur le fait que ca soit soit-disant lent a trouver, et que le pauvre utilisateur ne peut pas utiliser une Flash Application introuvable pour changer les fonts. A part ca ?

Qu'il ne peut pas non plus utiliser ROMedit qui est trouvable pour changer les fontes vu que tu utilises celles du boot code.

>Oui, mais comme Kevin l'a bien dit, il était impensable qu'il n'y ait pas d'updates... Et alors ? J'y peux rien !

Toi non. Les auteurs des premiers kernels et aussi du fameux fichier include de ACZ posté par XDanger, eux oui...

>Peut-être, mais ça n'est pas pour ça que c'est bien, sûr, propre. Il n'y a qu'à voir ce qui s'est passé en 1999, quand on est passé à AMS 2.xx. Il a fallu tout repartir a zero.

... à cause des kernels.

C'est quoi ce truc d'equates sans queue ni tete ?

Ça a été fait par ces développeurs renommés qui auraient vraiment dû être plus malins que ça.

>Oui, c'est vrai... En revanche, à ma connaissance, il n'y en a pas de plus propre pour d'autres champs de pSymPG. Mais on n'a pas besoin d'y acceder !

Si. Par exemple, un kernel multitâches (de style Prosit) a intérêt à mettre FindHandle dans sa sauvegarde du contexte du processus. Comme ça, il suffit d'interdire au scheduler la préemption de la ROM, et hop, le problème de la non-réentrance de AMS est règlé.
Et les autres champs peuvent aussi être intéressants.

>Tu es convaincu, ou faut-il qu'on en rajoute encore et que tu t'enfonces un peu plus dans ta mauvaise foi ? Non. Ca fait tres peu dans les programmes cites, et encore moins par rapport aux programmes publics.

Mais tu parlais de 99% des appels, pas de 99% des programmes. Et les programmes concernés sont probablement eux aussi plus qu'1%.

>Tu avais dit toi-même que la réimplémentation était envisageable si on allait 10 à 100 fois plus vite, ce qui est le cas sous AMS 2.xx. J'ai dit que la reimplantation etait correcte si ca allait plus vite de 5% et si c'etait necessaire. (Par exemple 5% de pas grand chose font un truc tout petit).

C'est moi qui avais donné le facteur 10.

Mais ttcinfo est aussi super utile.

Ben oui, les programmes de "system information" peuvent être utiles à des fins de débogage. Ces informations pourraient aussi être intéressantes dans ton ddump, d'ailleurs...

Vertyos
: Creez UN topic pour PedroM et engueulez-vous tant que vous voulez.

Uther Lightbringer :
Bah t'aurais au moins du en profiter pour trouver un nom qui corresponde au débat

Comme quoi y'en a qui comprennent. D'autres non (ou alors qui font exprès pour faire chier, dans ce cas là qu'ils le disent ça ira plus vite)

Uther Lightbringer
: et certains R[A]MCALLs comme les LCD_WIDTH,... sont très utiles.

Non. Seul CALCULATOR est utile, les autres en découlent directement. Et CALCULATOR peut aussi être trouvé par le programme lui-même assez facilement (il y a même plusieurs méthodes: ScrRect, hardware parameter block, ...).

> Tu gueules sans arret sur le fait que ca soit soit-disant lent a trouver, et que le pauvre utilisateur ne peut pas utiliser une Flash Application introuvable pour changer les fonts.
A part ca ?
Bah, oui. C'est lent, certes moins depuis que tu as changé la spec et que tu utilises les fonts du boot (ce qui reflète encore moins le comportement du système, si les fonts du boot ne sont pas les mêmes que les autres), mais ça reste plus lent que le pire cas pour la méthode d'affichage que j'ai faite, qui est de l'ordre de quelques milli-secondes. Les faits sont là.

> Et alors ? J'y peux rien !
Non, tu n'y peux rien. Tu as récupéré les ruines de ce qui restait pour l'améliorer et en faire quelque chose de mieux, c'est déjà bien, non ?

> Il a fallu tout repartir a zero. Ok ?
Voilà.

> C'est quoi ce truc d'equates sans queue ni tete ?
Un extrait d'une doc de l'époque que j'ai trouvée par hasard...

>>Tu avais dit toi-même que la réimplémentation était envisageable si on allait 10 à 100 fois plus vite, ce qui est le cas sous AMS 2.xx.
> J'ai dit que la reimplantation etait correcte si ca allait plus vite de 5% et si c'etait necessaire. (Par exemple 5% de pas grand chose font un truc tout petit).
Heu, là, je parlais à Kevin.

> et certains ROMCALLs comme les LCD_WIDTH,... sont très utiles.
D'une, ça ne sont pas des ROM_CALLs mais des RAM_CALLs. De deux, oui, c'est utile, mais ça nécessite un overhead monstre (format de relocation non standard -> ce qu'il faut pour le reloger + le code pour trouver la valeur de LCD_WIDTH, etc.)...

>Bah, oui. C'est lent, certes moins depuis que tu as changé la spec et que tu utilises les fonts du boot (ce qui reflète encore moins le comportement du système, si les fonts du boot ne sont pas les mêmes que les autres), mais ça reste plus lent que le pire cas pour la méthode d'affichage que j'ai faite, qui est de l'ordre de quelques milli-secondes. Les faits sont là.
Sauf que dans mon cas, ce n'est fait qu'une fois, a l'installation.
Pas a chaque lancement de programme.

ouah, j'y comprends rien... en tout cas ça à l'air vachement intéressant

PpHd: là, tu as raison. Mais ça nécessite des relocations non standard, qui sont, elles, faites à chaque lancement de programme...

Non. Seul CALCULATOR est utile, les autres en découlent directement. Et CALCULATOR peut aussi être trouvé par le programme lui-même assez facilement (il y a même plusieurs méthodes: ScrRect, hardware parameter block, ...).

Oui mais ca fait gagner de la place et de temps. Toujours le même problème tu aimes refaire pour tous les programmes un truc qui est commun. L'interet du kerenl est d'éviter ca.

D'une, ça ne sont pas des ROM_CALLs mais des RAM_CALLs. De deux, oui, c'est utile, mais ça nécessite un overhead monstre (format de relocation non standard -> ce qu'il faut pour le reloger + le code pour trouver la valeur de LCD_WIDTH, etc.)...

bon j'ai corigé mais tu as bien compris que c'était un labsus, je voulais bien sur parler de RAMCALL. le format prends de la place c'est vrai mais il a d'autre avantages et il a fait ces preuves. Et si le code est pas dans le kernel, c'est qu'il doit être dans le programme.

Uther Lightbringer
:

Non. Seul CALCULATOR est utile, les autres en découlent directement. Et CALCULATOR peut aussi être trouvé par le programme lui-même assez facilement (il y a même plusieurs méthodes: ScrRect, hardware parameter block, ...).

Oui mais ca fait gagner de la place et de temps. Toujours le même problème tu aimes refaire pour tous les programmes un truc qui est commun. L'interet du kerenl est d'éviter ca.

Ça prend 3 instructions ASM de plus de faire ça à partir de CALCULATOR. Donc des RAM_CALLs spéciaux pour chaque variable sont un effort totalement inutile ("overkill" comme on dirait en anglais). Et en plus, regarde le nombre de constantes dépendantes du modèle dans compat.h de TIGCC: les RAM_CALLs n'en proposent qu'une très petite partie (et heureusement, sinon le kernel serait énorme), et donc il faut de toute façon faire des tests en fonction de CALCULATOR, autant donc le faire systématiquement.

3 instructions, c'est au moins 6 octets.
Et toi tu râlais parce qu'une suite d'additions et shifts prenait 4 octets de plus qu'un muls #30,dn...
Tu ne dis que ce qui t'arranges, c'est là que tu perds ta crédibilité.
C'est dommage

Le kernel et le header du format kernel prennent largement plus que 6 octets!
On perd au moins 500 fois plus que ce qu'on gagne!

La taille du kernel ne se retrouve qu'une fois sur la TI.
Tes 3 instructions (qui font peut-être [même sûrement] plus de 6 octets) se retrouvent partout dans le programme et dans tous les progs qui n'utilisent pas ces RAMCALLs.

Le gain n'est pas de plus de 6 octets:

LCD_HEIGHT:
sans RAM_CALLs:

 moveq.l #64,d0
 add.l d0,d0
 tst.w d7 ;CALCULATOR
 bne.s \ti92pv200
 moveq.l #100,d0
\ti92pv200:

(10 octets)
avec RAM_CALLs:
move.w #LCD_HEIGHT,d0
(4 octets + 2 octets minimum de relogement = 6 octets minimum)
Gain par la RAM_CALL: 4 octets maximum.

LCD_WIDTH:
sans RAM_CALLs:

 moveq.l #120,d0
 tst.w d7 ;CALCULATOR
 bne.s \ti92pv200
 moveq.l #80,d0
\ti92pv200:
 add.l d0,d0

(10 octets)
avec RAM_CALLs:
move.w #LCD_WIDTH,d0
(4 octets + 2 octets minimum de relogement = 6 octets minimum)
Gain par la RAM_CALL: 4 octets maximum.

Et en calculant les 2 en même temps:

 moveq.l #64,d0
 add.l d0,d0
 moveq.l #120,d1
 tst.w d7 ;CALCULATOR
 bne.s \ti92pv200
 moveq.l #100,d0
 moveq.l #80,d1
\ti92pv200:
 add.l d1,d1

(16 octets)
avec RAM_CALLs:

 move.w #LCD_HEIGHT,d0
 move.w #LCD_WIDTH,d1

(8 octets + 4 octets minimum de relogement = 12 octets minimum)
Gain par la RAM_CALL: 4 octets maximum.

Je doûte que ces variables soient calculées 1000 fois ou plus sur une calculatrice. Et le kernel prend plus de 4000 octets.

Oui, mais le kernel ne permet pas seulement l'utilisation de ramcall...

heureusement... ton argument est un peu faible kevin

At ca a permis de mettre ces valeurs de facon impects sur V200 sans rien changer au programme.

CALCULATOR aurait quand-même suffi (et pour la plupart des programmes même sans ton "émulation TI-92+" comme tu l'appelles).

Ben j'y peux rien. J'aurais prefere ne pas la faire.

Mais là n'est pas la discussion.
L'important, c'est que CALCULATOR aurait suffi. Pas besoin de LCD_WIDTH etc.

Kevin Kofler :
Mais là n'est pas la discussion.
L'important, c'est que CALCULATOR aurait suffi. Pas besoin de LCD_WIDTH etc.

au moment de la sortie de la 89 c'était clairement plus utile fait comme ça...

Non. Les programmes ont de toute façon dû être portés pour l'écran plus petit, les programmeurs auraient donc pu insérer la bonne valeur de LCD_WIDTH en fonction de CALCULATOR en même temps (c'est minime comme effort par rapport à l'adaptation de l'affichage pour rentrer en la place plus petite). Et puis il y a des tas de constantes dépendantes du modèle qui ne sont pas couvertes par ces RAM_CALLs. Cf. http://tigcc.ticalc.org/doc/compat.html. Comme tu peux voir, toute la matrice clavier diffère!