Comment ça plante une fx-CP400 ?

→ **MyCalcs** profile · de **critor** » 31 Oct 2014, 00:18

Quoique l'on ait pu lui faire comme reproches, la fx-CP400, calculatrice graphique formelle tactile couleur de Casio, nous donnait l'impression d'avoir un OS (Operating System - système d'exploitation) extrêmement stable en comparaison de d'autres modèles d'âge similaire.

Les plantages restent toutefois possibles. Nous avons le plaisir de partager ce soir avec vous et à notre connaissance, le tout premier plantage de fx-CP400, dans le contexte de tentatives de mise à jour de l'OS vers la dernière version 2.00.2000.

Le message "ADRESS(R) ERROR!" nous suggère ici l'utilisation par le processeur d'une adresse invalide, c'est-à-dire ne correspondant à aucune puce physique.

Et une petite conversion en base décimale des nombres hexadécimaux reportés, nous confirme en effet que l'on serait en cas d'adressage continu à plusieurs giga-octets de hauteur, un espace largement vide quand on connaît la faible capacité de la machine (les puces ayant la plus large plage d'adressage étant ici la SDRAM de 16Mo et la NAND de 32Mo...)

→ **MyCalcs** profile · de **Lionel Debroux** » 31 Oct 2014, 08:24

Un processeur 32 bits possédant un espace d'adressage de 32 bits est la norme pour le matériel embarqué pas trop limité. Et en effet, comme les capacités mémoire des Nspire, des Prime et dex fx-CP400 sont fort limitées, le gros de l'espace d'adressage est vide - c'est normal.
Le jour où on aura une calculatrice avec plus de 4 GB de mémoire physique directement adressable n'est pas encore pour demain, a priori

→ **MyCalcs** profile · de **Cakeisalie5** » 18 Mar 2017, 22:31

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".