Gestion de la mémoire A l'heure où les ordinateurs grand public possèdent un millier de fois plus de mémoire vive que notre CPC adoré, penchons-nous avec la grâce découlant de 10 ans d'exercices matinaux quotidiens sur la façon dont le BASIC gère la quarantaine de kilos à sa disposition. Oui, car précisons-le tout de suite, les 64 ko supplémentaires du 6128 ne sont pas directement exploitables sous BASIC. Il faut soit utiliser le BANK-MANAGER qui reste assez limité, soit jongler soi-même avec la page &4000-&7fff (OUT &7fxx,n où n vaut &c0 pour la page par défaut, et de &c4 à &c7 pour les 4 banks supplémentaires).
Attention cependant, comme à chaque fois qu'on se sert de OUT, le système (et le BASIC à fortiori) ne se rendent pas compte de la manoeuvre. Le programme BASIC ne doit alors pas dépasser &3fff, et les variables elles ne doivent pas atteindre &7fff (elles sont stockées "en descendant").
Bref, les kilos supplémentaires ne permettent pas directement d'éviter le Memory Full en cas de gros programmes. Peu importe ! On trouvera toujours moyen de nous débarasser de nos kilos superflus (cf exercices quotidiens du chapô).
HIMEM and Dad
Le HIMEM, c'est la dernière adresse disponible pour le BASIC. Je vous rappelle que le HIMEM initial peut varier. Ainsi le BASIC sur 464 dispose de plus d'espace que le 6128, étant donné que l'AMSDOS se réserve &300 octets.
On modifie le HIMEM grâce à la commande MEMORY.
Tu sens bon l'after-shave Ce n'est pas l'hypothétique extrait d'une discussion entre Eliot et SNN, mais l'à-peu-près le plus correct que j'ai trouvé pour introduire ce paragraphe (vous allez vite comprendre).
En dessous des zones réservées par d'éventuelles ROM (dont l'AMSDOS), on en trouve une de redéfinition pour 16 caractères (par défaut). On diminue ou augmente la taille de cette zone avec SYMBOL AFTER. SYMBOL AFTER 256 libère toute la place.
Mais attention ! Un SYMBOL AFTER ne pourra se faire que si le HIMEM est placé un octet en dessous de la zone de redéfinition (c'est le cas au RESET, bien sûr). Autrement dit, ne pas faire de SYMBOL AFTER après un MEMORY, sous peine d'obtenir un "Improper argument", que je traduirais par "légume avarié".
Il existe quand même une possibilité : 10 hi=HIMEM
20 MEMORY &3fff:LOAD"banjo",&4000
30 MEMORY hi:SYMBOL AFTER 256:MEMORY &3fff Mais cette méthode n'est pas très utile, et même dangeureuse. Vous pouvez donc placer un autocollant des "crad'os" sur ce passage, cela égayera votre machine. Quoique, réservez plutôt vos "crad'os" pour labeliser un système d'exploitation bien connu, le dénominatif convenant parfaitement.
Tampon & HIMEM En temps normal, lors d'un accès K7 ou disc, le HIMEM diminue de &1000 (le BASIC s'occupant de déménager en douceur toutes les variables), les opérations de lecture/écriture s'effectuent, puis le HIMEM est replacé à sa position précédente.
Pourquoi &1000 (et pas Gérard) ? Les routines de lectures K7 travaillent avec des blocs de 2 ko. Pour préserver la compatibilité, il faut donc fournir un tampon de 2 ko pour chaque opération. L'AMSDOS n'a pas réellement besoin de ce tampon (sauf pour la lecture séquentielle et pour le catalogue, auxquels cas il demande en fait 1 ko). Mais le BASIC ne sait pas (et n'a pas à savoir) s'il fait un accès K7, D7, ou disc dur !
TI TILI TILITILIII ! Chargez ! Le BASIC accepte de charger tout programme binaire au-dessus du HIMEM (il n'effectue d'ailleurs aucune vérification, et vous pouvez fort bien écraser la RAM réservée à l'AMSDOS, ce qui n'ira pas sans provoquer un petit problème, puisque l'AMSDOS sera en train de travailler avec cette RAM).
Il est aussi possible de charger à une adresse inférieure au HIMEM. Imaginons le scénario catastrophe : MEMORY &8000:LOAD"triangle",&7800 Avant l'ouverture du fichier, un tampon est réservé de &7001 à &8000. Le HIMEM descendant temporairement à &7000, le fichier est "accepté" à l'adresse &7800. Cela ressemble à un bug, mais ca n'a rien de catastrophique en fait, car l'AMSDOS n'écrit pas dans le tampon et le BASIC est fichtrement bien foutu : il fait remonter l'HIMEM à &77ff (au lieu de &8000), donc tout va bien.
Par contre, si le tampon était utilisé, le début du fichier se verrait vraisemblablement écrasé. C'est pour cette raison qu'il faut éviter, en assembleur, de choisir comme adresse de tampon celle du début du fichier !
Le coup du openout
Nous avons vu que le BASIC jouait au yoyo avec le HIMEM pour réserver un tampon. On peut fixer une fois pour toute l'adresse de ce tampon. En effet, au début d'une opération de lecture/écriture, le BASIC rabaisse le HIMEM seulement s'il n'y a pas de tampon déjà existant. Et si on change le HIMEM avant la fin de l'opération, le tampon est laissé tel quel.
Pour pouvoir modifier le HIMEM en plein milieu de l'opération, on utilise le couple OPEN / CLOSE. En fait, OPENOUT est tout indiqué car il permet d'ouvrir un fichier bidon, tandis que OPENIN renverrait probablement une erreur.
Un exemple sera plus parlant : MEMORY &8FFF:OPENOUT"D":MEMORY &7FF:CLOSEOUT Lors de l'OPENOUT, le BASIC crée un tampon de &8000 à &8fff. Il devient d'ailleurs impossible de fixer le HIMEM au dessus de &7fff : le tampon doit être "protégé" des variables BASIC.
Après, on place le HIMEM à &7ff. Le BASIC, pas né de la dernière pluie, s'en rend compte lors du CLOSEOUT : il conserve la zone &8000-&8fff comme tampon, et les prochains accès se serviront de ce tampon.
Si on avait voulu charger directement un fichier en &800, le BASIC n'aurait pu réserver de tampon en-dessus de &800, et aurait renvoyé un laconique MEMORY FULL.
On peut modifier une nouvelle fois le HIMEM après le CLOSEOUT ; par contre, s'il dépasse &7fff, le tampon est "perdu".
Derniers conseils
Pensez à ne pas charger de fichier trop haut en mémoire, cela pourrait indisposer les possesseurs de RAMCARD. Mangez équilibré. Delaxez-vous.
Relaxez-vous.
Remerciements...
Cet article a été rédigé par MadRam. |
