Ceci est un déterrage plutôt pas mal, mais je n'ai pas pu m'empêcher de répondre.
Les fx-CP400 utilisent un processeur SuperH (SH-4A), dont la mémoire virtuelle, avec le processeur en mode privilégié (par opposition au mode utilisateur), se divise en plusieurs zones : P0 (0x00000000 à 0x7FFFFFFF), P1 (0x80000000 à 0x9FFFFFFF), P2 (0xA0000000 à 0xBFFFFFFF), P3 (0xC0000000 à 0xDFFFFFFF) et P4 (0xE0000000 à 0xFFFFFFFF). P0 est destiné à l'userspace (et est en relation avec U0), c'est dans cette zone qu'on peut définir des pages qui redirigent vers P1 ou plus haut. P1 et P2 sont mappées à l'espace d'adressage physique (qui est quant à lui de 29 bits seulement), la différence entre les deux étant que P1 a un cache et que P2 n'en a pas. L'interface des modules sur le bus (les deux seules interfaces entre les modules et le processeur étant le bus et les interruptions) sont eux destinés à être dans P4, auquel, à l'exception de l'On Chip RAM et de la Store Queue Area (?), l'utilisateur n'a pas accès. (mais de toute façon, CASIOWIN lance tout en privileged parce que olala ce serait du boulot de faire de l'usermode sécurisé, donc ici, l'utilisateur, on s'en fout)
Ici, on remarque que TARGET (on suppose qu'il s'agit de la valeur du registre TEA du MMU) est en 0xE5xxxxxx, et se situe donc dans P4 : il s'agit donc probablement d'un module (qui serait diablement proche de l'On Chip RAM, dont la XRAM se situe à 0xE5007000 sur un
SH7305). On peut supposer qu'il s'agit d'une incompatibilité entre deux microcontrôleurs (le programme étant conçu pour l'un, et étant exécuté sur l'autre, donc le module n'existe pas), ou d'un fail de calcul d'adresse (un offset foireux ?).
Mais bon, en vrai, je pinaille comme un gros relou, mais j'ai grave révisé et même appris en tapant ce post, juste parce que Critor parlait en 2014 d' "adressage continu à plusieurs giga-octets de hauteur".
