CODING ★ LA MÉMOIRE D'ÉCRAN ★

Basic la Memoire d'Ecran (CPC Revue)
Extrait du livre "MIEUX PROGRAMMER SUR AMSTRAD"

Les notions exposées dans cet article ne sont pas du tout indispensables pour devenir un bon progammeur en Basic ; elles permettent d'aller plus loin en triturant la zone mémoire de l'écran par des PEEK ou des POKE. Pour faire quoi ?

Tout d'abord faire des programmes de "HARD COPY" qui exécutent sur imprimante une sorte de photocopie de l'écran en cours, surtout utile pour les graphismes (vous pourrez utiliser ces programmes même si vous ne comprenez pas leurs fonctionnements). Avec ces notions, et de la patience, vous pourrez aussi créer des effets colorés inaccessibles par les seules fonctions Basic.

GENERALITES SUR LA MEMOIRE

Le CPC 464, comme la plupart des micro-ordinateurs de moins de 20 000 FF, utilise un microprocesseur "8 bits" (un octet). Pour aller chercher un octet en mémoire, il faut que ce dernier ait une adresse. Un octet peut prendre 256 valeurs possibles (256 = 28). Pour les adresses, disons un octet pour les "colonnes" et un octet pour les "lignes" d'un "tableau d'adresses", donc 256x256 = 65536 "cases mémoire", qu'on numéroté de 0 à 65535. C'est ce qu'on appelle 64 k-octets car le "kilo-octet" vaut en réalité 1024 octets... Donc 64 k-o est le maximum pour un micro 8 bits. Il faut les partager entre la ROM (le Basic résident) et la RAM (programmes + variables en cours + les points lumineux envoyés à l'écran). Avec un Basic de 32 k-o, il ne resterait que 32 k-o pour la RAM, d'où vingt et quelques k-o disponibles pour programmes plus fichiers, c'est ce qui se passe avec les MSX et bien d'autres. Nous, nous avons 32 k-o de Basic, 43 k-o disponibles + 16 k-o réservés à l'écran ! La raison de ce "miracle" est que l'AMSTRAD "recharge et décharge" la portion de la ROM dont il a besoin (c'est une vue d'esprit). De ce fait, une large partie de la RAM est plutôt "mouvante", ce qui va donner bien du plaisir aux amateurs de PEEK et de POKE... La partie mémoire écran occupe une zone fixe, de 49152 à 65487, mais le fait que l'on puisse mélanger texte et graphisme, et ce en trois MODES, fait que sa structure est d'une extrême complexité inouie (même principe que sur les APPLE II, mais en pire). C'est ce qui explique que l'affichage des caractères est assez lent, exemple, quand on fait LIST sur un long programme. Dans le manuel, les adresses sont indiquées en hexadécimal (préfixe & et quatre caractères). Il est pratique de savoir faire les conversions hexadécimal-décimal dans les deux sens (Note : le préfixe hexadécimal ne signifie pas "six'-' mais "seize").

LES CONVERSIONS HEXA/DECIMAL/BINAIRE

En binaire, on a deux symboles 1 et 0, en décimal on a dix symboles 0 à 9, en hexa on en a seize, 0 à 9 + A, B, C, D, E et F (&F=15;&A=10). On représente la valeur d'un octet par deux symboles hexa, ainsi &FA = (16 x 15) + 10 = 250. Il suffit de taper PRINT &FA et 250 apparaît à l'écran. De même, &FF = 255, c'est bien le maximum pour un octet. Une adresse tient sur deux octets, exemple &AFC8. Vous ne pouvez pas faire PRINT &AFC8 car l'AMSTRAD ne sait pas faire la conversion sur plus d'un octet, vous êtes obligé de décomposer :

PRINT &AF*256 + &C8

et la réponse apparaît : 45000. L'opération inverse est beaucoup plus facile :

PRINT HEX$(45000)

l'écran répond AFC8 (le & est sous-entendu).

Pour traduire une longue suite de valeurs hexa en décimal, vous gagnerez du temps en utilisant ce très court programme du listing n° 1.

Passons à la représentation binaire d'un nombre. Tapez, par exemple : PRINT BIN$(45956), vous obtenez une suite de 16 bits 1 et 0. Essayez maintenant PRINT BIN$(3), vous obtenez "1" (c'est une chaîne) ; avec PRINT BIN$(3,16), vous avez 14 zéros suivis de "11 ". Gare à l'opération inverse par &X, elle traduit cette "image binaire" en un nombre dit entier, c'est-à-dire compris entre -327869 et + 32767 I Un zéro suvi de quinze 1 donne 32767, tandis que 1 suivi de quinze zéros donne -32768.

