CODINGAMSLIVE ★ AMSLIVE n°10 - CPC (S)OS 2ème PARTIE : LA MÉMOIRE (2/2) ★

AMSLIVE n°10 - Memoire du CPC 2Coding Amslive

Au menu, cartographie de la mémoire. On va parler de vecteurs, de routines système... Encore un article particulièrement dédié au programmeur en assembleur. Que voulez-vous, on ne se refait pas.

Vous vous êtes procuré une RAMCARD ? Pour utiliser conjointement plusieurs programmes en ROM, ceux-ci doivent se partager la mémoire. Autant savoir comment elle est disposée ! Quant à l'augmentation de mémoire, même avec 2 Mo au c, heu, au dos de votre CPC, vous obtiendrez des Memory full. Le BASIC est capricieux et il faut savoir s'y retrouver dans les 64 1ers ko avant de s'attaquer à la RAM supplémentaire. On ne met pas de peau d'ours pour ménager sa monture, comme dirait l'autre.

Le schéma décrit sommairement l'organisation de la mémoire. Allons-y pour le détail.

0000 - 003F:

Les ReSTart Ici sont casées des petites routines dont l'objectif commun est d'appeler d'autres routines en ROM ou en RAM suivant les paramètres envoyés. La particularité des adresses 0, 8, 10, 18, 20, 28, 30, 38 est qu'on peut les atteindre avec les instructions RST 0, RST 8... respectivement (ou RST 0, RST 1, cela dépend de l'assembleur utilisé). Ces instructions ne prennent qu'un octet, au lieu de 3 pour un CALL. Les codes placés ici sont la réplique de ceux placés au même endroit de la ROM. Ainsi, quelque soit la configuration en cours, on peut y sauter sans hésiter.

Plusieurs adresses remarquables :

— 0, où se situe la routine de réinitialisation, Le système n'y va jamais, vous pouvez donc y installer une routine de votre cru (mais de 8 octets au maximum !).

— 30, réservé à l'utilisateur. Une autre routine possible de 8 octets !

— 38, le RST appelé lors d'une interruption. En 38, il y a un saut à des adresses différentes suivant le modèle de CPC.

0040 - LOWMEM-1 :

LOWMEM, l'adresse basse de la mémoire disponible est fixée lors de l'initialisation des ROMs externes qui peuvent donc réserver une zone en bas de mémoire. A ma connaissance, aucun logiciel ne le fait. LOWMEM est donc égal à 40.

LOWMEM - LOWMEM + 12F (par défaut 40-16F):

Tampon utilisé par l'interpréteur BASIC. Une phrase entrée (maximum 255 caractères) est codée à cet endroit avant d'être interprétée ou rajoutée au programme selon qu'il s'agisse de commandes directes ou d'une ligne de programme. Si la phrase codée (avec tokens, etc..) prend plus de place qu'en accorde le tampon, le message Line too long apparaît.

LOWMEM + 130 - ? (par défaut 170 - ?) :

Programme BASIC. Les contenus des variables numériques sont stockés directement avec le programme. L'explication est que ce type de variable a une longueur fixe (2 octets pour les entiers, 5 pour les réels). On peut donc les modifier à volonté sans remettre en cause l'architecture du programme. Pour une variable alphanumérique, on stocke une série de 3 octets qui définissent la longueur et la position de la chaîne dans la mémoire.

?? - HIMEM :

Dans cette partie sont placées les fameuses chaînes alphanumériques. La variable réservée HIMEM renvoie la plus haute adresse utilisable pour le BASIC. Cette valeur dépend de la place disponible après l'initialisation de toutes les ROMs (sur un 464 sans lecteur de disquette, elle est plus grande), de la taille de la table de caractères redéfinissables (SYMBOL AFTER), du tampon alloué pour les opérations de lecture/écriture (sur dise ou cassette), et enfin de la zone réservée par l'utilisateur pour les programmes binaires (MEMORY).

HIMEM+1 - DOU :

Dans cette zone, il peut y avoir des programmes binaires, un tampon pour les opérations de lecture/écriture, et la table de caractères redéfinissables. Le dernier octet utilisable (DOU) est fixé par les ROMs. Heu... je me répète, non ?

DOU+1 - ABFF:

Là, il y a les différentes plages mémoires réservées par les ROMs, qui ne doivent être utilisées que par les ROMs correspondantes. Attention, il s'agit d'adresses relatives ; si les 2 seules ROM sont POIRE qui a besoin de 100 (en hexa) octets, et BONNE qui en veut 200, voici l'évolution de la place disponible (et par suite l'adresse des zones réservées) suivant l'ordre d'initialisation :

1er cas ; 2ème cas
Dispo: 40-ABFF Dispo : 40 - ABFF
Après POIRE: Après BONNE :
40-AAFB ; 40-A9FB
Après BONNE : Après POIRE :
40-A8F7 ; 40-A8F7

