CODINGBUG ★ LE BUG DE L'OPENOUT ★

Le Bug de l'Openout (CPC Revue)Menu - Soft - Basic

Toute ROM a ses petits bugs, et le Basic du CPC 464 n'échappe pas à cette triste règle. Or, ce bug peu gênant avec cassettes devient un lourd handicap si l'on se sert d'un lecteur de disquettes. Voici les faits :

6100 INPUT "NOM du FICHIER", FICH$
6110 OPENOUT FICH$
6120 WRITE #9, etc.
6200 CLOSEOUT

S'il y a peu de variables en RAM, si le fichier FICH$ est assez petit (moins de 4000 octets environ), il n'y aura aucune anomalie, c'est-à-dire qu'en faisant CAT, nous aurons bien le nom du fichier FICH$.
A présent, le fichier fait déjà 5 ko, sauvegarde CAT. Oh ! surprise ! pas de FICH$ au catalogue (ou entête de fichier) mais un nom bizarre constitué par un fragment des données de FICH$ ! Autre inconvénient : le programme se bloque de nombreuses secondes avant et après l'enregistrement sur cassette ou disquette. Idem d'ailleurs au rechargement par OPENIN.
Lorsque l'on utilise le magnétophone, on ne s'aperçoit guère de la détérioration du nom du fichier, car on a, par exemple :

9100 OPENIN " "

ou mieux encore OPENIN"!" qui supprime les messages à l'écran "LOADING MACHIN Block 1". Le programme charge donc le premier fichier qu'il rencontre sur la cassette en lecture. En revanche, une telle écriture ferait planter avec un "Bad Command" s'il doit lire sur une disquette ! Il faut alors que OPENIN soit suivi du vrai nom du fichier, FICH$ ; et si celui-ci a été "détérioré" lors de son enregistrement, il y aura plantage. Motif : "nom de fichier inconnu"... Plutôt gênant ! Voici d'abord le remède (trouvé non sans peine... ) et ensuite l'explication.

LE REMEDE

Au début d'un programme Basic susceptible d'enregistrer ou de lire un long fichier, insérez les lignes suivantes :

50 OPENOUT "BIDON"
60 MEMORY HIMEM-1: CLOSEOUT

Très important :

– les définitions de variables (ex.: N = 15) ou de DIM (ex.: DIM AD$(200,5) seront placées APRES ces deux lignes ;
– en revanche, un SYMBOL AFTER doit être logé AVANT ces lignes.
Un exemple très concret : notre programme LABELMATIC publié dans CPC n° 1, page 21 sera amélioré de la façon suivante :
– effacer la ligne 300 ( = GOSUB) 51000)
– 30 GOSUB 51000
– écrire les lignes 50 et 60

Le GOSUB 51000 exécute un petit sous-programme qui établit les caractères AZERTY accentués, et il commence par un SYMBOL AFTER... On a donc déplacé ce GOSUB de la ligne 300 à la ligne 30. Sans cette précaution, on aurait droit à un "Memory full" (mémoire pleine).

EXPLICATION DU PHENOMENE

Le programme Basic se loge dans le "bas" de la mémoire, tandis que les variables s'empilent en "haut", juste avant la zone RAM réservée à la mémoire d'écran. Cette limite supérieure de la mémoire a pour adresse HIMEM ( = HIGH MEMORY). On peut l'abaisser par la commande MEMORY.

Or, voilà que le programme rencontre la commande OPENOUT, et voici la farce que cela provoque :

Le HIMEM s'abaisse automatiquement de 4096 octets, soit 4 kilo-octets, l'emplacement pour loger deux "blocks". Donc, tout le paquet des variables qui se trouvaient juste en-dessous, voient leurs adresses abaissées de 4096, et si elles sont nombreuses, ce relogement peut prendre du temps...

Si on avait demandé OPENOUT "AGENDA", le fichier serait enregistré sans problème sous ce nom fixe et programmé. En revanche, si c'est OPENOUT FICH$, il doit aller chercher FICH$ dans le bloc qu'il a déplacé (ou qu'il n'a pas fini de déplacer ?). Et c'est là que se manifeste le bug de la ROM AMSTRAD CPC 464 : si le bloc de variables est trop important, il "tape à côté" dans la mémoire et nous ramène autre chose en guise de FICH$. Arrive le CLOSEOUT, le HIMEM reprend son ancienne valeur, nouveau déplacement de la mémoire, mais vers le haut, tout aussi lent qu'à la descente... Avec OPENIN FICH$, c'est tout aussi long, mais il n'y a pas d'erreur pour retrouver la bonne valeur. Le bug ne concerne donc que OPENOUT.

A présent, expliquons le remède : Cet OPENOUT "BIDON" de la ligne 50 a pour seul but de faire abaisser l'HIMEM ; comme il n'y a encore rien "en-dessous", c'est instantané. C'est alors l'occasion de figer définitivement le sommet de la mémoire disponible par MEMORY HIMEM - 1, même après le CLOSEOUT. On laisse donc vide cet espace de 4 ko pour que les OPENOUT et OPENIN futurs ne fassent plus ces "coups d'accordéon" sur le bloc des variables, lequel restera fixe. Plus d'erreurs de noms de fichiers, plus d'attentes avant et après les enregistrements ou lectures des fichiers.

CPC N°3 - SEPTEMBRE 1985

★ REVUE: CPC Revue
★ ANNÉES: 1985
★ AUTEUR: Michel ARCHAMBAULT

★ AMSTRAD CPC ★ A voir aussi sur CPCrulez , les sujets suivants pourront vous intéresser...

Lien(s):
» Coding » Les Notions en Mémoires
» Coding » De Mozart a Amstrad (Amstrad Magazine)
» Coding » Cours et initiation d'ANTIBUG
» Coding » Basic la Memoire d'Ecran (CPC Revue)
» Coding » Premiers Pas en Basic (AM-MAG)
» Coding » Le Bug du DEC$ sur 464
Je participe au site:

» Vous avez remarqué une erreur dans ce texte ?
» Aidez-nous à améliorer cette page : en nous contactant via le forum ou par email.

CPCrulez[Content Management System] v8.7-desktop/c
Page créée en 270 millisecondes et consultée 1961 fois

L'Amstrad CPC est une machine 8 bits à base d'un Z80 à 4MHz. Le premier de la gamme fut le CPC 464 en 1984, équipé d'un lecteur de cassettes intégré il se plaçait en concurrent  du Commodore C64 beaucoup plus compliqué à utiliser et plus cher. Ce fut un réel succès et sorti cette même années le CPC 664 équipé d'un lecteur de disquettes trois pouces intégré. Sa vie fut de courte durée puisqu'en 1985 il fut remplacé par le CPC 6128 qui était plus compact, plus soigné et surtout qui avait 128Ko de RAM au lieu de 64Ko.