En effet, il y a plusieurs inexactitudes dans ce qu'il dit:
godzil
a écrit :
PpHD, au moment ou on installe le kernel, on a forcement installé HW2patch (en RAM pour se cas) juste avant de démarer PreOS, sinon barre noir, t bien d'accord nan ?
Oui. Sauf une petite précision: "on a forcement installé HW2patch ou h220xTSR (HW2Patch en RAM pour ce cas)".
Et si j'ai bien compris, JM modifi le Trap #11 pour eviter que des ports se fassent changer pendans l'utilisation de la TI,
Oui.
donc si au moment de l'install du kernel, tu sauvegarde la valeur des ports en Q et du Trap #11, quand un prog est lancé (dit moi si je me trompe) le kernel est solicité nan ?
2 problèmes:
- On ne peut pas sauvegarder ni restaurer la valeur des ports en $700000 ("Q") sans déprotéger la FlashROM et les ports I/O système. On peut seulement déprotéger 24 KO à la fois (+ la zone en $5000-$5fff qui est déprotégée par défaut, et + l'espace fantôme si on choisit les derniers 4 KO) en passant par la fonction #15 du trap #11.
- Si les ports en $700000 sont mis à leur valeur par défaut, si le kernel n'est pas dans la zone $5000-$5fff, occupée en partie par l'écran et en partie par des variables système, donc inutilisable pour le kernel, ça plante. Même en ajoutant $40000. (Ça ne sert que quand l'espace fantôme est déjà déprotégé, pas avec les valeurs par défaut.)
On peut éviter le 2
ème problème en utilisant la méthode de
h220xTSR (choisir une petite rangée d'octets dans $5000-$5fff qui n'est pas touchée par le trap 4 et y mettre du code juste pendant l'exécution du trap 4), mais il reste le 1
er. Ce que fait
h220xTSR est qu'il ne déprotège que $3e000-$3ffff, ce qui entraîne en même temps la déprotection de l'espace fantôme.
HW2Patch en RAM ne peut pas se contenter de faire pareil de par sa nature, donc il devrait déprotéger la FlashROM et les ports I/O système à
chaque rallumage, ce qui est beaucoup trop dangereux.
Donc quand un prog est solicité, normalement le trap #11 n'a pas du etre modifié, et si c le cas, tu force les ports et le trap #11 pour remettre tel que ct avant le changement de piles
Autre problème:
seuls les ports sont remis à leur valeur par défaut, AMS ne touche pas au trap #11. Et ces ports ne sont pas lisibles sans déprotéger la FlashROM et les ports I/O système, donc je ne vois pas comment tu veux tester s'ils ont été modifiés avant de déprotéger la FlashROM et les ports I/O système.
Le seul cas que je voit que sa patcherait pas, c quand un prog met la calc sur OFF, et que les piles sont changé...
Hein?
h220xTSR gère parfaitement ce cas. Le problème n'est pas là!
PS: Si je n'ai pas répondu plus tôt, c'est parce que je m'attendais à ce que JM allait le faire.
), mais bon, c pas une raison pr le casser qd il y en a une.
toujours les mêmes compères
