HW2 Plantage du changement de piles - Page 2

Ok, elle vide la cache.

Je n'ai toujours pas compris POURQUOI le trap #4 n'appelle pas correctement la 16ème fonction du trap #B.

Sinon j'ai découvert un truc très chiant : toute lecture du port $60001B le réinitialise à zéro
Si j'y accède "indirectement", c'est à dire en lisant l'adresse inférieure sur un mot ($60001A.w), va-t-il détecter que j'y accède ?

arf, c'est rarement voulu un bug

toute lecture du port $60001B le réinitialise à zéro
je savais pas
va-t-il détecter que j'y accède ?
oui

Remarque, pour "toute lecture du port $60001B le réinitialise à zéro" je ne suis plus très sûr.
A mon avis c'est plutôt le stockage d'un mot en $600018 qui est impossible en clair, une écriture ne fait rien d'autre qu'appeller l'AI2, elle n'affecte pas la valeur du registre.

Et je suis dans la merde


Il me faudrait un moyen de lire l'un de ces ports (n'importe lequel, je m'en fout) puis restaurer la valeur un peu plus tard

>> arf, c'est rarement voulu un bug
Tu ne sais pas comment le trap #4 fait pour détecter qu'un kernel est présent ?

JM
a écrit : Il est plus prudent de tout désinstaller pour changer les piles, mais ce n'est pas obligatoire (sauf pour Universal OS et tous les autres programmes détournant trap #4)

... ou EV_hook!!!
On ne peut pas lancer un programme au rallumage (pour appeler le trap #11) sans que plusieurs évènements soient déclenchés (à moins de détourner le trap #4, mais alors on est dans le cas ci-dessus)!

JM
a écrit : Pour que cette fonction ne soit pas appelée par inadvertance, ce qui planterait la TI, cette fonction de trap #$B teste d'abord si elle a été correctement appelée.

Je pense plutôt que c'est pour nous empêcher de nous en servir pour passer outre leurs limites. Mais on y arrive quand-même (merci Zeljko).

Tu ne sais pas comment le trap #4 fait pour détecter qu'un kernel est présent ?
Où tu as vu que trap #4 détectait la présence d'un kernel ?

C'est pas le kernel qui est à l'origine du plantage ?

Non, je l'ai dit : c'est un bug d'AMS et j'ai donné un exemple de plantage qui ne fait pas intervenir de kernel.

Pourtant il intervient quand on a installé un kernel, c'est bien ça !!!!?

oui, et ?

j'aurais dû faire un rappel sur la limitation matérielle moi

NON !

regarde l'exemple qu'iol donne dans le post #1

exec "4E444E75000" sans kernel et sans tsr, ni autre

JM : Voilà : d'où ma question du post #26 :
Le truc du kernel que le TIOS n'aime pas rt qui fait planter la calc quand on change les piles, y'a pas moyen de le "rendre invisible" à chaque extinction de la calc, puis de le restaurer à l'allumage ?
Ceci, en détournant le trap #4 bien sûr.

Non.

Haa quand même il aura fallu 16 posts pour avoir une réponse

Thibaut: TAIS TOI !

JM: C fait
Kevin: Seulement dans la version hw2patch de preos. Mise a jout du programme uninstal qui se demerde pour savoir si trap #4~de preos ou d'un autre.

>Attention, ne mets ça que si le HW2Patch en ROM est détecté!

>Avec le HW2Patch en RAM, ça ne marchera pas de toute façon,
Je sais pas. A voir.


Sinon c pas un bug d'AMS. Si on appelle tios:ff ca marchera correctement a mon avis. Mais pas asm("trap #4"). Cool, je connais enfin la difference entre off(); et asm("trap #4") -

Sinon c pas un bug d'AMS. Si on appelle tios: off ca marchera correctement a mon avis

Pourquoi ?

>Extended: Reflechis.
move.l USP,a0
move.l $10(a0),a0
cmp.l #....,a0
bcs.s fatal
cmp.l #....,a0
bcc.s fatal

[nosmile]Si on appelle tios:ff ca marchera correctement a mon avis.
Faux. Il faudrait d'abord que tios:ff alloue autant d'octets sur la pile que la routine qui appelle la 16è fontion de trap #11 (pour savoir si elle a été correctement appelé, elle analyse la pile utilisateur). Et même si c'était le cas, il faudrait toujours appeler tios:ff en mode utilisateur.

PpHd : hé on a le droit de poser des questions non ?
Ce topic est réservé à l'3133t ?

avec le HW2Patch en RAM, ça ne marchera pas de toute façon
En effet, il n'y a absolument aucune solution dans ce cas. Il faudrait relancer à chaque fois le code de déprotection de la calculatrice et modifier les ports.
La technique utilisée par HW2Patch en RAM consiste à éviter définitivement que les ports de la limitation matérielle soient à nouveau modifiés, en détournant trap #11. Malheureusement, lors d'un changement de piles, ces ports sont réinitialisés par du code qui ne peut pas être détourné.

JM: G pas teste. Merde

Pour détecter si le HW2Patch en ROM est présent, c'est tout simple. Extrait de la source de h220xTSR (pour 3 lignes, même pas besoin de me demander la permission de les utiliser ):

 ROM_CALL2 EX_stoBCD
 tst.w 92(a4) ;check for HW2Patch (ROM resident)
 beq patched ;if it is installed, refuse installation

Ça ne coûte vraiment rien de faire ce test avant d'essayer de hooker le trap 4.

PpHd tu aurais pas moyen en stoquank qq pars dans se que met le kernel en ram de stoquer la valeur du hook du trap #11 et a chaque fois que un pro est lancé tu test si le trap a pas été détourné, si c le cas tu le remet a sa valeur "normale" anti protection

Quoi t'en pense ? (j'parle ptet un peu la j'suis fatigué)

Je n'ai rien compris là.

Alors pour expliciter un peu :

Au lancement du kernel tu recup la valeur de trap #11 (normale détourné par HW2Patch avant puisqu'il faut l'installer avant preos) et tu le met bien au chaud qq pars dans la ram de la TI

Ensuite, a chaque fois qu'un prog ASM est lancé (le kernel est solicité que je sache dans se cas nan ?) tu test si la valeur actuelle en 0xAC (c bien 0xAC trap #11 nan ? ou j'me plante ?) est egale a la valeur que ta mis au chaud dans la ram, si c pas le cas tu remet 0xAC a la valeur que ta recup dans la Ram au chaud

En gros tu obtiens :

Installation du kernel :

T11Old = 0xAC

Au démarage du prog :

(0xAC == T11Old) ? : 0xAC=T11Old

T11Old représente la case qq pars au chaud dans la ram

Je ne vois pas du tout à quoi ça servirait.

a sa :

avec le HW2Patch en RAM, ça ne marchera pas de toute façon
En effet, il n'y a absolument aucune solution dans ce cas. Il faudrait relancer à chaque fois le code de déprotection de la calculatrice et modifier les ports.
La technique utilisée par HW2Patch en RAM consiste à éviter définitivement que les ports de la limitation matérielle soient à nouveau modifiés, en détournant trap #11. Malheureusement, lors d'un changement de piles, ces ports sont réinitialisés par du code qui ne peut pas être détourné.

Et ben, tu n'as rien compris de l'explication de JM...

C'est bien, on est 2 alors

Si le pbm c aussi la valeur des ports,

On peut remettre ses port a leur "bonne" valeur (pour déproteger) si on détecte que

0xAC et T11Old
sont !=