Lecture de Chaine 89s - Page 1

-

Orion_ a écrit :
je pensait donc, stocker les données dans des chaines.
seulement voila, je voudrais savoir comment faire, et surtout comment les lire par la suite sur TI, en ASM.

ben tu cherches l'adresse de debut du fichier, é pis voilà... ac les romcalls ou filelib c fait en 3 lignes. ensuite ba il suffit de lire les octets à l'adresse retrounée

Orion_ a précisé :
juste une précision, je pense inclure dans ma lib, uniquement les routines nécésaire de GraphLib (evitant ainsi 1.8Ko inutile et une lib en moins)
et y inclure aussi Pk92Lib. cela permettrait d'avoir une seul et unique lib

ben oui mais tout ceux qui ont un kernel (puisque tu veux une lib, c que ton prog est en kernel, à moins que tu ne fasses une lib statique, mais je vois pas l'intérêt pour un seul prog ) ont déjà graphlib..... et pk92lib c pas la mort et c déjà utilisé pas mal aussi
donc garde les libs std.

Ben c'est pas compliqué : (extrait du tutorial d'assembleur _nostub de Kevin) include "OS.h"  xdef _nostub  xdef _ti89  xdef _ti92plus  movem.l d4/a5,-(a7) ;sauvegarde d4 et a5  move.l $c8,a5 ;place la table des ROM_CALLs en a5  pea.l 3840 ;taille à allouer             ;(même chose que move.l #3840,-(a7), mais plus optimisé)  move.l HeapAllocPtr*4(a5),a0  jsr (a0) ;alloue les 3840 octets  move.l a0,d4 ;sauvegarde l'adresse du bloc alloué en d4  tst.l d4  beq nomem ;si le pointeur est nul, quitte le programme  move.l #3840,(a7) ;taille à copier ;Cette instruction n'est pas vraiment nécessaire puisque HeapAllocPtr ne modifiera ;pas la valeur qui est déjà sur la pile, mais mieux vaut ne pas se fier.  pea.l $4c00 ;source: adresse de l'écran  move.l d4,-(a7) ;destination: adresse du bloc alloué  move.l memcpy*4(a5),a0  jsr (a0) ;sauvegarde l'écran  lea.l 12(a7),a7 ;nettoie la pile ;début du programme principal  move.l ScreenClear*4(a5),a0  jsr (a0) ;efface l'écran  move.w #4,-(a7) ;cherche dans main  pea.l sym(PC) ;symbole à chercher  move.l SymFindPtr*4(a5),a0  jsr (a0) ;cherche la variable  addq.l #4,a7  move.w 12(a0),(a7) ;Le handle du symbole se trouve à l'offset 12 de la structure SYM_ENTRY.  move.l HeapDeref*4(a5),a0  jsr (a0) ;déréférence le handle  move.w #4,(a7) ;passe l'attribut A_REPLACE en argument  pea.l 3(a0) ;saute la taille de la variable et l'octet nul au début de la chaîne de caractères  clr.l -(a7) ;passe x=0 et y=0 en argument (On efface 4 octets, dont 2 pour x et 2 pour y.)  move.l DrawStr*4(a5),a0  jsr (a0) ;affiche le contenu de la chaîne de caractères  lea.l 10(a7),a7 ;nettoie la pile  move.l ngetchx*4(a5),a0  jsr (a0) ;attend l'appui d'une touche ;fin du programme principal  pea.l 3840 ;taille à copier             ;(même chose que move.l #3840,-(a7), mais plus optimisé)  move.l d4,-(a7) ;source: adresse du bloc alloué  pea.l $4c00 ;destination: adresse de l'écran  move.l memcpy*4(a5),a0  jsr (a0) ;restaure l'écran  addq.l #8,a7  move.l d4,(a7)  move.l HeapFreePtr*4(a5),a0  jsr (a0) ;libère le bloc alloué nomem:  addq.l #4,a7 ;nettoie la pile  movem.l (a7)+,d4/a5 ;restaure d4 et a5  rts  dc.b 0,'datafile' sym: dc.b 0 ;Le format des symboles est particulier: Il faut mettre un octet nul au début et à la fin, ;et le pointeur doit pointer sur le 0 final, pas sur le début.

Orion_
a écrit : je pensait donc, stocker les données dans des chaines.

Utilise plutôt des variables de type personnalisé!
Je cite la partie de mon tutorial qui suit le code cité par Samuel Labitte et que ce dernier a omise:

Quelques remarques pour finir:

* Ceci n'est qu'un exemple. Je vous déconseille fortement d'utiliser des chaînes de caractères pour enregistrer vos données, surtout s'il s'agit de données binaires, c'est-à-dire de nombres tels qu'on les trouve dans les registres plutôt que sous forme de chaînes de caractères. Il est beaucoup plus propre d'utiliser des variables de type personnalisé. Pour ceci, il suffit de placer les caractères suivants à la fin de la variable: 0,'TYPE',0,$f8. Vous pouvez remplacer TYPE par n'importe quelle chaîne de caractères de 1 à 4 caractères, qui apparaîtra dans l'écran Var-Link comme le type de la variable. L'octet $f8 correspond au OTH_TAG, qui indique à AMS qu'il s'agit d'une variable de type personnalisé.
* ATTENTION: Ce programme ne désarchive pas la variable puisqu'il est à lecture seule. Si vous désirez écrire dans une variable, vous devrez d'abord la désarchiver en utilisant EM_moveSymFromExtMem.

Orion_ a écrit :
juste une précision, je pense inclure dans ma lib, uniquement les routines nécésaire de GraphLib (evitant ainsi 1.8Ko inutile et une lib en moins)
et y inclure aussi Pk92Lib. cela permettrait d'avoir une seul et unique lib, et non pas 3 Librairies, donc TIDivX qui ne ferait qu'a peine 200 octets, et 2Ko de graphlib inutile puisque je n'utilise que les routines de Gray.

Très bonne idée, mais pourquoi faire ça à partir de librairies dynamiques? Avec des librairies statiques, c'est automatique!
Pour les niveaux de gris, il y a TIGCCLIB. Pour les fonctions de compression, si ttunpack ne te convient pas, va voir là.

...







c une idée STUPIDE !
soit il utilise les libs dynamiques std,
soit il fait ses routines ds ses progs... Dans ce cas PRECIS, les libs statiques n'ont aucun intérêt !! Qui d'autre que lui utilisera ses routines ??

L'idée, c'est d'utiliser les librairies statiques déjà existantes (TIGCCLIB pour les niveaux de gris, ttunpack ou packlib (cf. le lien du message n°4) pour la décompression).

Kevin Kofler
a écrit : L'idée, c'est d'utiliser les librairies statiques déjà existantes.

là c en effet + normal comme idée
mais on en revient tjs au meme débat

-

Et packlib (nouvelle librairie statique de la TICT), tu l'as essayée?

-

Excellent!

-

Orion_ a écrit :
vu que pk92lib et graphlib n'utilise pas d'autre lib externe donc, il suffit de les reprendre et elle seront direct en nostub,

Non, il faut:
- convertir les appels de ROM_CALLs.
- réécrire les parties qui utilisent des RAM_CALLs.

Orion_ a écrit :
et aussi comment faire pour que une lib stat ASM puisse s'utiliser en C

Mets section ".data" au début de tous les fichiers ASM. (Il y a intérêt à y en avoir plusieurs - un par fonction - pour que vraiment seules les fonctions effectivement utilisées se retrouveront dans l'éxécutable. S'il y a un seul fichier ASM, et donc un seul fichier objet, ce dernier sera toujours copié en entier.) Le reste est automatique.

-

Les arguments passés au prog, je crois que tu les retrouves successivement dans d0, d1,... si ce sont des nombres, ou dans A0, A1,... si ce sont des pointeurs.
Et si il y a plein d'arguments, le reste est dans la pile.

Orion_
a écrit : moué mais le passage en paramétre, je les recuperes comment en asm ?

Ça dépend des attributs du prototype C. Le mieux est de déclarer tes fonctions avec des spécifications de registres explicites. Par exemple:
int f(int x asm("d0"), long y asm("d1"), unsigned short z asm("d2"), void *p asm("a0"), char *q asm("a1"), short *r asm("a2"), long *s asm("a3"), ESI t asm("a4"));

Orion_ a écrit :
je pensais a une idée: reprendre les sources de graphlib
et pk92lib, + TIDivX, et en faire une lib statique nostub donc utilisable en ASM et en C, vous en pensez koi ?

Kevin Kofler
a écrit : Excellent!

arg, franchement tu m'étonneras tjs, kevin.
En ce qui me concerne, g pas changé d'avis depuis le post 1, qu'Orion_ semble n'avoir d'ailleurs pas lu

-

------

Tres mauvaise idee. Si les libs dynamiques existent, c'est pour qu'on s'en serve.

=> Plusieurs versions des fonctions sur ta calc (perte de place).
=> Plus difficile de mettre a jour.

ah, enfin qq1 qui pense comme moa

Et pas n'importe qui

oué

Pen^2 a écrit :
ah, enfin qq1 qui pense comme moa

Pas étonnant de sa part.

Je change pas d'avis Toi non plus d'ailleurs

Kevin Kofler a écrit :
Pas étonnant de sa part.

il est vrai que le suspens n'était pas insoutenable :E

-

n'importe koa

-