Vous remarquerez que 104 et 204 octets ont été pris. En fait, les 4 octets sont rajoutés par le système pour justement retrouver quelle plage est associée à quelle ROM. Même si une ROM ne réserve rien, 4 octets seront employés. Si vous n'avez pas de ROMs externes autre que AMSDOS, celle-ci utilisera la zone A700-ABFF (avec les 4 octets de A6FC à A6FF).
MAIS CE N'EST PAS FORCEMENT LE CAS !
Alors, s'il vous plaît, messieurs (et mademoiselle) les programmeurs, quand vous sauvegardez le lecteur actif, NE LISEZ PAS A700 mais faites plutôt LD HL,(#BE7D) puis LD A,(HL).

AC00 - B8FF :

Variables système. En gros, la partie avant B000 est consacrée à l'interpréteur BASIC (table de déclaration de variables, pointeur pour l'instruction READ, adresse de fin de programme...), et l'autre partie au système (couleurs, dimensions des fenêtres, tables de gestion du clavier...). On détaillera tout ça quand on étudira quel parties de la mémoire peut-on récupérer quand le BASIC ne sert plus. Si le cric te pique, que le POKE te croque. (Vieille incantation à la déesse Bidouillegribouille).

B900 - B923 :

Quelques vecteurs KERNEL. Le KERNEL, c'est le noyau du système, tout ce qui concerne le système lui-même et non pas les entrées/sorties. Des méta-routines si vous préférez. Non ? Vous ne préférez pas ? Tout ce qui est RSX, gestion des interruptions, c'est le kernel.

Mais les vecteurs en question concernent surtout la sélection RAM/ROM.

B924 - BAFF:

Routines systèmes, qui mettent à jour les variables systèmes, traitent les interruptions logicielles... A ne pas toucher, et ça ne sert à rien d'y sauter !

BB00 - BD39:

Les vecteurs ici présents sont organisés en gestionnaires spécialisés : Clavier, Texte, Graphique, Ecran, Cassette, Sonore, Kernel, Interfaçage.

BD3A - BDC0:

Ces vecteurs sautent aux routines mathématiques de la ROM (calculs en virgule flottante). Attention, les adresses changent du 464 au 664/6128. Le BASIC s'y retrouve car il change lui aussi !

BDC1 - BDCC :

Quelques octets de libres. Ils ne sont pas écrasés lors d'un RESET. Pourquoi diable le seraient-ils ?

BDCD - BDF6:

Vecteurs d'indirection : ils ne sont pas prévus pour être appelés directement car ils présupposent que la ROM inférieure est sélectionnée. D'ailleurs, ils sont appelés de cette ROM ! Tiens, une routine en ROM appelle un vecteur en RAM qui lui même resaute dans la ROM ?!? A quoi sert-ce ? Et bien, à pouvoir détourner l'attention du mari jaloux. Euh, excusez-moi, je voulais dire à pouvoir détourner le déroulement de la routine (d'où le nom, indirection). Allez, bon prince, je vous indique le rôle de BDF4 qui ne figure ni dans les Clefs, ni dans la Bible : il remet à jour la table de scanning des touches. En le détournant vers une routine adapté, vous pourrez guider un CPC avec un autre CPC, par exemple (équivalence du détournement de l'entrée standard sous UNIX !

BDF7 - BE3F:

De nouveau une zone libre.

BE40 - BE7F:

Cette zone est initialisée par l'AMSDOS Pourquoi ici ? Peut-être pour une compatibilité avec le CP/M. Quoi qu'il en soit, elle contient des paramètres physiques pour la gestion du disque (divers délais, octets de la phase résultat du FDC...), pour la gestion par interruption des dits délais, et certaines adresses de la plage initialisée par la ROM AMSDOS (cf plus haut).

BE80 - BFFF :

Cette partie n'est pas écrasée lors d'un RESET, mais elle l'est par la pile suivant la solicitation de cette dernière. En temps normal, la pile ne descend pas en dessous de BF00.

C000 - FFFF:

Les 16 ko de cette RAM écran ne sont pas entièrement affichés. Autrement dit, on peut y stocker des données qui n'altéreront pas l'affichage. Mais ces données seront perdues si vous faites rouler (scroller) l'écran ou si vous utilisez MODE. Il est possible de définir une autre plage écran par un CALL &BC06,&40 de derrière les fagots. Il faut alors protéger cette zone par un MEMORY &3FFF. Pour vous rendre compte, essayez MEMORY &6000:A$="BONJOUR":CALL &BC06,&40:MODE1:?A$ Ainsi, la technique du flipping est accessible sous BASIC !

Au prochain épisode, on se tournera vers le BASIC pour trouver comment utiliser MEMORY afin de ne plus jamais rencontrer le message MEMORY FULL. Plus jamais !

AMSLIVE n°10

» La 1ere partie : AMSLIVE n°05 - CPC (S)OS (1/3)
» La suite : AMSLIVE n°15 - CPC (S)OS (3/3)

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

Page précédente : AMSLIVE n°08 - Z80 : MACHINS, BIDULES, ASTUCES & TRUCS

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

Lien(s):
» Coding » AMSLIVE n°12 - Sons et Samples
» Coding » AMSLIVE n°19 - Crtc Detection - Retour Au Source
» Coding » AMSLIVE n°15 - la Vie en 16
» Coding » AMSLIVE n°12 - Vu Metre
» Coding » AMSLIVE n°16 - les Gros Ports
» Coding » AMSLIVE n°06 - Sinus
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 793 millisecondes et consultée 3093 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.