Comment detecter... - Page 2

Ouais, pour les rom_call.
Ben, a part ça, je vois pas vraiment ou il pourrait y avoir un prbm. Bon, faut dire aussi que je suis pas une référence

Et puis, c'est le seul truc que j'ai à peu prés compris

Est-ce que tu sais comment qu'on fait pour créer une variable exploitable par AMS ?

ben normalement mon prog cree une srting...
(je crois que j'ai trouvé la ou ca buggue : c l'addresse que renvoie DerefSym qui est mauvaise)

*Tu gère mal la rom call DerefSym. Elle renvoie un pointeur. Il faut que tu le prennes dans a0, et non dans d0.
fait move.l a0,a4 ;on sauve la SYM_ENTRY

*La rom call HeapDeref a besoin comme paramètre un handle, qui tient sur un mot.
fait move.w d0,-(a7) ;on empile pour dereferencer
et un addq.l #2,a7 après.

*move.l d0,a4 ;on sauve le pointeur
>fait movea.l a0,a4, car HeapDeref renvoie une adresse.

*à la fin:
addq.l #1,a4 ;0.b
>efface le vraiment, un nouveau bloc alloué n'est pas forcément initilalisé à 0.
fait clr.b (a4)+

*move.w $32,(a4)+ ; sign du kernel .w , 0.b
a4 pointe sur une adresse impaire, tu auras une address error
fait un truc de ce genre:
move.b $32,(a4)+
move.b $33,(a4)+

* move.b #45,1(a4) ;STR_tag .b
ici encore, tu dois absolument effacer à la main l'octet d'avant.
Fait un clr.b (a4)+ puis un move.b #45,(a4).

Attention, avec ton programme, s'il n'y a pas de kernel installé, ça renverra une chaîne vide.
Ah oui, et n'oublie pas de verifier si "kerinfo" est archivé, et désarchive le dans ce cas.

oui merci
pour les a0 au lieu de d0 j'aivais deja trouvé...

pour le reste : merci encore :


gwahooo ca marche

enpuis si il n'y a pas de kernel : oui je l'avais prévu, c plus simple ainsi
pour l'archive : si c archivé, ca va créer une var twin en ram non ?
[edit]Edité par azerty83 le 12-02-2002 à 22:23:46[/edit]

Et c'est quel partie de ton prog qui créer la chaine ?

ben tout...
(de la creation de l'entree dans la vat a l'allocation de la memoire en passant par le remplissage de la zone allouée)

>azerty83 : pour l'archive : si c archivé, ca va créer une var twin en ram non ?
ouais, en fait c'est pas très gênant, c'est juste que quand on resetera la calc, on tombera sur l'ancien valeur de kerinfo, au moment ou on l'avait archivée, et pas sur sa dernière valeur.
[edit]Edité par ExtendeD le 13-02-2002 à 21:03:24[/edit]

ouais...
de toutes facons si on reset, yaura plus de kernel
et puis je ne sais pa sdu tout comment archiver, effacer des variable alors

Merci, azerty83, et pour l'amélioration, je vais en plus donner la version du kernel installé
Avec ce que tu m'a filé, je pense pouvoir me débrouillé
Et merci ExtendeD d'avoir aidé azerty83

enfi la version ca ve etre goret a utiliser, c du decimal representé en hexa...

Pourquois ?
suffit de faire un ord(var). Ca te renvois le truc en déçimale. Et il suffit de traduire en hexa (tu vas pas me dire que tu sais pas faire ça pour avoir la version)

oui enfin c goret...
(tu renvoie ca dans une expr ou une string ?)

ben string, c'est plus simple à exploiter.
Ce serait bien si ça l'envoyer dans une list (OS+version), mais je sais pas comment on fait

J'ai un petit prbm
Bon, j'ai repris entièrement les sources de azerty83, j'ai fait un copié-collé à la suite du premier (sauf l'entète), j'ai changer les adresses de RAM ($32 et $33 par $30 et $31), j'ai déplacer dc.b 'kerninfo' pour le mettre à la fin (et que j'ai remplacer par kername) et j'ai ajouter un dc.b 'kerver' à la fin juste au dessous.

Quand je le démarre, j'ai l'écran qui s'efface (sauf la sl) puis qui se redessine et j'ai PO (pour preos) qui est stcké dans kervar. Kername est ignorer.

Voici la source (un peu longue) :

include "OS.h"
xdef _nostub
xdef _ti92plus
xdef _ti89
movem.l a4-a5,-(a7)
move.l $c8,a5

pea.l sym(pc)
move.l SymAdd*4(a5),a0
jsr (a0)

move.l d0,(a7)
move.l DerefSym*4(a5),a0
jsr (a0)

move.l a0,a4

move.l #7,(a7)
move.l HeapAlloc*4(a5),a0
jsr (a0)

move.w d0,12(a4)

move.w d0,(a7)
move.l HeapDeref*4(a5),a0
jsr (a0)

move.l a0,a4
move.w #5,(a4)+
clr.b (a4)+
move.b $32,(a4)+
move.b $33,(a4)+
clr.b (a4)+
move.b #45,(a4)
dc.b 0,'kername'

pea.l sym(pc)
move.l SymAdd*4(a5),a0
jsr (a0)

move.l d0,(a7)
move.l DerefSym*4(a5),a0
jsr (a0)