Heureusement, vous n'avez pas à vous en préoccuper car dans la pratique les seules images binaires qui nous intéressent sont sur un octet, donc de 1 à 255.

LE PLAN MEMOIRE DE L'ECRAN

Nous y voilà !

Deux cent lignes horizontales de 80 octets chacune. Dans une ligne, les numéros d'octets se suivent de gauche à droite. Prenons le cas le plus simple, celui du MODE 2 : chaque bit représente un "pixel" ou point à l'écran, ainsi 255 fait un tiret continu (huit bits 1). La ligne en haut de l'écran va de 49152 à 49231, soit 80 x 8 = 640 points (ce qui explique qu'en coordonnées graphiques l'échelle horizontale aille de 1 à 640). Hélas, l'octet suivant, le 49232, n'est pas'au départ de la deuxième ligne mais huit lignes plus bas ! Et ainsi de suite au pas de 8 lignes. Après un premier "passage" de 25 lignes espacées de 8, commence le deuxième passages sur les lignes du dessous. Pour tout comprendre, essayez le programme du listing n° 2.

Un joli store vénitien ! Les figures 1 et 2 vous donnent le plan des adresses d'écran. Vous constatez qu'entre deux "tirets" (deux octets) situés à l'écran, l'un en-dessous de l'autre, il y a un écart de 2048 octets ( = 2 k-octets), qu'entre deux lignes d'un même "passage" (donc espacées de 8 lignes d'écran), il y a un écart de 14336 octets.

A présent, modifiez la ligne 110 en mettant MODE 1. Surprise ! Les traits sont rouges ( = PEN 3). En ligne 110, mettez MODE 0 : les traits clignotent en rose/bleu ciel ( = PEN 15). Nous abordons alors le code des couleurs en fonction du MODE.


Fig. 1

Fig. 2


LE CODAGE DES COULEURS

En MODE 2, rien de plus simple : comme il n'y a que deux couleurs possibles, un bit 1 fait un pixel PEN, un bit 0 un pixel PAPER (Pixel est la contraction anglaise de PICTURAL ELEMENT).

Lancez ce programme du listing n° 3 qui va dessiner en 0 et 1 les images binaires des quatre premiers caractères sur un écran en MODE 2.

Le résultat est spectaculaire. On y retrouve les compositions illustrées dans le manuel AMSTRAD page A3.2 et suivantes. A présent, modifions la ligne 210 afin d'avoir MODE 1 (ou faites MODE 1 :RUN 220). Oh ! Que c'est vilain ! Sur chaque "pavé", on n'a qu'une moitié de chaque caractère. Il faudrait accoller les moitiés gauches des pavés pour reconstituer le texte. Les moitiés droites des pavés (ou des octets) ne comportent que des 0. Ces zéros constituent en fait le code couleur de PEN (PEN 1 en ce cas) : apparions - les gauche + droite, on a '01" quand il y a quelque chose à tracer, or &X01 = 1 (PEN 1). Tapons PEN 2 et, toujours en MODE 1, faisons RUN 220 : les 1 sont à droite et les zéros à gauche, &X10 = 2 (PEN 2). Tapons PEN 3 et même manœuvre. Dans chaque pavé, le demi caractère est répété à gauche et à droite, or &X11 =3. Puisque dans chaque octet on associe un bit de la moitié droite à un de la moitié gauche, il n'y a que quatre combinaisons possibles :

"00" ( = 0) ; "01" ( = 1)

"10" ( = 2) et "11" ( = 3)

C'est pourquoi on n'a que quatre couleurs en MODE 1. Et que se passe-t-il sur l'écran vidéo ? Sur chaque image binaire d'un octet (le "tiret"), chaque bit 1 est doublé, et dans la couleur du PEN. Un caractère occupe donc deux pavés, et comme il y a 80 octets par ligne, cela fait bien 40 caractères par ligne d'écran.

En MODE 0, c'est le même principe, mais en divisant par deux, un quart de caractère par pavé. Pour apparier les bits, on a alors 16 combinaisons possibles (les seize couleurs). A l'écran, chaque bit 1 est quadruplé dans la même couleur.

LE HARD COPY D'ECRAN

