Site logo

Triceraprog
La programmation depuis le Crétacé

  • Lecture : Eight Bit Magazine ()

    Il y a quelques mois, je tombais par hasard (autant que l'on puisse attribuer au hasard la manière dont est transmise l'information sur Internet) sur un Kickstarter pour le numéro trois d'un magazine nommé Eight bit.

    La promesse est celle d'un magazine dont les sujets tournent autour des ordinateurs de l'époque 8 bits, s'adressant à la fois aux collectionneurs mais aussi aux utilisateurs de ces machines. Ceci sous la forme d'articles tournant autour d'Histoire et présentation de matériel, d'articles techniques et de tests.

    La côté assumé et séduisant est celui d'être un vrai magazine papier, avec une mise en page à l'ancienne un peu modernisé. Une sorte de fanzine d'extrêmement bonne qualité avec un contenu fourni.

    Après réception et lecture des trois premiers numéros, je peux dire que j'ai apprécié. Dans l'ensemble du moins : comme dans chaque magazine, il y a des parties que je survole un peu plus que les autres. Je ne suis pas très friand du format interview par exemple, dans ce magazine comme dans d'autres.

    Les numéros

    Dans le volume 1, l'article le plus intéressant pour moi est celle sur le galaksija, ordinateur yougoslave à l'architecture ouverte, diffusée par magazine et construite à la main par les utilisateurs de l'époque. Je ne connaissais pas du tout cette machine et l'histoire en est fascinante.

    Le reste du magazine est aussi très intéressant, avec un tour au centre du Commodore 64, de la revue de matériel et une mini introduction à ce qu'est la programmation. La promesse est là. Un magazine des années 80 télé-transporté en 201x.

    Pas de grosse découverte dans le numéro 2, mais des articles plaisants pour aller au cœur du ZX81 et comprendre en surface comment sont programmés les sprites sur Commodore 64.

    Le troisième numéro présente le CPC 464, article qui ne contient pas vraiment de surprise pour moi. La très passionnante histoire des débuts du jeu d'aventure sur micro est mon point d'intérêt majeur.

    Conclusion

    « Eight Bit Magazine » est une bonne découverte. C'est bien écrit et vogue entre nostalgie et information.

    Du coup, j'attends le numéro 4.

    3 numéros de Eight Bit Magazine


  • Du langage machine à l'assembleur sur VG5000µ ()

    Après cette pause estivale, reprenons là où l'on était restés. Dans l'article précédent, je parlais du langage machine, une suite de signaux provoquant l'activité d'un processeur selon des directives précises.

    Un inconvénient du langage machine, c'est qu'il est peu pratique à manipuler. Par exemple, sur un Z80, charger l'accumulateur (une mémoire spécifique interne au processeur) avec la valeur 1, je dois écrire : 00111110 00000001 en binaire, ou encore 3E 01 en système hexadécimal.

    Écrire de cette manière n'est pas simple, prend beaucoup de temps avec un grand risque d'erreurs. Relire est encore pire. Programmez une machine de cette manière et vous ressentirez a priori rapidement le besoin de manipuler des éléments plus faciles à comprendre pour un Humain.

    Et c'est ainsi que du langage machine on passe au langage d'assemblage, ou, par abus de langage, à l'assembleur.

    L'assembleur

    La première chose à savoir est que l'assembleur est un programme. Mais par extension, le langage qui est utilisé par ce programme est aussi appelé assembleur. Dans la suite, le mot servira principalement à désigner le langage en lui-même.

    L'assembleur donc, est un langage à la syntaxe et à la grammaire extrêmement proche du langage machine. Chaque instruction en assembleur est directement traduisible dans sa version en langage machine et chaque instruction en langage machine a son écriture en assembleur.

    En assembleur Z80, pour continuer sur le même exemple, la suite de signaux 00111110 00000001 qui charge 1 dans l'accumulateur s'écrit LD A, 1 en assembleur. C'est toujours un peu cryptique, mais ça se lit bien plus facilement. LD pour « load », charger en anglais, est suivi de deux paramètres : la destination A, qui désigne l'accumulateur, et la valeur 1.

    Je précise bien assembleur Z80 car, tout comme le langage machine diffère d'un processeur à l'autre, l'assembleur, qui est une transcription lisible de ce langage machine est lui aussi spécifique à chaque processeur.

    Ça reste ardu non ?

    Les commandes du processeur Z80 couvrent le chargement de données dans sa mémoire interne (les registres), des calculs, des comparaisons,... Ces commandes étant très simples, il en faut souvent un certain nombre pour arriver au résultat voulu. Et la programmation est sans filet : le processeur exécutera à la lettre les commandes envoyées.

    C'est pour cela que des langages de plus haut niveau d'abstraction, comme le BASIC (pour rester sur le VG5000µ), ont été créés. Le BASIC a des instructions simples à utiliser, son interpréteur se charge de vérifier les erreurs, de gérer la mémoire,... Les instructions de base du BASIC sont aussi les mêmes, pour ce qui est du coeur du langage, d'une machine à une autre, alors qu'il existe un assembleur différent dès que l'on change de processeur.

    Toute la simplification des actions et la gestion d'erreurs a par contre un coût. De plus, le BASIC des machines telles que le VG5000µ est interprété, c'est-à-dire que les instructions et leurs paramètres sont décodées à chaque fois qu'elles sont exécutées. Cette interprétation amène au final à des instructions machines, mais très nombreuses.

    Programmer en assembleur permet de s'affranchir de toute la lourdeur d'un langage interprété comme le BASIC, au prix d'un peu d'effort et d'attention. Et sur ce point, programmer une ancienne machine en 2017 aide beaucoup. Imaginez : programmer sur la machine elle-même à l'époque nécessitait de charger un programme d'édition, ce qui pouvait être long, et de repartir de zéro au moindre problème, puisqu'une erreur pouvait amener au plantage de la machine.

    En 2017, avec émulation et outils d'assemblage qui tournent sur un ordinateur récent pour une vérification ultime sur la vraie machine, c'est beaucoup, beaucoup plus simple.

    La mission

    Le premier objectif en assembleur sur VG5000µ va être d'afficher une chaîne de caractères à l'écran. L'équivalent d'un PRINT "Bonjour!". Mais avant cela, il me faut parler un peu de la ROM de la machine.

    La ROM est une mémoire persistante, son contenu reste le même à chaque fois que la machine est en fonctionnement et il ne peut pas être modifié pendant l'exécution. On l'oppose souvent à la RAM, qui est une mémoire volatile, dont le contenu est perdu dès que la machine est éteinte.

    La ROM, dans une machine comme le VG5000µ, contient l'ensemble des opérations nécessaires à son fonctionnement : comment dialoguer avec le processeur qui s'occupe de l'affichage, comment jouer un son, comment charger et sauver des données sur cassette,... La ROM contient aussi l'interpréteur BASIC et la gestion de l'interaction avec l'utilisateur.

    Si son contenu n'est pas modifiable, il est par contre tout à fait possible de le lire, ou même d'en appeler des routines.

    Dans le cadre de cette mission, je vais donc utiliser la routine d'affichage de chaîne de caractères. C'est exactement la même qui est utilisée in fine par l'instruction PRINT, mais je vais l'utiliser directement.

    La routine

    La routine d'affichage de chaîne de caractères est située à l'adresse $36AA (le préfixe $ indique un nombre hexadécimal, en décimal, c'est l'équivalent de l'adresse 13994).

    Cette routine se charge en fait de l'impression à l'écran, sur une imprimante ou sur une cassette de sauvegarde. À défaut d'une action spéciale, l'affichage se fait à l'écran, je ne touche donc à rien.

    La chaîne de caractères doit se terminer par le caractère de valeur 0 en mémoire.

    La routine a besoin de connaître l'adresse en mémoire de la chaîne de caractères à afficher et pour celui utilise le registre HL. Tous les autres registres seront modifiés, il faudra donc en préserver le contenu.

    Aparté sur les registres : programmer en assembleur nécessite de connaître l'architecture logique du processeur. Une de ses composantes est que sa mémoire interne est découpée en registres. On peut imaginer les registres comme des conteneurs d'informations numériques.

    Le programme va donc ressembler à quelque chose comme ça :

    • Sauvegarde des registres
    • Charger le registre HL avec l'adresse de la chaîne de caractères
    • Appeler la routine $36AA
    • Restaurer les registres
    • Revenir au programme appelant


    La dernière étape de retour au programme appelant est nécessaire car l'appel depuis le BASIC se fera par l'instruction CALL qui appelle une routine en assembleur qui doit rendre la main afin que le programme BASIC puisse continuer.

    Écriture en assembleur

    Pour sauvegarder les registres, je vais utiliser la pile. La pile est une zone de mémoire dans laquelle on peut pousser des informations pour les récupérer plus tard, dans un ordre tel que la dernière information poussée est la première information récupérée. Vous pouvez imaginez une pile de feuilles de papiers sur laquelle vous pouvez ajouter une nouvelle feuille sur le dessus, ou bien retirer la feuille du dessus pour en lire le contenu.

    Pousser tous les registres sur la pile peut se faire comme ceci :

    PUSH AF
    PUSH BC
    PUSH DE
    PUSH HL
    

    À la fin de ce petit programme, il faudra dépiler les valeurs de registre dans l'ordre inverse :

    POP HL
    POP DE
    POP BC
    POP AF
    

    Pour charger le registre HL avec l'adresse de la chaîne de caractère, on va demander de l'aide à l'assembleur (le programme, ici). Cette adresse en effet pourrait être fixée à la main, mais cela ne serait pas très flexible. Plutôt qu'une adresse, on utilise plutôt une étiquette (un label) comme une référence au contenu pointé.

        LD HL, chaine
        (... plus loin ...)
    chaine:
        DEFB "Bonjour !", 0
    

    DEFB n'est pas réellement une instruction qui s'associe au langage machine. C'est une pseudo instruction, ou directive d'assemblage, qui indique à l'assembleur les valeurs numériques à placer directement en mémoire. Ici, on y place les valeurs numériques correspondantes aux caractères de "Bonjour !", suivi de la valeur 0, qui indique la fin de la chaîne. L'étiquette chaîne prendra automatiquement lors de l'assemblage l'adresse mémoire calculée.

    Si DEFB est séparé de programme lui-même, c'est qu'une fois en mémoire, le processeur Z80 exécutera les instructions une à une, sans avoir de moyen de distinguer ce qui est une véritable instruction de ce qui est de la donnée. Si la chaîne de caractères se trouve sur son chemin d'exécution, elle sera prise pour une série d'instructions.

    Pour les curieux : « Bonjour! » pris comme une suite d'instructions donne ce qui suit et qui n'a pas beaucoup de sens

    LD B,D
    LD L,A
    LD L,(HL)
    LD L,D
    LD L,A
    LD (HL),L
    LD (HL),D
    LD HL,$0000
    


    Reprenons... appeler la routine $36AA est simplement :

    CALL $36AA
    

    Et revenir au programme appelant se fait avec l'instruction RET.

    Dernière petite opération, il faut spécifier à l'assembleur l'adresse de début du programme, afin que les adresses des étiquettes puissent être calculées. Cela peut se faire, entre autre méthode, par l'utilisation de la directive d'assemblage ORG, comme origin.

    Ce qui donne au final la séquence suivante :

        ORG $7000
    
        PUSH AF
        PUSH BC
        PUSH DE
        PUSH HL
    
        LD HL, chaine
        CALL $36AA
    
        POP HL
        POP DE
        POP BC
        POP AF
    
        RET
    chaine:
        DEFB "Bonjour !", 0
    

    Ce qui donne une fois passé à l'assembleur la séquence en langage machine suivante (en représentation hexadécimale) :

    E5 C5 F5 D5 CD AA 36 D1 F1 C1 E1 C9 42 6F 6E 6A 6F 75 72 21 00
    

    Lancement du programme

    Cette séquence en langage machine doit ensuite être implantée dans la mémoire et appelée depuis le BASIC. Une manière de faire est d'utiliser les instructions DATA et POKE du BASIC. DATA indique des séquences de valeurs à lire avec READ. POKE modifie une valeur de la mémoire à l'adresse spécifiée par le premier paramètre avec la valeur en deuxième paramètre.

    Voici un exemple de chargeur de programme en langage machine écrit en BASIC sur VG5000µ.

    10 S=&"7000"
    20 READ A$
    30 IF A$="FIN" THEN END
    20 A$="&"+CHR$(34)+A$+CHR$(34):A=VAL(A$)
    30 POKE S,A
    50 S=S+1
    60 GOTO 20
    300 DATA F5,C5,D5,E5,21,07,70,CD,AA,36,E1,D1,C1,F1,C9,42,6F,6E,6A,6F,75,72,20,21,00 
    400 DATA FIN
    

    Une fois ce programme entré et lancé avec RUN, la routine d'affichage peut être appelée avec CALL &"7000" et affichera Bonjour! à l'écran.

    Résultat

    Forcément, j'ai déployé beaucoup d'efforts pour afficher une simple chaîne de caractères. Il n'y a pas vraiment d'intérêt autre que pédagogique. Le programme en lui-même est long à cause de la sauvegarde et la restauration des registres, il faut l'accompagner d'un chargeur qui est plus grand que le programme en assembleur lui-même, et l'action n'étant appelée qu'une fois, il n'a pas d'intérêt en vitesse d'exécution.

    Mais nous avons pu voir à quoi ressemblait la programmation en assembleur.

    Bonjour! Bonjour!


  • Z80 et VG5000µ ()

    Lors des articles précédents sur l'affichage, un résultat était net : c'est lent ! Extrêmement lent. Les magazines ou de livres consacrés à la programmation des machines personnelles des années 1980 affirmaient tous ceci : si vous voulez quelque chose de rapide, passez à l'assembleur.

    Que signifie utiliser l'assembleur, et en quoi c'est différent du BASIC ? Pourquoi est-ce que c'est plus rapide ? Était-ce vraiment la seule solution ? C'est ce que nous allons voir dans cet article et les suivants.

    J'ai tenté plusieurs approches pour arriver au premier programme en assembleur dans une série d'articles. Et j'en suis arrivé à la conclusion qu'il n'y a pas moyen de passer outre quelques explications rapides des constituants de l'ordinateur et de leurs fonctionnements.

    On va tout de même garder une vue large et schématique pour la plupart des composants. Pour le microprocesseur, un Z80 sur le VG5000µ, il faudra descendre un peu vers le fonctionnement de la puce, sans y sombrer.

    En effet, programmer en assembleur, c'est programmer la machine au plus près, suivant ses caractéristiques, sans l'aide d'un langage de programmation offrant des abstractions.

    La machine, en très bref

    Le VG5000µ est composé de :

    • Un microprocesseur Z80A, que je désignerai plus simplement comme Z80, qui est le nom générique pour cette série. Le microprocesseur est souvent désigné comme le cœur de l'ordinateur. Je préfère le désigner comme chef d'orchestre. C'est ce composant qui exécute les instructions du programme.
    • Un clavier, qui est une série d'interrupteurs agencés sous forme de matrice dont l'état peut-être lu grâce au contrôleur d'entrée/sortie du Z80.
    • Une mémoire au contenu figé (ROM) de 16ko, qui contient le programme de gestion de la machine.
    • Trois mémoires vives (RAM) de 8ko, contenant toutes les données dynamiques de la machine. Deux de ces mémoires servent au fonctionnement général, la troisième est réservée au fonctionnement du processeur graphique.
    • Un processeur graphique, EF9394, qui gère l'affichage.
    • Une interface cassette.
    • Des BUS et des circuits logiques pour relier le tout.

    Schéma simplifié VG5000

    Le fonctionnement du CPU, en très bref

    Au démarrage de la machine, le Z80, alimenté, va entrer dans une boucle d'exécution jusqu'à son extinction :

    • Acquérir une instruction à l'adresse mémoire de l'instruction suivante (adresse 0 au démarrage).
    • Changement de l'adresse de l'instruction suivante.
    • Exécution de l'instruction acquise.

    À cela s'ajoute le traitement des interruptions. Lorsque le processeur reçoit une interruption, l'adresse mémoire de l'instruction suivante est forcée à une valeur spécifique. Une instruction dédiée permet de reprendre plus tard l'exécution là où elle avait été interrompue.

    Boucle du CPU

    C'est une vue un simplifiée du fonctionnement du Z80, je laisse de côté les détails, comme le fait que l'acquisition d'une nouvelle instruction n'attend pas la fin de l'exécution de la précédente. D'un point de vue logique, en ce qui nous concerne, cela revient au même.

    Voyons les étapes plus en détails.

    Acquisition de l'instruction

    Le Z80 est relié via trois BUS aux mémoires du VG5000µ, exception faite de la mémoire dédiée au processeur graphique. Un BUS, c'est tout simplement une série de conducteurs électriques (disons, des fils) qui permettent à différents composants de communiquer.

    Pour acquérir son instruction, le Z80 va utiliser un premier BUS, celui d'adresse, pour signaler de quelle adresse mémoire l'instruction courante est voulue. Puis, via un second BUS, celui de contrôle, le Z80 signal qu'il veut lire le contenu à cette adresse. Après une brève attente, le troisième BUS, celui de données, pourra être lu et contiendra l'information recherchée, fournie par l'une des mémoires.

    Une instruction complète pour un Z80 peut être composée d'un ou plusieurs octets. Dans le cas d'instructions à plusieurs octets, ceux-ci seront demandés les uns après les autres.

    Exécution de l'instruction

    Une fois l'instruction acquise, celle-ci est décodée et exécutée. Une instruction en langage machine Z80 est une suite de 1 à 4 octets. Chaque octets est une série de 8 informations binaires. Ces informations binaires, au niveau du microprocesseur, sont des informations électriques : est-ce que le signal est haut (1), ou bas (0) ?

    La manière dont est architecturé le Z80 fait que ces signaux activent à leur tour d'autres signaux, qui provoquent le transfert d'information à travers les circuits internes au Z80. Ces circuits internes peuvent être des mémoires (les registres), des unités de calculs simples, des unités de calculs et de logique. Les signaux peuvent aussi atteindre les BUS pour émettre des informations ou en recevoir.

    Ainsi, par exemple, l'instruction de retour d'un sous-routine, dont le nom est 'RET', se compose en langage machine des signaux suivants 11001001. C'est une instruction sans argument qui déclenche une série de micro-actions . La première est de demander à la mémoire le contenu à l'adresse désignée par le registre SP, qui est un registre dédié à ce genre d'opérations, tout en augmentant la valeur de SP de 1. La seconde est identique : demander le contenu mémoire à l'adresse SP nouvellement modifiée tout en l'incrémentant de 1.

    Le résultat de ces deux octets obtenus est placé dans le registre PC, qui est le registre qui désigne l'instruction suivante à obtenir.

    Ouf !

    C'est un peu lourd ? Voilà ce qu'il faut retenir : une instruction en langage machine déclenche une série de micro instructions influant les composants internes du microprocesseur.

    C'est justement parce que tout ce détail est encombrant pour réfléchir à la résolution d'un problème que nous allons vite monter d'un cran en abstraction, et passer à l'assembleur, dans le prochain article.


  • Récréation 3D, VG5000µ version 2 ()

    Il y a deux mois, je publiais ma première récréation en 3D, une évocation d'un VG5000µ. J'avais modélisé la machine un peu au jugé et au final, il y avait pas mal d'erreurs dans les dimensions. Un peu trop à mon goût. J'ai donc refait l'exercice, cette fois avec un VG5000µ et une règle à côté de moi.

    Et voici le nouveau résultat, bien plus satisfaisant.

    VG5000µ en 3D, version 2


« (précédent) Page 17 / 22 (suivant) »

Tous les tags

3d (14), 6809 (1), 8bits (1), Affichage (24), AgonLight (2), Altaïr (1), Amstrad CPC (1), Apple (1), Aquarius (2), ASM (30), Atari (1), Atari 800 (1), Atari ST (2), Automatisation (4), BASIC (30), BASIC-80 (4), C (3), Calculs (1), CDC (1), Clion (1), cmake (1), Commodore (1), Commodore PET (1), CPU (1), Debug (5), Dithering (2), Divers (1), EF9345 (1), Émulation (7), Forth (3), Game Jam (1), Hector (3), Histoire (1), Hooks (4), i8008 (1), Image (16), Jeu (14), Jeu Vidéo (4), Livre (1), Logo (2), Machine virtuelle (2), Magazine (1), MAME (1), Matra Alice (3), MDLC (7), Micral (2), Motorola (1), MSX (1), Musée (2), Nintendo Switch (1), Nombres (3), Optimisation (1), Outils (3), Pascaline (1), Peertube (1), Photo (2), Programmation (3), Python (1), ROM (15), RPUfOS (5), Salon (1), SC-3000 (1), Schéma (5), Synthèse (14), Tortue (1), Triceraprog (1), VG5000 (62), VIC-20 (1), Vidéo (1), Z80 (20), z88dk (1)

Les derniers articles

Instance Peertube pour Triceraprog
Environnement de développement pour Picthorix
Un jeu en Forth pour Hector HRX : Picthorix
Yeno SC-3000 et condensateurs
Suite de tests pour VG5000µ
Un peu d'Atari ST
Le Forth sur Hector HRX
J'MSX 24 et un micro jeu
Récréation 3D, Matra Alice
Tuiles des plus très-curieuses

Atom Feed

Réseaux