Ben en soi, c'est pas mal, sauf que ça termine d'exploser le range utilisable. Puis faut le coder aussi, j'ai fait hier soir la liste de quel ramcall prend quoi ici ou là, et qu'est-ce qu'il renvoie ici ou là, c'est imbitable à implémenter (utilisation de d0,d1,d5,a0,a2,a5 , mais aussi... rien!). J'en suis arrivé à la conclusion que l'idéal, c'est de ne corrompre aucun registre.
=> C'est pour ça que l'adresse de retour, tu sais pas quoi en faire, vu que tu ne sais pas où sera la pile quand tu restaureras SR.
=> c'est pour ça que je demandais une variable
=> c'est pour ça que pour se passer d'une variable, faut pousser l'adresse de retour dans la bonne pile, et donc trifouiller le SR sur la pile superviseur.

C'est le fruit de mes tentatives de code d'hier soir.
(et aux dernières niouzes, c'était ptêt bien dl'a merde. Je suis en train d'accoucher)

(même si je ne suis pas sûr qu'il soit fréquent d'utiliser des ROM_CALLs en F-Line quand on est en mode superviseur )

Utilisation de BitmapPut pour faire afficher à l'int5 un curseur dans un éditeur, par exemple.