Le Casio PB-700

Eh oui ! Le PB-700, tout comme bon nombre d'autres modèles de micropoches, a droit aussi à ses "instructions cachées"... Le PB-700 ne disposant pas en standard des instructions PEEK et POKE, il constitue donc un système en théorie complètement hermétique à toutes tentatives d'explorations internes, quelles qu'elles soient. C'est indiscret. C'est interdit. Tel l'avait décidé Casio. C'était mal me connaître... Paré pour un voyage à l'intérieur du PB-700 ?

Pour ce faire, relions le PB-700 à l'une de ses interfaces cassette, et relions celle-ci à la carte son de notre PC. Cela permet d'une part l'observation visuelle d'un enregistrement BASIC, exact reflet de ce qui se trouve en mémoire... Mais cela permet d'autre part de faire charger au PB-700 ce qu'il croit être l'une de ses propres sauvegardes, alors que nous y avons effectué bon nombre de couper-coller afin d'y insérer les codes que l'on souhaite... en veillant bien évidemment à respecter les "checksums", et effectivement le PB-700 se laisse berner et avale sans sourciller l'enregistrement trafiqué ! Alors observons et trafiquons...

Entrons dans P0 la ligne "10 PRINT". Sauvegardons sous n'importe quel nom, et échantillonons ce SAVE sur le PC en un fichier WAV mono 8 bits 44.1 KHz à l'aide de notre logiciel de traitement du son favori. Observons. Tout d'abord, une porteuse, en fait une suite de "1". Puis une première séquence de bits que nous ignorerons. A la suite une deuxième porteuse constituée également de "1". Et enfin une deuxième séquence de bits constituant notre programme, c'est ce qui nous intéresse. Regroupons les bits de cette séquence quatre à quatre de droite à gauche, pour obtenir des quartets : ... 1110 0010 0010 0110 0000 1000 1110 0000 0000 0110 0111 0101 1110 1111 1111 0110 0000 1111 0110. Convertissons les quartets en hexadécimal, bits de poids faible à gauche : 7 4 4 6 0 1 7 0 0 6 E A 7 F F 6 0 F 6. On ne tient pas compte du premier 7. On groupe les quartets par 3 : 446 017 006 EA7 FF6 0F6. Dans chaque groupe, les deux premiers quartets représentent un octet du programme, quartet de poids faible à gauche. Le troisième quartet est le checksum : si le nombre de bits de l'octet est pair, il vaut 6. Sinon, 7. D'où décodage final :

44 10 00 AE FF F0

- 10 PRINT - -

Début des données Numéro de ligne (sur 16 bits, octet de poids faible à gauche) Code de l'instruction "PRINT" Fin de ligne Fin du programme

Il suffit ensuite de remplacer l'instruction de cette ligne par une autre pour établir la table des codes des instructions standards. L'on s'aperçoit ainsi que les codes allant de 00 à 7F correspondent aux caractères de même code, les codes 80 à D1 correspondent aux instructions, F0 est le code de fin de programme, FE est le code de l'instruction ":" séparant deux instructions BASIC dans une ligne (à ne pas confondre avec le caractère ":") et FF est le code de fin de ligne. L'on comprend aussi pourquoi aucun des caractères de code supérieurs à 7F n'est accessible directement au clavier : leurs codes mis en mémoire BASIC correspondent aux instructions...

Mais à quoi correspondent les codes D2 à EF, ainsi que les codes F1 à FD ? Pour le savoir, il faut reprendre le WAV, et par de savants couper-coller, on transforme par exemple le code AE de "PRINT" en code EA, c'est-à-dire permuter les deux quartets, et on réinjecte le tout au PB-700 par "LOAD". Après chargement, on "LIST" et notre "10 PRINT" s'est transformé en un étrange "10 L5<" :

44 10 00 EA FF F0

- 10 L5< - -

Début des données Numéro de ligne Code de l'instruction cachée "L5<" Fin de ligne Fin du programme

Que voilà une instruction bien bizarre ! A l'exécution, le PB-700 semble se planter, après OFF puis ON, un LIST est refusé par un "PR error"... Des instructions cachées comme "L5<", il y en a 30 dont les codes vont de D2 à EF. Certains noms sont assez farfelus, comme "l$T", "J:O", "$Y2", "or{" et autres "f.Dl"... Leur exécution n'apporte hélas rien de bien intéressant : plantages, simili-"LIST"s, "NEW"s, "PASS"s... Quant à leur édition, ce n'est pas mieux : en général, "EDIT" les normalise. "EDIT" d'ailleurs, a du mal à digérer certains des nouveaux venus. Cependant j'ai relevé deux petites perles. Et c'est la première fois que je voie ça sur un micropoche : deux instructions à nom variable... En effet, elles n'ont jamais le même nom à chaque fois qu'on les "LIST" ou "EDIT". La seule chose qui ne change pas est que le nom affiché reste toujours aussi farfelu !

