★ CODING ★ BUG ★ 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$ 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$. 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" 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 ; 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.
|