Adapté d'après mon gestion_primitives.s de P3S (étape 5) :[ul][li]appeler un TRAP dédié à cette modification[/li][li]on se retrouve donc avec 8 octets de plus sur la pile, qui sont, du sommet vers le bas :[ul][li]le SR actuel (word à SP)[/li][li]l'adresse de retour à l'appelant du TRAP (long à SP+2)[/li][li]l'adresse du vecteur du TRAP appelé (word à SP+6)[/li][/ul][/li][li]1^re instruction de ton code TRAP : appliquer ta modification sur le SR situé sur la pile en SP andi.w #0xF8FF, (%sp)[/li][li]2^de instruction de ton code TRAP : appeler RTE qui va se contenter de revenir là où tu étais quand tu as appelé le TRAP... mais avec un SR modifié \o/ !!![/li][/ul]Mais bon, c'est barbare, et **il me semble** (à vérifier dans la doc 68k de Rouveyrol) que ton privilege violation vient du fait qu'un ANDI.W sur SR est interdit, même en mode superviseur, alors que le MOVE.W sur SR est autorisé (mais uniquement en superviseur), ce qui donnerait un truc du genre :

move.w %sr, %d0
andi.w #0xF8FF, %d0
move.w %d0, %sr

Ce code est vraiment à prendre avec des pincettes, je n'ai pas pratiqué depuis un an >_<"...
Quant au code barbare avec utilisation du TRAP, il **semble** me souvenir que c'est à cause du MOVE dans SR qui est interdit en mode esclave, d'où l'astuce du « je fais un TRAP pour copier SR sur la pile, je trifouille ce SR et je RTE-ise pour feinter le proc et lui faire avaler mon SR trafiqué malgré le mode esclave » (il me **semble**, j'ai bien dit !!!)
À moins que le TRAP ne fasse passer temporairement et automatiquement en mode superviseur ?
Rhâ je ne m'en souviens plus !