Il faut que votre imprimante possède l'instruction "BIT IMAGE", c'est le cas de la plupart des imprimantes "à aiguilles" ou "matricielles". En usage normal, une imprimante traduit l'octet reçu en dessinant le caractère ayant ce code ASCII, ici c'est beaucoup plus simpliste. Les huit aiguilles de la tête d'impression illustrent l'image binaire de cet octet. Ces dessins de bits vont être des "barres" verticales, or sur l'écran ils sont horizontaux ! Il suffit de tourner notre graphisme d'un quart de tour sur le papier. L'imprimante commencera par le bord vertical gauche en terminant par le bord droit de l'écran ; le bas de l'écran sera donc le long de la marge gauche du papier. Ce n'est pas gênant. L'auteur utilise une EPSON RX80 (les modèles FX ont les mêmes codes). Si la vôtre est d'une autre marque, il va falloir modifier les libellés des codes de commandes ; nous légenderons les nôtres afin que vous puissiez les traduire pour votre machine. Si vous trouvez les mêmes, ne soyez pas surpris car une bonne quinzaine de "marques" sont des EPSON rebaptisées.
Il y a deux programmes différents, pour le MODE 2 et le MODE 1 (la version MODE 0 ne satisfait pas l'auteur). Il s'agit en fait de sous-programmes utilitaires (listings 4 et 5).

LEGENDES DES CODES EPSON

CHR$f27);CHR$(64) = vide le buffer (initialisation) CHR$(27);"3";CHR$(24) = interlignes de 24/216 de pouce CHR$(27);"A";CHR$(8) = interlignes de 8/72 de pouce CHR$(15) = caractères condensés (17 par pouce) CHR$(27);"K" = mode bit-image

LE PRINCIPE

On explore des bandes verticales de l'écran de largeur 1 octet. Ces 200 octets sont mis en DIM Z puis ils sont retransmis à l'imprimante qui écrit donc une ligne. Passage à la colonne précédente et ainsi de suite. En jouant sur divers paramètres d'impression, nous sommes parvenus à restituer les proportions hauteur x largeur de l'écran (approximativement). En MODE 0, nous ne sommes pas (encore) parvenus à obtenir des dimensions d'image imprimées satisfaisantes, d'où l'absence de la version MODE 0. Très important : en MODE 1, les inscriptions doivent être en PEN 1 ou en PEN 3 (pas en PEN 2) car nous ne prenons que la moitié gauche des images binaires (ligne 55090).
Suite à un petit.bug de la ROM de l'EPSON RX 80, nous n'envoyons en "bit image" que des suites de 50 ou 100 octets à la fois.

REMARQUE

C'est aussi pour des raisons de proportions d'écran que les coordonnées graphiques sont de 640 x 400 alors que logiquement ce serait 640 x 200.

CODAGE BINAIRE D'UN CARACTERE

Vous voulez définir un caractère qui se trouve être un caractère existant mais légèrement modifié. Vous trouvez fastidieux de redessiner sa grille 8 x 8 et de totaliser toutes ces lignes. Alors, utilisez les programmes du listing n° 6 qui fait instantanément tout ce travail.

Tapez indifféremment le caractère, s'il existe, au clavier ou son code ASCII. L'écran vous soumet sa fiche signalétique complète, à savoir :

Le caractère, son code ASCII, sa configuration binaire en "1" et "0" et les totaux de chaque ligne. Exemple avec X majuscule : Code ASCII 88, codage 198, 108, 56, 56, 108, 198, 198, 0.

Faites un autre essai en tapant 251.

Ce programme refuse certains signes de ponctuation tels que + - , . &. En ce cas entrez le code ASCII.

Michel ARCHAMBAULT , CPC n°1

★ ANNÉE: 1985
★ AUTEUR: Michel ARCHAMBAULT

★ AMSTRAD CPC ★ DOWNLOAD ★

File:
» La  Memoire  d  Ecran    FRENCHDATE: 2012-12-19
DL: 300
TYPE: ZIP
SiZE: 5Ko
NOTE: Extended DSK/40 Cyls
.HFE: Χ

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

Lien(s):
» Coding » Les Notions en Mémoires
» Coding » Basic - Table de References Croisees des Variables Basic (CPC Revue)
» Coding » Le Bug du DEC$ sur 464
» Coding » Basic Memorisez l'Ecran du CPC
» Coding » A bug in the CPC464 (Computing with the Amstrad)
» Coding » Basic : Un poke économe
Je participe au site:
» Vous avez des infos personnel, des fichiers que nous ne possédons pas concernent ce programme ?
» 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 654 millisecondes et consultée 2211 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.