HW2 Plantage du changement de piles - Page 1

Pour ceux qui ne veulent pas s'attarder sur les détails, sachez qu'il s'agit en fait d'un bug d'AMS 2.0x dont TI ne semble pas avoir connaissance puisqu'il suffit d'exécuter exec "4E444E750000" sur une calculatrice "propre" (aucun patch/kernel/TSR...) et de changer les piles pour faire planter la TI (HW2).

Les détails :

Il faut d'abord s'avoir que sur les 89 HW1&2 et 92+ HW2, le CPU n'est pas alimenté par la pile bouton. Un changement de piles lorsque la calculatrice est éteinte réinitialise toujours le CPU ! Le boot est exécuté, puis AMS est appelé et des ports dont ceux gérant la limite matérielle ($700000-$700007) sont réinitialisés. Puis AMS détecte que la calculatrice était éteinte et elle termine son exécution à la fin de la routine trap #4.
Pourtant, trap #4 semble restaurer les ports $700000-$700007 à la fin, mais l'opération échoue parce que trap #B considère qu'elle n'a pas été correctement appelée et ne touche pas aux ports $700000-$700007.

En attendant que TI corrige ça, j'ai deux solutions :
- HW2Patch modifie d'autres zones de la flash, mais ça me fait ultra-chier...
- je laisse le boulot aux kernels (PreOS en fait) qui doivent seulement détourner trap #4 :

trap4:	move.l	a0,-(a7)
	move	usp,a0
	move.l	a0,-(a7)
	sub	a0,a0
	move	a0,usp
	bsr.s	t4call
	move	(a7)+,a0
	move	a0,usp
	move	(a7)+,a0
	rte
t4call:	move	sr,-(a7)
	dc.w	$4EF9
oldtrap4
	dc.l	0

Le kernel s'en charge

oué, te fait pas chier pour rien !

JM : c'est quoi la différence entre move usp,a0 et move.l a7,a0 ?

3 lettres

a7 pointe sur la pile superviseur là.

Donc en fait le patch de Kevin était compliqué pour rien.

Le mieux ça serait quand même que TI prenne conscience du bug

ExtendeD : mais c'est intéressant ça !!!!!!!!!! je ne savais pas qu'on pouvait accéder à la pile utilisateur en mode superviseur. Ca va me simplifier un truc dans le noyau répartiteur des tâches de GraphX

oué

Extended oué, oué, selon le mode, a7 = ssp ou usp

... Je n'ai pas bien lu l'affaire, mais csi c'est un probleme qui sera resolut qu par les kernel. c'est pas top pour les nostubiens..

h220xtsr corrigait dejà le problème.

Du boulot pour moi donc

J'ai tout mâché !

Oué

au fait t'as un peu de temps en ce moment PpHd ?
parce qu'il y a un bug dans MakePrgm
Je t'en dis plus ?

euh... je crois qu'il a mieux à faire que de s'occuper de makeprgm
moi aussi d'ailleurs

JM=> je me doute bien, et c pour ça que je ne lui ai pas fait le report de bug alors que je l'ai trouvé il y a au moins un moas

Accouche !

est ce bien sérieux ?

Erf moi sur ma ti, j'ai juste installé HW2 Patch ... j'ai pas de tsr etc...
Conclusion... bien j'ai pas interet a changé de pile!!!

c qd meme pas la mort un pitit plantage
(
par contre c vrai que g deja perdu des src comme ça
enfin rien de tres important
)

ExtendeD
a écrit : Donc en fait le patch de Kevin était compliqué pour rien.

Pas tout à fait.
Même si je fais ça, je dois en plus mettre $3f000 dans la variable où AMS stocke l'adresse du dernier programme ASM exécuté pour que le trap 4 me déprotège bien l'espace fantôme et pas n'importe quoi. Et il faut aussi trouver cette variable sur tous les AMS, ce qui n'est pas gagné. Pour le HW2Patch en ROM, c'est différent parce que le trap 11 déprotège tout automatiquement avec le HW2Patch en ROM. Ce n'est pas tout à fait aussi simple pour h220xTSR.

Pour l'instant, je garde ma méthode qui marche très bien.

TiMad
a écrit : ... Je n'ai pas bien lu l'affaire, mais csi c'est un probleme qui sera resolut qu par les kernel. c'est pas top pour les nostubiens..

Le problème n'est vraiment grave que si tu utilises un TSR. Sinon, il te suffit de ne pas changer les piles pendant l'exécution d'un programme pour éviter le plantage. Ce n'est que s'il y a un TSR que tu ne peux pas changé les piles sans qu'il y ait un programme (le TSR) qui tourne. Et si tu as un TSR, tu es censé utiliser h220xTSR, et ce dernier corrige ce problème.

PpHd a écrit :
Du boulot pour moi donc

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, avec h220xTSR, c'est inutile, et ça pose problème si on veut mettre à jour h220xTSR (trap 4 déjà détourné), et sur HW1, c'est inutile également.

TiMad a écrit :
Erf moi sur ma ti, j'ai juste installé HW2 Patch ... j'ai pas de tsr etc...
Conclusion... bien j'ai pas interet a changé de pile!!!

Reflash...
On se demande pourquoi tu as mis le HW2Patch...

Parce que j'aime pas les tsr c'est comme les kernels.. je suis trop faignant pour les executer..
Et HW2Pacth est tres bien a mon gout

TiMad a écrit :
Parce que j'aime pas les tsr

Si tu n'utilise que du _nostub non-TSR, tu n'as pas besoin de quoi que ce soit. Ni HW2Patch, ni h220xTSR.

Tout depend ce que l'on fait...

Il n'est pas nécessaire de corriger ce bug pour changer ses piles.
Il suffit juste qu'aucun programme asm ne soit actif (kernel, TSR...) lorsque tu éteins ta calc. 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) : on peut supprimer la limite en relançant immédiatement un prog asm ou une chaîne exec.

Le truc (c'est quoi ? un handle ? un vecteur ? ...) 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 ?

Tout est expliqué dans le premier post...

Désolé je ne vois pas du tout l'explication du fait que "l'opération échoue parce que trap #B considère qu'elle n'a pas été correctement appelée" !


J'ai une autre question, est-ce que le M68k vide son cache lors de la survenu d'une interruption, ou bien il continue l'instruction en cours PUIS celle qui était en cache, avant de sauter ?

l'opération échoue parce que trap #B considère qu'elle n'a pas été correctement appelée
C'est la 16è fonction de trap #$B (d3.l = 15) qui gère les ports de la limitation matérielle. On lui donne une adresse et elle permet l'exécution dans une fenêtre de 12/28 ko (selon qu'AMS limite à 8 ou 24 ko) commençant à cette adresse (modulo 4 ko). 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. Et justement, trap #4 ne l'appelle pas corretement.

est-ce que le M68k vide son cache lors de la survenu d'une interruption, ou bien il continue l'instruction en cours PUIS celle qui était en cache, avant de sauter ?
Le CPU termine d'exécuter l'instruction en cours et déclenche l'interruption.