CODING ★ ON ASSEMBLE ENSEMBLE ★

Assembleur ACPC n°29 - On assemble ensemble
Qui se ressemble s'assemble, il me semble. l'assemblée que nous formons ensemble assemblera en Cœur les programmes que nous verrons aussi ensemble, dans l'ensemble. Non mais, sans blague!

Alors que Zède se grattait encore le haricot pour trouver je ne sais quelle extravagance, il nous demanda (à Poum et à moi-même) ce que nous ferions à sa place. Nous ne fûmes pas lents à répondre que si nous étions à sa place, nous ne ferions pas ce qu'il fait mais plutôt ce que nous ferions. Il resta bouche bée, pantois, et. finit par nous avouer, allongé sur un canapé de cuir marron clair, le fin fond de son problème, demeurant quelque part au niveau de son vécu.

Le pauvre vieux Zède se trouva fort dépourvu quand la bise fut venue (et cela n'était pas celle de Miss X) ; plus d'idée, le vide, bref, incapable d'écrire ou de programmer quoi que ce soit, il est temps qu'il parte en vacances. En moins de temps qu'il n'en faut pour le dire, Poum et moi avons décidé de reprendre ce cours Assembleur, en espérant qu'il soit long.

Nous sommes tout ouïe en ce qui concerne vos demandes et vos suggestions. Nous sommes là pour vous expliquer les quelques notions que nous possédons. Comme tout homme, il nous arrive de nous tromper parfois. Nous vous prions de ne pas nous en tenir rigueur. Je traîne derrière moi une sale histoire de LDIR depuis deux ans et je vous assure que ce n'est pas drôle tous les jours. Nous allons essayer de vous offrir une initiation par l'exemple. Non pas que notre forme de programmation soit la meilleure, mais elle permet d"'aligner du code" sans ennuis et d'acquérir une certaine forme de réflexion propre à l'Assembleur.

Si vous nous suivez dans nos élucubrations, vous saurez programmer en Assembleur d'ici quelques mois. Cette rubrique est un complément aux livres que vous devez avoir, notamment un ouvrage contenant une étude sur le jeu d'instructions du Z80 (comme celui livré avec le CPC détaille le jeu d'instructions du Basic). Il faut aussi vous munir d'un Assembleur permettant de traduire le langage mnémonique en codes machine. Bref, ces articles ne sont qu'un "plus" à des outils à posséder absolument. « Clefs pour CPC » de chez PSI ou encore la Bible du CPC aux éditions Micro Application se consacrent au système et pas réellement au Z80. Il vous faut un livre tel que Programmation en Assembleur du Z80, chez Sybex, ou je ne sais quel autre ouvrage contenant un dictionnaire des mnémoniques de notre microprocesseur. S'il vous manque une de ces pièces, ne vous étonnez pas de tourner en rond. Imaginez quelqu'un qui se plongerait dans un moteur avec un simple tournevis. Dans ces cas là, le pire est à craindre.

ECRAN NACRE
(MAL DE CRANE)

Pour que cette initiation ne soit ni trop ennuyeuse ni trop rébarbative, nous allons essayer de vous offrir différentes routines qui amèneront chaque fois, à partir d'un algorithme, une forme de programmation. Pour des raisons de clarté, ces sources ne seront pas trop optimisés, quoique... L'optimisation fait partie des petits trucs que l'on apprend au fur et à mesure et il serait vénal de tout vouloir savoir d'un coup.
Nous vous glisserons, ça et là, quelques astuces dans les numéros suivants. Pour le moment, c'est la trame qui compte. Notez tout de même que pour programmer en Assembleur, il est bon de posséder le Basic, non pas comme un professionnel, mais d'être au moins capable de faire ses programmes. La logique ne s'invente pas et il faut bien un départ. Ce serait folie de commencer par l'Assembleur et grand mérite à ceux qui ont débuté ainsi.

Ce mois-ci, nous vous proposons un petit programme d'affichage de pages écrans. Il est de très loin inférieur à ceux de Zénith 2 mais permet de travailler avec de la mémoire très convoitée : l'écran. Cette routine n'a d'intérêt que par son côté initiatique, nous le précisons encore. Voici l'idée originale, écrite en pseudo-langage, de notre listing.
La condition d'entrée dans la routine est que l'écran, apparaissant en &C000 (ou encore #C000, voire 49152, soit l'adresse écran normale), soit chargé dans un espace mémoire intermédiaire, situé de &4000 à &7FFF (MEMORY &4000 : LOAD "SCREEN.BIN", &4000).

  • Remplacer les octets pairs de la première ligne de l'écran visible avec leur correspondant dans l'écran intermédiaire.
  • Remplacer les octets impairs de la dernière ligne de l'écran visible avec leur correspondant de l'écran intermédiaire.
  • Passer à la deuxième ligne avec les octets pairs...
  • De même avec l'avant-dernière ligne et les octets impairs...

Comme vous pouvez l'imaginer, l'effet rendu est celui de deux grilles, l'une descendante et l'autre montante, qui se croisent et finissent par former l'écran voulu. Si nous avons décidé de gérer lïmage à l'octet plutôt qu'au pixel, c'est pour des raisons de simplicité. Il aurait été laborieux de travailler au PICture'S Element, sachant que, selon les modes, un octet n'en contient pas le même nombre. Voici donc comment a été pensé le programme en fonction de cette idée de base.

;
;
ORG #9000
;
LD HL,#C000
LD (HAUT+1),HL
LD HL,#FF81
LD (BAS+1),HL
;
LD B,200
BOUCLE: PUSH BC
HAUT: LD HL,&C000
CALL AFF
BAS: LD HL,&FF81
CALL AFF
LD HL,(HAUT+1)
CALL &BC26
LD (HAUT+1),HL
LD HL,(BAS+1),HL
POP BC
DJNZ BOUCLE
RET
;
AFF: LD BC,-#8000
LD D,H
LD E,L
ADD HL,BC
LD B,80
LIGNE: LDI
INC HL
INC DE
LD C,69
PAUSE: DEC C
JR NZ,PAUSE
DJNZ LIGNE
RET

STRUCTURE

Comme pour chaque ligne nous afficherons 40 fois un octet sur deux, que celui-ci soit à une adresse paire ou non, pourquoi créer deux routines différentes ? Nous prenons en compte qu'une partie du programme se chargera de cette tâche. Nous appellerons cette procédure AFF car elle affiche, quoi qu'on en dise. Le fait de transférer des octets de la mémoire centrale vers la mémoire vidéo revient à afficher ce premier espace. Voici son fonctionnement:

La condition d'entrée est que le registre HL pointe sur l'adresse du premier octet écran à modifier. L'opération consiste alors à préparer les registres pour l'instruction LDI.
BC est chargé avec -#8000, qui est le décalage entre la mémoire écran réelle et le tampon intermédiaire. HL est copié dans DE, ce qui aurait aussi pu se faire par l'intermédiaire de la pile, mais avec moins d'élégance et moins de performance.

Nous avons dit que #8000 était le décalage entre les deux écrans. Dans ce cas, pourquoi additionner -#8000 alors qu'on aurait dû simplement soustraire +#8000 ? Sachez que ces deux opérations sont du même effet, mais que celle-ci est un peu plus rapide. B est affecté de 80 unités, car nous allons faire 40 transferts d'octets dans cette boucle. Certains diront que prendre 80 pour mettre 40 est légèrement foldingue, mais comme B est décrémenté deux fois dans la boucle (avec LDI et avec DJNZ), nous retombons sur nos pieds.
LDI transfère, et comme nous n'avançons que d'un octet, nous incrémentons HL et DE, ce qui les force deux octets plus loin. Une petite pause pour que tout cela ne se passe pas trop vite et le tour est joué.
Maintenant que la partie laborieuse est en place, il ne nous reste qu'à écrire son initialisation et son appel. Voici donc le corps du programme.

LE PIED! LE CORPS...

Avant tout, on initialise les variables du programme, soit l'adresse du premier octet de la première ligne (&C000) et l'adresse du deuxième de la dernière (&FF80+ 1). Comme vous pouvez le voir, ces variables ne sont pas stockées comme de vulgaires données, elles font réellement corps avec le programme. Pourquoi utiliser quatre octets supplémentaires alors que ceux-ci ont déjà une place? L'instruction LD HL,VALEUR est codée sur trois octets: le premier est l'instruction, le deuxième et le troisième sont la valeur. Nous disons donc à l'Assembleur d'écrire ce nombre directement à sa place plutôt que d'être obligé d'aller le chercher ultérieurement avec un adressage direct.
La suite est simple: une boucle de 200 lignes les affiche une à une du haut vers le bas et inversement. en trame, un octet sur deux, les impairs montent tandis que les pairs descendent. Affichage d'une ligne paire, puis de l'impaire, calcul de la ligne suivante pour les tombants et de la ligne précédente pour les montants. Restauration des registres et retour au Basic si tout est fait.

GOOD MONTH A TOUS!

C'est ici que nos chemins se séparent pour ce mois et qu'ils se retrouveront pour quelques pages le mois prochain. Atchao (à tes souhaits).

Et Poum, dans le Sined, ACPC n°29 Septembre 90, p52-53

Page précédente : Assembleur ACPC n°28 - Les rotations & divisions

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

Lien(s):
» Coding » Assembleur ACPC n°33
» Coding » Assembleur ACPC n°17
» Coding » Assembleur ACPC n°24
» Coding » Bidouilles ACPC n°14 - Les secrets du GATE ARRAY (1/2)
» Coding » Bidouilles ACPC n°48 - Les vecteurs system (6/6)
» Coding » Bidouilles ACPC n°17 - Le catalogue 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 271 millisecondes et consultée 1703 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.