move.l a0,a4

move.l #7,(a7)
move.l HeapAlloc*4(a5),a0
jsr (a0)

move.w d0,12(a4)

move.w d0,(a7)
move.l HeapDeref*4(a5),a0
jsr (a0)

move.l a0,a4
move.w #5,(a4)+
clr.b (a4)+
move.b $30,(a4)+
move.b $31,(a4)+
clr.b (a4)+
move.b #45,(a4)

addq.l #4,a7
movem.l (a7)+,a4-a5
rts
dc.b 0,'kername'
dc.b 0,'kerver'
sym:
dc.b 0


Normalement, ça devrait mettre PO dans kername et ÿG dans kerver.

Tu viens de faire tourné sous tes yeux l'anti-crash de PreOS (remercie le au passage de ma part ).
En asm, quand tu fais dc.b "...", tu forces le compilo à écrire dans le programme des données et non des instructions, et les données restent dans l'executable exactement à l'endroit ou tu les as déclarées. Si tu le mets juste après une instruction, la calc croira que ces données sont aussi des instructions, et essaiera de les executer, et donc risquera de planter.
Il faut donc mettre tout les dc.b à la fin de ton programme, après ton rts final.

Vive PreOS !!!

PreOSbugs

Sinon, même en mettant tous les dc.b aprés le rts, ça me renvois toujours pas la version du kernel. Kername est toujours aussi bassement ignoré.

deja il faut que tu mette 2 labels (sym1 et sym2) si tu veux pouvoir utiliser les 2 noms...
a la fin, fais :

dc.b 0,'kername'
sym2:
dc.b 0,'kerver'
sym1:
dc.b 0


je pens que ca ira mieux
(pour le reste, g po regardé)

Maintenant, grace à azerty83, c'est ÿG qui est stocké dans kername et kervar qui est ignorer

ben moi je verrais bien ca :

 include "OS.h" 
 xdef _nostub 
 xdef _ti92plus 
 xdef _ti89 
 movem.l a4-a5,-(a7) 
 move.l $c8,a5 

 pea.l sym[4]1[/4](pc) 
 move.l SymAdd*4(a5),a0 
 jsr (a0) 

 move.l d0,(a7) 
 move.l DerefSym*4(a5),a0 
 jsr (a0) 

 move.l a0,a4 
 
 move.l #7,(a7) 
 move.l HeapAlloc*4(a5),a0 
 jsr (a0) 

 move.w d0,12(a4) 

 move.w d0,(a7) 
 move.l HeapDeref*4(a5),a0 
 jsr (a0) 

 move.l a0,a4 
 move.w #5,(a4)+ 
 clr.b (a4)+ 
 move.b $32,(a4)+ 
 move.b $33,(a4)+ 
 clr.b (a4)+ 
 move.b #45,(a4)  

 pea.l sym[4]2[/4](pc)  
 move.l SymAdd*4(a5),a0 
 jsr (a0) 

 move.l d0,(a7) 
 move.l DerefSym*4(a5),a0 
 jsr (a0) 

 move.l a0,a4 
 
 move.l #7,(a7) 
 move.l HeapAlloc*4(a5),a0 
 jsr (a0) 
  
 move.w d0,12(a4) 
 
 move.w d0,(a7) 
 move.l HeapDeref*4(a5),a0 
 jsr (a0) 
 
 move.l a0,a4 
 move.w #5,(a4)+ 
 clr.b (a4)+  
 move.b $30,(a4)+  
 move.b $31,(a4)+ 
 clr.b (a4)+ 
 move.b #45,(a4) 

 addq.l #4,a7  
 movem.l (a7)+,a4-a5 
 rts 
 dc.b 0,'kername' 
sym1:
 dc.b 0,'kerver' 
sym2: 
 dc.b 0 

No such op-code a pu clavier sur PC¸ sorry

Vive les clavier quand même
TI-GCC me dit : "No such op-code" à chaque ligne.
Ce qui veu dire, si j'ai bien traduit, ce n'est pas une instruction connus. J'ai l'impression qu'il à pété un cable, lui

Vérifie que tes instructions commencent bien par un espace et que cet espace soit un vrai (pas un espace protégé).

Effectivement, ça peut servir

Ca fonctionne !!!!
Mal, mais ça fonctionne
Bon reste plus qu'a faire en sortes de ne pas faire intervenir l'anti-crash de PreOS.
ExtendeD à dis que c'était à cause des dc.b qu'il fallait mettre aprés le rts final. Si c'est un rts final, c'est qu'il faut en mettre un avant.
Je dirais... aprés le move.b "45,(a4). Si c'est pas ça, je me demandait aussi s'il faillait pas mettre un plus aprés ce même a4.
Me tromperais-je ??

Non, le rts est bien placé. C'est juste que tu as mal rafraîchi la pile. Remplace le addq.l #4,a7 à la fin par addq.l #8,a7.
Et ça peut s'optimiser tout ça avec des sous-routines, la création des 2 variables est presque identique.

Ok. Ben, en fait, je suis encore pire qu'azerty83, donc déjas, un truc qui fonctionne, ce serait déjas bien
Aprés, on verras pour l'opti

Au fait, ça change quoi qu'on mette 4, 8 9, 10.... ?

4, 8 9, 10 ?

heu dequoi que tu parles là ?