Et pour les codes F1 à FD ? Là, pas de surprise, on obtient les caractères de même code CHR$. Il s'agit, vous le savez déjà, de caractères japonais.

Cette exploration des entrailles cachées du PB-700 est riche d'enseignements. En effet, à présent, nous savons tout sur ses codes internes et il est donc possible de dresser la table complète des codes BASIC. Dans cette table, les codes sur fond blanc sont les codes standards, ceux sur fond gris ne peuvent être obtenus directement, et ceux sur fond noir correspondent aux instructions "cachées" à nom variable. Concernant les instructions "cachées", le côté farfelu de la chose excepté, on peut être déçu à juste titre car on n'a rien trouvé de bien utile. A moins de futures découvertes en ce domaine... Cependant combien aurions-nous apprécié la découverte d'une instruction cachée, mais réelle celle-ci, comme par exemple une instruction "CHECK" qui permettrait un autotest du micropoche et prévue pour les services de maintenance...

Et c'est tout ? Pas tout à fait. Car dans certains cas, programmer le PB-700 par synthèse directe de codes peut se révéler très intéressant... Prenons un exmple : Imaginez que vous ayez besoin d'afficher la chaîne de caractères "%'@[ ]_" par programme. Une idée, comme ça. Normalement, on ne peut faire que PRINT CHR$(37)+CHR$(39)+CHR$(64)+ etc... étant donné que ces caractères ne sont pas accessibles directement au clavier. En utilisant la programmation synthétique, rien ne nous interdit de créer directement un PRINT "%'@[ ]_". L'avantage est évident : une meilleure lisibilité du programme et un gain de 1 à 5 octets par caractère. Et lorsqu'on ne dispose pas de modules OR-4, le moindre octet est précieux... Et on peut même aller plus loin. Par exemple, synthétisons la ligne :

44 10 00 AE 22 EA 22 FF F0

- 10 PRINT " L5< " - -

Début des données Numéro de ligne Code de l'instruction "PRINT" Code du caractère " Code de l'instruction cachée "L5<" Code du caractère " Fin de ligne Fin du programme

Un "LIST" nous retourne "10 PRINT "L5< "". Mais si vous exécutez "RUN", vous obtenez à l'affichage un carreau, qui n'est autre que le caractère CHR$ de code 234 soit... EA en hexadécimal ! Il faut toutefois bien faire attention à ne jamais éditer de telles lignes sous peine de "normalisation". Et là, par contre, le programme est p'têt un peu moins lisible... Mais cela peut rendre bien des services également, tant au niveau gain d'octets que de rapidité d'exécution...

Autre chose : Casio nous indique, dans le manuel d'utilisation, que le tampon d'entrée, utilisé par exemple pour l'introduction au clavier d'une ligne BASIC, est limité à 79 caractères. Ce n'est pas tout à fait exact. En fait il s'agit de 79 octets, ce qui n'est pas tout à fait la même chose ! Ce qui veut dire que, par synthèse de codes, il est tout à fait possible de programmer une lignes BASIC qui fasse plus de 79 caractères, du moment qu'elle ne dépasse pas 79 octets... Ca peut être pratique dans quelques cas. A noter que si ces lignes étendues sont parfaitement RUNables et LISTables, elles ne sont plus EDITables... Comme vous le voyez, la programmation synthétique du PB-700 nous apporte tout de même quelques possibilités nouvelles...

Si vous même vous souhaitez vous adonner aux joies de la programmation synthétique sur votre PB-700, ou plus généralement si vous souhaitez mettre en place un dispositif de communication simple mais efficace entre votre compatible IBM et votre poquette, vous devez vous munir des utilitaires conçus par mon éminent "collègue" allemand Marcus Von Cube, grand spécialiste des ordinateurs de poche Casio. Ses utilitaires, qui sont désormais considérés comme faisant référence en la matière, et donc indispensables, permettent notamment la conversion de fichiers binaires dont le contenu représente un enregistrement PB-700 (une cassette "virtuelle" en quelque sorte) en un enregistrement audio correspondant, et vice-versa. J'ai choisi d'attribuer l'extension '.CAS' aux cassettes "virtuelles", mais ce n'est en aucun cas une obligation. Pour obtenir les utilitaires de Marcus, je vous invite à consulter sa page dédiée sur son site Internet personnel.