CODINGAMSLIVE ★ AMSLIVE n°15 - CPC (S)OS (3/3) : GESTION DE LA MÉMOIRE ★

AMSLIVE n°15 - CPC Sos Partie 3Coding Amslive
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 manœuvre. 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). (NDSNN : Si Madram avait mieux écouté, j'ai dit à Eliot 'Tu sens bon la Préparation H", ce qui n'a rien à voir !)

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 hh: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 AMS'LIVE. Quoique, réservez plutôt vos "crad'os" pour labéliser un système

d'exploitation bien connu, le dénominatif convenant parfaitement.

TAMPON & HIMEM

En temps normal, lors d'un accès K7 ou dise, 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 TILI TILIII ! 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 à &7ff (au lieu de &8000), donc tout va bien.

Par contre, si le tampon était utilisé, le début du fichier se verrai! 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 : (NDSNN : Un synthétiseur vocal en une ligne de Basic !)

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 &800O&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é. Defaxez-vous.
Relaxez-vous.

Madram, ASMLIVE n°15, page 9-11

AMSLIVE n°15

» AMSLIVE n°05 - CPC (S)OS (1/3)
» AMSLIVE n°10 - CPC (S)OS (2/3) : LA MÉMOIRE

★ ANNÉE: ???
★ AUTEUR: MADRAM

Page précédente : AMSLIVE n°15 - Asm

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

Lien(s):
» Coding » AMSLIVE n°03 - CPC Plus - Ssn
» Coding » AMSLIVE n°15 - YM FAIT DU SKI
» Coding » AMSLIVE n°18 - Crtc Detection
» Coding » AMSLIVE n°14 - Multiplication Saignee a Mort
» Coding » AMSLIVE n°04 - Asic - Scrollhard
» Coding » AMSLIVE n°06 - Rsx Amsdos
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 591 millisecondes et consultée 2811 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.