Triceraprog

Comparaisons 8 bits en Z80

2026-04-06T00:00:00+02:00

Il y a bien quelque chose avec le Z80 qui me ralenti à chaque fois, ce sont les comparaisons. L'égalité, c'est facile. Mais dès qu'il s'agit de comparer deux octets pour savoir si l'un est plus grand que l'autre, strictement ou pas, et encore pire, si ce sont des octets signés, j'y passe du temps... pour souvent me tromper.

Et donc, voici un petit tableau récapitulatif pour m'aider à m'y retrouver, et peut-être que ça pourra aussi vous aider.

Table des matières

Comparaisons non signées (8 bits)
Comparaisons signées (8 bits)
Comparaisons signées simplifiées (8 bits)
Les drapeaux

Comparaisons non signées (8 bits)

Un octet non signé est positif et dans l'intervalle [0, 255]. Après cp b (qui calcule A−B sans stocker le résultat), on a : Z = 1 si A = B et C = 1 si A < B.

A = B

    cp b
    jr z,egal
    ; cas 1 : A ≠ B
    jr next
egal:
    ; cas 2 : A = B
next:

A ≠ B

Le même code que pour A = B, mais en privilégiant le cas A ≠ B.

    cp b
    jr nz,inegal
    ; cas 1 : A = B
    jr next
inegal:
    ; cas 2 : A ≠ B
next:

A < B et A ≥ B

Les deux cas sont identiques, c'est juste une question de sémantique.

    cp b
    jr c,inf_strict
    ; cas 1 : A < B (ou A ≥ B)
    jr next
inf_strict:
    ; cas 2 : A ≥ B (ou A < B)
next:

A ≤ B et A > B

Les deux cas sont identiques, c'est juste une question de sémantique.

    cp b
    jr z,inf_ou_egal
    jr c,inf_ou_egal
    ; cas 1 : A > B (ou A ≤ B)
    jr next
inf_ou_egal:
    ; cas 2 : A ≤ B (ou A > B)
next:

Comparaisons signées (8 bits)

En signé, les deux octets sont dans l'intervalle [−128, +127]. La condition A < B est plus complexe à évaluer, car il faut aussi prendre en compte le flag de débordement (overflow) qui peut se produire lors de la soustraction A−B.

Si on est assuré qu'aucun overflow ne se produit (si A et B sont tous deux dans un intervalle [−64, +63]), voir la section suivante.

En signé ou pas, l'égalité est identique à celle des non signés, elle n'est pas reproduite ici.

Note : jr ne supporte pas les conditions sur S et V, il faut donc utiliser jp pour ces cas.

A > B ou A ≤ B (signé)

    cp b
    jr z,inf_ou_egal    ; A et B égaux
    jp pe,ov_gt         ; Overflow, il faut inverser la condition
    jp p,sup_strict     ; S=0 et pas d'overflow, donc A > B (strict)
    jp inf_ou_egal      ; S=1 et pas d'overflow, donc A ≤ B
ov_gt:                  ; Cas de l'overflow
    jp m,sup_strict     ; S=1 et overflow, donc A > B
    jp inf_ou_egal      ; S=0 et overflow, donc A ≤ B
sup_strict:
    ; cas 1 : A > B (signé)
    jp next
inf_ou_egal:
    ; cas 2 : A ≤ B (signé)
next:

A < B ou A ≥ B (signé)

    cp b
    jp pe,ov_lt         ; Overflow, il faut inverser la condition
    jp m,inf_strict     ; S=1 et pas d'overflow, donc A < B
    jp sup_ou_egal      ; S=0 et pas d'overflow, donc A ≥ B
ov_lt:                  ; Cas de l'overflow
    jp p,inf_strict     ; S=0 et overflow, donc A < B
    jp sup_ou_egal      ; S=1 et overflow, donc A ≥ B
inf_strict:
    ; cas 1 : A < B (signé)
    jp next
sup_ou_egal:
    ; cas 2 : A ≥ B (signé)
next:

Comparaisons signées simplifiées (8 bits)

Lorsque A et B sont dans un intervalle tel qu'aucun overflow ne se produit lors de A−B (tous deux dans [−64, +63] ou toute opération garantie sans débordement) le code est simplifié en retirant les vérifications d'overflow.

A > B ou A ≤ B (signé, pas d'overflow)

    cp b
    jr z,inf_ou_egal    ; A = B
    jp p,sup_strict     ; S=0, donc A > B
    jp inf_ou_egal      ; S=1, donc A ≤ B
sup_strict:
    ; cas 1 : A > B (signé)
    jp next
inf_ou_egal:
    ; cas 2 : A ≤ B (signé)
next:

A < B ou A ≥ B (signé, pas d'overflow)

    cp b
    jp m,inf_strict     ; S=1, donc A < B
    jp sup_ou_egal      ; S=0, donc A ≥ B
inf_strict:
    ; cas 1 : A < B (signé)
    jp next
sup_ou_egal:
    ; cas 2 : A ≥ B (signé)
next:

Les drapeaux

L'état des drapeaux après cp b.

Flag	Signification
`Z`	1 si `A = B` (`A - B = 0`)
`C`	1 si `A < B` (non signé) (emprunt lors de `A−B`)
`S`	Bit 7 de `A−B` (signe du résultat 8 bits)
`P/V`	1 si overflow signé (voir conditions ci-dessous)

À propos de l'overflow signé : il se produit lorsque A et B ont des signes opposés et que le résultat de A−B a un signe différent de celui de A.

Entre autre, il n'y a pas d'overflow possible si A et B sont de même signe.

À propos de S et V :

S	V	Interprétation
0	0	A − B ≥ 0, pas de débordement, donc A ≥ B
1	0	A − B < 0, pas de débordement, donc A < B
0	1	Résultat positif mais a débordé, donc A < B
1	1	Résultat négatif mais a débordé, donc A > B

Instructions et drapeaux

La syntax des sauts ne fait pas toujours référence directe au nom des drapeaux, ce qui est confusant.

Instruction	Description
`jr z/nz`	Saut relatif sur Z
`jr c/nc`	Saut relatif sur C
`jp m/p`	Saut absolu sur S
`jp pe/po`	Saut absolu sur P/V

z80dezasm, désassembler et commenter le Z80

2026-03-22T00:00:00+01:00

L'origine

C'est à l'été 2017 qu'après avoir commencé à étudier en profondeur le VG5000µ, je me mets en tête de commenter l'intégralité de sa ROM. Il y a bien quelques morceaux de ROM désassemblée qui existent, mais c'est incomplet et surtout, à cause des astuces d'instructions partielles du Z80, pas ré-assemblable à l'identique.

Or, en plus de l'étude, j'aimerais pouvoir modifier la ROM pour faire des essais, voire ajouter des commandes. Je cherche alors un désassembleur Z80 qui puisse aussi ajouter des commentaires et produire un code ré-assemblable. Je n'en trouve pas. Et puis, il y a cette page qui me fait dire que ça ne serait pas si compliqué que ça à faire.

C'est ainsi que je commence à développer un désassembleur Z80, que je nomme alors z80tools, car il n'est alors qu'une partie d'un répertoire d'outils variés permettant d'analyser la ROM. Une partie de ces outils seront extraits au fur et à mesure pour donner ce repo. Il m'en reste une paire d'autres à extraire et puis, surtout, il reste ce plus gros morceau : le désassembleur/commenteur lui-même.

Seulement, c'est un gros morceau de scripts écrits itérativement au fur et à mesure de mes besoins, sans vraiment une idée de produit publiable. Je le garde donc dans un coin et je me contente de publier le résultat du commentaire de la ROM du VG5000µ, avec la spécification du format que j'utilise.

Mars 2026

Cet outil me servira dans d'autres projets, principalement lors des sessions de la RPUfOS, pour analyser les ROMs des machines cibles lorsque celles-ci utilisent un Z80. Jamais rien de complet ceci dit.

Et puis vient à nouveau une session, avec pour machine cette fois le Canon X-07. C'est une machine qui a de la documentation, mais pas toujours très précise, et de l'émulation, mais pas vraiment fiable (en cause, le coprocesseur T6834, pas documenté assez précisément). Je relance l'outil pour aller vérifier certaines hypothèses et je me dis qu'il serait peut-être temps que je publie ce projet !

Et c'est donc chose faite. J'ai donné un nom au projet : z80dezasm, packagé l'application avec uv, fait un peu de ménage à coup de linter (même si c'est encore vraiment le bazar dans le code), nettoyé les trucs hardcodé qui ne fonctionnent que sur ma machine ou sur le VG5000µ et écrit un README pour expliquer comment utiliser l'outil, en récupérant le bout de spécification que j'avais écrit pour le dépôt des commentaires. Ouf.

z80dezasm

L'outil z80dezasm est ici !.

Gardez en tête que ça reste un outil personnel trituré depuis 2017 et dont j'ai été le seul utilisateur pendant presque 9 ans. Ce n'est peut-être pas l'outil le plus facile à utiliser, ni le plus robuste, ni (certainement pas) le plus rapide. Mais s'il vous convient comme il me convient, c'est tant mieux.

Entre temps, une ou deux années après avoir commencé, j'avais trouvé un autre désassembleur/commenteur assez similaire (dont j'ai perdu la trace, désolé), mais bon, j'avais l'habitude du mien. Il existe aussi le maintenant bien connu ghidra, mais pareil... j'ai mes habitudes et ma façon de faire.

Adressage 6502, un récapitulatif

2026-03-20T00:00:00+01:00

Si vous aussi vous jetez régulièrement un œil sur les adressages possibles et valides pour le 6502, voici un tableau récapitulatif qui pourra vous servir. En tout cas, il me servira.

Tableau Récapitulatif

Mode	Syntaxe	Exemple	Taille	Cycles	Notes
Implicite	`OP`	`RTS`	1	2-6	-
Accumulateur	`OP A`	`LSR A`	1	2	-
Immédiat	`OP #nn`	`LDA #$42`	2	2	Constante
Page Zéro	`OP $nn`	`LDA $80`	2	3-5	Rapide
Page Zéro,X	`OP $nn,X`	`LDA $80,X`	2	4-6	Wrapping en page 0
Page Zéro,Y	`OP $nn,Y`	`LDX $10,Y`	2	4	LDX/STX uniquement
Absolu	`OP $nnnn`	`LDA $1234`	3	4-6	-
Absolu,X	`OP $nnnn,X`	`LDA $2000,X`	3	4-7	+1 si page crossed
Absolu,Y	`OP $nnnn,Y`	`LDA $3000,Y`	3	4-7	+1 si page crossed
Relatif	`OP label`	`BEQ Loop`	2	2-4	Branches uniquement
Indirect	`JMP ($nnnn)`	`JMP ($FFFC)`	3	5	JMP uniquement
Indexed Indirect	`OP ($nn,X)`	`LDA ($40,X)`	2	6	X ajouté d'abord
Indirect Indexed	`OP ($nn),Y`	`LDA ($40),Y`	2	5-6	Y ajouté après

`($nn,X)` vs `($nn),Y`

Indexed Indirect vs. Indirect Indexed, ma source de confusion préférée.

Écriture	($nn,X)	($nn),Y
Évaluation	X ajouté avant lecture	Y ajouté après lecture
Calcul	`addr = read16(($nn+X)&$FF)`	`addr = read16($nn)+Y`
Wrapping	X wrappe en page 0	Y sur 16-bit complet
Usage typique	Tables de pointeurs, dispatch	Tableaux, structures

Références

Les deux pages sur lesquelles je vais régulièrement :

Forth sur 6502, épisode 11

2026-02-25T00:00:00+01:00

ACCEPT, enfin !

Cela aura pris un peu de temps, entre autres raisons car d'autres activités se sont invitées entre-temps, mais ACCEPT est enfin implémenté ! ACCEPT est un mot qui lit une ligne de texte entrée par l'utilisateur et la stocke dans une adresse mémoire fournie lors de l'appel. Généralement, cette adresse est le TIB (Terminal Input Buffer), qui sera ensuite fournie à l'interpréteur Forth.

Comme indiqué lors du précédent article, se posait la question de savoir comment récupérer les données. J'ai tenté deux versions et je suis finalement partie sur celle que je pressentais : utiliser la mémoire PPU pour stocker les données en cours d'édition, puis les récupérer lorsque la touche RETURN est appuyée.

Oui, mais... même si la mémoire représentant les caractères est linéaire, depuis le début de l'implémentation j'ai réservé des caractères sur les bords de l'écran pour ne rien y afficher, afin de respecter les marges nécessaires lors d'un affichage sur écran cathodique. Récupérer les données nécessite donc de prendre des morceaux de mémoire à différents endroits. Pas forcément très complexe, mais ça nécessite un peu plus de réflexion qu'un simple transfert en une fois.

Et tant qu'à faire, puisque je dois définir une géométrie d'écran logique, pourquoi ne pas implémenter un mot WINDOW qui permettrait de définir les marges haut, bas, gauche et droite ? C'est ce que j'ai commencé par faire, en adaptant la gestion du curseur qui était codée en dur avec des marges fixes. Deux routines me permettent d'avancer et de reculer le curseur en respectant cette géométrie de fenêtre logique, et c'est bon. Les marges sont toujours là, initialisées au démarrage, mais à présent elles sont configurables.

Retour sur ACCEPT. Au début, il s'agit uniquement de reprendre le code d'affichage de caractères que j'avais déjà. Le code me semble quand même voué à être un peu long, je lui dédie donc un fichier. Il me faut implémenter l'édition d'une ligne logique, avec gestion des touches curseur du clavier (au moins droite et gauche), ainsi que des touches INS (insertion), DEL (suppression) et RETURN (validation de la ligne). Ces touches ne sont pas encore branchées, je repasse donc sur la gestion du clavier.

Gestion du clavier complet

Tant qu'à faire, puisque je suis sur le clavier, j'en profite pour gérer les majuscules, minuscules et kanas. Pour cela, il me faut compléter la fonte. Celle que j'avais choisie n'a pas tous ces caractères. J'en cherche une et je tombe sur la fonte Misaki, qui, en plus des katakanas, contient des caractères graphiques. Parfait pour utiliser la touche GRPH du clavier.

La fonte format bitmap 8x8 est fournie avec beaucoup de caractères. J'écris donc un petit script Python pour en prendre une sélection et générer ma fonte dans le format Famicom attendu. Puis je mappe tous les scancodes, un par un, vers leurs équivalents pour quatre tables différentes : majuscules, minuscules, kanas et graphiques. Je sélectionne quelques codes entre 0 et 32 pour les touches de contrôle, en respectant les codes classiques et en improvisant un peu pour les autres.

Et me voilà avec un mapping complet. Je peux compléter ACCEPT pour gérer les touches SHIFT, KANA et GRAPH. Les touches de direction avant et arrière ne posent pas beaucoup de problèmes... à part le curseur.

Tant que le curseur était en fin de ligne, c'était simple. Mais maintenant qu'il se déplace sur des caractères déjà présents, je veux le faire clignoter afin de laisser le caractère en dessous apparent. Et pour savoir quel est ce caractère, il faut aller le chercher... dans la mémoire de l'écran !

Transferts PPU <-> RAM

Je laisse donc le clavier de côté. Il est temps de s'occuper des transferts RAM/PPU. J'ai déjà, via le framework utilisé, un transfert de buffer de la RAM vers la mémoire PPU. Celui-ci fonctionne par recopie de données dans un buffer de commandes. C'est bien pour la sécurité des données : comme elles sont copiées, la source peut changer en RAM, elles sont au chaud dans la commande. Par contre, cela prend du temps de recopie et de la place en RAM.

J'implémente donc une version qui permet de référencer une adresse mémoire et une longueur, qui servent directement lors du décodage des commandes pendant la synchronisation verticale. À la charge de l'appelant d'assurer que les données sont toujours là où elles doivent être. J'en profite pour afficher le message de bienvenue avec cette commande, afin de valider le fonctionnement.

De là, il est assez facile d'en faire la commande symétrique : une commande qui référence une adresse mémoire et une longueur en RAM, et qui y copiera les résultats de requêtes PPU lors de la prochaine synchronisation verticale. En spécifiant comme adresse celle d'une variable contenant le caractère sous le curseur et comme longueur 1, je peux récupérer ce caractère courant.

Pour être sûr des buffers, j'attends la synchronisation verticale après chaque déplacement de curseur. Pendant l'édition d'une ligne d'entrée logique, ce n'est pas très important.

Retour à l'édition de ligne logique

Bien. À présent, j'ai la possibilité de récupérer le caractère sous le curseur, mais aussi tous les caractères à l'écran. Avant d'implémenter RETURN, je fais un détour par INS et DEL, afin de pouvoir faire de l'édition et de ne pas partir du principe que l'utilisateur tape une ligne parfaite du premier coup. Mes multiples tests montrent que ce n'est pas le cas. J'ai besoin de ces touches !

Un détour par le Family BASIC me montre que INS insère un espace à l'emplacement du curseur, ok, mais que DEL est en fait un BACKSPACE : il supprime le caractère avant le curseur et recule le curseur d'une position. Par cohérence, j'implémente le même comportement.

Cependant, il n'est pas possible de déplacer des morceaux de mémoire PPU directement. Ou alors je n'ai pas trouvé (et les personnes à qui j'ai demandé ne savaient pas). Qu'à cela ne tienne, ACCEPT a à sa disposition un buffer de travail dans lequel il déposera les données finales. Je l'utilise comme buffer temporaire. Pour les deux opérations, je récupère les données de l'écran (en respectant la géométrie de la fenêtre logique), je fais la modification en RAM, puis je renvoie le tout à l'écran.

Je ne m'embête pas à trouver la sous-partie qui va bouger, je récupère et je renvoie tout. J'attends même une synchronisation verticale pour chaque ligne physique transférée pour être certain de tenir dans le temps de synchronisation. Sur émulateur, ça ne bronche pas. On verra sur vrai matériel. Au pire, je pourrais grouper quelques transferts pour trouver le bon équilibre. Mais là encore, on est en pleine édition de ligne logique utilisateur, on peut se permettre des attentes sans affecter l'expérience utilisateur.

ACCEPT !

L'avantage avec l'implémentation de INS et DEL, c'est qu'il y a déjà tout ce qu'il faut pour implémenter RETURN. J'ai la récupération des données en RAM. Reste à pousser la longueur actuelle de la ligne logique sur la pile. Cette longueur est maintenue au fur et à mesure des opérations d'édition.

Il reste des choses à faire pour une édition au clavier agréable et complète. Et une paire de petits bugs, dont la longueur de la ligne logique qui n'est pas mise à jour correctement dans certains cas. Je m'en occuperai plus tard. Il est grand temps d'avancer vers INTERPRET !

Amélioration du framework de test

Au passage, avec l'arrivée du clavier, j'ai ajouté comme prévu l'injection de caractères depuis le framework de tests. Cela m'a permis d'écrire un test pour INS et un autre pour DEL. Ces tests demandent la mise en place de contextes en plusieurs étapes, avec parfois des attentes de frames pour attendre les résultats. Les tests commençaient à être très verbeux et j'ai donc fait une passe pour factoriser tout ça dans des fonctions d'aide qui me permettent d'écrire le déroulement des opérations qui seront ensuite conduites de manière asynchrone.

Interprète... interprète !

Maintenant que j'ai une boucle d'entrée de texte, la prochaine étape est l'interprétation du résultat. Cela va nécessiter l'écriture de nombreux mots standards de Forth (au passage, j'ai implémenté DROP car actuellement je dois ignorer le retour de ACCEPT). Cependant, ces mots devraient être nettement plus simples que ACCEPT ou la gestion clavier.

La « simple » implémentation d'ACCEPT a eu de nombreuses ramifications. J'en ai même profité pour faire quelques petites optimisations/simplifications simples au passage.

J'aimerais pour la suite pouvoir écrire quelque chose comme HEX 7FF FF C!, qui écrit la valeur 0xFF à l'adresse 0x7FFF, ce que le framework de test peut détecter. Cela signifie le découpage par mots de la chaîne d'entrée, un traitement de base numérique, le parsing de nombres dans cette base et l'implémentation de C! (le plus facile de toute la liste).

Partons là-dessus !

Deux livres pour le développement sur Famicom

2026-02-24T00:00:00+01:00

En attendant le prochain article de la série sur le développement d'un Forth sur Famicom, qui prend un peu de temps, je voulais faire une petite aparté pour présenter les deux livres qui m'accompagnent, en plus de différentes ressources en ligne.

En effet, un livre que l'on peut feuilleter, où on peut retrouver un passage rapidement, c'est pratique.

Making Games for the NES

Le premier livre est en anglais et aborde le développement de jeux pour la NES, et donc pour la Famicom. Très progressif, il amène chaque aspect de la machine avec clarté. Pas forcément dans les plus obscurs des détails et c'est aussi ce qui est intéressant : c'est une bonne première approche.

Le livre date un peu. Ça n'est pas très important pour la console elle-même, qui n'a pas bougé, mais quelques outils évoqués ne sont plus forcément les meilleurs choix.

L'auteur, Steven Hugg, a écrit d'autres livres pour d'autres machines et est aussi derrière le site 8bitworkshop, qui propose un environnement de développement en ligne pour différentes machines, dont la NES. Tous les exemples du livre y sont disponibles et peuvent être testés et modifiés directement dans le navigateur.

Langage machine 6502 et 6510

Le second livre est en français et aborde le langage machine du 6502 ainsi que les particularités du 6510. C'est avant tout un livre écrit avec le Commodore 64 en tête, mais sa structure en fait une bonne référence à garder sous la main pour la partie 6502.

N'ayant pas une grande expérience du 6502 (même si depuis le début du projet, j'ai progressé) je m'y réfère encore pas mal, surtout pour les modes d'adressages basés sur X et Y, pour lesquels j'ai encore tendance à tout mélanger.

Je me sers aussi du site 6502.org, mais comme je le disais, avoir un livre sous la main, c'est pratique. Et en français, c'est reposant.

Merci à l'auteur, Philippe Gianviti.

Forth sur 6502, épisode 10

2026-01-18T00:00:00+01:00

Un curseur et des branches

Le clavier est pour le moment implémenté avec deux mots. L'un qui sera gardé, KBDSCAN et l'autre qui est là en attendant de pouvoir écrire la même chose en Forth, KBDPROCESS. L'objectif premier est de transformer KBDPROCESS en son équivalent Forth que je placerai dans ma boucle principale (pas encore QUIT, qui n'est pas encore prêt).

Mais avant toute chose, j'ai quelque chose à corriger avec le curseur. Pour le moment, j'affiche le curseur avec EMIT, ce qui fait avancer la prochaine position d'affichage de caractère. Ce que je veux, c'est afficher le caractère reçu du clavier avec EMIT puis afficher le caractère du curseur sans faire avancer la position d'affichage. Ainsi, le caractère du curseur sera toujours une position après le dernier caractère affiché.

Pour cela, j'ai un peu remanié le code afin de séparer l'envoi du caractère à afficher et la mise à jour de la position d'affichage. Le code de EMIT appelle les deux fonctions et j'ai ajouté le mot PUTCHR qui affiche le caractère à la position courante sans avancer la position du curseur.

Ainsi, l'affichage d'un caractère reçu depuis le clavier devient :

KEY             \ Le caractère reçu du clavier est mis sur la pile
EMIT            \ Affiche le caractère présent sur la pile et avance le curseur
CURSOR_CODE @   \ Récupère le code du caractère du curseur
PUTCHR          \ Affiche le caractère du curseur sans avancer le curseur

Le fait de mettre le code du curseur dans une variable pointée par CURSOR_CODE permettra de changer la forme du curseur en fonction du mode (pour indiquer si on est en mode KANA ou non par exemple).

Avec un mot KEY bloquant, cela serait suffisant. Ce bout de code serait mis dans la boucle infinie et puis voilà. Seulement, je veux pouvoir opérer d'autres traitements dans la boucle d'attente de caractère. Faire clignoter le curseur par exemple, sans gestion par interruption. Et puis, c'est une bonne occasion d'implémenter une branche conditionnelle.

Le standard Forth actuel définit IF, ELSE et THEN de manière haut niveau, en indiquant le comportement attendu. Dans les Forth plus anciens, comme le FIG-Forth dont je m'inspire, le détail d'implémentation est d'utiliser les mots bas niveau 0BRANCH et BRANCH pour déplacer IP (le pointeur d'instruction).

J'ai déjà BRANCH, c'est le mot qui me permet d'avoir ma boucle infinie, en reculant IP de façon inconditionnelle. QUIT, actuellement, ressemble à ceci :

    MAIN_LOOP       \ Appel du mot dans lequel je fais mes tests
    BRANCH          \ Déplacement inconditionnel de IP en ajoutant le mot qui suit en mémoire
    $fffc           \ le mot qui suit en mémoire : -4. Ce qui ramène IP au niveau de MAIN_LOOP

0BRANCH fonctionne de la même manière, mais ne déplace IP que si la valeur au sommet de la pile est zéro. Dans le cas contraire, l'instruction ne fait rien d'autre que déplacer l'IP pour passer par-dessus le mot qui suit en mémoire, puis donne le contrôle à l'instruction suivante. Dans tous les cas, la valeur sur la pile est retirée de la pile.

Le mot est assez simple à implémenter avec mes briques existantes. Voici le code assembleur :

    ; 0BRANCH, branches if TOS is zero, else continues
DEFINE_CODE_WORD_WITH_SYMBOL ZERO_BRANCH, "0BRANCH", BRANCH, 0
    ; Pop TOS into Temp
    POP_PARAM_STACK_TO_REG Temp

    ; If Temp (16 bits) is zero, do the branch, call branch
    lda Temp
    ora Temp + 1
    beq BRANCH_word_pfa

    ; Not zero, advance IP by 2 (to skip the branch offset)
    inc_reg REG_IP
    inc_reg REG_IP
    END_TO_NEXT

(rappel : TOS signifie "Top Of Stack", le sommet de la pile de données)

Avec 0BRANCH, le traitement et affichage du clavier devient :

    KBDSCAN         \ Scan du clavier et mise à jour des tampons
    KEY?            \ Y a-t-il un caractère disponible ?
    0BRANCH         \ Si non, branchement
    $000c           \ vers l'instruction après PUTCHR (12 octets plus loin)
    KEY             \ Récupération du caractère
    EMIT            \ Affichage du caractère et avancée du curseur
    CURSOR_CODE @   \ Récupération du code du curseur
    PUTCHR          \ Affichage du curseur sans avancer le curseur
    \ Suite du code de la boucle principale

Avec ce morceau de code, j'ai un curseur qui fonctionne et je peux l'initialiser dans COLD. J'en profite pour implémenter LIT qui permet de pousser la valeur qui suit le mot en mémoire sur la pile. Cela me permet d'écrire des valeurs immédiates dans le code Forth. Jusqu'à maintenant, j'utilisais des constantes qui contenaient les valeurs initiales.

Il n'est pas impossible que je revienne sur l'initialisation (et le déplacement) du curseur dans le futur pour deux raisons liées. La première est qu'écrire sur les bords de l'écran sur ces machines n'est pas une bonne idée : les télés cathodiques avaient tendance à couper les bords de l'image. Pour le moment, je n'écris ni sur la première ni sur la dernière colonne. Mais en regardant Family BASIC, je vois que ce sont deux colonnes entières qui sont laissées comme marges. Ainsi que les deux premières lignes.

Ce qui m'amène à la seconde raison liée : permettre de changer la géométrie de la fenêtre de texte par l'utilisateur. C'est une commande qui existe sur l'Hector HRX par exemple. Avec ce système, ce mot WINDOW permettrait de définir les marges haut, bas, gauche et droite. À noter pour plus tard... car cela compliquera la gestion du scroll lors de l'arrivée en bas de la zone.

Entrer du texte

Le texte s'affiche donc à l'écran, très bien. Mais il n'est pas encore prêt pour être traité par le système Forth. Pour cela, FIG-Forth utilise un buffer dont l'adresse est maintenue dans la variable adresse TIB (Text Input Buffer), ainsi que sa taille dans la variable adresse #TIB, comme indiqué dans le livre Starting Forth dans le chapitre Under the Hood.

Je ne sais pas encore où placer ce buffer. Je vois plusieurs options possibles :

Je maintiens un buffer en RAM des caractères entrés et édités, en parallèle de ce qui est envoyé à l'écran. Cela limite l'édition à une ligne logique, pas possible de se balader sur un écran pleine page. Et maintenir en synchro deux systèmes parallèles n'est pas souvent une bonne idée.
J'utilise l'écran lui-même comme buffer et je limite l'édition à une ligne logique. Le fait que les données à l'écran ne soient pas continues à cause des réservations des premières et dernières colonnes complique un peu les choses. Il faut aussi ramener les informations présentes dans la mémoire vidéo vers la RAM pour traitement, ce qui est assez lent et nécessite d'être fait pendant la VSync.
J'utilise l'écran lui-même comme buffer et je permets l'édition pleine page. C'est globalement la même chose que l'option précédente, avec en plus un algorithme pour déterminer où commence la ligne logique lorsque l'on appuie sur RETURN.

Dans l'idéal, j'aimerais la troisième option. Cependant si cette fonctionnalité est très pratique en BASIC où on peut revenir sur des lignes précédentes pour les éditer, l'intérêt est moins évident en Forth, où il faut « oublier » les mots avant de les redéfinir.

La première option m'ennuie à cause du double traitement. Je pense que la seconde option sera mon choix de base. Si je vectorise le mot ACCEPT, il sera possible pour un utilisateur avancé de redéfinir le comportement pour faire de l'édition pleine page, en fonction de la RAM disponible sur la cartouche... je m'emballe.

Et les tests ?

L'affichage initial du curseur était testé par mes tests unitaires. Indirectement, le mot LIT que j'utilise à l'initialisation est testé. Par contre, j'ai à présent du texte en entrée et une boucle interactive avec du branchement conditionnel. Et pour ça, je n'ai qu'un test manuel : lancer le programme et vérifier que le clavier fonctionne. Et j'ai encore plus de mots standards que je devrais ajouter à un moment comme DUP, DROP, SWAP, OVER, etc. que je voudrais pouvoir tester depuis Forth.

Il existe un framework de test Forth, extrêmement simple, du nom de ttester, de John Hayes, ainsi que des versions dérivées. J'ai hâte de pouvoir l'utiliser. J'ai deux options. La première est de réécrire le code avec mon système de macros. Jouable, mais un peu long et fastidieux. La seconde est d'attendre d'avoir un interpréteur Forth fonctionnel... mais cela va m'obliger à écrire de nombreux mots sans tests, ce qui me déplaît. Je vais réfléchir à la question.

Pour la partie gestion du clavier, je pense ajouter à mon framework de test une injection de caractères. Il restera le test du clavier à tester physiquement, mais la boucle principale pourra être testée avec des entrées simulées.

La suite !

Mon étape suivante va être de compléter le traitement du clavier avec les majuscules, minuscules et kanas. Puis le traitement des touches de directions, insertions, suppressions, etc. Sur cette partie, je ne pense pas faire d'article, cela va être très mécanique. Cependant, je devrai me diriger vers l'implémentation du mot ACCEPT, qui gère l'entrée clavier et la fournit dans le buffer TIB. Cela m'obligera à choisir une des options évoquées plus haut, et ce sera donc probablement le sujet de l'article suivant.

Ah, et il sera peut-être temps de vérifier si tout cela fonctionne sur une vraie Famicom avec un vrai clavier Family BASIC !

En attendant, voici une capture sur émulateur :

Forth sur 6502, épisode 9

2026-01-11T00:00:00+01:00

Froid, abandon, quitte...

C'est triste un démarrage de Forth... COLD, ABORT, QUIT. On aurait pu imaginer des mots comme WARMUP, READY, LOOP. Mais je n'ai pas prévu de renommer les mots standards de Forth. Et comme indiqué dans l'article précédent, il est temps de déplacer le code de démarrage vers les mots officiels.

Et à vrai dire, comme prévu, il n'y avait pas grand chose à faire.

Tout d'abord, le code de démarrage devient juste initialiser l'interpréteur avec le mot COLD :

boot_forth:
    ; Set the Work Register to the first word to execute:
    lda #<COLD_word_cfa
    sta REG_W
    lda #>COLD_word_cfa
    sta REG_W + 1

    ; And use it
    jmp docol

Et pour faire simple, ABORT et QUIT appellent juste des mots cachés qui contiennent le code assembleur que j'avais déjà. Cela donne :

    ; COLD
    DEFINE_FORTH_WORD COLD, 0, 0
    .word RESET_ENV_word_cfa
    .word ABORT_word_cfa
    ; ABORT never returns, no need for DO_SEMI

    ; ABORT
    DEFINE_FORTH_WORD ABORT, COLD, 0
    .word RESET_STACK_word_cfa
    .word QUIT_word_cfa
    ; QUIT never returns, no need for DO_SEMI

Reste QUIT qui est la boucle infinie. J'avais déjà une boucle infinie sous forme de mot assembleur, je l'ai renommée et voilà, terminé !

Certes, ce n'est pas encore un vrai mot QUIT, qui doit traiter les entrées utilisateur et exécuter les commandes. Mais en tout cas, la structure est en place.

Lire le clavier

Et donc puisque tout cela n'était pas bien compliqué, et que QUIT va avoir besoin de lire le clavier, passons à la lecture du clavier.

Accès au clavier

Le clavier Family BASIC est connecté à la Famicom via le port d'extension. Celui qui est devant dans une Famicom classique. Avant de l'interroger, il faut écrire à l'adresse $4016 puis lire depuis l'adresse $4017.

L'écriture à l'adresse $4016 contrôle le balayage du clavier. En effet, le clavier est une matrice de touches sur 9 lignes et 2 colonnes. La matrice est visible sur NESDev.

L'écriture à $4016 utilise les 3 premiers bits pour contrôler le scan.

Bit	Description
0	0 = scan normal ; 1 = réinitialiser le scan ligne 0, colonne 0
1	Sélection de colonne
2	Activer le clavier (1 = activé)
3-7	inutilisés

La lecture depuis $4017 récupère les données du clavier.

Bit	Description
0	Inutilisé
1-4	Données de colonne
5-7	Inutilisés

Un délai doit être respecté entre l'écriture à $4016 et la lecture depuis $4017 pour permettre au clavier de préparer les lignes de données.

Scan dans le Forth

Pour le scan dans le Forth, j'utilise trois tampons en mémoire qui sont chacun de taille 9 octets (un par ligne). Pour chaque ligne les informations des deux colonnes sont regroupées dans un seul octet.

Bits 0-3 : données de la colonne 0
Bits 4-7 : données de la colonne 1

Le premier tampon sert au scan en cours. Un second sert à stocker le résultat du scan précédent. Le troisième sert à détecter les changements entre les deux scans (en faisant un XOR entre les deux autres tampons).

Une fois les tampons remplis, le tampon de changements est analysé pour détecter les changements d'état des touches. Si un bit a changé dans le tampon de changements, l'état pressé/relâché est déterminé à partir du tampon de matrice actuel. Ceci est fait pour l'octet entier, donc si plusieurs bits ont changé dans une ligne, ils sont tous traités.

Puis pour chaque bit modifié qui est aussi détecté comme un appui, une recherche dans une table de caractères fait la correspondance. Si le caractère est affichable, il est placé dans une file de caractères qui pourra être interrogée plus tard par le mot Forth KEY, qu'il reste à implémenter.

Pour chaque bit modifié, je calcule aussi un code de touche ((ligne << 4) | numéro_de_bit), mais je ne l'utilise pas. Cela vient d'une idée précédente où je voulais tout d'abord générer les évènements de touches puis les décoder dans un second temps. Au final, j'ai trouvé ça bien compliqué pour cette machine.

Ce qu'il reste à faire

Plein de choses. Même en se limitant au clavier. Mais je pense que le plus long a été fait : le principe général de scan et de décodage. Il me reste à traiter les touches spéciales (comme SHIFT, CTRL, etc) et à implémenter le mot Forth KEY.

J'ai prévu d'implémenter aussi le mot KEY? qui permet de savoir si une touche est disponible. Ainsi que KEYPRESSED? et KEYDOWN? pour interroger l'état de touches spécifiques.

On peut écrire !

En branchant rapidement la détection des touches avec un appel codé en dur à EMIT dans la boucle principale, je peux écrire à l'écran ! Le curseur n'avance pas, car lui aussi était un appel codé en dur, cependant, c'est assez satisfaisant.

D'ailleurs, je pense que la prochaine étape sera le traitement de l'avancée du curseur depuis la boucle principale en Forth. Cela va m'obliger à implémenter quelques nouveaux mots, comme 0BRANCH (afin de faire des tests conditionnels).

Forth sur 6502, épisode 8

2026-01-02T00:00:00+01:00

Afficher des caractères

Lors du précédent article, l'ajout de variables et de la pile des paramètres nous a approché de l'objectif actuel : afficher des caractères à l'écran. Ou plus exactement, remplacer l'affichage de la chaîne de caractères depuis l'assembleur au démarrage du programme vers la partie Forth.

Pour commencer et s'assurer que j'ai du code qui peut transformer des coordonnées en adresse PPU et afficher un caractère, je crée un mot TEST_EMIT qui va prendre ces coordonnées et afficher un unique caractère comme curseur. Comme je n'ai que 26 lettres majuscules actuellement dans mes données graphiques, il est temps d'aller modifier les données. J'ajoute en caractères 255 un carré plein. Cela fera un bon curseur.

Il me faut aussi deux variables pour stocker les coordonnées du curseur : CURSOR_X et CURSOR_Y que j'initialise à l'emplacement où je veux afficher le curseur au démarrage (en effet, je n'ai pas encore de moyen de modifier le contenu d'une variable facilement à partir d'un nombre).

    DEFINE_VARIABLE CURSOR_X, POST_LOGIC
    .word $0001

    DEFINE_VARIABLE CURSOR_Y, CURSOR_X
    .word $0002

On peut noter que 16 bits pour des coordonnées d'écran en caractères, c'est beaucoup. On peut imaginer « compresser » les deux coordonnées dans une seule variable. Ça compliquera un peu l'écriture cependant. Je me laisse ça en note pour plus tard.

Ah oui, autre chose. Peut-être que vous l'aviez remarqué avant moi, mais les variables que je définis sont actuellement dans le programme, et donc en ROM ! Pas terrible pour des variables. Je me note ça aussi pour plus tard (mais dans pas longtemps, car sinon, le curseur ne pourra pas bouger).

Presque EMIT

Quant à TEST_EMIT, il est en assembleur et il ressemble à ceci :

    ; Test word for hardcoded EMIT
    DEFINE_CODE_WORD TEST_EMIT, CURSOR_Y, 0
    jsr compute_screen_address  ; Now Addr has the screen address in PPU

    ; Warning, address endianness is swapped for vram_queue_set_ppu
    ; High byte first
    lda Addr
    sta VramQueuePtr+1
    lda Addr+1
    sta VramQueuePtr
    lda #$00        ; Horizontal increment
    jsr vram_queue_set_ppu

    ; Write character to buffer
    vram_t_set_buffer 1
    lda #'C'        ; Hardcoded character
    ldy #$00
    sta (VramQueuePtr), y

    END_TO_NEXT

compute_screen_address est une sous-routine qui prend les coordonnées du curseur et calcule l'adresse PPU correspondante. C'est une partie dont je veux m'assurer avoir compris le fonctionnement (et l'écriture en 6502).

J'utilise ensuite le système du template de projet pour communiquer avec le PPU.

VramQueuePtr sert dans un premier temps de variable paramètre pour vram_queue_set_ppu, qui positionne le registre d'adresse PPU. Plus exactement qui prépare la commande dans la liste d'affichage.
la macro vram_t_set_buffer réserve de l'espace (ici 1 octet) dans la liste d'affichage et fait pointer VramQueuePtr au début de cet espace. Le contenu de ce buffer sera transféré à l'adresse PPU spécifiée.

À noter que l'allocation de l'espace retourne sans rien faire s'il n'y a plus de place. Comme je ne vérifie rien, cela peut être assez catastrophique. Pour le moment, j'affiche un seul caractère par rafraîchissement, ça va passer. Le système du template limite la taille d'un transfert à 64 octets et le buffer complet est de 256 octets. Je ne sais pas encore si je mettrai des protections en place ou bien si je laisse l'utilisateur gérer cela. Je n'aime pas trop l'idée de se retrouver avec un programme qui plante sans explication, mais d'un autre côté, c'est du Forth, pas du BASIC.

Et ça marche, voici le résultat :

Des variables... pour de vrai ?

Comme indiqué plus haut, le contenu de mes variables sont en ROM. Pas terrible. Comment faire pour avoir des variables définies par la ROM, mais dont le contenu est en RAM ? Une méthode classique est de transformer les variables en constantes. Je sais, dit comme ça, ça semble bizarre. Mais ça se comprend : on transforme une variable, qui contient donc sa propre valeur, en une constante qui contient l'adresse mémoire où la valeur sera stockée. Cet espace sera réservé en RAM.

Après tout, le fonctionnement d'une variable en Forth n'est rien d'autre qu'un mot qui place une adresse mémoire sur la pile des paramètres. La variable place son propre PFA. Une constante place une valeur spécifiée.

EMIT... pour de vrai aussi

Pour le moment TEST_EMIT code en dur le caractère. EMIT, lui, doit envoyer à l'affichage le caractère dont le code est présent sur la pile. Pour avoir un vrai EMIT, il faut donc modifier TEST_EMIT pour qu'il récupère le code caractère depuis la pile des paramètres. Et cette valeur devra y être placée auparavant. Cela tombe bien, je viens d'implémenter le concept de constantes.

Voici donc mon curseur :

    DEFINE_CONSTANT CURSOR_CODE, TEST_ADDR
    .word $FF

Et la boucle principale Forth devient :

    DEFINE_FORTH_WORD MAIN_LOOP, MEMORY_TEST, 0
    .word READ_JOY_SAFE_word_cfa
    .word MEMORY_TEST_word_cfa
    .word CURSOR_CODE_word_cfa      ; On place le code caractère sur la pile
    .word EMIT_word_cfa             ; On appelle EMIT pour afficher ce caractère
    .word POST_LOGIC_word_cfa
    .word DO_SEMI_word_cfa

Ça fonctionne. Pour un même résultat.

Cependant, EMIT est censé aussi avancer la position du curseur. Ce que je peux brancher, mais qui va poser problème. Car la position avançant à chaque affichage, le curseur se retrouve affiché à chaque position de l'écran, et l'écran devient rapidement entièrement rempli d'une couleur unie.

En attendant une vraie gestion de curseur, je replace le curseur à la position initiale à chaque itération de la boucle principale.

    ; MAIN LOOP word
    DEFINE_FORTH_WORD MAIN_LOOP, MEMORY_TEST, 0
    .word READ_JOY_SAFE_word_cfa
    .word MEMORY_TEST_word_cfa

    .word CURSOR_INIT_X_word_cfa
    .word CURSOR_X_word_cfa
    .word STORE_word_cfa
    .word CURSOR_INIT_Y_word_cfa
    .word CURSOR_Y_word_cfa
    .word STORE_word_cfa

    .word CURSOR_CODE_word_cfa
    .word EMIT_word_cfa
    .word POST_LOGIC_word_cfa
    .word DO_SEMI_word_cfa

Ce qui équivaut en Forth à :

    : MAIN_LOOP
        READ_JOY_SAFE
        MEMORY_TEST

        CURSOR_INIT_X CURSOR_X !
        CURSOR_INIT_Y CURSOR_Y !

        CURSOR_CODE EMIT
        POST_LOGIC
    ;

Moving Forth, épisode 6

Revenons un peu à la lecture de la série d'articles Moving Forth avec la sixième partie. Après avoir présenté les primitives du langage, ce qui forme le « kernel », l'auteur aborde la notion de « high-level kernel ». Il s'agit du reste du système, celui qui permet l'interactivité et donc la compilation de nouveaux mots et leur exécution. Ce « high-level kernel » est écrit en Forth et se veut portable, contrairement au « kernel » contenant les primitives, écrit en assembleur.

On y apprend que le démarrage de Forth est effectué par

un mot appelé COLD, qui s'occupe de l'initialisation des variables internes (de l'environnement je dirais),
qui lui-même appelle ABORT, qui réinitialise la pile de paramètres,
qui lui-même appelle QUIT, qui réinitialise la pile de retour, l'état de l'interpréteur, et lance la boucle principale de l'interpréteur.

QUIT est une boucle infinie qui lit l'entrée utilisateur et appelle le mot INTERPRET, qui s'occupe de l'analyse de l'entrée.

J'ai déjà le contenu de COLD et ABORT dans mon bootstrap de Forth. Il me faudra les implémenter en tant que mots Forth.

Pour implémenter QUIT, il me faudra implémenter la réception de l'entrée utilisateur, et donc du clavier de la Famicom. Puis pas mal d'autres mots qui seront nécessaires pour INTERPRET.

De là, l'article mentionne sans entrer dans le détail le concept de « vocabulaire », qui permet d'avoir plusieurs dictionnaires de mots, regroupés par fonctionnalités. Comme le Forth de l'article n'en a pas, il n'y a pas plus d'explications. J'ai prévu de mon côté d'implémenter cette notion.

Puis l'auteur revient sur l'entête d'un mot et du drapeau « IMMEDIATE » que j'avais évoqué lors de la sixième partie et la création des mots complets. Lors de la compilation d'un mot (on verra ça plus tard), les mots trouvés sont normalement « compilés » dans le mot en train d'être définis. Sauf si le mot est marqué comme « IMMEDIATE », auquel cas il est exécuté immédiatement. Cela permet de contrôler la compilation. On peut considérer que c'est de la « méta-compilation », comme des macros qui vont effectuer des opérations pendant la compilation.

Par exemple, IF est un mot « IMMEDIATE » qui va insérer des instructions de branchement conditionnel dans le mot en cours de définition, conjointement avec ELSE et THEN, qui sont aussi des mots « IMMEDIATE ».

L'article décrit d'ailleurs rapidement la manière dont la compilation fonctionne :

la compilation démarre avec le mot :,
le mot est créé avec CREATE,
le CFA est initialisé pour pointer sur le DOCOL,
on passe en mode « compilation »,
chaque mot trouvé voit son CFA ajouté à la fin du PFA du mot en cours de définition,
lorsque le mot ; est trouvé, on ajoute le CFA de ;S (EXIT) à la fin du PFA
on repasse en mode « interprétation ».

Il y a des choses en plus qui sont faites, comme rendre le mot visible à la fin de la compilation, l'insérer dans le dictionnaire du vocabulaire courant, traiter les mots « IMMEDIATE », etc... Mais le principe est là.

Après avoir indiqué les mots qui sont impactés par le modèle d'exécution choisi, la fin de l'article montre le layout mémoire sur CP/M pour le Forth implémenté, ce qui ne m'intéresse pas trop ici, ainsi que différent types de layout de mots Forth.

Je ne les reproduis pas ici, vous pouvez aller les voir dans l'article original. On y voit quatre Forth différents qui font chacun des choix différents. Mes choix sont globalement ceux de FIG-Forth, ce qui n'est pas étonnant puisque c'est le type de Forth que j'ai pu aborder dans mes expériences précédentes

La suite

On s'approche d'un système interactif, mais il reste encore un gros morceau côté Famicom plus que côté Forth : la gestion du clavier. Détecter qu'il est là, scanner les touches, les interpréter, en particulier les touches spéciales (peut-être dans un second temps). Si l'appui sur une touche provoque l'affichage d'un caractère à l'écran, on aura presque la première partie de l'interpréteur.

Côté Moving Forth, c'est terminé. Il reste en fait deux articles, mais qui traitent de spécificités sur des architectures particulières. Cela s'éloigne trop du projet que j'ai. Je parcourrai peut-être une autre référence comme le livre « Starting Forth », qui me servira probablement de guide pour l'implémentation de QUIT et INTERPRET.

À bientôt pour la suite !

Forth sur 6502, épisode 7

2026-01-01T00:00:00+01:00

En route pour l'affichage

Afficher du texte à l'écran

L'étape d'aujourd'hui va permettre de se diriger vers l'affichage d'un texte à l'écran depuis la boucle Forth. Pour cela, il faut revenir un peu sur le fonctionnement de la Famicom.

Le processeur qui s'occupe de l'affichage est le PPU (Picture Processing Unit). Ce processeur a son espace d'adressage mémoire propre de 16 ko dont le routage est configuré par la cartouche insérée. Dans la console, 2 ko de RAM sont dédiés au PPU, assez pour stocker les informations de deux écrans (index de caractères et attributs). La cartouche doit apporter a minima les informations de caractères (en ROM généralement, mais peut aussi offrir un espace RAM pour les construire) ; elle peut aussi étendre le nombre d'écrans (jusqu'à 4) ou ajouter un système de banking de pages.

De manière générale, tout le mapping de la mémoire du PPU est contrôlé par la cartouche, à part les palettes. La cartouche la plus simple possible n'offrira que les 8 ko de ROM nécessaires aux deux tables de définition de caractères, mais on peut faire beaucoup plus complexe.

À cela s'ajoute 256 octets de mémoire pour la gestion des sprites.

Le PPU utilise toutes ses informations pour composer l'image à l'écran. Cependant le processeur 6502 n'a pas accès à cette mémoire. Pour y accéder, il existe des registres mappés dans l'espace d'adressage du CPU. Mais... il y a un mais. Lorsque le PPU est en train de faire le rendu, il a un besoin exclusif d'accès à sa mémoire. Le CPU doit donc attendre que le PPU soit dans une période où il n'a pas besoin d'accéder à sa mémoire : la période de « VBlank » (Vertical Blank), qui correspond au moment où l'écran n'est pas en train d'être rafraîchi (le balayage vertical revient en haut de l'écran).

Par sécurité, pendant cette période, il faut désactiver le PPU, puis faire les modifications nécessaires et enfin réactiver le PPU. Il y a donc un temps assez bref pendant lequel on peut faire des modifications à la mémoire du PPU.

Le squelette de projet que j'ai choisi utilise une pratique assez courante : construire une liste de commandes à envoyer au PPU. Lorsque la synchronisation verticale se produit, la liste préparée est traitée. Cette liste est limitée en taille, puisque le temps d'accès est limité.

Tout cela pour dire que pour afficher un caractère à l'écran, il va falloir envoyer plusieurs commandes au PPU.

Tout d'abord positionner le registre d'adresse de la prochaine écriture en mémoire PPU.
Puis envoyer le caractère à écrire.

Le mot Forth EMIT, qui affiche un caractère, devra donc faire tout cela à chaque fois, ce qui n'est pas très efficace. Mais c'est le plus simple à implémenter. Il est possible d'utiliser une incrémentation automatique de l'adresse d'écriture par le PPU, et celle-ci pourra être utilisée pour optimiser TYPE ou ." plus tard. Mais cela ne sera pas si simple, car le buffer de commandes est limité en taille et il faudra traiter la césure de chaînes trop longues.

À voir. Le principe du projet est d'avoir un équivalent Forth au Family BASIC, pas un système optimisé.

EMIT va donc ressembler à ceci :

récupération des coordonnées du curseur,
calcul de l'adresse PPU en fonction des coordonnées,
positionnement du registre d'adresse PPU (dans la liste de commandes),
écriture du caractère à l'adresse PPU (dans la liste de commandes),
mise à jour des coordonnées du curseur,
NEXT.

Il faut donc maintenir les coordonnées du curseur quelque part, et cela signifie l'utilisation de variables.

Les variables

Les variables en Forth sont, comme tout le reste, des mots dans le dictionnaire. Lorsqu'une variable est exécutée, elle place l'adresse réservée pour son contenu sur la pile des paramètres, et c'est tout.

Pour cela, un mot de type variable a pour CFA une routine qui place l'adresse PFA sur la pile des paramètres. Le Parameter Field, lui, est un espace mémoire réservé de deux octets qui contiendra la valeur de la variable.

Avec la totalité d'un mot de type variable, cela fait 2 octets pour la valeur, 2 octets pour le CFA, 2 octets pour le chaînage, 1 octet pour la longueur du nom, et le nom lui-même. Soit un minimum de 8 octets par variable pour une variable à 16 bits. Cela peut sembler cher payer, mais ce système est autonome.

Cela permet d'écrire, si la variable s'appelle CURSOR_X par exemple :

    CURSOR_X @  \ lit la valeur de la variable
    CURSOR_X !  \ écrit la valeur dans la variable

Le mot @ (fetch) lit une valeur à l'adresse située au sommet de la pile des paramètres et place cette valeur sur la pile.

Le mot ! (store) prend une adresse et une valeur sur la pile des paramètres, et écrit la valeur à l'adresse.

Il nous faut donc écrire :

le code assembleur pointé par un mot de type variable (que j'appellerai DOVAR)
le mot @
le mot !
... et donc s'occuper du fonctionnement de la pile des paramètres.

Je n'implémenterai pas encore le mot VARIABLE qui permet de définir une nouvelle variable depuis Forth. Je vais écrire les variables directement en assembleur pour le moment.

Pas si vite !

Cela fait déjà beaucoup de choses à faire avant d'implémenter EMIT. J'ai besoin d'une étape intermédiaire pour m'assurer que tout fonctionne correctement. Pour cela, je vais réécrire le mot de test en Forth.

Pour rappel, voici à quoi ressemble le mot de test en assembleur :

   ; A test word that writes $42 to $7FF
    DEFINE_CODE_WORD TEST, BRANCH, 0
    lda #$42
    sta $7FF
    END_TO_NEXT

En Forth, cela s'écrit simplement (pourvu que la base des nombres soit en hexadécimal) :

    : TEST
        42 7FF C! ;

Mais comme c'est le système de pile de paramètres et de variables que je veux tester, je vais plutôt écrire :

    : TEST
        TEST_VALUE @    \ lit la valeur de la variable TEST_VALUE
        TEST_ADDR @     \ lit la valeur de la variable TEST_ADDR
        !               \ écrit cette valeur de TEST_VALUE à l'adresse TEST_ADDR
        ;

Retour à la pile des paramètres

La pile des paramètres est une zone de mémoire en RAM, de 256 octets. Cela permet de l'indexer facilement en mode indirect avec le registre Y. Pour ne pas monopoliser le registre, je garde une variable d'un octet en Page Zéro. Cela nécessite cependant d'aller chercher et modifier la variable à chaque opération de pile.

Ainsi, le haut de la pile sera à tout moment :

(ParamStack),y pour l'octet de poids faible avec y = REG_PSP
(ParamStack),y pour l'octet de poids fort avec y = REG_PSP + 1

La pile grandit vers les adresses mémoire basses, avec l'index initialisé à 0 et décrémenté lors des PUSH, incrémenté lors des POP. Le premier emplacement de valeur 16 bits sera donc aux adresses indexées par $FE et $FF.

Je modifie un peu mes macros de définition de mots car FETCH et STORE doivent s'encoder en tant que mots avec les symboles @ et !, mais la génération des labels pour l'assembleur ne peut pas utiliser ces symboles. J'ajoute donc la possibilité de différencier le nom du mot et le symbole utilisé dans le dictionnaire.

FETCH fait les actions suivantes :

récupérer l'adresse au sommet de la pile des paramètres
la placer dans un registre d'adresse Page Zero temporaire
lire la valeur à cette adresse (2 octets)
placer cette valeur sur la pile des paramètres

STORE fait les actions suivantes :

récupérer l'adresse au sommet de la pile des paramètres
la placer dans un registre d'adresse Page Zero temporaire
récupérer la valeur suivante sur la pile des paramètres (2 octets)
écrire cette valeur à l'adresse dans le registre temporaire

Le mot de test en Forth

Le mot final de test en Forth devient, accompagné du code des deux variables :

    ; TEST_VALUE, a variable to hold a test value
    DEFINE_VARIABLE TEST_VALUE, STORE
    .word $4200

    ; TEST_ADDR, a variable to hold a test address
    DEFINE_VARIABLE TEST_ADDR, TEST_VALUE
    .word $07FE

    ; A test word that writes $4242 to $7FE (16 bits)
    DEFINE_FORTH_WORD NEW_TEST, TEST_ADDR, 0
    .word TEST_VALUE_word_cfa
    .word FETCH_word_cfa
    .word TEST_ADDR_word_cfa
    .word FETCH_word_cfa
    .word STORE_word_cfa
    .word DO_SEMI_word_cfa

C'est... beaucoup plus long que les deux instructions d'assembleur initiales. Cela ne fait pas non plus exactement la même chose, car j'ai implémenté tous ces mots pour des valeurs de 16 bits. Plutôt que d'écrire $42 à l'adresse $7FF, j'écris $4200 à l'adresse $7FE (avec l'endianness, cela écrit bien $42 à $7FF). Cela fait passer le test et même si c'est un peu différent, cela teste bien le fonctionnement de la pile des paramètres et des variables.

Conclusion

Pas de lecture d'article Moving Forth aujourd'hui, il y a déjà assez de matière ici. J'ai une pile de paramètres fonctionnelle (mais non protégée), un système de variables, deux instructions élémentaires de manipulation de la pile.

Je m'approche du nécessaire pour l'implémentation de EMIT, qui sera très probablement le sujet du prochain article.

Forth sur 6502, épisode 6

2025-12-30T00:00:00+01:00

Des mots complets

Depuis le début de l'implémentation de ce Forth sur 6502, j'ai parlé de « pseudo mots ». Ces mots ont un CFA (Code Field Address) et un PFA (Parameter Field Address), mais pas d'entête de mot ni de principe de dictionnaire.

Or pour qu'un mot soit complet en Forth, il faut ces deux autres concepts. Dans cette implémentation je vais utiliser deux autres sections : le NFA (Name Field Address) et le LFA (Link Field Address).

Ce qui donne la structure complète suivante :

NFA : entête du mot, dont le premier octet est la longueur du nom du mot, suivi du nom lui-même. Seuls les 5 bits de poids faible sont utilisés pour la longueur (ce qui limite la longueur des noms à 31 caractères). Le bit de poids fort est toujours à 1, les deux autres bits seront vus plus tard. De plus, le dernier octet du nom a son bit de poids fort à 1 pour indiquer la fin du nom.
LFA : adresse du mot précédent dans la liste chaînée des mots. Tous les mots disponibles dans ce Forth forment une liste chaînée, chaque mot pointant vers le mot défini avant lui. Le dernier mot défini pointe vers l'adresse 0 pour indiquer la fin de chaîne.
CFA : adresse du code machine qui sera exécuté lorsque le mot sera appelé.
PFA : paramètres du mot, s'il en a.

Précision : cette implémentation d'un mot complet est celle que l'on trouve dans des Forth historiques 8 bits. Mais elle n'est pas obligatoire, il peut y avoir des variantes. Rien n'empêche d'inverser l'ordre du NFA et du LFA. Ou de terminer le nom par un octet nul plutôt que par un marqueur dans le bit de poids fort.

En regardant des normes plus récentes (section 3.3), on voit qu'il existe un « name space » un « code space » et un « parameter space », et que les mots sont organisés dans un « dictionnaire », cependant, il est laissé à l'implémentation de faire les choix de représentation.

Implémentation

Pour implémenter ces mots complets, j'ajoute des macros pour faciliter l'écriture (et surtout la réécriture en cas de changement d'idée).

Mon mot de test, qui permet de valider que le programme exécute bien la boucle, était comme ceci :

test_word_cfa:
    .word test_word_pfa
test_word_pfa:
    lda #$42
    sta $7FF
    jmp next

Il devient maintenant :

    DEFINE_CODE_WORD TEST, BRANCH, 0
    lda #$42
    sta $7FF
    END_TO_NEXT

La macro DEFINE_CODE_WORD prend trois paramètres : le nom du mot, le mot précédent (pour le chaînage) et un drapeau pour les mots immédiats, que l'on n'a pas encore abordé. La macro END_TO_NEXT termine le mot en appelant NEXT.

Ainsi, pour le mots Forth définis par du code assembleur, il ne reste apparent que le code lui-même, encadré par les macros.

J'ai une seconde macro qui permet de définir des mots exécutés par « DOCOL », c'est-à-dire des mots écrits comme une série de pointeurs vers d'autres mots.

La boucle principale devient :

    DEFINE_FORTH_WORD MAIN_LOOP, TEST, 0
    .word READ_JOY_SAFE_word_cfa
    .word TEST_word_cfa
    .word POST_LOGIC_word_cfa
    .word DO_SEMI_word_cfa

Moving Forth, épisode 5

Avançons dans la lecture de la série d'articles Moving Forth avec la cinquième partie.

L'auteur présente le code source d'un ANSI Forth, CamelForth, pour les processeurs Z80, 8051 et 6809. Passons. Ce qui m'intéresse le plus, c'est la notion de « kernel ». À partir de quel ensembles de mots de base écrits peut-on construire un Forth complet ? Et surtout, combien de mots doit-on implémenter en assembleur avant de construire le reste par dessus ?

C'est une question que je me posais dès le premier article dans la conclusion. Je me disais que pour faciliter les choix d'implémentation, il serait intéressant d'avoir un minimum de mots implémentés en assembleur.

Cependant, ce dont nous prévient l'article, c'est que même s'il est théoriquement possible de se limiter à 13 primitives, dans la pratique, faire ce choix entraînera un Forth peu véloce.

L'auteur propose une liste de critères pour décider si un mot doit être implémenté en assembleur ou en Forth :

la base arithmétique, logique et mémoire le sont. Cela semble évident.
si le mot est difficile à écrire en Forth (ou de manière trop complexe), alors il devrait être en assembleur.
si le mot est très souvent utilisé, il devrait être en assembleur.
si le code assembleur est plus compact (ou vraiment plus efficace) que le code Forth, il devrait être en assembleur.
si la logique du mot est complexe, il devrait être en Forth.

Avec ces critères, l'auteur arrive à une liste de 70 primitives dans son implémentation. Cela donne une idée d'échelle.

Il décrit enfin une boucle de développement pour l'implémentation d'un Forth. Je suis déjà parti sur la mienne, mais cela est intéressant à regarder.

L'auteur implémente toute sa base en premier, puis assemble et corrige les erreurs. Puis écrit du code qui affiche un premier caractère une fois l'initialisation complète. Puis il écrit un mot entièrement en Forth et vérifie le fonctionnement de NEXT, DOCOL et ;S/EXIT.

Enfin, il implémente les branchements et DODOES globalement en même temps qu'avoir un interpréteur interactif rudimentaire afin de tester ses mots.

Globalement, c'est similaire à ce que je suis en train de faire. J'ai écrit un octet en mémoire plutôt qu'un caractère à l'écran, car c'était plus simple. Mais l'idée est la même.

De plus, je teste de manière automatique, et je compte bien continuer. Même si on va voir que ça va se compliquer un peu.

Conclusion et prochain épisode

J'ai à présent une liste de mots de deux types différents formant un dictionnaire. Ce que je voudrais maintenant est afficher un message à l'écran. J'ai déplacé et changé le message écrit par le squelette de projet pour me donner un modèle, et je veux à présent faire la même chose, mais dans la boucle Forth.

J'ai commencé quelques essais et des questions se posent sur la granularité des mots. Je vais devoir implémenter le mot EMIT. Celui-ci aura besoin de conserver une position à l'écran. Pour cela, je vais avoir besoin de variables.

Pour transformer ces variables en adresse mémoire, je peux soit tout écrire en assembleur (ce que je fais probablement faire dans un premier temps), mais aussi en profiter pour implémenter quelques mots de traitement arithmétique.

Bref, à la prochaine !

Forth sur 6502, épisode 5

2025-12-22T00:00:00+01:00

La boucle, pour de vrai !

Jusqu'à présent, la boucle principale du programme en Forth était basée sur un hack. Ce hack consistait à réinitialiser l'IP (Instruction Pointer) à la fin du traitement. C'est un peu comme si à chaque fois qu'on avait fini le traitement, on relançait le programme depuis le début.

Il est temps d'implémenter un nouveau mot Forth : BRANCH. Ce mot, suivi dans le PFA par un offset, opère un saut inconditionnel en additionnant cet offset à l'IP courant. En choisissant un offset négatif, l'exécution va revenir en arrière et donc créer une boucle infinie.

Le pseudo code est le suivant :

    (IP) -> X       lit l'offset pointé par l'Instruction Pointer
                    L'IP ayant été positionné sur l'emplacement après le mot BRANCH
                    par NEXT.
    IP + X -> IP    ajoute l'offset à l'IP
    NEXT            appelle NEXT pour continuer l'exécution

Du fait du traitement de mots en 16 bits, cela donne un code assez long en 6502. Mais je crois que ce sera le cas pour toute cette aventure. Le 6502 est un processeur foncièrement 8 bits. Encore une fois, modulo ma méconnaissance de ce CPU. Je reviendrai peut-être dessus plus tard en le maîtrisant mieux. Ou on me signalera des optimisations.

Avec le mot BRANCH implémenté, la liste de mots de ma boucle principale devient :

loop_words:
    .word main_loop_cfa
    .word branch_cfa
    .word $fffc ; -4 in little-endian to create an infinite loop

Plus besoin de reset_code dont je retire le label et le pseudo PFA. Le hack est enlevé et j'ai enfin ma boucle complète en Forth. Puisque loop_words est maintenant un (pseudo-)mot Forth complet, je lui ajoute un CFA et le bootstrap change en initialisant le registre W avec ce CFA et en appelant DOCOL.

C'est un peu plus élégant je trouve... mais cela fait perdre une place dans la pile de retour, puisque la première valeur de IP (même pas initialisée) y sera poussée par DOCOL. À voir lequel du bootstrap par IP + NEXT ou par W + DOCOL est le plus intéressant.

Moving Forth, épisode 4

C'est un tout petit article que cette quatrième partie de la série Moving Forth, tout comme ma partie d'implémentation ci-dessus.

Cette partie pose la question : comment est-ce qu'on démarre l'implémentation d'un Forth ? Cool ! Mais j'ai déjà commencé. En vrai, j'ai déjà lu plusieurs fois cette série d'articles, il n'y a donc pas de surprise et cette partie entre autres m'a guidé dans mes choix initiaux.

L'article commence par mettre sur la table deux choix d'implémentation : une implémentation en assembleur en direct sur la machine hôte, ou une implémentation par méta-compilateur, c'est-à-dire un autre Forth qui génère le code machine du Forth cible. Pas de surprise si vous avez suivi jusque-là, c'est la version assembleur que j'ai choisie. L'auteur lui, après avoir indiqué que la voie du méta-compilateur est plus complexe, préfère néanmoins celle-ci, plus portable et plus moderne (même pour 1993).

J'avais l'idée éventuellement d'avoir aussi un méta-compilateur avec lequel des programmes pourraient être écrits en Forth pour la machine cible, ici la Famicom. Mais je ne suis pas certain de l'intérêt. Ma démarche est celle d'offrir à la Famicom un parallèle Forth au Family BASIC, avec un interpréteur interactif sur la machine et son clavier. Pour créer des jeux modernes sur Famicom, il y a déjà des outils je pense plus adaptés.

Donc : Forth en assembleur ! Tout du moins son noyau.

Même si un méta-compilateur serait intéressant pour développer les mots au-delà du noyau... mmmhhhh... Bon on verra.

L'article continue en parlant de Forth en C comme d'une question qui ne peut pas ne pas se poser. Peut-être parce qu'en 1993, le C est le langage sérieux pour le développement système ? C'est un chemin que j'avais pris il y a quelques années quand je m'étais intéressé au Forth. Mais rapidement, j'étais arrivé à la conclusion que ce sont deux langages aux philosophies (et modèles) très différents, et l'implémentation faisait un peu gymnastique de contorsion.

Au final, pourquoi pas, en implémentant une machine virtuelle Forth en C, avec quelques commandes de base du noyau. Ça fait partie des choses sur lesquelles je voudrais revenir maintenant que je maîtrise mieux le Forth. Vous le sentez venir le rabbit hole ? Allez, sur la pile !

Prochain épisode

Un article très court donc. Le suivant sera plus intéressant pour la suite de l'implémentation car il traitera de ce qui forme un noyau Forth : les mots de base, les primitives, sur lequel le reste est construit.

Et je pense qu'il sera temps de faire un détour vers le passage à des mots Forth complets, avec leur entête et leur chaînage.

Forth sur 6502, épisode 4

2025-12-21T00:00:00+01:00

Nous y voilà ! Après avoir mis en place un framework de tests dans l'article précédent, il est temps d'implémenter le mot NEXT.

Un petit rappel du premier article de Moving Forth : NEXT est le mot qui permet de faire avancer l'exécution d'une séquence de pointeurs vers des mots Forth. Son pseudo-code (en modèle Indirect Threaded Code) est le suivant :

    (IP) -> W   récupère la mémoire pointée par IP dans le registre "W"
                -> W contient maintenant l'adresse du Code Field
    IP+2 -> IP  avance IP, le compteur de programme
    (W) ->  X   récupère la mémoire pointée par W dans le registre "X"
                -> X contient maintenant l'adresse du code d'exécution
    JP (X)      saute à l'adresse présente dans le registre X

Implémentation

En 6502, le code est un peu long, car l'adressage indirect nécessite de passer par des registres en page zéro. Et les manipuler demande plusieurs instructions. Je ne suis pas très versé en 6502, on verra s'il y a moyen de faire mieux plus tard.

Dans certains Forth, NEXT est tellement court qu'il se pose la question d'en faire une macro. Ici, la réponse est assez simple : c'est non. Le code est assez long, et donc NEXT sera appelé avec un JMP à son adresse.

Très bien, j'ai donc NEXT. Il me faut aussi une liste de mots à appeler. Le but étant d'implémenter l'écriture d'une valeur en mémoire, je vais créer un pseudo-mot TEST-WORD. Puis comme il faut faire cela en boucle, un second mot qui réinitialisera l'IP (Instruction Pointer) au début de la séquence, que je vais appeler RESET-CODE.

Cela donne quelque chose comme ceci :

loop_words:
    .word test_word_cfa
    .word reset_code_cfa

Les pointeurs sont vers les CFA (Code Field Address) des mots. Pour rappel, le CFA est l'adresse où se trouve le code machine qui sera en charge d'exécuter le mot suivant (oui, c'est bien du Indirect Threaded Code, c'est indirect).

Par exemple, pour TEST-WORD, le CFA est l'adresse de la première instruction assembleur qui compose le mot :

test_word_cfa:
    .word test_word_pfa
test_word_pfa:
    lda #$42
    sta $7FF
    jmp next

NEXT va lire le CFA, puis sauter à l'adresse indiquée, qui est test_word_pfa. Et donc exécuter le code qui place la valeur $42 à l'adresse $07FF, avant de redonner la main à NEXT.

J'ai dit plus haut que c'était un pseudo-mot. En effet, le CFA et le PFA ne sont qu'une partie de la définition d'un mot complet en Forth. Mais comme cette partie n'a pas été abordée pour le moment, et qu'elle n'est pas nécessaire pour faire fonctionner NEXT, je laisse ceci de côté.

Reste à bootstrapper l'IP pour qu'il pointe sur loop_words au démarrage du programme. J'ajoute donc un petit code d'initialisation qui... sera aussi le code du mot RESET-CODE :

boot_forth:

    ; Set the Instruction Pointer to the start of temporary Forth code
reset_code:
    lda #<loop_words
    sta REG_IP
    lda #>loop_words
    sta REG_IP + 1

    ; Jump to the Forth NEXT loop
    jmp next

Plus tard, il faudra aussi initialiser d'autres registres dans ce code. Mais pour le moment, ça suffit.

J'enlève l'ancien code d'écriture en mémoire de la boucle principale, je remplace par un appel à boot_forth, et voilà ! Les tests passent... Mais le code d'affichage n'affiche plus le HELLO FAMICOM du squelette. C'est normal puisque la boucle principale Forth n'appelle pas le code de synchro et d'affichage.

La boucle complète

J'ai tous les éléments pour remettre en place la boucle principale. Il suffit de créer deux mots (ou plutôt pseudo-mots) qui feront juste un appel aux deux routines présentes initialement dans la boucle principale.

read_joy_safe_word_cfa:
    .word read_joy_safe_word_pfa
read_joy_safe_word_pfa:
    jsr read_joy_safe
    jmp next

post_logic_word_cfa:
    .word post_logic_word_pfa
post_logic_word_pfa:
    jsr post_logic
    jmp next

Et de modifier la liste des mots à appeler dans loop_words :

loop_words:
    .word read_joy_safe_word_cfa
    .word test_word_cfa
    .word post_logic_word_cfa
    .word reset_code_cfa

Et l'affichage remarche. Avec beaucoup plus d'indirections et donc plus lent, c'est vrai. Je verrai plus tard comment regrouper les appels. Ou comment modifier les sous-routines pour les implémenter directement comme des mots.

En tout cas pour le moment, j'ai retrouvé le comportement initial. Parfait.

DOCOL et ;S

Dans la partie 2 de cette série, j'avais listé les mots DOCOL et ;S comme prioritaires à implémenter. En effet, ces mots permettent d'appeler des mots définis par d'autres mots. C'est exactement ce qui est fait avec loop_words. Sauf que cela n'est pas un vrai mot. Il n'a même pas de CFA. Cette liste est démarrée manuellement par le code d'initialisation, que je rappelle en boucle.

Mais cette boucle est aussi un petit hack avec le RESET-CODE. Je ne peux pas l'utiliser proprement pour démontrer DOCOL et ;S. Je vais donc créer un autre pseudo-mot

main_loop_cfa:
    .word docol
main_loop_pfa:
    .word read_joy_safe_word_cfa
    .word test_word_cfa
    .word post_logic_word_cfa
    .word do_semi_cfa

docol étant le code machine de DOCOL et do_semi_cfa le pointeur sur le CFA de ;S.

La boucle « hack » se retrouve donc remplacée par :

loop_words:
    .word main_loop_cfa
    .word reset_code

Pseudo-code pour les deux mots

Le pseudo-code de DOCOL est le suivant :

   PUSH IP      pousse IP sur la pile de retour
   W+2 -> IP    puisque W pointait sur le Code Field,
                W+2 est l'adresse du Parameter Field.
                Le Parameter Field contient la liste des
                adresses des mots à exécuter. IP pointe
                donc sur cette liste.
   JUMP NEXT    saute à NEXT pour continuer l'exécution

Le pseudo-code de ;S est le suivant :

   POP IP       récupère l'adresse de retour depuis
                la pile de retour et la place dans IP
   JUMP NEXT    saute à NEXT pour continuer l'exécution

Et ça fonctionne

À nouveau, les tests passent et l'affichage fonctionne. Les trois premiers mots Forth sont donc implémentés : NEXT, DOCOL et ;S.

Moving Forth, article 3

Jetons à présent un œil sur le troisième article de la série Moving Forth. Son titre est « Demystifying DOES> », mais il en profite surtout pour décortiquer le fonctionnement des CFA et PFA.

On passe sur l'introduction, qui revient sur des erreurs dans les parties précédentes pour arriver à l'explication du Code Field.

Le Code Field, c'est le cœur du fonctionnement d'un mot en Forth. C'est un indicateur de la nature du mot, de la façon dont il va se comporter, être exécuté. Le Code Field indique quoi faire avec les paramètres du mot, les paramètres étant situés dans le Parameter Field, qui suit le Code Field.

Ainsi, on peut définir différents fonctionnements :

un mot qui exécute les paramètres comme du code machine,
un mot qui traite les paramètres comme des référence à d'autres mots,
un mot qui traite les paramètres comme un emplacement mémoire réservé pour une variable,
etc...

En quelque sorte, le Code Field représente une routine avec un paramètre implicite : le Parameter Field.

L'article fait un parallèle avec la programmation objet, où le Code Field serait la méthode unique d'une classe, et le Parameter Field l'instance de cette classe pour chaque mot utilisant ce Code Field. Je ne suis pas certain que ce parallèle aide beaucoup... mais pourquoi pas.

Code Field et Indirect Threaded Code

Dans le modèle ITC (Indirect Threaded Code), le Code Field est une adresse qui pointe vers un code machine chargé d'interpréter le contenu du Parameter Field. On a vu deux cas pour le moment :

un Code Field qui pointe vers DOCOL entraîne l'appel successif de tous les mots dont les listés dans le PFA. Ces mots sont eux-mêmes représentés par leur CFA.
un Code Field qui pointe vers directement sur l'adresse du Parameter Field. Dans ce cas, le code machine est directement dans le PFA.

Il existe différents Code Field standards en Forth, mais rien n'empêche l'utilisateur d'en définir de nouveaux. Et c'est exactement ce que fait le mot DOES> mentionné par le titre. Cependant, son fonctionnement nécessitera probablement un article à lui seul. Retenez juste que DOES> permet de définir une nouvelle classe de mots partageant un même Code Field personnalisé.

L'article mentionne aussi les mots CREATE ou encore ;CODE, qui respectivement permettent de définir un nouveau mot et de définir un mot dont le code est écrit en assembleur. Là encore, ce sont des sujets pour plus tard lorsqu'il sera question de définir des mots par programmation.

Pour le moment, je n'ai toujours que des pseudo-mots, et ils sont tous définis directement dans le code assembleur.

L'article est plus long car il aborde ces sujets dans les différents modèles d'exécution de Forth, ainsi que les mots CONSTANT et VARIABLE, qui sont des mots de constructions avec un Code Field particulier, que nous verrons plus tard.

La suite

J'ai à présent les premiers pseudo-mots pour mon Forth, mais il m'en manque un pour créer la boucle en entier. En effet, pour le moment je réinitialise l'interpréteur pour relancer la boucle. Ce n'est pas une vraie boucle Forth. Je pense que ma prochaine étape sera donc de créer le mot BRANCH, qui modifie le registre IP.

Forth sur 6502, épisode 3

2025-12-20T00:00:00+01:00

Des tests

Depuis le dernier article, je me suis surtout concentré sur la mise en place d'un framework de tests, ainsi que sur une réflexion de « comment commencer » ?

La lecture de l'article 2 de Moving Forth m'a donné une liste de mots à implémenter en priorité : NEXT, DOCOL et ;S. Cela afin d’arriver rapidement sur une boucle écrite en Forth. J'y reviendrai plus loin dans l'article.

Côté tests, ça a été une aventure en plusieurs étapes. Dans l'idée d'augmenter le nombre de tests, je voulais m'appuyer sur un framework de tests LUA tout fait. J'en ai trouvé un, luaunit qui m'a semblé tout à fait répondre à mes attentes. Pour l'utiliser, je dois utiliser un require("luaunit") dans mon script de tests. Et là ont commencé les ennuis. Tout d'abord, require() n'est pas permis par défaut dans Mesen2, il faut aller permettre les fonction E/S dans les paramètres.

Malgré cela, le script ne semble pas être trouvé, alors qu'il est bien dans un répertoire de recherche (vérifié avec le contenu de la variable package.path). En tout cas pas en mode --testrunner, car en debug depuis l'interface graphique, ça fonctionne ! Après étude des sources de Mesen2, je vois le soucis (qui était bien affiché dans mes logs, mais assez subtil pour que je passe à côté) : le mode testrunner et le mode UI résolvent différemment le chemin des scripts, à un séparateur de chemin près.

La correction est simple, je la fais et je suis prêt à faire un merge request... pour m'apercevoir que le dépôt est fermé aux contributions. Après enquête, il semblerait que le développeur a disparu de la circulation en juillet 2025. Puisque le dépôt est fermé, j'imagine que c'est un retrait volontaire et non un événement malheureux. Je l'espère. On me dit qu'il aurait déjà fait ça dans le passé lorsqu'il avait eu besoin de se concentrer.

En attendant, j'ai donc créé ma version de Mesen2 avec cette correction (et une autre trouvée dans un autre fork qui me semblait intéressante). Merci l'open source.

Vient ensuite mon deuxième soucis : luaunit ne va pas convenir. Comme tous (?) les frameworks de tests, le framework gère des contextes cloisonnés, s'occupe de lancer les tests, de capturer les erreurs, etc. Bref, il a les commandes. Sauf que Mesen2 requiert que certaines fonctions de contrôle de l'émulateur soient appelées depuis des callbacks. Autrement dit, Mesen2 veut aussi avoir le contrôle.

Après avoir retourné le problème quelques temps, je me suis dit que finalement, j'allais faire un petit framework sur mesure adapté à Mesen2. Il aura certainement moins de fonctionnalités qu'une solution complète, mais tant pis. J'ai donc écrit un framework basé sur une machine à états qui fait avancer les tests au fur et à mesure que l'émulateur lance des callbacks. Ça fonctionne, mais c'est un peu verbeux à l'écriture pour le moment. J'espère pouvoir dégager quelques fonctions utilitaires pour simplifier l'écriture des tests par la suite, si besoin.

Ah, et j'englobe l'appel des tests dans un xpcall(), une fonction bien pratique en LUA qui permet de capturer les erreurs, et donc d'arrêter l'émulateur proprement en cas de problème avec affichage du message d'erreur.

Mes trois tests

Pour le moment, j'ai trois tests :

Le premier test vérifie que les symboles des registres Forth sont bien présents dans les symboles. Il y a peu de chance que ça ne passe pas, mais c'est ce qu'on se dit avant que ça ne passe pas...
Le deuxième test vérifie que le programme arrive jusqu'à la boucle principale. Un smoke test de base.
Le troisième test vérifie qu'une adresse mémoire particulière est modifiée. C'est actuellement l'action qui est faite dans la boucle principale.

En fait, il y a pas mal d'autres choses qui sont faites dans la boucle principale par le squelette de projet que j'utilise. Je verrai si j'ai besoin à un moment de tester cette partie, mais pour le moment, dans une logique TDD, tant que je n'y touche pas, je ne teste pas.

La suite

Pas de lecture de la partie 3 de Moving Forth pour le moment. En effet, celle-ci se concentre sur le CFA (Code Field) et le PFA (Parameter Field), puis enchaîne sur les mots de construction. Je n'en suis pas encore là. Je reprendrai les résumés lorsque j'aurai une boucle Forth fonctionnelle.

Car c'est la prochaine étape : pour le moment, le code contient une boucle assembleur qui :

lit les entrées des pads
écrit une valeur à une adresse mémoire fixe (pour le test)
attend la synchronisation verticale
exécute une file d'instruction PPU (pour l'affichage)
boucle

Ma prochaine étape est de remplacer cette boucle par la même chose en Forth. Pour cela, je dois implémenter au moins le mot NEXT qui appellera ce même code suivant le schéma Forth. Autrement dit, ces routines devront se terminer par un appel à NEXT pour continuer l'exécution, plutôt que de se terminer par un RTS (return from subroutine).

Point d'étape

J'ai donc à présent un environnement d'assemblage et de tests, une boucle minimale. Le prochain article sera écrit lorsque j'aurai a minima un NEXT fonctionnel.

Et pour terminer, voici la sortie des tests actuels :

mesen --testrunner out/nes_template.nes start_tests.lua
-- STARTING TESTS --
[1/3] Running: Forth symbols exist
  ✓ PASSED
[2/3] Running: Program boots and reaches main loop
  ✓ PASSED
[3/3] Running: Verify memory change at specific address
  ✓ PASSED
============================================================
TEST REPORT
============================================================
Total: 3 | Passed: 3 | Failed: 0
============================================================

Forth sur 6502, épisode 2

2025-12-12T00:00:00+01:00

Le projet minimal

Avant de passer à la lecture de l'article 2 de la série Moving Forth, je veux mettre en place un projet « minimal ». Plus exactement, c'est initialement ce que je voulais faire, avec un petit code source pour Famicom qui affiche un texte, un Makefile et bien entendu, un framework de tests.

Mais les notes que j'avais prises sur la Famicom remontaient à un petit moment, et il y a quelques trucs à initialiser avant d'afficher un caractère à l'écran. J'ai donc cherché un squelette de projet déjà fait. Sur une machine populaire, ça doit bien exister.

Mon choix s'est porté sur Nes Template de Mike Moffitt. Le squelette n'est pas minimaliste, mais a une bonne base, avec un système de configuration flexible pour la ROM destination, et assez de quoi écrire un message à l'écran, ainsi que manipuler des banques de mémoire. C'est bien écrit, bien commenté. Ça me convient bien.

J'y ai ajouté un script Lua pour automatiser des tests en utilisant l'émulateur Mesen2. Le script place une callback à une adresse mémoire spécifique et s'y arrête lorsque cette adresse est atteinte par le registre PC.

Et voilà ce que cela donne :

mesen --testrunner out/nes_template.nes tests/tests.lua
-- STARTING TESTS --
Setting callback at address: 0xC0D2
Memory position reached: 0xC0D2

Le mapping mémoire

À la fin de l'article précédent, j'avais évoqué le mapping mémoire afin de vérifier les contraintes de la Famicom.

Voici un mapping rapide (que l'ont peut retrouver plus en détail sur Nesdev) :

$0000-$00FF : Page zéro     (256 octets)
$0100-$01FF : Pile          (256 octets)
$0200-$07FF : RAM interne   (1536 octets)

$2000-$2007 : Registres PPU (le processeur graphique)
$4000-$4017 : Registres APU (le processeur audio) et E/S

$6000-$7FFF : RAM sur cartouche     (si présente)
$8000-$FFFF : PRG ROM sur cartouche (si présente)

Les deux dernières zones sont dépendantes de la cartouche et du « mapper » utilisé. Dans la configuration par défaut du projet template que j'utilise, il n'y a pas de RAM configurée sur la cartouche. Il y a par contre 16 banques de 16 Ko de PRG ROM (de la ROM accessible par le CPU), mappée de $8000 à $FFFF. Une banque de 16 Ko est fixe (la dernière, de $C000 à $FFFF) et l'une des autres banques peut être mappée de $8000 à $BFFF. Certaines de ces banques sont utilisées pour stocker les ressources graphiques, qui sont ensuite envoyées à de la mémoire vidéo présente sur la cartouche.

Il faudra très certainement ajouter de la RAM sur cartouche pour faire quelque chose d'intéressant avec Forth. Je verrai à la fin du développement quel mémoire serait nécessaire pour une production sur cartouche. De toute façon, pendant le développement, j'utiliserai un émulateur la plupart du temps et une cartouche de développement pour vérifier sur vrai matériel.

Le projet template permet de réserver assez facilement des pointeurs dans la page zéro. Il définit d'ailleurs déjà un certain nombre de variables temporaires. Je vais tout simplement utiliser ce système pour déclarer les registres Forth.

Pour la pile des paramètres, je vais m'inspirer de ce que le template utilise pour sa queue de commandes graphiques : réservation d'un espace mémoire non initialisé dans la RAM interne et définition d'un pointeur associé dans la page zéro.

Moving Forth, article 2

Dans le deuxième article de la série Moving Forth, l'auteur commence par lister les mots essentiels au Forth. Les mots sur lesquels le reste repose, et qui nécessitent d'être efficace.

Les mots

En premier, il y a les mots qui forment l'interpréteur lui-même :

NEXT
DOCOL (aussi appelé ENTER dans l'article)
;S (aussi appelé EXIT dans l'article)

NEXT est le cœur de l'interpréteur, le mot qui fait avancer toute la machinerie. Il récupère l'adresse du mot à exécuter depuis l'instruction pointer (IP), puis incrémente l'IP pour le mot suivant. Ensuite, il récupère l'adresse de la routine associée au mot (dans le cas de l'Indirect Threaded Code, choisi ici, c'est une adresse mémoire qui pointe vers l'adresse de la routine) et saute à cette adresse pour exécuter le mot. Il vaut mieux lire cette ligne lentement...

C'est évidemment le premier mot à implémenter. Et il est d'ailleurs possible de faire tourner un petit programme avec seulement ce mot. NEXT ne fait qu'appeler une liste de routines. Et ces routines appellent à leur tour NEXT pour continuer l'exécution.

DOCOL est le mot qui gère l'appel d'un mot défini par d'autres mots. Il sauvegarde l'IP actuel sur la pile de retour, puis positionne l'IP à l'adresse du code du mot appelé. Ensuite, il saute à NEXT pour continuer l'exécution.

;S est le mot qui gère le retour d'un mot défini par d'autres mots. Il récupère l'adresse de retour depuis la pile de retour et la place dans l'IP, puis saute à NEXT pour continuer l'exécution.

Ensuite, l'article liste les deux mots de constructions que sont DOVAR et DOCON, respectivement pour définir des variables et des constantes. Ainsi que LIT, pour charger une valeur littérale sur la pile de paramètres.

Il liste aussi DODOES que je laisserai de côté dans un premier temps. C'est un mot un peu plus complexe qui permet l'extension des mots définis par BUILD/DOES>>.

Et bien entendu, les mots standards :

@ (fetch)
! (store)
+ (addition)
SWAP
OVER
ROT
0=
+!

Les études de cas

L'article aborde ensuite plusieurs études de cas avec différents processeurs. Il ne cite pas le 6502, je ne m'y attarde donc pas.

Conclusion

L'étape suivante sera l'implémentation de au moins NEXT, DOCOL et ;S, afin de pouvoir exécuter un petit programme composé de routines en assembleur. Comme je compte tester le programme, il me faudra aussi un framework de test un peu plus sérieux que le petit script Lua que j'ai écrit pour l'instant.

En attendant, j'ai placé les registres Forth dans la page zéro et réservé un espace mémoire pour la pile des paramètres. Le test donne à présent :

mesen --testrunner out/nes_template.nes tests/tests.lua
-- STARTING TESTS --
Found symbol REG_W at 0x0010
Found symbol REG_IP at 0x0012
Found symbol REG_PSP at 0x0014
Found symbol REG_TOS at 0x0016
All required symbols found
Setting callback at address: 0xC0D2
Memory position reached: 0xC0D2

Forth sur 6502, épisode 1

2025-12-07T00:00:00+01:00

Family Forth, le projet

En m'intéressant au langage de programmation Forth, j'ai parfois croisé l'affirmation que pour bien comprendre Forth, il fallait en développer un.

C'est cohérent avec son histoire, qui débute comme une trousse à outils de son inventeur pour lui faciliter les développements qu'il fait pour ses employeurs.

J'ai lu un certain nombre de documents sur Forth, parcouru quelques implémentations et même développé un jeu dans ce langage pour Hector HRX.

Plus récemment, en m'amusant avec le BASIC pour Famicom, je me suis demandé ce qui pourrait être développé sur la console pour tirer parti du clavier. Alors, pourquoi pas un Forth interactif sur Famicom ?

Une rapide recherche m'a montré que des expériences en Forth pour Famicom avaient déjà été faites, mais pas forcément sous l'angle interactif. Et bien entendu, il existe déjà des Forth pour 6502, le processeur qui équipe cette machine (même si c'est une version custom, cela ne change pas grand chose).

Mais la prémisse reste : l'intérêt est de développer son propre Forth. Et c'est donc ce que je vais faire dans une série d'articles qui me serviront à poser mes idées, comme pense bête. Et pourquoi pas comme inspiration pour d'autres, si vous voulez bien me suivre, qui sait ?

Pour initier le développement, j'ai décidé de suivre la série d'articles Moving Forth, qui a été publiée à partir du numéro 59 du « The Computer Journal », en janvier/février 1993.

Cette série d'articles est intéressante car elle étudie pour différentes étapes les options d'implémentations qui s'offrent, avec des références. Elle donne aussi des implémentations pour divers CPUs, mais pas pour 6502, ce qui me laissera un peu de choix dans mes réflexions, même si je doute que ceux-ci soient très originaux.

Ces articles étant assez anciens, ils renvoient aussi à une conception pas trop moderne de Forth, qui a évolué depuis, et donc plus proche de ce qu'on pourrait attendre sur Famicom. Enfin peut-être, on verra.

Le 6502 est aussi un CPU que j'ai très peu pratiqué, c'est donc une occasion de gagner en expérience dessus.

Moving Forth, article 1

De chaque article de Moving Forth, je vais retirer les informations qui me semblent importantes dans la démarche de développement. Et je commence donc par... le premier article.

Quelques choix

Tout d'abord, la taille des mots. Sur un tel processeur, le choix est assez facile : 16 bits est le minimum pour manipuler des adresses mémoire. Les mots seront donc sur 16 bits. L'article rappelle d'ailleurs qu'il vaut mieux utiliser le mot « cellule » (CELL) car un « mot » est quelque chose d'autre en Forth.

Vient ensuite le choix du modèle de fonctionnement. Il y a plusieurs moyens de faire fonctionner un Forth, l'article mentionne le « Indirect Threaded Code » (ITC), le « Direct Threaded Code » (DTC), le « Subroutine Threaded Code » (STC) et le « Token Threaded Code » (TTC). Il mentionne aussi le « Segment Threaded Code », mais c'est particulier au 8086, donc pas pertinent ici.

Le choix classique pour des machines 8 bits est le « Indirect Threaded Code ». Je vais suivre le mouvement et choisir cette méthode. L'article indique que ça n'est ni la méthode la plus rapide ni la plus compacte, qu'elle a un avantage de simplicité, mais que c'est surtout une habitude historique.

Cependant, c'est aussi la méthode dont j'ai l'habitude lorsque j'ai pratiqué Forth sur d'autres machines 8 bits. Je me note cependant dans un coin de peut-être étudier plus tard les autres méthodes.

Registres

Il nous faut aussi des registres. On parle là de registres Forth, et de la manière dont ils seront implémentés sur le CPU, ici le 6502.

Voici la liste des registres pour lesquels il faudra trouver une place, par ordre d'importance décroissante :

W (working register)
IP (instruction pointer)
PSP (parameter stack pointer)
RSP (return stack pointer)
TEMP (temporary register)

Rappel, tous ces registres doivent être sur 16 bits.

L'article mentionne un registre TOS (top of stack), optionnel mais qui peut optimiser certaines opérations. Pour le moment, je vais le laisser de côté.

Il est aussi fait mention d'un mapping possible des registres sur 6502, que voici :

* W, emplacement en page zéro
* IP, emplacement en page zéro
* PSP, registre `X` du 6502
* RSP, registre `SP` du 6502
* TOS, emplacement mémoire

X et SP étant des registres 8 bits, cela limite la taille de la pile de paramètres et de la pile de retour. À voir si c'est un problème ou pas.

Ce qui me fait penser qu'il y aura tout intérêt d'écrire un maximum de mots Forth à partir d'autres mots Forth et de limiter les mots en assembleur, au moins dans un premier temps. Ceci afin de limiter la réécriture de routines si je change d'avis sur le mapping des registres.

Conclusion

Très bien, après tout cela, il est temps de passer à la définition d'un projet minimal sur la machine cible. Entre autre, il faudra vérifier les emplacements déjà réservés, que ce soit dans la page zéro ou ailleurs en mémoire.

Compression de données, Huffman

2025-11-15T00:00:00+01:00

Voici un nouvel article de la série sur la compression de données, qui fait suite à celui sur la compression RLE, la compression LZ et la compression ZX0.

À la fin de l'article sur la compression LZ, il avait été question de fréquence d'apparition des nombres pour les offsets de référence et les longueurs de motif. Cette constatation avait amené lors de l'article sur ZX0 à regarder le codage gamma, qui permet de coder des entiers avec un nombre de bits variable afin d'optimiser la taille des petits nombres (qui sont plus fréquents).

Revenons sur cette histoire de fréquence en l'étendant à tous les symboles présents dans les données à compresser. Il serait intéressant d'avoir un codage dépendant de la fréquence d'apparition des symboles : plus le symbole est fréquent, plus son code est court.

Ce codage est obtenu avec l'algorithme de Huffman.

En plus d'avoir des codes de longueurs variables en fonction de la fréquence, Huffman garantit qu'aucun code n'est le préfixe d'un autre code, ce qui rend l'algorithme de décodage très facile. Le codage est aussi optimal : il n'y a pas de codage préfixe plus court pour les fréquences données.

Algorithme de compression de Huffman

L'idée générale de l'algorithme est la suivante : après avoir calculé les fréquences d'apparition des symboles, on construit un arbre binaire où chaque symbole est une feuille de l'arbre, avec les symboles les plus fréquents proches de la racine. Le code d'un symbole correspond alors au parcours depuis la racine jusqu'à la feuille, en prenant 0 pour une branche et 1 pour l'autre.

Pour initier la construction de l'arbre, on crée une liste de nœuds, un par symbole associé à sa fréquence. Ensuite et itérativement jusqu'à avoir l'arbre complet, on prend les deux nœuds de plus petite fréquence et on crée un nouveau nœud parent avec comme fréquence la somme des deux fréquences.

Reprenons l'exemple qui nous suit depuis le début. Pour rappel, il s'agit de cette image :

................
....#######.....
..##@@@@@@@##...
.##@OOOOOOO@##..
.#@OoooooooO@#..
#@OoooooooooO@#.
#@OoooooooooO@#.
#@OoooooooooO@#.
#@OoooooooooO@#.
#@OoooooooooO@#.
#@OoooooooooO@#.
.#@OoooooooO@#..
.##@OOOOOOO@##..
..##@@@@@@@##...
....#######.....
................

On commence donc par calculer les fréquences (ou occurrences, cela revient au même) des symboles :

Fréquences des symboles :
  '.': 78 (28.78%)
  'o': 68 (25.09%)
  '#': 46 (16.97%)
  '@': 34 (12.55%)
  'O': 30 (11.07%)
  '\\n': 15 (5.54%)

Donc, plein de '.' et de "o", et pas beaucoup de retours à la ligne. À noter qu'avec 6 symboles différents, on pourrait utiliser un codage fixe sur 3 bits par symbole (2^3 = 8 possibilités). Voyons ce que donne Huffman en déroulant l'algorithme :

On prend les deux nœuds de plus petites occurrences : '\n' (15) et 'O' (30)
On crée un nœud parent "\nO" avec occurrences 45 (15 + 30)
On prend les deux nœuds de plus petites occurrences : '@' (34) et le "\nO" (45)
On crée un nœud parent "@\nO" avec occurrences 79 (34 + 45)
On prend les deux nœuds de plus petites occurrences : '#' (46) et 'o' (68)
On crée un nœud parent "#o" avec occurrences 114 (46 + 68)
On prend les deux nœuds de plus petites occurrences : '.' (78) et le "@\nO" (79)
On crée un nœud parent ".@\nO" avec occurrences 157 (78 + 79)
On prend les deux nœuds de plus petites occurrences : "#o" (114) et ".@\nO" (157)
On crée un nœud racine avec occurrences 271 (114 + 157)

Ce qui nous amène à l'arbre suivant :

            [271]
           /     \
   <-- 0  /       \  1 -->
         /         \
      [114]        [157]
     /     \      /     \
   [46]   [68]  [78]   [79]
     #      o     .   /    \
                    [34]  [45]
                      @  /    \
                        [15] [30]
                         \n    O

Pour trouver les codes associé à chaque symbole, on parcourt l'arbre depuis la racine jusqu'à chaque feuille, en prenant 0 pour la branche de gauche et 1 pour la branche de droite. Et cela donne :

  '.'  : 10   (longueur=2)
  'o'  : 01   (longueur=2)
  '#'  : 00   (longueur=2)
  '@'  : 110  (longueur=3)
  'O'  : 1111 (longueur=4)
  '\\n': 1110 (longueur=4)

En prenant la moyenne des longueurs pondérées par les occurrences, on obtient une taille moyenne de 2.45 bits environ par symbole. C'est mieux que les 3 bits fixes, mais pas extraordinaire non plus en considérant que 3 bits auraient pu coder 8 symboles.

Cependant, il n'y a pas besoin de faire l'analyse au préalable et à la main pour savoir combien de bits sont nécessaires. L'algorithme de Huffman le fait tout seul.

La compression elle-même consiste ensuite à remplacer chaque symbole par son code binaire. Pour notre exemple, cela donne pour la première ligne la suite de bits suivante : 10101010101010101010101010101010, ce qui fait une suite d'octets : 0xAA 0xAA 0xAA 0xAA. On passe de 16 octets à 4. On voit aussi qu'un motif se répète... intéressant non ? J'évoquerai cela à la fin de l'article.

Algorithme de décompression

La décompression est très simple : avec le flux compressé et l'arbre, on parcours l'arbre en lisant les bits un par un. À chaque 0, on descend sur la branche de gauche, à chaque 1 sur la branche de droite. Lorsqu'on atteint une feuille, on émet le symbole correspondant et on repart de la racine.

Je vous laisse faire l'exercice avec 0xAA (c'est-à-dire 10101010) pour retrouver une série de quatre '.'.

Et l'arbre ?

C'est bien beau d'avoir codé les données grâce à l'arbre. Mais il nous faut l'arbre pour décoder le flux compressé. Il est donc nécessaire de le transmettre avec les données compressées. Il y a plusieurs manières de faire, mais voici une approche simple :

Pour chaque nœud interne, on écrit un 0 (en bit) et on sérialise récursivement les deux nœuds enfants.
Pour chaque feuille, on écrit un 1 suivi du code du symbole (sur 8 bits).

En commençant par la racine, on obtient un parcours en profondeur de l'arbre. Pour notre exemple, cela donne la séquence de bits suivante (les caractères sont ici pour la lisibilité, mais en pratique ce sont leur représentation binaire qui est utilisée) :

0
  0
    1 `#`
    1 `o`
  0
    1 `.`
    0
      1 `@`
      1 `\n`
    1 `O`

Cela fonctionne puisque, par construction, chaque nœud interne a toujours deux enfants, sauf s'il n'y a qu'un seul symbole dans les données.

L'exemple ici prend 8 octets (avec quelques bits non utilisés dans le dernier octet). C'est assez petit par rapport aux données, ça va.

Les chiffres

Avec les données de l'exemple,. on obtient les résultats suivants :

Taille originale : 271 octets (2168 bits)
Taille compressée : 666 bits (84 octets, avec 6 bits de padding)
Taille de l'arbre : 8 octets
Taille totale compressée : 92 octets

Ce qui donne une taille finale compressée, arbre compris, de 33.95% de la taille originale.

Combinaisons

Si on regarde le flux compressé (hors arbre), voici ce que cela donne en hexadécimal :

0xAA 0xAA 0xAA 0xAA 0xEA 0xA0 0x00 0x2A 0xAE 0xA0 0xDB 0x6D 0xB0 0x55 0xD0 0x6F 0xFF 0xFF 0xFF 0xC1 0x5D 0x1B 0xD5 0x55 0xFC 0x57 0x1B 0xD5 0x55 0x5F 0xC5 0xC6 0xF5 0x55 0x57 0xF1 0x71 0xBD 0x55 0x55 0xFC 0x5C 0x6F 0x55 0x55 0x7F 0x17 0x1B 0xD5 0x55 0x5F 0xC5 0xC6 0xF5 0x55 0x57 0xF1 0x74 0x6F 0x55 0x57 0xF1 0x5D 0x06 0xFF 0xFF 0xFF 0xFC 0x15 0xD4 0x1B 0x6D 0xB6 0x0A 0xBA 0xA8 0x00 0x0A 0xAB 0xAA 0xAA 0xAA 0xAA 0x80

Comme indiqué plus haut, on remarque des motifs qui se répètent. Ce flux est donc probablement un bon candidat pour une compression supplémentaire avec LZ par exemple. Pourquoi pas ?

L'algorithme DEFLATE (utilisé dans le format .zip par exemple) fait le contraire : il applique d'abord LZ77 pour compresser les motifs répétitifs, puis applique Huffman pour compresser les symboles résultants. C'est un peu plus compliqué que cela, mais c'est l'idée générale, et c'est l'idée générale derrière plusieurs formats de compressions : des mélanges d'algorithmes.

Conclusion

Huffman est un algorithme de compression efficace sur des données avec des fréquences d'apparition de symboles non uniformes. Si tous les symboles sont également fréquents, il n'y aura pas d'avantage à utiliser Huffman par rapport à un codage fixe. De plus, il faut stocker l'arbre, il est donc important de vérifier que la taille gagnée par la compression compense la taille de l'arbre (il est aussi possible d'utiliser des arbres statiques connus à l'avance pour certains types de données, mais cela sera potentiellement moins efficace).

On retrouve cet algorithme dans de nombreux formats de compression, souvent combiné avec d'autres algorithmes. C'est une des bases de la compression de données, il est donc intéressant de connaître son principe de fonctionnement.

Cet article termine la petite série sur la compression de données sans perte.

Supplément

Le code que j'ai utilisé lors de l'écriture pour vérifier les exemples est disponible ici.

Compression de données, le format ZX0

2025-11-02T00:00:00+01:00

Après avoir présenté dans l'article précédent sur la compression LZ l'idée générale de référencement arrière de données déjà présentes en mémoire, cet article va se concentrer sur une implémentation spécifique de la famille LZ : le ZX0, un algorithme développé par Einar Saukas avec pour double objectif une taille très compacte pour le code de décompression et une recherche des choix optimaux lors de la compression.

Au niveau du code de décompression, sur Z80 et pour reprendre les exemples fournis dans le README officiel, on a les chiffres suivants :

Routine "Standard" : 68 octets
Routine "Turbo" : 126 octets, environ 21% plus rapide
Routine "Fast" : 187 octets, environ 25% plus rapide
Routine "Mega" : 673 octets, environ 28% plus rapide

Pour obtenir un code de décompression aussi compact, les choix faits dans le format ZX0 sont adaptés à un décodage avec peu de calculs et des calculs simples.

Rentrons dans les détails.

Le double flux

ZX0 utilise deux flux de données distincts. Le premier flux contient les informations sur les blocs : quel type de bloc (littéral ou référence arrière), les offsets et les longueurs. Ce flux est lu bit par bit. Le second flux contient les données littérales elles-mêmes, lues octet par octet.

Il suffit donc d'avoir une routine qui lit le bit suivant du premier flux et une routine qui lit l'octet suivant du second flux. Un pointeur suffit pour le second flux. Le premier flux est un peu plus complexe : il nécessite un pointeur, un octet courant et un compteur de bits restants dans l'octet courant. Cela reste très simple.

Ces deux flux sont entrelacés. Lorsque l'une des deux routines a besoin d'un nouvel octet, elle le lit depuis les données compressées. Cela signifie qu'en fait, un seul pointeur est nécessaire pour parcourir les deux flux. De manière symétrique, cela signifie que lors de la compression, les données doivent être écrites en un seul flux en entrelaçant les deux types de données au fur et à mesure qu'elles forment un octet complet.

Encodage des nombres

À la fin de l'article précédent, la constatation était que les références avaient souvent des petites longueurs et qu'il pouvait être intéressant de trouver un moyen d'encoder ces petites longueurs de manière efficace.

ZX0 prend acte et utilise un codage nommé « codage gamma » ou encore « codage gamma d'Elias » ("Elias Gamma coding").

Principe du codage gamma

Le codage gamma propose d’écrire un nombre en deux parties : la longueur binaire nécessaire et la valeur restante depuis la puissance de 2 inférieure.

La longueur du nombre en binaire est encodée de manière unaire : on regarde combien de bits sont nécessaires pour écrire le nombre en binaire, on écrit cette valeur moins un en unaire (avec autant de 0 que le nombre voulu), puis on termine avec un 1. Incidemment, cela représente la puissance de deux inférieure nécessaire pour coder le nombre.

Par exemple, pour le nombre 3, qui s'écrit 11 en binaire (2 bits), on écrit 01 (un 0 suivi d'un 1). Pour le nombre 10, qui s'écrit 1010 en binaire (4 bits), on écrit 0001 (trois 0 suivis d'un 1).

Pour la valeur restante, on prend le nombre, on enlève la plus grande puissance de 2 qui ne dépasse pas ce nombre, puis on écrit le reste en binaire, sur le nombre de bits calculé précédemment (le nombre de fois où on a trouvé 0 avant le 1).

Par exemple, pour le nombre 3, la plus grande puissance de 2 inférieure est 2 ($2^1$), donc le reste est $3 - 2 = 1$, qui s'écrit 1 en binaire sur 1 bit. Pour le nombre 10, la plus grande puissance de 2 inférieure est 8 ($2^3$), donc le reste est $10 - 8 = 2$, qui s'écrit 010 en binaire sur 3 bits.

Ainsi on a :

3  ->   01 1    (pour un total de 3 bits)
10 -> 0001 010  (pour un total de 7 bits)

Ce codage est efficace pour les petits nombres (jusqu'à 15), car il peut les écrire avec moins de 8 bits. En revanche, il devient moins efficace pour les nombres plus grands (par exemple 16 occupe 9 bits en codage gamma).

Ce codage offre aussi l'avantage d'être sur un nombre de bits variable et de permettre la « découverte » de cette taille lors de la lecture.

Mais pour rendre le décodage encore plus simple, ZX0 utilise une variante appelée « codage gamma entrelacé » qui permet de lire tous les bits dans l'ordre en une seule passe. L'entrelacement se fait entre la partie unaire et la partie binaire (dans le sens du plus petit bit vers le plus grand). Les bits de la première partie (unaire) sont les bits impaires et les bits de la seconde partie (binaire) sont les bits paires.

Exemples :

3  codé   01 1   devient 011
10 codé 0001 010 devient 0001001

Avec ce système, il suffit de lire un bit et s'arrêter s'il est à 1, sinon lire un autre bit pour la partie binaire, l'ajouter à l'accumulateur préalablement décalé vers la gauche. Puis recommencer jusqu'à trouver un 1. Pour que l'algorithme fonctionne, l'accumulateur doit être initialisé à 1.

Par exemple, pour décoder 011 :

Lire 0 (unaire), on continue
Lire 1 (binaire), accumulateur = 1 << 1 | 1 = 3
Lire 1 (unaire), on s'arrête, valeur finale = 3

Et pour décoder 0001001 :

Lire 0 (unaire), on continue
Lire 0 (binaire), accumulateur = 1 << 1 | 0 = 2
Lire 0 (unaire), on continue
Lire 1 (binaire), accumulateur = 2 << 1 | 1 = 5
Lire 0 (unaire), on continue
Lire 0 (binaire), accumulateur = 5 << 1 | 0 = 10
Lire 1 (unaire), on s'arrête, valeur finale = 10

Les types de blocs

Maintenant que l'on sait qu'il y a deux flux et comment encoder les nombres, voyons comment ZX0 organise les blocs de données. Il existe trois types de blocs :

Bloc littéral : contient les données littérales. Est associé à une longueur.
Bloc de référence : référence une séquence de données précédemment rencontrée. Est associé à un offset et une longueur.
Bloc de référence de même offset : tout comme un bloc de référence, mais réutilise le dernier offset utilisé et ne spécifie donc que la longueur.

Pour différencier ces trois types de blocs, ZX0 utilise un seul bit. Un seul bit pour désigner trois types de blocs ? Cela est possible car certaines contraintes logiques existent entre les blocs :

Deux blocs littéraux ne peuvent pas se suivre (sinon ils seraient fusionnés en un seul bloc littéral).
Un bloc de référence de même offset ne peut apparaître qu'après un bloc littéral.
Le premier bloc est toujours un bloc littéral (et d'ailleurs le tout premier bit qui devrait indiquer le type de bloc est omis).

Ainsi, le bloc littéral et le bloc de référence de même offset sont tous deux indiqués par un 0 et le bloc de référence avec nouvel offset est indiqué par un 1. Le contexte permet de savoir quel type de bloc est concerné entre les deux premiers.

Les longueurs sont encodées en utilisant le codage gamma entrelacé décrit précédemment. Pour les offsets, c'est un peu plus compliqué : l'offset est divisé en deux parties, le MSB (Most Significant Byte) utilise le codage gamma entrelacé, tandis que le LSB (Least Significant Byte) est stocké tel quel sur 7 bits (au lieu de 8). Comme on ne peut pas encoder 0 en gamma, le MSB de l'offset est stocké avec une valeur augmentée de 1.

Autre petite optimisation : puisqu'une référence avec nouvel offset a toujours une longueur minimale de 2, la longueur stockée pour une référence est en fait la longueur moins 1.

Exemples :

0 011               -> bloc littéral de longueur 3
                       (ou bien référence de longueur 3 selon le contexte)
1 1 0000011 0001001 -> bloc de référence avec nouvel offset de longueur 3
                       (1 en codage gamma pour MSB = 0)
                       (0000011 pour LSB = 3)
                       et longueur 11 (10 + 1)

Recherche optimale

Lors de l'article précédent qui présentait l'idée derrière la compression LZ, il avait été question de prendre en référence arrière la plus grande séquence identique possible. Cela fonctionne : c'est un type d'algorithme glouton (greedy). Cependant, cette méthode n'est pas forcément (pas souvent ?) optimale. Peut-être que prendre à un endroit le motif le plus long empêche de faire un meilleur choix de référence un peu plus loin. Ou bien peut-être que cela cause des codages gamma sur trop de bits. L'algorithme ZX0 fait le choix de trouver la solution optimale.

Pour cela, à chaque position lors de la compression, l'algorithme va examiner tous les offsets possible et regarder s'il est possible de faire une référence arrière et maintenir une chaîne optimale en calculant le coût total si une référence devait être faite à cet endroit.

L'algorithme fait appel à de la programmation dynamique pour obtenir un code compact et efficace. Efficace, mais pas rapide : la compression avec ZX0 est lente avec des fichiers un peu conséquents, c'est son principal inconvénient. Mais en échange, on est assuré que, avec les choix de codage de ce format, le résultat est le plus compact possible.

Test sur l'exemple

Reprenons à nouveau l'image en niveaux de gris des deux articles précédents et voyons ce que cela donne avec le format ZX0.

L'exemple, pour rappel :

................
....#######.....
..##@@@@@@@##...
.##@OOOOOOO@##..
.#@OoooooooO@#..
#@OoooooooooO@#.
#@OoooooooooO@#.
#@OoooooooooO@#.
#@OoooooooooO@#.
#@OoooooooooO@#.
#@OoooooooooO@#.
.#@OoooooooO@#..
.##@OOOOOOO@##..
..##@@@@@@@##...
....#######.....
................

Le résultat de la compression avec ZX0 est le suivant :

File compressed from 272 to 51 bytes! (delta 3)

Soit un fichier final ayant un peu moins de 19% de la taille originale. Pour rappel, la compression RLE et LZ « naïve » avaient donné un fichier de 57% la taille originale. C'est nettement mieux.

Voici le contenu de fichier final :

0000000  95  2e  89  0a  2e  a4  23  f7  de  b9  ed  40  fe  ff  ef  de
0000010  ee  e0  4f  fe  7f  dc  fb  de  e1  6f  9f  fe  dd  fc  de  e0
0000020  f7  dc  91  de  1f  12  5d  d7  ce  75  8a  d9  46  1d  d7  02
0000030  55  55  80

On peut s'amuser à décoder le début à la main.

On garde le premier octet $95 (10010101 en binaire) en mémoire, il s'agit des informations de blocs. Le premier bloc est toujours un bloc littéral, on commence donc par une longueur en codage gamma entrelacé. 1 signifie une longueur de 1. On lit donc le premier octet du flux littéral : $2e (le caractère .). Nous voici avec notre premier caractère décodé.

On continue à lire ce qu'il reste de notre octet $95 : le bit suivant est un 0. Puisque le bloc précédent était un bloc littéral, ce 0 indique un bloc de référence de même offset. Le offset précédent est initialisé à 1 en début d'algorithme. On a donc une référence de 1 en arrière (le caractère . déjà décodé). Reste à lire la longueur en codage gamma entrelacé : 010101... le nombre n'est pas terminé, il nous faut un nouvel octet depuis le flux. C'est $89 (10001001 en binaire).

On continue la lecture : 1. Le bit de fin du codage gamma. Ce qui donne au final 0101011, soit 0001 111 en désentrelacé, soit une longueur de 15. On copie donc 15 fois le caractère trouvé une position avant. Nous voici avec 16 caractères . décodés. À noter qu'il n'y avait qu'un seul octet dans le flux littéral, mais la copie avance en recopiant le caractère déjà décodé. Avec une référence arrière de 1, il y a autant de copie de . que nécessaire.

Continuons. Le prochain bloc est indiqué par le bit suivant : 0. Puisque le bloc précédent était une référence, ce 0 indique un bloc littéral. On lit la longueur en codage gamma entrelacé : 001, soit 01 0 en non entrelacé, ce qui signifie 2. On lit donc les deux octets suivants dans le flux littéral : $0a (le caractère de retour chariot) et $2e (le caractère .). Nous venons de compléter la première ligne de l'image et de débuter la seconde.

Vous pouvez continuer si vous le souhaitez, mais je m'arrête ici pour cet exemple.

Fonctionnalités avancées

Avant de refermer cet article, il est intéressant de noter que ZX0 propose quelques fonctionnalités supplémentaires.

La compression à rebours

Plutôt que de compresser les données du début à la fin du fichier d'entrée, ZX0 permet de compresser les données en commençant par la fin du fichier d'entrée. L'algorithme est le même, sauf que le flux commence par la fin et que les références « arrières » sont « plus loin » en mémoire (puisque le début du flux est à la fin du fichier).

Cela est intéressant dans des scénarios où les données compressées et décompressées se recouvrent (ce qui est tout à fait possible aussi avec la compression standard) et que l'on veut « viser » l'adresse mémoire la plus haute disponible.

En effet, lors d'un recouvrement, l'algorithme à besoin d'un « décalage minimum » entre les deux flux de données (indiqué par le « delta » affiché lors de la compression). Pour bien comprendre ce que signifie ce delta et l'intérêt de la compression à rebours, le mieux est de consulter les diagrammes fournis dans le README.

Compression avec préfixe

Très pratique pour des décompressions « par morceaux », il est possible de fournir au compresseur un préfixe de données que l'on sait seront déjà présentes en mémoire lors de la décompression juste avant les nouvelles données à décompresser.

Le compresseur pourra donc piocher les références dans ce préfixe, sans pour autant inclure ces données dans le flux compressé. Bien entendu, il faut garantir que ces données seront bien présentes en mémoire lors de la décompression, puisque le décompresseur va les référencer.

Mode rapide

Enfin, du fait de la recherche optimale, la compression avec ZX0 peut être assez lente. Le compresseur propose donc une option « rapide » pour diminuer le temps de compression. L'option -q a pour effet de réduire fortement la fenêtre de recherche des références arrière qui est normalement de 32640 octets et passe à 2176 octets.

La recherche optimale est toujours effectuée, mais en allant chercher beaucoup moins loin les blocs pouvant être référencés. Cela diminue fortement le temps de compression, mais potentiellement aussi le taux de compression.

Pour l'exemple ci-dessus, dont la taille totale est bien inférieure à 2176 octets, cela ne change rien du tout. Ni en temps, ni en taille finale.

Conclusion

ZX0 est un algorithme de compression assez populaire sur les machines 8 bits. Le code source est disponible, il est simple à mettre en oeuvre, le code de décompression est très compact. Il a même été porté sur d'autres processeurs que le Z80.

Bien qu'un peu lent à compresser, le résultat de compression est bon et la décompression rapide. Ça en fait un très bon choix.

J'espère avoir pu vous donner une idée des choix faits par cet algorithme de compression/décompression et de son fonctionnement. Pas de code source dans cet article, j'ai directement utilisé l'implémentation officielle.

Compression de données, référencer les répétitions

2025-10-24T00:00:00+02:00

Dans l'article précédent sur la compression, l'idée était de remplacer les successions d'éléments identiques par un couple (nombre de répétitions, valeur). Cela fonctionne bien avec des plages de données contenant un même élément, mais beaucoup moins bien lorsque les données changent fréquemment.

La séquence suivante, par exemple, sera très mal compressée par cette méthode RLE :

.#.#.#.#.#.#.#.#.#.#.#.#.#.#.#.#

En effet, cette séquence ne contient aucune répétition d'un élément unique. Chaque élément est différent du précédent. Avec la méthode RLE, on devrait écrire :

(1, .), (1, #), (1, .), (1, #), ...

On peut avoir envie de se dire, avec cette séquence, que le motif à répéter est .# et qu'on le répète 16 fois. Mais on pourrait aussi se dire que c'est 4 fois le motif .#.#.#.#. Ou encore 2 fois le motif .#.#.#.#.#.#.#.#. Dans tous les cas, il nous faudrait une sorte de dictionnaire pour référencer les motifs que l'on voudrait répéter.

Et c'est une manière assez courante de compresser des données : référencer un dictionnaire.

Cependant, un dictionnaire, ça prend de la place. Et dans la compression que nous allons voir aujourd'hui, la méthode est d'utiliser les données elles-mêmes comme dictionnaire pour éviter de construire (et stocker) un dictionnaire à part. C'est la méthode LZ (Lempel-Ziv), du nom de ses inventeurs, ou en tout cas une manière dérivée de LZ.

Le dictionnaire

L'idée est la suivante : lorsque l'on en est à un point du flux de décompression, toutes les données précédemment décompressées sont disponibles en mémoire.

Imaginons par exemple, avec la séquence précédente, que l'on a déjà décompressé les deux premiers caractères : .#. On peut tout à fait commencer à référencer ce motif dans le flux à decompresser qui arrive. La séquence à décompresser suivante pourrait être « répète le motif de longueur 2 qui commence 2 positions avant ». Ce qui donnerait, une fois ajouté aux données déjà décompressées : .#.#.

À l'étape suivante, on pourrait avoir : « répète le motif de longueur 4 qui commence 4 positions avant ». On aurait à présent : .#.#.#.#

Et ainsi de suite.

Codage général

Ainsi, il nous faut construire un flux compressé qui est une suite d'éléments unitaires (des séquences qui n'ont pas encore été vues) et de références à des motifs déjà vus (avec une paire (position en amont, longueur)).

Sans entrer dans une implémentation précise, pour le motif précédent, on pourrait avoir ceci :

.# (suite d'éléments unitaires)
(-2,2) (référence au motif de longueur 2, 2 positions avant)
(-4,4) (référence au motif de longueur 4, 4 positions avant)
(-8,8) (référence au motif de longueur 8, 8 positions avant)
(-16,16) (référence au motif de longueur 16, 16 positions avant)

Si on utilise un élément marqueur pour indiquer si ce qui suit est une suite d'éléments unitaires ou une référence, cela donnerait globalement 15 éléments pour représenter les 32 éléments de l'original. Soit une taille finale d'un peu plus de 40% de l'original.

Pas mal.

Note : en vrai, on ne référencera pas des motifs aussi petits que deux éléments, car le gain en taille ne serait pas suffisant. Avec ce codage simpliste, il faut au moins 4 éléments pour référencer un motif de manière efficace.

Méthode de compression

Afin de compresser un flux de données avec cette méthode, à chaque étape, il faut chercher dans le flux en entrée si le motif qui suit est présent dans les données précédentes. Et ce pour la longueur la plus grande possible.

Pour l'exemple, lorsque l'on commence le flux, le premier caractère est un .. Ce caractère n'est pas encore dans les données présentes (puisque c'est le premier). On l'écrit donc comme élément unitaire dans le flux compressé. De même pour le caractère suivant, un #, que l'on écrit aussi en tant qu'élément unitaires à la suite du premier.

Pour la suite, on a dans le buffer à traiter une séquence .#.#.#.#.... On cherche le plus long motif qui est déjà dans les données. Ici, c'est .#, que l'on trouve à la position -2 (2 positions avant). On écrit donc la référence (-2,2) dans le flux compressé.

Et ainsi de suite, jusqu'à la fin du flux d'entrée.

Essai sur la séquence de l'article précédent

Je reprends l'image en niveaux de gris de l'article précédent sur la compression RLE :

................
....#######.....
..##@@@@@@@##...
.##@OOOOOOO@##..
.#@OoooooooO@#..
#@OoooooooooO@#.
#@OoooooooooO@#.
#@OoooooooooO@#.
#@OoooooooooO@#.
#@OoooooooooO@#.
#@OoooooooooO@#.
.#@OoooooooO@#..
.##@OOOOOOO@##..
..##@@@@@@@##...
....#######.....
................

Dans le cas RLE, j'avais supprimé les sauts de ligne pour ne garder qu'une suite d'éléments et profiter des plages formées par la fin d'une ligne et le début de la ligne suivante. Ici, je vais les garder, c'est beaucoup moins génant puisque la méthode compresse les séquences répétées.

Passé par l'algorithme décrit précédemment, voici ce que l'on obtient :

  Littéral:  (0, '....')
  Référence: (1, (-4, 4))
  Référence: (1, (-8, 8))
  Littéral:  (0, '\n')
  Référence: (1, (-5, 4))
  Littéral:  (0, '#######')
  Référence: (1, (-17, 8))
  Littéral:  (0, '##@@@@@@@')
  Référence: (1, (-19, 5))
  Littéral:  (0, '\n')
  Référence: (1, (-16, 4))
  Littéral:  (0, 'OOOOOOO')
  Référence: (1, (-18, 5))
  Littéral:  (0, '\n.#@OoooooooO@')
  Référence: (1, (-17, 4))
  Référence: (1, (-16, 10))
  Référence: (1, (-18, 6))
  Référence: (1, (-17, 17))
  Référence: (1, (-34, 34))
  Référence: (1, (-34, 34))
  Littéral:  (0, '\n.')
  Référence: (1, (-18, 10))
  Référence: (1, (-16, 4))
  Référence: (1, (-17, 4))
  Littéral:  (0, '#@OOOOOOO@#')
  Référence: (1, (-17, 5))
  Référence: (1, (-18, 4))
  Littéral:  (0, '@@@@@')
  Référence: (1, (-16, 5))
  Référence: (1, (-17, 4))
  Référence: (1, (-19, 4))
  Littéral:  (0, '###')
  Référence: (1, (-15, 5))
  Référence: (1, (-17, 7))
  Référence: (1, (-10, 5))
  Référence: (1, (-7, 7))

Ce qui donne une entrée de 272 éléments (256 éléments plus les retours chariots) compressée en 156 éléments, soit environ 57% de la taille initiale.

C'est légèrement moins bien que la méthode RLE pour ce cas qui avait été construit spécialement pour que ça fonctionne bien en RLE. Donc... ce n'est pas mal du tout (et on a les retours chariots en bonus).

Peut-on faire mieux ?

Comme la dernière fois, pour le moment, on a une implémentation assez générique que l'on compte en éléments. Si on considère que ces éléments sont en fait des octets, il y a beaucoup de place perdue, ne serait-ce que par l'utilisation d'un octet complet pour différencier les littéraux des références.

De même, on peut se poser la question de l'utilisation d'un octet complet pour la position et la longueur dans les références, alors que les plus grandes valeurs absolues utilisées dans cet exemple sont 34. On pourrait limiter ces valeurs à 4 bits chacun pour coder les deux valeurs sur un seul octet.

J'ai fait l'essai... et ce n'est pas brillant. La compression est alors assez mauvaise, passant alors à un résultat compressé de 225 octets.

Par contre, en utilisant une valeur maximale de 32, alors on retrouve le taux de compression précédente.

Mais plus que la valeur maximale, il est intéressant de s'intéresser à la répartition des valeurs utilisées.

Grâce à un petit programme d'analyse, voici ce que j'obtiens pour cet exemple :

Distribution des longueurs de référence:
  Valeur | Occurrences | Histogramme
  -------|-------------|------------
       4 |           9 | #########
       5 |           6 | ######
       6 |           1 | #
       7 |           2 | ##
       8 |           2 | ##
      10 |           2 | ##
      17 |           1 | #
      34 |           2 | ##
  Statistiques: Min=4, Max=34, Moyenne=8.28, Médiane=5.0

Distribution des positions de référence (valeurs absolues):
  Valeur | Occurrences | Histogramme
  -------|-------------|------------
       4 |           1 | #
       5 |           1 | #
       7 |           1 | #
       8 |           1 | #
      10 |           1 | #
      15 |           1 | #
      16 |           4 | ####
      17 |           7 | #######
      18 |           4 | ####
      19 |           2 | ##
      34 |           2 | ##
  Statistiques: Min=4, Max=34, Moyenne=16.40, Médiane=17.0

Distribution combinée (longueurs + positions):
  Valeur | Occurrences | Histogramme
  -------|-------------|------------
       4 |          10 | ##########
       5 |           7 | #######
       6 |           1 | #
       7 |           3 | ###
       8 |           3 | ###
      10 |           3 | ###
      15 |           1 | #
      16 |           4 | ####
      17 |           8 | ########
      18 |           4 | ####
      19 |           2 | ##
      34 |           4 | ####
  Statistiques: Min=4, Max=34, Moyenne=12.34, Médiane=10.0

On peut remarquer que même si l'amplitude des valeurs est grande (de 4 à 34), la moitié des valeurs utilisées sont plutôt petites (entre 4 et 10), et la moyenne n'est pas très élevée non plus. Est-ce que ça ne vaudrait pas le coup d'utiliser un codage variable pour ces valeurs, afin de privilégier les petites valeurs ?

C'est sur cette piste que part l'algorithme ZX0, que nous verrons dans un prochain article.

À noter que une piste est possible en calculant une représentation des valeurs adaptée à leurs distributions. Pour cela, on peut utiliser un codage de Huffman, et c'est la piste utilisée par l'algorithme DEFLATE (utilisé dans les fichiers ZIP et PNG entre autres).

Conclusion

Avec cette méthode de compression par références dans un dictionnaire construit, il est possible de compresser des flux de données avec beaucoup plus de variations qu'avec la méthode RLE. LZ est en fait la base de beaucoup d'algorithmes de compression sans pertes. Le temps de compression est « élevé » car il est nécessaire de chercher des motifs dans des plages de données (la recherche peut d'ailleurs être paramétrée selon ce que l'on veut). La décompression est en revanche assez rapide, il n'y a pas de calculs ou d'opérations complexes à faire.

Supplément

Le code que j'ai utilisé lors de l'écriture pour vérifier les exemples est disponible ici.

Briques Stellaires, jeu pour PHC-25

2025-10-12T00:00:00+02:00

Avec la publication de la version 0.9 de Briques Stellaires, ma contribution à la Game Jam « Retro Programmers United for Obscure Systems » session PHC-25 est l'occasion de revenir sur cette session et ma proposition.

Vu les caractéristiques modestes mais sympathiques du PHC-25, j'ai eu envie de faire un jeu plutôt action. Exercice toujours délicat pour ces machines peu utilisées dont les émulateurs sont très très perfectibles, pour ne pas dire à côté de la plaque. Mais ayant eu un accès temporaire à la machine, je ne me suis dit que... allez pourquoi pas.

J'étais parti sur un twist du classique casse-brique. Au final, le temps passant toujours à sa proverbiale vitesse, le jeu est... un casse-brique tout ce qu'il y a de plus standard.

Mais voyons un peu les détails potentiellement intéressants du développement.

L'environnement de développement

Je suis parti pour cette contribution sur un développement en assembleur Z80. Je le regretterai plus d'une fois, quand il m'a fallu mettre au point la routine de rebond. Mais comme je savais que cela serait potentiellement compliqué avec des regressions très probables, j'ai cherché dès le début un environnement me permettant de faire des tests unitaires.

J'avais déjà mis en place des tests unitaires pour le jeu sur VG5000, cependant, ils devaient être lancés en même temps que l'exécutable principal. Puis c'était un bricolage rapide qui manquait de fonctionnalités.

Je suis donc parti sur un environnement déjà fait : DeZog. C'est un environnement intégré à Visual Code, initialement fait et spécialisé pour le ZX Spectrum, mais qui peut être utilisé comme environnement Z80 générique. DeZog supporte l'exécution de tests unitaires, avec de nombreuses assertions, le tout pouvant tourner dans un émulateur interne.

DeZog implémente aussi un lien de debuggage avec différents émulateurs, dont MAME. Parfait pour la mise au point.

Les choix pour le PHC-25

Il y a plusieurs modes graphiques sur le PHC-25, qui utilise comme VDP un clone du MC6847 avec le maximum de RAM vidéo supportée. On peut considérer qu'il y a deux grandes classes de modes graphiques : des modes alpha-numérique/semi-graphique, et des modes bitmap, avec des variations dans les contraintes.

Pour le jeu, j'ai choisi un mode alpha-numérique/semi-graphique qui permet d'avoir une résolution en « gros pixels » de 68x48. C'est suffisant pour un casse-brique.

Pas de son ni de joystick, car le PHC-25 a besoin d'une extension pour cela. Et puis... le temps, toujours le temps.

Liste d'affichage

Sur le PHC-25, le MC6847 utilise pour RAM vidéo une mémoire directement accessible par le bus du Z80. Et lorsqu'il y a arbitrage, c'est le Z80 qui gagne. Ainsi, des accès à la mémoire vidéo pendant le rafraîchissement de l'écran provoquent des parasites bien visibles.

Il faut donc absolument éviter d'accéder à la mémoire vidéo pendant le rafraîchissement. C'est d'ailleurs ce que fait la ROM du PHC-25 où les commandes graphiques sont appliquées progressivement pendant l'interruption (INT), branchée sur VBLANK.

Et c'est aussi ce que je fais dans Briques Stellaires. Après avoir passé le Z80 en mode d'interruption IM2 (il n'y a pas de possibilité prévue par le système pour s'accrocher à l'interruption en IM1), je déroule des listes d'affichages au moment de l'interruption. Ces listes d'affichages sont elles-mêmes construites pendant le reste du temps, par des accès en RAM normale exclusivement.

Ces listes d'affichages sont de type : afficher une brique, effacer une brique, effacer et afficher la balle,...

Le traitement de l'affichage du contour de jeu ainsi que des pages de titre et de score est un peu différent : je prépare l'affichage dans un buffer auxiliaire de la taille de l'écran, puis je copie ce buffer en RAM vidéo pendant le VBLANK, petit à petit.

L'affichage de la raquette est similaire : il est fait dans le buffer auxiliaire, puis la ligne correspondante est copiée en RAM vidéo pendant le VBLANK systématiquement. C'est un choix que j'ai fait assez tôt car je ne savais pas trop à quelle vitesse la raquette allait bouger et je voulais un système simple, avec un temps fixe pendant la VBLANK.

La physique

Voilà qui m'a pris plus de temps que prévu. Je savais que cela allait être délicat, avec des rebonds particuliers et des vitesses non entières. En effet, les coordonnées de la balle sont en virgule fixe, 8 bits pour la partie entière, 8 bits pour la partie fractionnaire. Là encore, c'est un choix que j'ai fait assez tôt, car je ne savais pas quelle vitesse de balle allait être intéressante. Et avec la résolution de l'écran, des vitesses entières allaient donner des mouvements bien trop rapides.

Pour les collisions, je trace une ligne entre la position précédente et la position actuelle de la balle, point par point, en testant les collisions avec les briques, la raquette et les bords. La ligne ne fait rarement plus de deux pixels, mais là encore, cela permet de gérer différentes vitesses, donc des vitesses supérieures à 1 par axe.

Par contre, j'ai simplifié : une collision arrête immédiatement la trajectoire. Je ne cherche pas à compléter le mouvement restant après le rebond. Aux vitesses utilisées au final par le jeu, la différence est imperceptible.

La gestion de variables

Puisque le jeu est sur cassette, il est toujours intéressant de minimiser la taille des données encodées. Pour gagner de la place, j'ai implémenté avec le système de STRUCT et de macros de sasmjsplus qui permet de « déclarer » des variables près du code, mais qui sont toutes regroupées à la fin du code lors de l'assemblage.

Au démarrage du programme, je fixe toute la zone à zéro. Un peu à la manière d'une section BSS dans un programme C.

J'avais envisagé d'utiliser un système de compression, surtout pour les niveaux. Mais le manque de temps et finalement la taille relativement modeste du programme (moins de 3ko) m'ont fait abandonner cette idée.

Conclusion

Briques Stellaires est un casse-brique très rudimentaire. Et autant que je puisse m'en souvenir, c'est la première fois que je programme un casse-brique. Je me suis perdu dans la gestion de collisions et malgré les tests unitaires qui m'ont gardé sur les rails, j'y ai passé beaucoup de temps. Un peu avant la date limite de la jam, j'ai coupé dans toutes mes idées un peu originales pour me concentrer sur l'essentiel : un jeu auquel on peut jouer.

Compression de données, compter les répétitions

2025-07-28T00:00:00+02:00

Dès le début de l'informatique, même si je ne saurais pas dater exactement quand, il a été question de stocker ou transmettre des données de manière efficace. Comment stocker ou transmettre un maximum de données avec un minimum d'espace ou de bande passante ? La compression de données répond à cette problématique avec des algorithmes qui repèrent l'information redondante pour la représenter de manière plus concise, ou bien qui éliminent des données jugées'(selon certains critères) moins utiles que d'autres.

Dans ce premier article, nous allons voir ce que j'imagine être la plus simple des méthodes et qui vient souvent à l'esprit en premier lorsque l'on découvre le sujet : la compression RLE (Run Length Encoding).

Le flux d'entrée

Imaginons une image en niveaux de gris que l'on pourrait représenter de cette manière :

................
....#######.....
..##@@@@@@@##...
.##@OOOOOOO@##..
.#@OoooooooO@#..
#@OoooooooooO@#.
#@OoooooooooO@#.
#@OoooooooooO@#.
#@OoooooooooO@#.
#@OoooooooooO@#.
#@OoooooooooO@#.
.#@OoooooooO@#..
.##@OOOOOOO@##..
..##@@@@@@@##...
....#######.....
................

Les niveaux de gris sont représentés par des caractères, et chaque caractère représente un pixel de l'image. L'image est de 16 lignes et 16 colonnes, soit 256 éléments. Ne nous occupons pas pour le moment de comment coder ces éléments. Ce sont juste des éléments.

L'idée générale

L'idée de la compression RLE vient de la constatation rapide qu'il existe des suites de données identiques dans les données, et que l'on peut même facilement énoncer. Par exemple, sur la première ligne, on peut dire qu'il y a 16 fois la valeur .. Sur la deuxième ligne, on peut dire qu'il y a 4 fois la valeur . puis 7 fois la valeur # puis 5 fois la valeur .. Et ainsi de suite.

C'est le principe de la compression RLE : on va remplacer les suites d'éléments identiques par deux éléments : le nombre de répétitions et la valeur répétée. Par exemple, la première ligne devient (16, '.'), la deuxième ligne devient (4, '.'), (7, '#'), (5, '.').

Voilà ce que cela donne pour l'image complète, si on met toutes les lignes bout à bout (sans les sauts de ligne) :

(20,.), (7,#), (7,.), (2,#), (7,@), (2,#), (4,.), (2,#), (1,@), (7,O), (1,@), (2,#), (3,.), (1,#), (1,@), (1,O), (7,o), (1,O), (1,@), (1,#), (2,.), (1,#), (1,@), (1,O), (9,o), (1,O), (1,@), (1,#), (1,.), (1,#), (1,@), (1,O), (9,o), (1,O), (1,@), (1,#), (1,.), (1,#), (1,@), (1,O), (9,o), (1,O), (1,@), (1,#), (1,.), (1,#), (1,@), (1,O), (9,o), (1,O), (1,@), (1,#), (1,.), (1,#), (1,@), (1,O), (9,o), (1,O), (1,@), (1,#), (1,.), (1,#), (1,@), (1,O), (9,o), (1,O), (1,@), (1,#), (2,.), (1,#), (1,@), (1,O), (7,o), (1,O), (1,@), (1,#), (3,.), (2,#), (1,@), (7,O), (1,@), (2,#), (4,.), (2,#), (7,@), (2,#), (7,.), (7,#), (21,.)

Ce qui donne 89 couples de valeurs, soit 178 éléments au total. Contre 256 éléments dans l'image d'origine. On a donc bien réduit le nombre d'éléments nécessaires pour représenter l'image.

Mais attention, ce qui permet la réduction, ce sont les suites de même valeur.

Si les données sont constituées de valeurs souvent changeantes, la compression ne va pas bien fonctionner, voire donner plus d´éléments en sortie. Par exemple, si l'image n’était constituée que de valeurs différentes de leurs précédentes, on devrait à chaque fois écrire (1, élément), et donc au final doubler le nombre d'éléments nécessaires. Pas très efficace.

Codage du flux compressé

Jusqu'à maintenant, on n'a parlé que d'éléments. Cependant, ces éléments doivent être codés d'une manière ou d'une autre pour être stockés sur la machine. Par exemple, on peut considérer assez facilement que le flux d'entrée est codé en caractères sur 8 bits. C'est trop pour 4 valeurs différentes (2 bits sont suffisants), mais on peut imaginer avoir d'autres valeurs sur les 256 possibles dans d'autres images.

On va donc garder cette représentation en 8 bits pour les éléments valeurs. Même en sortie.

Pour le nombre de répétitions, il faut faire un choix sur le plus grand nombre de répétitions possibles. Ces choix vont dépendre de la nature des données. Pour un premier choix, on va faire simple : 256 répétition maximum. Une image de 16x16 éléments monochrome serait donc codée par deux valeurs en 8 bits : (0, valeur). En effet, comme une répétition de 0 n'a pas de sens, on se sert du 0 pour coder 256.

Deux octets au lieu de 256, c'est pas mal. Mais on peut aussi imaginer que les images monochromes ne sont pas représentatives.

En prenant un octet pour les répétitions et un octet pour la valeur, le codage et le décodage sont très simples et la taille pour l'image exemple est de 178 octets, soit 178 octets pour 256 éléments.

Peut-on faire mieux ?

Oui. Il y a plusieurs manières différentes de coder un flux compressé RLE. La méthode indiquée précédemment est la plus simple. Mais on peut en imaginer d'autres.

Par exemple, on peut réserver une plage de nombres dans l'indication des répétitions pour indiquer un nombre d'octets à suivre qui seront recopiés tels quels (parce qu'ils ne présentaient pas de répétition en entrée).

Par exemple, sur un morceau en entrée comme :

....#.#.#.....

On code les valeurs

(r4, '.'), (c5, '#.#.#'), (r3, '.')

Où r signifie "répétition" et c signifie "copie".

D'un point de vue codage, on peut choisir que les valeurs 0 à 127 représentent des répétitions, et les valeurs 128 à 255 représentent des copies.

Voilà ce que cela donne pour l'image complète avec cette méthode :

(20,.), (7,#), (7,.), (2,#), (7,@), (2,#), (4,.), (2,#), (129,@), (7,O), (129,@), (2,#), (3,.), (131,#@O), (7,o), (131,O@#), (2,.), (131,#@O), (9,o), (135,O@#.#@O), (9,o), (135,O@#.#@O), (9,o), (135,O@#.#@O), (9,o), (135,O@#.#@O), (9,o), (135,O@#.#@O), (9,o), (131,O@#), (2,.), (131,#@O), (7,o), (131,O@#), (3,.), (2,#), (129,@), (7,O), (129,@), (2,#), (4,.), (2,#), (7,@), (2,#), (7,.), (7,#), (21,.)

47 éléments au lieu de 89. Des éléments de taille variable cependant. Ici la taille en octets est de 136 plutôt que 178. Ce qui est un nouveau gain (au prix d'une toute petite complexité supplémentaire à traiter à la décompression)

Peut-on faire encore mieux ?

Vous pouvez trouver d'autres manières de coder un flux compressé RLE. En fonction de la plateforme, de la nature des données, de la taille des éléments, etc, il est possible de trouver des ajustements et des variations qui permettent de gagner de la place.

Conclusion

La compression RLE est une méthode simple à comprendre et à implémenter. Le temps de compression et de décompression sont très rapides car les calculs sont très simples.

Elle peut donner de bons résultats sur des données avec beaucoup de plages de même valeur. C'est aussi une méthode non destructive : une fois décompressées, les données sont identiques à l'original avant compression.

Dans un prochain article, nous verrons une autre méthode de compression classique et qui fonctionne bien sur des répétitions de motifs.

Supplément

Le code que j'ai utilisé lors de l'écriture pour vérifier les exemples est disponible ici.

PHC-25, et Z80 en IM 2

2025-06-09T00:00:00+02:00

Ça y est, la nouvelle saison des Retro Programmers United for Obscure System a démarré. Et cette fois, c'est le PHC-25 qui est à l'honneur. Un ordinateur de Sanyo à base de Z80 (d'un clone plus précisément) et d'un MC6845 (... un clone aussi) et plutôt bien fourni en mémoire vive pour cette classe de machines : 16 ko de RAM et 6 ko pour la VRAM, accessible directement par le Z80 (avec des contraintes de timing si on veut éviter des parasites graphiques).

Bien entendu, comme toutes les machines concernées par cette game jam, le PHC-25 est un ordinateur qui n'a pas une grande logithèque, et pas non plus beaucoup d'activité ni de documentation. C'est le principe.

Pour cette Jam, je suis parti sur l'idée que le programme sera en assembleur. Certains vont certainement encore faire des miracles en BASIC, mais ce n'est pas ma tasse de thé, même si je l'ai enté par le passé. Avec la communauté des participants, nous nous sommes donc penchés sur la compréhension de la machine. Pas facile là encore car nous ne sommes pas nombreux à avoir un PHC-25, il faut donc continuellement passer par les bonnes âmes qui peuvent lancer nos tests.

Après quelques jours, j'ai commencé à mettre mes notes, un programme d'exemple et une manière de packager un programme assembleur sur gitlab. C'est principalement le résultat d'un travail de recherche collectif.

J'ai pu aussi corriger deux petits trucs dans MAME, qui reste loin d'être parfait pour le PHC-25, mais qui est un tout petit peu mieux qu'il y a deux semaines. La machine reste assez simple et peu exotique par rapport à d'autres que l'on a traitées auparavant.

IM 2

Lors de nos discussions et analyse, il est apparu que la ROM du PHC-25 lançait une ISR (Interrupt Service Routine) à chaque synchronisation verticale. C'est classique. Pendant cette ISR, la ROM fait les modifications en VRAM en fonction des modifications d'affichages demandées par le BASIC, cela pour éviter les parasites graphiques. Il y a aussi une lecture du clavier, la gestion du son,...

Mais aucune possibilité de reroutage. Là où l'on trouve dans d'autres machines un « hook » sur lequel on peut attacher son propre code, ici, il n'y a rien.

La proposition a été faite de passer le Z80 en IM 2, afin de gérer entièrement l'interruption. Cela fonctionne, et ce que je vais expliquer ici. À noter que l'IM 2 est une fonctionnalité du Z80 et que la grande partie de ce qui suit est valable pour d'autres machines similaires à base de Z80.

Interrupt Mode ?

Le Z80 peut fonctionner selon trois modes d'interruption. Le mode 0 est le mode par défaut. C'est un mode reliquat du 8080. Dans ce mode, lorsque l'interruption est reçue, le Z80 va lire l'instruction suivante qui va lui être présentée depuis un mécanisme externe. Généralement, c'est une instruction RST qui est utilisée, afin de brancher à l'une des routines RESTART du Z80.

Mais la plupart, si ce n'est toutes, des machines familiales à base de Z80 utilisent le mode 1, qui est beaucoup plus simple. Dans ce mode, lorsque l'interruption est reçue, le Z80 branche tout simplement à l'adresse fixe 0x0038, à partir de laquelle on place l'ISR. C'est ce que fait le PHC-25. Mais comme son ISR n'offre pas de moyen d'extension, on est vite limité si on veut prendre les choses en main.

Le mode 2, ou IM 2, est un mode qui est normalement fait pour être utilisé avec un contrôleur d'interruption externe. Dans ce mode, l'interruption est suivie d'une valeur paire sur 8 bits. Cette valeur est utilisée comme index dans une table d'adresses d'ISRs. Le Z80 va lire l'adresse de l'ISR à partir de cette table, puis il va brancher à cette adresse.

Cependant, le PHC-25 n'a pas de contrôleur d'interruption externe. Ainsi, la valeur reçue peut être un peu n'importe quoi (et même pas forcément paire). L'astuce consiste donc à utiliser une table dont toutes les entrées pointent vers la même adresse. Comme l'index peut-être paire ou impaire, cela implique une contrainte supplémentaire : l'adresse de l'ISR doit être composée de deux octets identiques ($FEFE par exemple). Autre petit piège, comme la valeur 255 peut-être reçue, la table doit contenir 257 octets, et non pas 256 uniquement.

En pratique

Voici le code commenté pour mettre en place l'IM 2 sur le PHC-25 :

    ; Code pour l'assembleur SjASMPlus

    org $c009   ; Adresse de départ du programme.
                ; On commence à $C009, car c'est l'adresse de départ
                ; avec le chargeur BASIC utilisé. Mais vous pouvez
                ; adapter.

start:
    call install_im2    ; Le programme démarre par l'installation de l'IM 2

infinite_loop:
    halt                ; Attente de l'interruption
    jp infinite_loop    ; Puis boucle


    ; Installation de l'IM 2
install_im2:
    di      ; On commence par désactiver les interruptions
            ; Comme on va modifier la configuration,
            ; on ne veut pas qu'elles se déclenchent pendant ce temps


    ; Déplace la pile
    ; Peut-être optionnel, mais comme ça, on sait où elle est
    ; On ne pourra pas retourner dans la ROM, mais de toute façon
    ; elle ne fonctionnerait pas en IM2.
    pop hl                  ; sauve l'adresse de retour de la routine
    ld  sp,$fffe            ; place la pile à $FFFE
    push hl                 ; Pousse l'adresse de retour sur la pile
                            ; À présent, le RET peut retourner à l'endroit de l'appel


    ; Remplit la table des vecteurs d'interruption
    ld      hl,$fe00        ; La table démarre en $FE00
    ld      e,l
    ld      d,h
    inc     de              ; Idiome de remplissage de mémoire
    ld      bc,257          ; De longueur 257 octets
    ld      a,$fd           ; Contenant l'adresse $fdfd
    ld      (hl),a
    ldir                    ; Remplissage de mémoire

    ; On place un saut vers l'ISR dans le vecteur d'interruption
    ld      hl,$fdfd        ; L'adresse du vecteur
    ld      a,$c3           ; Instruction de saut (JP) vers xxxx
    ld      (hl),a
    inc     hl
    ld      de,isr          ; L'adresse de l'ISR
    ld      (hl),e
    inc     hl
    ld      (hl),d          ; Met l'adresse de l'ISR après l'instruction JP

    ; Place la table des vecteurs d'interruption ($FExx)
    ld      a,$fe
    ld      i,a             ; Met l'adresse haute à $FE
    im      2               ; Commute en Mode d'Interruption 2

    ; All set
    ei                      ; Réactive les interruptions
    ret

char:
    db      32

    ; Routine de service d'interruption
    ; Appelée au début de la synchronisation verticale
    ; Affiche un caractère en haut à gauche de l'écran
    ; (en mode SCREEN 1)
isr:
    ld      hl,char
    ld      a,(hl)
    inc     (hl)
    ld      hl,$6000
    ld      (hl),a
    ei
    reti

Récréation Famicom

2025-05-16T00:00:00+02:00

Et puisque ces temps-ci, je m'intéresse à la Famicom, en ayant commencé par le Family Basic , j'ai voulu faire une petite image 3D de la console.

Family BASIC, le BASIC sur Famicom

2025-05-10T00:00:00+02:00

L'hiver dernier, j'ai découvert le Family Basic, ou Famibe, un BASIC pour la Famicom (le petit nom de la Family Computer de Nintendo, dont la version occidentale donnera la Nintendo Entertainment System, ou NES).

Le Family Basic, qui vient dans une boite bien visible sur une étagère, comprend une cartouche, un clavier et un manuel. Le clavier est un vrai clavier et est assez agréable à utiliser. Il se branche sur le port d'extension en façade de la console, là où se branchent les périphériques d'entrées supplémentaires, les deux manettes étant connectées à la console « en dur ».

La cartouche est plus haute que les cartouches Famicom classiques, presque la taille d'une cartouche NES. Dedans, il y a de la rom PRG (le programme), de la rom CHR (les données graphiques) et de la RAM (la mémoire vive) supplémentaire. Cette RAM peut d'ailleurs être alimentée par piles lorsque la console est éteinte, ce qui permet de garder des programmes en mémoire.

Quant au manuel, en japonais, il est assez fourni et explique comment utiliser le BASIC, comment utiliser les particularités de celui-ci et contient des listings de programmes à taper, avec des explications.

Ce BASIC est plutôt intéressant, et même si la mémoire vive est très limitées (2ko sur les version 1 et 2 de la cartouche, 4ko sur la version 3), il est possible de faire des choses intéressantes.

Il y a eu plusieurs versions du Family Basic. La première, sortie en 1984, semble ne pas avoir été très fiable et a pu être échangée contre une version 2 (il semble exister une version 2.0 et une version 2.1). Ces deux versions ont une cartouche de couleur noire. La version 3, dans une cartouche rouge et sortie en 1985, est beaucoup plus intéressante : plus de commandes et plus de mémoire vive.

J'ai résumé quelques-unes de mes expériences dans une vidéos que vous pouvez voir ci-dessous.

Un article en anglais, qui donne plus d'informations que ce présent petit article est disponible sur le site Nerdly Pleasures.

Instance Peertube pour Triceraprog

2025-01-12T00:00:00+01:00

Un projet que j'avais depuis un moment maintenant était de mettre en place une instance Peertube pour ce site. J'ai profité d'un changement de version majeur de Peertube pour réactiver ce projet et c'est maintenant chose faite.

J'ai ai donc mis les deux vidéos sur le BASIC et celle sur le LOGO.

Environnement de développement pour Picthorix

2024-11-22T00:00:00+01:00

Forth est naturellement un langage qui est souvent utilisé dans un environnement interactif qui est à la fois un interpréteur et un compilateur. Il est aussi parfois accompagné d'un éditeur qui permet d'enregistrer des pages de code, afin de les sauvegarder, de les recharger et de les exécuter.

Le Hector HRX a bien tout ça, et cela était probablement très agréable dans les conditions d'époque. Enfin, peut-être pas lorsque l'on n'avait que le lecteur de cassette intégré. En effet, le système puissant des écrans charge et sauve les pages automatiquement au besoin. Pratique lorsque la mémoire de masse est à accès direct, comme une disquette. Mais avec une cassette, il faut souvent avancer, rembobiner avec de bonnes chances d'écraser des données.

Pour le développement de Picthorix, j'ai souvent utilisé le mode interactif pour bien comprendre le fonctionnement de certains mots, pour tester des idées, pour vérifier le fonctionnement de certaines parties de mon code. Mais hors de question d'utiliser en continu le mode natif, j'aurais perdu trop de temps en manipulations et en erreurs.

Donc, comme souvent, j'ai réfléchi à un petit environnement de développement à base d'éditeur et d'émulateur sur PC.

Formatage des écrans

Le Hector HRX peut avoir en mémoire 10 écrans simultanés. Chaque écran contient 798 caractères. Chaque caractère est donc précieux. Mais formatter son code pour le rendre lisible et ajouter des commentaire est très précieux aussi, surtout dans un langage que l'on ne maîtrise pas.

J'ai donc fait le choix d'avoir en source un fichier texte de forme libre et d'avoir une moulinette qui compacte le code pour mettre le maximum de code dans un écran. Il existe aussi le mot Forth --> qui permet de lancer l'exécution de l'écran suivant numériquement, la moulinette peut donc ajouter ce mot de transition à la fin de chaque écran, sauf le dernier.

En pratique, il y a quelques pièges dans lesquels je suis tomber. Le premier est que la définition d'un mot ne peut pas commencer sur un écran et continuer dans le suivant. Il aurait fallu avoir un peu d'analyse du code Forth pour faire ce découpage correctement. C'est un piège que j'ai contourné de manière tout à fait manuelle : je place les --> à la main dans le code source pour séparer les screens. Pas le plus agréable, je me suis souvent retrouvé avec des screens trop grands qui ne chargeaient pas correctement, mais pas assez par rapport au temps de développement que cela m'aurait pris.

Second piège, que j'ai mis un moment à comprendre. Parfois, mes affichages de chaînes de caractères étaient décalées, comme si des espaces étaient ajoutées en début de chaîne. J'ai mis un moment à comprendre que c'était parce que la mot de début de chaîne ." se trouvait en fin de ligne, mais pas en dernière caractère, et que le premier mot affiché se trouvait à la ligne suivante. Comme les écrans ont une largeur fixe, des espaces étaient ajoutés mécaniquement en début de chaîne.

J'ai corrigé ça rapidement en revenant à la ligne lors de la détection d'un mot .". Cela fait perdre de l'espace, mais pas trop. Ça passe...

Dernier piège... un développement un peu fait rapidement. La moulinette n'est pas très solide et se plante parfois lorsque la ligne source est « trop » longue. Je n'ai pas analysé pourquoi. J'ai contourné le problème en coupant les lignes trop longues dans le source lorsque le bug apparaissait. Celui-ci provoque un saut au prochain screen pour une raison qui m'échappe, mais qui serait probablement simple à comprendre avec du temps pour le débugger. Je n'ai pas pris ce temps.

L'éditeur

Le code source est édité dans Visual Code, mais techniquement, il n'y a rien de spécial. Je ne l'ai pas spécifiquement customisé, à part une petite colorisation syntaxique.

L'émulateur

Comme d'habitude, j'utilise MAME pour son scripting Lua qui a un accès au debugger. J'ai fais évoluer le script déjà utilisé dans des précédents projets (description initiale ici). Il a fallu bien entendu adapter les points d'arrêt pour l'automatisation et injecter les écrans préalablement converti en format binaire en mémoire.

L'injection des écrans directement en mémoire est un peu fragile. En effet, Forth ajuste des variables lorsque l'on créé et on manipule des écrans. J'ai tenter de forcer ces variables à des valeurs connues en fonction des écrans injectés, mais sans vraiment de succès. Je me retrouvais avec un environnement extrêmement instable. J'ai cependant repéré qu'en évitant d'utiliser le premier écran, le système se comportait bien. Tant pis pour la perte d'un écran.

Une fois les écrans injectés, je lance la compilation en passant l'émulateur en mode rapide, et j'obtiens ainsi un compilateur. La nature du Forth fait qu'à la fin du processus, j'ai une image du jeu compilé en mémoire à un emplacement tout à fait déterminé.

À partir de là, soit je peux lancer le jeu pour les tests, soit tester certains mots. Je peux aussi sauvegarder la mémoire pour la recharger plus tard.

Comme au bout d'un moment, j'ai rempli tous les screens, j'ai eu besoin d'une deuxième série d'écran à compiler à la suite. Pour scripter cela, le dernier écran de la première série termine en écrivant à un endroit précis de la mémoire et très éloigné de l'espace utilisé. Le script Lua détecte cette écriture et injecte la nouvelle série d'écran, puis lance une nouvelle compilation.

Cela aurait pu être étendu à plus de séries d'écrans, il reste encore beaucoup de place en mémoire avec le jeu au complet. Cependant, comme il s'agit de le mettre sur cassette à la fin, il faut aussi veiller à ce que le temps de chargement soit de durée acceptable.

Toujours automatiser !

C'est mon conseil récurrent, et je le répète à nouveau. La dernière étape pour créer un jeu distribuable est donc de dumper la mémoire contenant tous les mots compilés qui forment le jeu. À partir du debuggeur, il faut donc spécifier une plage mémoire à sauvegarder et une adresse du mot de démarrage. Pour cela, en fin de compilation de la dernière série de screen, j'affichais les informations (taille, adresse de début) à l'écran. Restait à utiliser ces informations dans le debugger pour sauvegarder la mémoire.

Le jour où je voulais publier le jeu, impossible d'avoir un dump qui fonctionne. J'ai passé la soirée à analyser un bug. Forcément, un vendredi soir, la fatigue de fin de semaine n'aide pas. Je suis allé me coucher sans trouver. Le lendemain, je relance et je trouve immédiatement (une bonne nuit de sommeil, ça aide). La taille que j'avais recopié à la main pour le dump n'était pas la bonne, de quatre octets...

J'ai donc ajouté au script Lua le dump automatique, en allant chercher l'information sur la taille laissée par la fin de la compilation en mémoire.

Conclusion

Chaque operation manuelle répétée est une occasion de perdre son temps...

À part ça, pas grand chose de neuf. Les outils sont disponibles dans les sources du jeu. Cependant, à la date d'écriture de cet article, avoir un Hector HRX qui fonctionne bien sur MAME nécessite quelques modifications que je n'ai pas encore proposé pour intégration. Mais cela sera fait quand j'aurais nettoyé les changements et vérifié que je n'ai pas cassé d'autres machines.

Un jeu en Forth pour Hector HRX : Picthorix

2024-11-18T00:00:00+01:00

À nouvelle édition de Retro Programmers United for Obscure Systems, nouvelle machine et une nouvelle participation.

La gamme de machine couverte par cette édition est la gamme Hector HR et suivants : 2HR, 2HR+, HRX, MX40 et MX80. Pour des informations sur cette gamme de machines, je vous invite à consulter cette page.

Hector HRX

Ces machines forment une gamme de machines vaguement compatibles les unes avec les autres. Des petites différences de matériel, et surtout de ROM, font que les programmes ne sont pas forcément compatibles entre les différentes machines. D'après ce que j'ai compris, pour rien n'arranger, c'était une machine ouverte à la bidouille et aux modifications hardware. Le parc de machines devait donc être assez hétérogène.

De la gamme, j'ai donc choisi une machine : le HRX. Pour deux raisons. La première est parce que j'en avais une sous la main (mais en demande de réparation), et j'aime bien pouvoir voir la machine pour imaginer le jeu qui va avec (et pour tester... quand la machine fonctionne). La seconde car c'est une machine qui a un Forth résident. Et si je connais un peu le Forth pour avoir joué avec et lu à son propos, je n'avais jamais développé un programme complet en Forth. Or, c'est dans ces situations que l'on découvre vraiment un langage.

La découverte

La première étape, comment toujours, est de découvrir la machine. Il y a pas mal de documentation disponible sur les différentes machines, surtout sous forme de magazines spécialisés à petits tirages (j'imagine), un peu de document de reverse engineering, des plans des certaines des machines (dont le HRX) et le code source de MAME. Il existe même un manuel Forth, sous forme de didacticiel, pour le HRX. Ce manuel m'a été très utile pour me remettre dans l'esprit Forth et faire le tour des capacités de la machine.

Une fois lu le manuel et fait quelques exercices et tests, j'ai démarré... non pas le jeu, mais une relecture du manual, en notant tous les mots Forth et leur fonctionnement, afin de les classer par catégorie, les expliquer et les rendre accessible sous forme de référence en ligne, indexé. Cela m'a pris pas mal de temps, mais j'étais certain d'avoir parcouru tous les mots, de les avoir presque tous compris, et surtout, de pouvoir les retrouver rapidement.

Le résultat est disponible sur cette page.

Ce n'est pas tout à fait complet et j'y trouve encore quelques petites erreurs en m'y référant, mais c'est déjà très utilisable. Le code source de la page est disponible si vous voulez le compléter.

L'environnement de développement

Le Forth du HRX est fourni avec un système de « screen », qui est classique pour le Forth. Les « screens » permettent d'éditer et d'enregistrer des données, généralement des commandes et des mots, pour les réutiliser à volonté. Le système offre du paging automatique mais avec un système sur cassette, c'est pratiquement inutilisable.

De plus, l'éditeur est un éditeur de ligne, pas très agréable, même si ça dépanne. Il existe un éditeur pleine page que l'on peut charger depuis une disquette. Ça peut être intéressant pour retrouver les sensations sur la machine, mais pour un développement, je trouvais ça un peu lourd.

J'ai donc, comme souvent, créé mon petit environnement en utilisant MAME et un script d'automatisation. Je ferai un article à ce sujet par la suite. Sans détail, cela m'a permis de programmer depuis Visual Code et de lancer une compilation en me servant de la machine émulée.

Le jeu

Lorsque je n'ai pas une machine fonctionnelle sous la main, je préfère chercher des idées de jeux qui ne vont pas pousser les performances ou les exotismes de la machine. Particulièrement dans le cas de ces machines avec peu d'activité, où les émulateurs ne sont pas toujours très fidèles.

Mon fils m'a proposé alors l'idée d'un Picross, aussi connu sous le nom de Nonogram ou encore Logimage... et plein d'autres noms. L'idée est de remplir une grille en suivant des indications sur les groupes de « pixels » par lignes et par colonnes. Bonne idée, je suis parti là-dessus.

Du à ma méconnaissance du Forth, ça a été assez laborieux. J'ai pas mal appris au passage et j'écrirais certaines choses probablement différemment si je devais recommencer. Je n'ai pas utilisé les capacités de la machines au niveau graphique, qui peut aller bien plus loin que ça, avec de l'adressage au pixel sans color clash.

Au passage, j'ai aussi appris à créer des grilles de Picross. Pour cela, j'ai utilisé un programme un ligne qui permet de savoir si la grille est résolvable ou pas. C'est pratique, car il ne suffit pas de faire une grille avec un dessin sympa. Il faut à cette grille une solution unique, ce qui n'est pas toujours le cas sur une grille quelconque.

Au final, j'ai créé 9 grilles, dont deux vraiment comme une initiation et cinq comme références aux cinq jeux précédents avec lesquels j'ai participé aux précédentes éditions de RPUfOS.

Pour télécharger le jeu, c'est sur la page itch.io.

Le code source est disponible
Vidéo de Retro Vynz contenant une revue du jeu
Vidéo de Olipix une présentation et revue du jeu ainsi qu'un petit passage où j'interviens (en disant globalement la même chose que dans cet article)

Yeno SC-3000 et condensateurs

2024-09-14T00:00:00+02:00

Suite à une panne sur un Yeno SC-3000 récemment, j'ai du changer un condensateur. En travail préparatoire, j'ai fait une photo annotée de la carte mère.Là voici, si ça peut aider.

L'image est cliquable pour l'agrandir.

Suite de tests pour VG5000µ

2024-09-06T00:00:00+02:00

Il y a quelques années, j'avais commencé une suite de tests pour le VG5000µ sous la forme d'un programme en mélange de C et assembleur. L'idée était double : écrire une référence pour s'inspirer dans la programmation du VG5000µ (et particulièrement de l'EF9345), ainsi que tester la fidélité des émulateurs.

Je me suis servi de cette base de code pour la première raison et mes besoins personnels. J'ai aussi pu corriger une paire de bugs dans MAME grâce à la seconde utilisation.

Cependant, cette base de code traîne depuis un moment sur mon disque et je n'y passe pas beaucoup de temps. Alors autant que ça serve à d'autres, et je mets donc aujourd'hui cette base à disposition.

Je ne sais plus trop dans quel état il est. Ça doit globalement fonctionner. J'imagine.

En tout cas, c'est dispo sous licence CC0, donc faites-en ce que vous voulez.

Un peu d'Atari ST

2024-08-31T00:00:00+02:00

Ce site est, en tout cas a été jusqu'à maintenant, très machines 8 bits. Du fait des participations aux Retro Programmers United for Obscure Systems, mais aussi aux machines sur lesquelles je m'amuse le plus. L'avantage des machines 8 bits, c'est qu'elles la plupart du temps assez simple à comprendre, à programmer, avec des designs techniques parfois originaux mais qui restent abordables.

Cependant, il y a peu, Zisquier a lancé un site pour aborder le 68000 à travers la programmation en assembleur sur Atari ST. Je m'étais lancé dans l'idée d'essayer d'enseigner l'assembleur de manière ludique, mais comme on dit, « life happens » et je n'ai pas poursuit sur la lancée.

Comme j'étais en pause d'été, que l'Atari ST (STE en réalité) fait partie de mon historique de machines personnelles, et que j'avais quitté cette machine sans en avoir fait le tour je pense, même si j'y avais fait un peu d'assembleur, je me suis dit que c'était l'occasion de la redécouvrir. Par la programmation bien entendu.

Le ton de Zisquier est direct, il va à l'essentiel, progressivement. Il y a des tests à la fin des leçons qui apportent un petit côté ludique. C'est fun et j'aime bien. Et petit à petit, me voici actuellement avec un sprite qui se déplace à l'écran au-dessus d'un décors.

Le code est un peu moche, j'y vais un peu à tâtons et je ne sais pas toujours quels sont les meilleurs façon d'utiliser les instructions 68000. Mais il y a un Discord associé avec des personnes qui sont aidantes sur le sujet.

Le sprite est en CC-BY 3.0 par « Withthelove », trouvé sur OpenGameArt.org.

Le tileset est en CC0 par « Kenney », c'est Tiny Town remanié au niveau de la palette de couleurs et du layout pour correspondre à l'Atari ST et à mon besoin.

Le Forth sur Hector HRX

2024-08-15T00:00:00+02:00

Avec la nouvelle session de Retro Programmers United for Obscure Systems, il est temps de découvrir la ligne des Hector HR. Que ce soit l'Hector 2HR, le 2HR+, le HRX et probablement le MX.

Pour en savoir plus sur ces ordinateurs, il existe une page dédiée à ces machines.

Après avoir cherché un peu dans les resources Hector, je me suis dirigé pour ma contribution à cette session vers le « Hector HRX » et son Forth. En effet, le HRX est un de ces rares ordinateurs 8 bits qui venait avec un Forth en ROM, au lieu du plus classique BASIC.

Il existe un livre sur le Forth pour Hector HRX, « la pratique du Forth avec Hector », qui est plutôt agréable à lire afin de découvrir la machine à travers ce langage, et pourquoi pas, découvrir le Forth au passage.

L'ennui avec le livre, c'est qu'il présente les mots en contexte, mais qu'il n'y a pas de référence regroupement les mots par catégorie, ou par usage. Il faut donc se souvenir du passage où le mot est présenté, et le retrouver parmi la prose pédagogique.

Je n'étais pas non plus certain que tous les mots soient présentés par le livre (après en avoir fait la liste, il en manque bien quelques uns, mais c'est en fait très complet).

Pour moi, il manquait donc une référence, et c'est ce que je me suis appliqué à faire. Cette référence n'est pas un apprentissage du Forth, la lecture du livre ou d'une autre ressource est nécessaire. Par contre, elle présente une liste catégorisée des mots ainsi que les grands principes du Forth et son implémentation sur Hector HRX.

Éspérant donc que cette référence pourra vous être utile comme elle l'est pour moi, je l'ai publiée à cette adresse.

J'MSX 24 et un micro jeu

2024-07-02T00:00:00+02:00

Le salon

Les 23 et 23 mai 2024 ont eu lieu à Paris deux journées autour du MSX. La rencontre se passait à ISART, une école de jeux vidéo, et était co-organisée par l'association MO5 et le MSX Village.

Deux journées vraiment sympas avec quelques conférences, dont certaines faites par le concepteur du MSX en personne, Kazuhiko Nishi, qui avait fait le déplacement. Son but est de présenter ses projets de MSX0 et MSX3, sur lesquels je ne m'étendrai pas ici.

Pour moi, cela a été l'occasion de rencontrer des gens passionnés par le MSX. N'étant moi-même pas très connaisseur de la machine, en tout cas pas autant qu'eux, j'ai pu apprendre plein de choses. Outre une exposition autour des jeux Konami, avec plein de MSX jouables en libre service, il y avait une petite exposition d'illustrations faites dans des modes de rendus MSX, ainsi qu'une présentation de diverses extensions modernes et françaises pour les machines du standard.

La game jam

Pendant le week-end, une game jam a été proposées aux étudiants de l'école qui nous accueillait. Quelques étudiants se sont prêtés au jeu. Le but était bien évidemment de créer un jeu pour MSX, fonctionnel sur une machine réelle, et donc de comprendre ses contraintes. L'organisateur les avait briefé auparavant, pour ne pas partir de zéro le jour J.

Le thème ? « l'amour éternel ». Il y avait de bonnes idées autour du thème, mais je ne sais pas si les jeux ont été terminés.

De mon côté, j'étais titillé par l'idée de participer. Mais je ne voulais pas non plus y passer le week-end. J'ai donc fait rapidement un petit truc le dimanche matin, probablement en 2 ou 3 heures tout en déambulant dans le salon. Le résultat n'est pas tout à fait un jeu : on ne peut pas gagner. Mais on peut perdre, et c'est déjà ça. On pourrait ajouter au jeu un score à maximiser...

Dans ce jeu, il faut attraper des logos MSX qui apparaissent sur le terrain. Lorsqu'on en attrape un, cela laisse sur place un petit visage souriant, propageant ainsi l'amour éternel du MSX. Ces visages gênent les déplacements, et il devient donc de plus en plus difficile d'attraper les logos. Le jeu est en mode 1 et est jouable sur un MSX1. J'ai bien entendu utilisé la librairie MSXgl que nous utilisons aussi pour le projet Room 5 pendant les lives twitch de l'association MO5. Jeu qui d'ailleurs était jouable sur place et sur vrai matériel.

Bref, deux journées qui font plaisir.

Récréation 3D, Matra Alice

2024-06-08T00:00:00+02:00

Suite à des discussions semi-sérieuses sur la possibilité de transporter un Matra Alice pour l'utiliser à la plage, je me suis amusé à imaginer (et à modéliser) une extension « batterie + écran » pour le Matra Alice.

Ce n'est qu'une vue d'artiste, aucune étude de faisabilité n'a été faite. Mécaniquement, je n'ai aucune idée de si ça tiendrait, je ne sais pas si ça serait pratique... c'est pour le fun !

Dans cette hypothétique extension qui se clipserait à l'arrière de la machine, on peut imaginer des batteries pour fournir les 5V nécessaires (si on laisse tomber le port série), des connecteurs pour amener le signal vidéo à un écran plat. Et pourquoi pas une extension RAM ?

On m'a signalé que la chaîne YouTube « The Taylor and Amy Show » avait adapté un écran plat à un TRS-80 MC-10, si vous voulez voir ça, c'est par ici.

Tuiles des plus très-curieuses

2024-05-07T00:00:00+02:00

Et voici la cinquième session de Retro Programmers United for Obscure Systems, organisée par Olipix qui se termine !

Et j'y ai participé.

La machine

Tout d'abord, la machine. Le principe de cette game jam est de développer un jeu pour une machine qui n'a pas eu une grande ludothèque. Avec le Matra Alice, la question se posait. En effet, la première machine de la gamme, le Matra Alice 4k, est la même machine que le Tandy MC-10, qui a lui une ludothèque un peu plus fournie.

L'idée était donc de se concentrer plutôt sur les deux autres machines de la gamme commerciale : le Matra Alice 32 et le Matra Alice 90. Ces machines, qui offrent une compatibilité au niveau BASIC avec la première, sont néanmoins différentes, en particulier à cause d'un processeur graphique différent. Dans ces deux machines, il s'agit de l'EF9345. Le même qui équipe le VG5000µ, avec la même taille de mémoire vidéo associée, 8k.

Autant dire que niveau graphique, j'étais en terrain connu.

Niveau processeur par contre, c'est une découverte. Le 6803 est un microcontrôleur 8 bits, de la famille des 6800. Mais je ne connaissais pas vraiment. En tout cas, je n'en avais aucune pratique. Il a de la RAM embarquée sur la page 0. Il a aussi un chronomètre (timer), normalement utilisée pour les communications (séries et cassette).

Le développement

Avant de parler du jeu, un mot sur le développement. Comme je venais de recevoir l'extension « Multiports » , je voulais que le jeu puisse être sur cartouche. Autre avantage, pas de temps de chargement si l'émulateur gère bien cette extension.

Vous le savez si vous avez lu d'autres articles sur ce blog, j'aime bien avoir une chaîne de développement avec le maximum d'automatismes, pour me concentrer sur le développement du jeu et faire le moins d'opérations manuelles possibles.

Mon choix habituel va vers MAME. Et MAME a un support pour l'Alice... mais pas pour l'extension. Mon premier développement a donc été d'ajouter à MAME le support de l'extension, en tout cas le support cartouche et l'ajout de RAM. Le changement a été accepté, mais j'ai quelques modifications qui m'ont été demandées et que je dois toujours terminer.

Utilisant mes scripts d'automatisation habituels, j'avais en tout cas de quoi lancer l'émulateur automatiquement après une compilation.

Cependant pour compiler... il faut un compilateur. Il n'y a pas beaucoup de choix pour le 6803 pour un compilateur C, et légèrement plus, mais pas trop, pour un assembleur. Dans un premier temps, j'ai fais quelques tests avec un premier assembleur... mais avec le jeu que je voulais faire, je me suis dit que j'y gagnerais en productivité avec un compilateur C.

Après quelques recherches et essais, j'ai choisi CC6303. Le message « The assembler and linker should be reasonably reliable and complete. » m'a fait un peu peur, mais j'ai quand même tenté. J'ai fais des tests, et ça semblait générer du code correct.

Sur toute la durée du développement, j'ai eu deux fois des problèmes de génération de code. Je ne les ai pas analysés plus que ça, car c'était (bien entendu) vers la fin.

J'ai contribué à une paire de modifications au passage. Au moins, la game jam aura permis modestement d'améliorer les outils de développement pour cette machine.

Le jeu

Comme d'habitude, je suis parti sur une idée bien trop ambitieuse, et avec le premiers mois consacré à la découverte de la machine et aux modifications de MAME, j'ai dû revoir mes plans. En fait, même avec la totalité du temps, je n'aurais pas pu faire ce que je voulais...

Je suis donc parti sur une idée de jeu que je voulais aussi faire : un Match-3. C'est un type de jeu auquel je joue beaucoup. C'est aussi un type de jeu qui a beaucoup de variations : est-ce que les tuiles tombent, est-ce qu'elles montent, est-ce qu'elles sont renouvelées, quel scoring, quels bonus, des challenges, etc.

Pour démarrer, j'ai fait un prototype avec un terrain de 10 par 10, toujours rempli de tuiles. Lorsque 3 tuiles identiques ou plus sont alignées, elles disparaissent. Les tuiles du dessus tombent, et des nouvelles tuiles apparaissent en haut. Les tuiles étaient représentées par des chiffres. Le but pour moi était de 1/ trouver l'algorithme de recherche des tuiles alignées, 2/ vérifier que la machine était assez puissante pour ce type de jeu.

Une fois le prototype fonctionnel, j'ai commencé à ajouter des graphismes. J'ai utilisé Pixelorama pour dessiner les tuiles, avec un thème « Alice au Pays des Merveilles ». Comme je l'ai fait auparavant, j'exporte manuellement les images en PNG (j'aimerais bien un export automatique, mais cela ne semble pas possible pour le moment, ou alors je n'ai pas trouvé). Ces imagines PNG sont ensuite converties en données dans un format que je peux inclure dans le code.

De temps en temps, je lançais un test sur la machine réelle. C'est ainsi que je me suis aperçu que mon extension a un problème avec son extension RAM. Comme je n'avais pas le temps de m'en occupé, j'ai coupé la RAM supplémentaire (c'est une option de l'extension). Le jeu n'a pas besoin de beaucoup de mémoire, le code et les données graphiques étant présents dans la ROM.

Une fois le jeu fonctionnel, je voulais ajouter un principe de challenges pour avoir une sorte de mode « histoire ». Je voulais aussi ajouter un mode « infini », mais je n'aurai pas assez de place pour ça. Je voulais aussi ajouter un petit personnage qui réagit aux actions du joueur.

Dessiner un personnage avec les contraintes de couleur et mes (bas) talents de dessinateur a été un peu compliqué, mais je suis assez content du résultat.

Problème : la place sur la cartouche. Une cartouche d'extension Multiports a une taille totale de 64k. En mode cartouche, cette taille est divisée en 8 banques de 8k. Cela signifie qu'à un moment donné, il n'y a que 8ko accessible. Le Multiports a un système simpliste de changement de banque : il suffit d'écrire sur une plage de donnée précise le numéro de la banque voulue. C'est suffisant, mais sans support du compilateur, c'est un peu acrobatique.

Je n'avais pas le temps de pousser un système d'appels de code entre les banques, j'ai donc séparé le jeu en deux grandes parties. Dans la première partie, et donc la première banque, je mets tout ce qui est graphiques. C'est une astuce sur les jeux cassettes que je reprends ici : un premier programme se charge et redéfini les caractères. Ensuite, il lance le jeu.

La première banque contient aussi l'écran de titre.

Le cœur du jeu est dans la deuxième banque. Pour passer d'une banque à l'autre, j'ai un petit bout de code que je place en RAM pour faire le changement. Chaque programme est compilé comme un logiciel indépendant.

Mais... et le titre ?

Le titre est une référence à la traduction française de « Alice's Adventures in Wonderland » qui est trouvable sur le projet Gutenberg. Le chapitre deux commence par ce passage : « “De plus très-curieux en plus très-curieux!” s’écria Alice ».

Dans mon jeu, Alice se retrouve dans un monde étrange avec des tuiles à aligner. On ne peut pas dire que ça va très loin d'un point de vue histoire et justification... mais ça suffira.

Oh, et j'ai aussi dessiné une jaquette pour la cartouche et la manuel. À base de dessin sur tablette et de beaucoup de temps de retouche avec The Gimp, puis de composition avec Blender pour ajouter les tuiles.

Quelques liens

Le code source est disponible.
Vidéo de Retro Vynz

Vidéo de Olipix

Conclusion

Le jeu est disponible sur itch.io. J'ai rapidement ajouté une version cassette, car tout le monde n'a pas un Multiports (pas encore disponible sur la page, elle sera dans la version 1.1 que j'ajouterai bientôt).

Notes sur le Motorola 6809

2024-02-23T00:00:00+01:00

Je place ici quelques notes sur le Motorola 6809, pour me remettre rapidement dans le bain lorsque je change de processeur.

Registres

2 accumulateurs 8 bits A et B, qui peuvent se joindre en un seul accumulateur 16 bits D
1 registre d'index X 16 bits
1 registre SP (Stack Pointer)
1 registre PC (Program Counter)
1 registre d'état : 11HINZVC
- 5, H : half carry
- 4, I : interrupt
- 3, N : negative
- 2, Z : zero
- 1, V : overflow
- 0, C : carry

Interruptions

NMI (Non Maskable Interrupt)
IRQ1 (Interrupt Request) : pour les périphériques externes
IRQ2 (Interrupt Request) : pour le timer et l'interface série

IRQ1 a la priorité sur IRQ2.

Vecteurs d’interruptions :

MSB	LSB	Interruption
FFFE	FFFF	Reset
FFFC	FFFD	NMI
FFFA	FFFB	Software interrupt (SWI)
FFF8	FFF9	IRQ1
FFF6	FFF7	ICF (Input Capture)
FFF4	FFF5	OCF (Output Compare)
FFF2	FFF3	TOF (Timer Overflow)
FFF0	FFF1	SCI (RDRF + ORFE + TDRE)

Ensemble des Instructions

Mode d'adressage

Implied/Inherent : aucune donnée n'est nécessaire
Immediate : la donnée est dans l'instruction (1 ou 2 octets)
Direct : la donnée est dans l'octet suivant (1 octet, le poids fort est fixé à $00)
Extended : la donnée est dans les deux octets suivants (adresse 16 bits)
Indexed : la donnée est dans la mémoire, à l'adresse donnée par le registre d'index (opérande de 8 bits ajoutée à X)
Relative : la donnée est dans l'octet suivant, signée (pour les branchements)

Instructions

Opérations à pointeur	Mnemonic	Imm	Dir	Ind	Ext	Inh	Operation	HINZVC
Compare Index Reg	CPX	X	X	X	X		X - M : M + 1	..!!!!
Decrement Index Reg	DEX					X	X - 1-> X	...!..
Decrement SP	DES					X	SP - 1-> SP	......
Increment Index Reg	INX					X	X + 1-> X	...!..
Increment SP	INS					X	SP + 1-> SP	......
Load Index Reg	LDX	X	X	X	X		M -> Xh, M+1 -> Xl	..!!0.
Load SP	LDS	X	X	X	X		M -> SPh, M+1 -> SPl	..!!0.
Store Index Reg	STX		X	X	X		Xh -> M, Xl -> M+1	..!!0.
Store SP	STS		X	X	X		SPh -> M, SPl -> M+1	..!!0.
Index to Stack	TXS					X	X - 1 -> SP	......
Stack to Index	TSX					X	SP + 1 -> X	......
Add B with X	ABX					X	B + X -> B	......
Push X	PSHX					X	Xl->(SP),SP-1>SP,Xh...	......
Pull X	PULX					X	(SP)+1->SP,Xh->Xh,...	......

Operations Acc. & Mémoire	Mnemonic	Imm	Dir	Ind	Ext	Inh	Operation	HINZVC
Add Accumulators	ABA					X	A + B -> A	!.!!!!
Add B to X	ABX					X	00:B + X -> X	......
Add A with Carry	ADCA	X	X	X	X		A + M + C -> A	!.!!!!
Add B with Carry	ADCB	X	X	X	X		B + M + C -> B	!.!!!!
Add with A	ADDA	X	X	X	X		A + M -> A	!.!!!!
Add with B	ADDB	X	X	X	X		B + M -> B	!.!!!!
Add Double	ADDD	X	X	X	X		D + M:M+1 -> D	..!!!!
And with A	ANDA	X	X	X	X		A & M -> A	..!!0.
And with B	ANDB	X	X	X	X		B & M -> B	..!!0.
Shift Left Arithmetic M	ASL			X	X		B7 dans C, C dans B0	..!!!!
Shift Left Arithmetic A	ASLA					X	B7 dans C, C dans B0	..!!!!
Shift Left Arithmetic B	ASLB					X	B7 dans C, C dans B0	..!!!!
Shift Left Arithmetic D	ASLD					X	B15 dans C, C dans B0 ?	..!!!!
Shift Right Arithmetic M	ASR			X	X		B0 dans C, B7 dans B7	..!!!!
Shift Right Arithmetic A	ASRA					X	B0 dans C, B7 dans B7	..!!!!
Shift Right Arithmetic B	ASRB					X	B0 dans C, B7 dans B7	..!!!!
Bit Test A	BITA	X	X	X	X		A & M, A non modifié	..!!0.
Bit Test B	BITB	X	X	X	X		B & M, B non modifié	..!!0.
Compare A/B with M	CBA					X	A & B, A/B non modifié	..!!!!
Clear Memory	CLR			X	X		00 -> M	..0100
Clear A	CLRA					X	0 -> A	..0100
Clear B	CLRB					X	0 -> B	..0100
Compare with A	CMPA	X	X	X	X		A - M	..!!!!
Compare with B	CMPB	X	X	X	X		B - M	..!!!!
1's Complement M	COM			X	X		~M -> M	..!!01
1's Complement A	COMA					X	~A -> A	..!!01
1's Complement B	COMB					X	~B -> B	..!!01
Decimal Adj. A	DAA					X	Ajustement BCD	..!!!!
Decrement M	DEC			X	X		M - 1 -> M	..!!!.
Decrement A	DECA					X	A - 1 -> A	..!!!.
Decrement B	DECB					X	B - 1 -> B	..!!!.
Exclusive OR with A	EORA	X	X	X	X		A ^ M -> A	..!!0.
Exclusive OR with B	EORB	X	X	X	X		B ^ M -> B	..!!0.
Increment M	INC			X	X		M + 1 -> M	..!!!.
Increment A	INCA					X	A + 1 -> A	..!!!.
Increment B	INCB					X	B + 1 -> B	..!!!.
Load to A	LDAA	X	X	X	X		M -> A	..!!0.
Load to B	LDAB	X	X	X	X		M -> B	..!!0.
Load to D	LDD	X	X	X	X		M:M+1 -> D	..!!0.
Logical Shift Left M	LSL			X	X		B7 dans C, 0 dans B0	..!!!!
Logical Shift Left A	LSLA					X	B7 dans C, 0 dans B0	..!!!!
Logical Shift Left B	LSLB					X	B7 dans C, 0 dans B0	..!!!!
Logical Shift Left D	LSLD					X	B15 dans C, 0 dans B0 ?	..!!!!
Shift Right Logical M	LSR			X	X		B0 dans C, 0 dans B7	..0!!!
Shift Right Logical A	LSRA					X	B0 dans C, 0 dans B7	..0!!!
Shift Right Logical B	LSRB					X	B0 dans C, 0 dans B7	..0!!!
Shift Right Logical D	LSRD					X	B0 dans C, 0 dans B15 ?	..0!!!
Multiply	MUL					X	A * B -> D	.....!
2's Complement M	NEG			X	X		-M -> M	..!!!!
2's Complement A	NEGA					X	-A -> A	..!!!!
2's Complement B	NEGB					X	-B -> B	..!!!!
No Operation	NOP					X		......
Logical OR with A	ORAA	X	X	X	X		A	M -> A
Logical OR with B	ORAB	X	X	X	X		B	M -> B
Push A	PSHA					X	A -> (SP), SP - 1 -> SP	......
Push B	PSHB					X	B -> (SP), SP - 1 -> SP	......
Pull A	PULA					X	SP + 1 -> SP, (SP) -> A	......
Pull B	PULB					X	SP + 1 -> SP, (SP) -> B	......
Rotate Left M	ROL			X	X		C dans B0, B7 dans C	..!!!!
Rotate Left A	ROLA					X	C dans B0, B7 dans C	..!!!!
Rotate Left B	ROLB					X	C dans B0, B7 dans C	..!!!!
Rotate Right M	ROR			X	X		C dans B7, B0 dans C	..!!!!
Rotate Right A	RORA					X	C dans B7, B0 dans C	..!!!!
Rotate Right B	RORB					X	C dans B7, B0 dans C	..!!!!
Subtract A with B	SBA					X	A - B -> A	..!!!!
Subtract with Carry with A	SBCA	X	X	X	X		A - M - C -> A	..!!!!
Subtract with Carry with B	SBCB	X	X	X	X		B - M - C -> B	..!!!!
Store A	STAA		X	X	X		A -> M	..!!0.
Store B	STAB		X	X	X		B -> M	..!!0.
Store D	STD		X	X	X		D -> M:M+1	..!!0.
Subtract from A	SUBA	X	X	X	X		A - M -> A	..!!!!
Subtract from B	SUBB	X	X	X	X		B - M -> B	..!!!!
Subtract Double	SUBD	X	X	X	X		D - M:M+1 -> D	..!!!!
Transfer A to B	TAB					X	A -> B	..!!0.
Transfer B to A	TBA					X	B -> A	..!!0.
Test Zero or Minus M	TST			X	X		M, M non modifié	..!!00
Test Zero or Minus A	TSTA					X	A, A non modifié	..!!00
Test Zero or Minus B	TSTB					X	B, B non modifié	..!!00

Sauts et Branches	Mnemonic	Dir	Rel	Ind	Ext	Inh	Test	HINZVC
Branch Always	BRA		X					......
Branch Never	BRN		X					......
Branch on Carry Clear	BCC		X				C = 0	......
Branch on Carry Set	BCS		X				C = 1	......
Branch on Equal	BEQ		X				Z = 1	......
Branch on Greater or Equal	BGE		X				N ^ V = 0	......
Branch on Greater	BGT		X				(N ^ V)	Z = 0
Branch on Higher	BHI		X				C + Z = 0	......
Branch on Higher or Same	BHS		X				C = 0	......
Branch on Less or Equal	BLE		X				(N ^ V)	Z = 1
Branch on Less than 0	BLT		X				N ^ V = 1	......
Branch on Minus	BMI		X				N = 1	......
Branch on Not Equal	BNE		X				Z = 0	......
Branch on Overflow Clear	BVC		X				V = 0	......
Branch on Overflow Set	BVS		X				V = 1	......
Branch on Plus	BPL		X				N = 0	......
Branch to Subroutine	BSR		X					......
Jump	JMP			X	X			......
Jump to Subroutine	JSR	X		X	X			......
Return from Interrupt	RTI					X		!!!!!!
Return from Subroutine	RTS					X		......
Software Interrupt	SWI					X		!1!!!!
Wait for Interrupt	WAI					X		......

Manipulation des drapeaux	Mnemonic	Inh	Operation	HINZVC
Clear Carry	CLC	X	0 -> C	.....0
Clear Interrupt	CLI	X	0 -> I	.0....
Clear Overflow	CLV	X	0 -> V	....0.
Set Carry	SEC	X	1 -> C	.....1
Set Interrupt	SEI	X	1 -> I	.1....
Set Overflow	SEV	X	1 -> V	....1.
Accumulator to CCR	TAP	X	A -> CCR	!!!!!!
CCR to Accumulator	TPA	X	CCR -> A	......

Ports

Port 1

P10-P17 : entrées/sorties, 8 bits. Toutes les lignes sont configurables en entrée ou en sortie indépendamment.

Port 2

P20-P24 : entrées/sorties, 5 bits.

P20 et P21 déterminent le mode de fonctionnement du processeur (lors du reset)
Si P21 est configuré en sortie, il est lié à la fonction de comparison du timer
Peut être utilisé comme port série
Les lignes sont configurables en entrée ou en sortie indépendamment.

Port 3

P30-P37 : entrées/sorties, 8 bits. Adresses et données multiplexées. A0 à A7 et D0 à D7.

Port 4

P40-P47 : adressage de la mémoire externe, A8 à A15.

Mémoire interne

128 octets de RAM interne

Timer programmable

Compteur ($09:$0A) : lecture seule. Une écriture dans $09 reset le compteur à $FFF8, à éviter.
Comparateur ($0B:$0C) : 16 bits, lecture/écriture. Lorsqu'il est égal au compteur, OCF est mis à 1.
Capture d'entrée ($0D:$0E) : lecture seule. Enregistre la valeur du compteur lorsqu'une transition est détectée, tel que définie par IEG.
Contrôle du Timer ($08) : lecture, écriture sur bits 0-4. Les bits de poids fort représentent l'état.

Sous le capot de l'Alice 32/90, un EF9345

2024-01-04T00:00:00+01:00

La machine de la nouvelle session du « Retro Programmers United for Obscure Systems » est connue. C'est le Matra Alice. Et plus exactement les version 32 et 90, afin de s'échapper de la trop grande proximité entre le Alice premier du nom et le Tandy MC-10 (une telle proximité que ce sont les mêmes machines).

Les versions 32 et 90 étant très similaires niveau hardware, je les nommerais conjointement Alice 32/90.

Pour cet article, ce qui va m'intéresser est que l'Alice 32/90 utilise un EF9345, comme le VG5000. Et l'EF9345 étant aussi utilisé dans le VG5000µ, c'est une puce que je connais bien. Cependant, l'Alice 32/90 l'utilise différemment. Je dirais même qu'il l'utilise mieux.

L'autre axe de cet article est que je veux utiliser l'EF9345 depuis le BASIC. La machine tournant avec un 6803, les I/O sont mappées en mémoire. Et il est donc possible d'accéder aux registres de l'EF9345 depuis le BASIC avec des PEEKs et POKEs. Pas besoin de passer par l'assembleur. Par contre, pas de mystère, c'est lent !

Le mode graphique en BASIC sur l'Alice

Première chose amusante, l'Alice 32/90 démarre dans un mode 32 colonnes qui n'existe pas pour l'EF9345. Je pense que ce mode par défaut, qui utilise en fait le mode 40 colonnes de l'EF9345, est là pour être compatible avec le Alice 4k au niveau BASIC. Pour assurer cette compatibilité, des caractères utilisateurs sont chargés dans la RAM vidéo au démarrage pour représenter les différentes combinaison d'un bloc de 2x2 « gros pixels » pour chaque caractère.

L'Alice 32/90 peut cependant utiliser l'EF9345 en vrai mode 40 colonnes, et même en mode 80 colonnes. Pour cela passer d'un mode à l'autre, il faut utiliser les commandes CLS32, CLS40 et CLS80. Je vais me concentrer sur le mode 40 colonnes.

Celui-ci est initialisé dans le mode « 40 CHAR LONG ». C'est un mode qui prend trois pages de 1Ko en mémoire vidéo. La première page contient les caractères, la deuxième les attributs et la troisième les couleurs. Ça fait beaucoup sur les 8ko de RAM vidéo de la machine, et le VG5000µ avait fait le choix d'utilise le mode « 40 CHAR SHORT » qui ne prend que 2ko. Cependant, on y gagner en simplicité et flexibilité au niveau des attributs.

Autre choix de l'Alice : le système ne conserve pas de miroir en RAM de l'affichage. Là encore, bon choix pour l'utilisation de la RAM principale. En contrepartie cela signifie que les opérations non prévues par le BASIC devront se faire en s'adressant directement à l'EF9345.

Plus techniquement, le mode est initialisé avec les registres suivants :

- TGS = 0x10 (binaire: 00010000) -> 312 lignes non entrelacées, synchro composite, pas de synchro entrante, service row = 0, 40 Char Long
- MAT = 0x28 (binaire: 00101000) -> couleur de marge noire, curseur complet clignotant, curseur désactivé (!), simple hauteur
- PAT = 0x67 (binaire: 01100111) -> service row visible, bulk haut et bas visible, conceal désactivé, flash activé
- DOR = 0x13 (binaire: 00010011) -> page G'0 située en Z = 3, page G'10 située en Z = 2, page Q située en Z = 0
- ROR = 0x08 (binaire: 00001000) -> première ligne bulk = 8, page d'origine Z = 0

Les registres de l'EF9345

Depuis le processeur, l'EF9345 est accessible via 8 registres. Ces registres sont accessibles en lecture et écriture, et sont tous des registres de 8 bits. Ils sont accessibles via les adresses suivantes :

- R0 = $BF20 ; 48928 (commande)
- R1 = $BF21 ; 48929 (paramètre principal)
- R2 = $BF22 ; 48930 (paramètre)
- R3 = $BF23 ; 48931 (paramètre)
- R4 = $BF24 ; 48932 (pointeur auxiliaire haut)
- R5 = $BF25 ; 48933 (pointeur auxiliaire bas)
- R6 = $BF26 ; 48934 (pointeur principal haut)
- R7 = $BF27 ; 48935 (pointeur principal bas)

Une adresse supplémentaire est située en $BF28 (48936). Il s'agit en fait de R0 mais avec le flag d'exécution (bit 7 du numéro de registre) mis à 1. Cela permet de demander à l'EF9345 d'exécuter la commande indiquée dans R0.

Techniquement, n'importe quel registre peut être utilisé pour exécuter une commande en mettant le bit 7 à 1. Cela permet d'ailleurs quelques optimisations. Je n'ai pas vérifié si les adresses au delà de $BF28 étaient mappées. Si ce n'est pas le cas, on n'utilisera pas, voire jamais, R0 directement en écriture directement, mais toujours via le « faux registre » R8.

Note additionnel : le livre "les astuces d'Alice 32 et 90" indique qu'il est en effet possible d'utiliser tous les registres en mode « exécution ».

Un premier affichage

Voici un programme qui place tous les registres directs correctement pour afficher un « A » à l'écran sur la ligne 0 (ligne de service), colonne 10. Notez que cela fonctionnera parfaitement en mode CLS32. Vous pouvez vous amuser à écrire où vous voulez dans l'espace de 40 colonnes par 25 lignes pour constater que le mode 32 colonnes est en fait le mode 40.

Attention, dans cette configuration de l'EF9345, la deuxième ligne affichée est la ligne... numéro 8.

100 REM AFFICHE UN CARACTERE
110 POKE 48928, 0   : REM R0 (COMMANDE) KRF / INUTILE
120 POKE 48929, 65  : REM R1 (C)
130 POKE 48930, 0   : REM R2 (B)
140 POKE 48931, 20  : REM R3 (A)
150 POKE 48932, 0   : REM R4 (NA pour KRF)
160 POKE 48933, 0   : REM R5 (NA pour KRF)
170 POKE 48934, 0   : REM R6 (MP / LIGNE)
180 POKE 48935, 10  : REM R7 (MP / COL)
190 POKE 48936, 1   : REM R0 + EXEC (KRF)

Une démonstration plus complète

Voici un programme de démonstration plus complet, mais pas entièrement, puisqu'il y a plein de choses à faire avec l'EF9345 qui ne sont pas démontrées ici.

Attention : je n'ai pas du tout testé sur vrai matériel. L'EF9345 étant sensible aux synchronisations (on ne peut pas lui parler n'importe quand), je ne sais pas à quel point le BASIC est capable de gérer cela. Il est possible que ce programme ne fonctionne pas bien sur vrai matériel. Je suis preneur de retours (et j'essaierai moi même un de ces jours).

Voici quelques commentaires :

En ligne 100, on initialise les registres nécessaires pour afficher une chaîne de caractère utilisant les mêmes attributs.
En ligne 200, on initialise les registres restants pour afficher un caractère et passer à la colonne suivante (attention, il n'y a pas de détection de fin de ligne).
En ligne 300, on initialise tous les registres pour afficher un caractère avec des attributs différents. Dans les commentaires KRF est le nom de la commande d'affichage d'un caractère en mode « 40 CHAR LONG ».
En ligne 400, une routine se charge de monter en mémoire vidéo les données pour un caractère utilisateur.
En ligne 10000, c'est le début du test et j'affichage "BONJOUR". C'est un PRINT en bien plus compliqué et bien plus lent...
En ligne 10100, j'affiche les 128 caractères alphanumériques en ROM de l'EF9345.
En ligne 10200, j'affiche une autre plage de 32 caractères, graphiques, en ROM de l'EF9345.
En ligne 10300, j'affiche les 128 caractères semi-graphiques en ROM de l'EF9345. Dans ces trois affichages, c'est la variable B qui indique le type de caractères à utiliser.
En ligne 10400, j'affiche un caractère graphique plein pour montrer les 16 teintes disponibles pour les caractères.
En ligne 11000, je tente de lire les registres indirects de l'EF9345. Cela ne fonctionne pas tout à fait bien. Possible que ce soit un problème de synchro (d'où la petite boucle, même si 1/ ce n'est pas comme cela qu'on synchronise l'EF9345 2/ la lenteur du BASIC me fait penser que quoique l'on fasse, il y a toujours un risque de tomber au mauvais moment).
En ligne 12300, je modifie le registre indirect ROR afin de faire un scrolling vertical. Comme la mémoire « sous » l'écran n'est pas préparée, cela affiche un peu n'importe quoi. C'est surtout une démonstration de l'utilisation de registre indirect en écriture.
En ligne 13000, je charge un caractère utilisateur (le bonhomme du manuel du VG5000µ) puis j'affichage un des « sets » de caractères redéfinis. Particularité : c'est un ensemble de 100 caractères allant de 0 à 3, puis de 32 à 127... L'adresse de destination A=192 est aussi assez compliquée à calculer (en tout cas, ça ne s'invente pas, et le datasheet demande une grande attention, je ferai peut-être un article séparé là-dessus). Dans les caractères affichés, vous verrez les blocs redéfinis pour la compatibilité avec l'Alice 4k.

Pour la manière dont fonctionne la mémoire de l'EF9345, en attendant un article, vous pouvez tentez de comprendre avec le code du fichier ef9345_memory.py dans mon dépôt GitHub dédié aux outils d'étude pour le VG5000µ.

10 CLS:GOTO 10000

100 REM PREPARATION AFFICHAGE CARACTERE
110 POKE 48930,B
120 POKE 48931,A
130 POKE 48934,Y
140 POKE 48935,X
150 RETURN

200 REM AFFICHE UN CARACTERE AVEC INCREMENTATION
210 POKE 48929,C
220 POKE 48936,1:REM KRF + INCR
230 RETURN

300 REM AFFICHE UN SEUL CARACTERE COMPLET
310 POKE 48929,C
320 POKE 48930,B
330 POKE 48931,A
340 POKE 48934,Y
350 POKE 48935,X
360 POKE 48936,0:REM KRF
370 RETURN

400 REM CHARGEMENT D'UN CARACTERE REDÉFINI
410 FOR I=1 TO 10
420 READ C
430 POKE 48932,INT(A/256)
440 POKE 48933,A AND 255
450 POKE 48929,C
460 POKE 48936,48+4:REM OCT + AUX_PTR (EXEC)
470 A=A+4
480 NEXT I
490 RETURN

10000 REM PROGRAMME DE TEST
10010 X=5:Y=0 : REM COORDONNEE
10020 B=0:A=20 : REM ATTRIBUTS
10030 A$="BONJOUR"
10040 GOSUB 100
10050 FOR I=1 TO LEN(A$)
10060 C=ASC(MID$(A$,I,1))
10070 GOSUB 200
10080 NEXT I

10100 REM AFFICHAGE DE CARACTERES
10110 Y=8:X=0:B=0:A=112
10120 FOR C=0 TO 127
10130 IF X>39 THEN X=0:Y=Y+1
10140 X=X+1
10150 GOSUB 300
10160 NEXT C

10200 Y=12:X=0:B=48:A=112
10210 FOR C=0 TO 31
10220 GOSUB 300
10230 X=X+1
10240 NEXT C

10300 Y=13:X=0:B=32:A=112
10310 FOR C=0 TO 127
10320 IF X>39 THEN X=0:Y=Y+1
10330 GOSUB 300
10340 X=X+1
10350 NEXT C

10400 REM COULEURS
10410 Y=17:X=0:B=32:C=127
10420 FOR A=16 TO 112 STEP 16
10430 GOSUB 300
10440 X=X+1
10450 NEXT A
10460 Y=18:X=0:B=33
10470 FOR A=16 TO 112 STEP 16
10480 GOSUB 300
10490 X=X+1
10500 NEXT A

11000 REM LECTURE DES REGISTRES INDIRECTS
11010 POKE 48936,128+8+1:REM IND + LECTURE + TGS (EXEC)
11020 T=PEEK(48929):REM LECTURE R1
11030 PRINT"TGS=";T:FOR I=0 TO 20:NEXT I
11040 POKE 48936,128+8+2:REM IND + LECTURE + MAT (EXEC)
11050 M=PEEK(48929):REM LECTURE R1
11060 PRINT"MAT=";M:FOR I=0 TO 20:NEXT I
11070 POKE 48936,128+8+3:REM IND + LECTURE + PAT (EXEC)
11080 P=PEEK(48929):REM LECTURE R1
11090 PRINT"PAT=";P:FOR I=0 TO 20:NEXT I
11110 POKE 48936,128+8+5:REM IND + LECTURE + DOR (EXEC)
11120 D=PEEK(48929):REM LECTURE R1
11130 PRINT"DOR=";D:FOR I=0 TO 20:NEXT I
11140 POKE 48936,128+8+7:REM IND + LECTURE + ROR (EXEC)
11150 R=PEEK(48929):REM LECTURE R1
11160 PRINT"ROR=";R

12300 REM CHANGE ROR POUR SCROLLING
12310 FOR I=8 TO 31
12320 POKE 48929,I:REM ECRITURE R1
12330 POKE 48936,128+0+7:REM IND + ECRITURE + ROR (EXEC)
12340 FOR J=0 TO 20:NEXT J
12350 NEXT I
12360 POKE 48929,8:REM ECRITURE R1
12370 POKE 48936,128+0+7:REM IND + ECRITURE + ROR (EXEC)

13000 REM CARACTERES REDÉFINIS
13010 DATA 28,58,28,8,127,93,93,28,54,99
13020 A=192
13030 GOSUB 400

13100 Y=20:X=0:B=128+32+16:A=112:REM GP11
13110 FOR C=0 TO 127
13120 IF X>39 THEN X=0:Y=Y+1
13125 IF C=4 THEN C=32
13130 GOSUB 300
13140 X=X+1
13150 NEXT C

14000 GOTO 14000

Dans la prison hantée sur AgonLight

2023-12-21T00:00:00+01:00

Comme présenté dans un article précédent, j'ai participé à la game jam Retro Programmers United for Obscure Systems, organisée par Olipix. Le principe est de développer un jeu pour une machine qui n'a pas eu une grande ludothèque (moins de 100 titres).

Après avoir terminé ma contribution sur le Lynx, je me suis dit qu'un portage pour l'AgonLight serait intéressant et plutôt facile. Les capacités graphiques sont bien supérieures, et le processeur est un Z80, supporté par la même toolchain que j’avais utilisée pour le Lynx (z88dk).

Un petit mois plus tard, c'est chose faite. Le jeu est disponible sur itch.io.

J'en ai profité pour ajouter une version en anglais et une version en esperanto. Puisque tout est développé depuis les mêmes sources, ces versions sont aussi disponibles sur le Lynx.

Au passage, la taille de l'exécutable a été un tout petit peu réduite. Pas assez pour entrer sur la version Lynx 48k malheureusement. Et en projetant le gain potentiel en travaillant la compression des données, j'ai assez peu d'espoir d'y arriver. Cela pourrait probablement être possible en reprogrammant le jeu en assembleur, mais j'ai déjà passé assez de temps sur ce projet et j'ai envie de passer à autre chose. De plus, je perdrai la possibilité d'un portage facile sur une machine avec un autre processeur.

J'ai aussi publié les sources du jeu sur GitHub.

À bientôt pour de nouvelles aventures !

VG5000µ, Schémas de principe mis à jour en v1.5

2023-11-21T00:00:00+01:00

Et voici une nouvelle mise à jour du schéma de principe.

Il y a une seule modification par rapport à la version 1.4, qui est l'ajout du mode international lorsque la diode 6602 relie le signal NMI/ au Y3/ de 7807. Avec cette diode présente, le VG5000µ passe en anglais.

Merci à Etno pour cette information.

Ce qui donne, mis à jour.

La platine principale

Image cliquable pour une version en haute définition. (mise à jour 21 novembre 2023)

La platine K7/Son

Image cliquable pour une version en haute définition. (mise à jour 9 sept. 2018)

Rappel des versions précédentes

Un an de Retro Programmers United for Obscure Systems

2023-11-20T00:00:00+01:00

Un peu plus d'un an en fait, puisque Olipix lance ce groupe en juin 2022. L'idée, je le rappelle, est d'offrir à des machines qui en leur temps n'ont pas eu une grande ludothèque quelques titres supplémentaires, dans un format game jam de trois mois (souvent étendus à quatre).

Dans cet article, je vais revenir rapidement sur les 4 jeux que j'ai développés à cette occasion, avec quelques commentaires.

VG5000µ : La Maison dans la colline

La première machine choisie a été le VG5000µ, une machine que, vous le savez si vous suivez ce blog, j'étudie depuis un moment. Pour un premier développement réel (autre que des tests), je voulais un affichage rapide, mais sans aller dans un jeu rapide. L'idée du jeu d'aventure graphique avec support de texte est arrivée rapidement.

J'ai commencé ici une série d'articles sur le développement du jeu.

Le jeu est développé avec z88dk, en C avec un peu d'assembleur pour l'affichage. J'ai aussi réalisé tous les graphismes (et ça se voit ?) avec Pixelorama. Pour les outils de données, c'est du Python avec un fichier de description du jeu, qui sort les données binaires injectées dans l'exécutable.

Le jeu est disponible sur itch.io.

Olipix fait une revue du jeu dans cette vidéo.

EXL100 : Plouf... in space

La deuxième machine choisie a été l'EXL100, une machine que je ne connaissais pas du tout. Et une machine plutôt exotique. Un processeur que je ne connais pas, l'essentiel de la mémoire utilisable non adressable par le processeur... et un synthétiseur vocal plutôt difficile à utiliser.

J'avais quelques idées pour utiliser la machine, mais j'ai rapidement compris que le temps de me familiariser avec et de faire des tests, je n'aurais pas le temps de faire un jeu. J'ai donc changé d'avis et suis partie sur un jeu programmé en BASIC, qui permet facilement d'utiliser toute la mémoire. Et pour le type de jeu, un touché-coulé, mais avec un twist : les bateaux sont en mouvement. Je n'étais pas très certain que le gameplay donne quelque chose, mais au final et après quelques ajustements, ça fonctionne plutôt bien.

Sur la fin, les calculs en BASIC commençaient à être un peu lents, et j'ai donc ajouté un peu d'assembleur dans le peu de mémoire adressable par le processeur. J'ai utilisé l'assembleur ASL qui est un des rares supportant le TMS7020. J'y associe un petit script en Python pour générer les DATA pour le BASIC. C'était assez manuel, je n'aime pas trop ça, mais comme souvent : manque de temps pour des choix assez tardifs.

Puis les bateaux sont devenus des vaisseaux parce que... parce que.

Je voulais aussi redéfinir quelques caractères pour un affichage plus sympa, mais je n'ai pas eu le temps. Peut-être un jour si je ressors l'idée ?

Le jeu est disponible sur itch.io.

Olipix fait une revue du jeu dans cette vidéo, dans laquelle nous avons aussi discuté du développement du jeu.

Aquarius : Le jardin des œufs

La troisième machine a été l'Aquarius. Retour à du Z80 qui m'est familier. Et une machine simple. Dépouillée même. L'avantage pour le graphisme, c'est qu'il faut faire avec les caractères de la machine. Heureusement, un éditeur dédié à la machine est disponible en ligne, ce qui a bien simplifié les choses.

Comme la fin de la game jam était autour de Pâques, j'ai voulu faire thématique avec une chasse au œufs. Dans la lignée des anciens jeux avec des plateformes qui n'ont pas vraiment de sens, j'ai designé un jardin étrange, avec quelques éléments de game design classiques.

Dans tous ces jeux, je pars d'un principe : les joueurs de retro n'ont souvent pas vraiment de temps à passer sur ces machines, particulièrement celles qui ne sortent jamais. Je vise donc des jeux courts, quelque chose qui puisse se découvrir et se terminer en une vingtaine de minutes. Quitte à se qu'il se termine en moins de 5 minutes lorsque l'on connaît la solution.

Puisque le jeu se termine rapidement, j'ai ajouté un compteur de mouvements, avec d'y associer une sorte de time attack... mais sans temps.

Le jeu est entièrement en assembleur, utilisant sjasmplus, un assembleur que j'avais essayé auparavant et que je voulais creuser un peu plus. C'était l'occasion. Un jeu tout en assembleur, ça prend un peu plus de temps à développer, par contre, question mémoire, ça permettait de faire petit. Et encore, il y a de la marge d'optimisation.

Le jeu est disponible sur itch.io.

Olipix fait une revue du jeu dans cette vidéo.

Camputers Lynx : Dans la prison hantée

Une nouvelle session, et une nouvelle machine sortie de nulle part. J'avais connaissance de la machine, mais je ne m'étais jamais penché dessus et... quel étonnement. Cette machine a été conçue avec des choix originaux. C'est du Z80, bon point pour moi. La partie vidéo est aussi très intéressante avec des pixels indépendants en couleur les uns des autres. Une rareté pour l'époque. Bien entendu, je me dis qu'il faudra absolument utiliser cette particularité.

J'ai passé un bon moment sur la machine sur des tests variés. Les limitations d'accès à la RAM, avec un mapping vraiment pas simple, et des émulateurs pas très aboutis m'ont fait désespérer une paire de fois. J'ai souvent mis le projet sur le côté.

Pour le jeu, je voulais aller du côté de Temple of Apshaï, un jeu qui m'avait marqué étant petit. Comme d'habitude, dans une formule courte. Vu tout le temps passés à faire des tests et à procrastiner, j'ai aussi fait le choix d'utiliser un set de sprites désigné par Kenney. Sur base d'un set noir et blanc, j'ai ajouté un peu de couleurs, puisque je voulais utiliser les capacités de la machine en la matière.

Initialement, j'étais parti sur la réutilisation du format et des scripts de la Maison dans la Colline. Cependant, j'avais un peu luté avec le côté semi-manuel de la méthode. J'ai donc décidé d'utiliser Tiled pour la conception des niveaux, et un script Python pour générer les données. Tiled est vraiment sympa à utiliser et je pense que je le réutiliserai dans le futur pour des projets similaires.

Pour le code, j'ai utilisé z88dk avec un peu d'assembleur pour l'affichage, mais beaucoup moins que pour le VG5000µ. Je voulais réutiliser le principe d'affichage rapide, mais les émulateurs Lynx ne supportent pas (encore ?) la redirection du vecteur d'interruption pour la VSYNC. J'ai rapidement fait une croix dessus. N'ayant pas accès à cette machine, je devais absolument faire avec les émulateurs.

Aussi, rapidement, j'ai compris que le jeu n'entrerais pas en mémoire de la version 48k, mais uniquement sur la version 96k (cela semble beaucoup, mais de cette mémoire, 32ko sont réservés pour la vidéo).

Le jeu est disponible sur itch.io.

Retro VynZ a fait une partie filmée sur sa chaîne YouTube.

Olipix présente le jeu, suivi d'un petit échange sur sa chaîne YouTube.

Et la suite ?

J'ai passé de bons moments sur ces projets. Découvrir ces machines est un plaisir (même si elles sont parfois un peu énervantes), cela profite un peu (un tout petit peu) à leur visibilité, à leur redécouverte. Et si ça n'amuse que nous, c'est déjà ça.

Je ne connais pas encore la prochaine machine, je ne sais donc pas vers où je vais aller, mais j'ai en tête deux défis : utiliser un peu plus de couleurs et, pour la première fois, ajouter du son !

À bientôt pour de nouvelles aventures !

La palette de couleur de l'Agon Light

2023-06-10T00:00:00+02:00

Ces derniers temps, je m'amuse avec un AgonLight (ou plus exactement un AgonLight2, qui est la version Olimex).

Cette machine est assez récente et possède une petite communauté. Sa documentation est par contre très éparse pour le moment. Du plus, la partie graphique de la machine se reposant sur FabGL, une partie des informations intéressantes sont en fait à déduire de cette bibliothèque. Mais d'autres se déduisent de l'implémentation pour la machine du BBC Basic.

Je vais me servir de ce blog pour prendre quelques notes. Cette semaine, j'ai tourné en rond autour de la gestion de la palette et des modes graphiques disponibles.

Modes graphiques

Les modes graphiques, à cette date (MOS 1.03), sont :

Mode	Résolution (Pixels)	Fréquence (Hz)	Nb. de couleurs	Palette?
0	1024x768	60	2	Oui
1	512x384	60	16	Oui
2	320x200	75	64	Non
3	640x480	60	16	Oui

Palette de couleurs

Dans les modes en palette, les couleurs se choisissent parmi l'espace de couleur complet RGB222. Les 4 niveaux pour chaque composante sont 0x00, 0x55, 0xAA et 0xFF. Ce qui donne :

Attention, la palette est réinitialisée lors d'un changement de mode

R,G,B ?

Une chose étonnante, c'est qu'il est possible de spécifier les palettes, et il est obligatoire de spécifier les pixels des surfaces, en RGB888, alors que l'espace de couleur est RGB222. Le VDP (ou plutôt FabGL), va chercher à trouver les couleurs en fonction. Ce n'est pas hyper pratique au premier abord, et c'est un bon gâchis d'espace.

Mieux vaut ne spécifier que des couleurs faisant partie de la palette.

La Maison dans la colline, partie 7

2023-05-10T00:00:00+02:00

Dans ce septième article de la série sur le jeu « La maison dans la colline », il va être question de tests anti-regression.

Regressions

Mais qu'est-ce qu'une regression ? C'est un fonctionnement qui donnait toute satisfaction et qui, suite à un changement dans le système, se met à ne plus fonctionner comme attendu. Autrement dit, une apparition de bug !

Les bugs n'arrivent jamais de nulle part, il y a toujours une raison. Mais plus un programme est grand, plus il se complexifie et plus le risque de programmer des morceaux qui entrent en conflit apparaît. C'est à peu près inéluctable et le développement d'un logiciel est, normalement, accompagné d'un certain nombre de règles pour éviter au mieux et surtout repérer au plus vite les défauts qui apparaissent.

La vitesse de détection est importante, car il une regression peut ne pas être immédiatement flagrante. Il est possible que quelque chose casse sur une partie « éloignée » de ce sur quoi on travaille sur le moment. Il est aussi possible que le défaut soit subtile ; présent, mais pas évident. Tout à l'air de bien fonctionner en apparence, mais pas dans les détails. Et si on continue à développer avec ce défaut présent, il se peut très bien que l'on amplifie le problème, ajoutant du bug à du bug.

La vitesse est aussi importante pour une question de contexte. Lorsque l'on a en tête une partie en train d'être travaillée, il est plus simple de corriger ce qui vient d'être modifié que lorsque l'on s'en rend compte plus tard, lorsqu'on est passé à autre chose.

Dans le contexte de « La maison dans la colline », je suis tout seul et, comme je l'ai déjà dit auparavant, j'essaie de maximiser mon temps libre passé sur le projet. Ainsi, une session à essayer de trouver et corriger la raison d'un bug introduit deux sessions avant ne m'enchante pas du tout.

J'ai donc mis en place deux systèmes pour m'aider à détecter rapidement les bugs

Tests unitaires

Le premier système est un système simpliste de tests unitaires. Le principe est de mettre le système dans un certain état, de faire une opération, puis de vérifier que le système est dans l'état attendu.

J'ai mis en place ce système après avoir débuté le projet et lorsque celui-ci commençait à devenir un peu complexe. Malheureusement ou heureusement, j'avais pris quelques raccourcis qui rendaient certains tests un compliqués. Cela m'a pris un peu de temps pour nettoyer ça ; au passage, j'en suis sorti avec quelques nettoyages bienvenue dans le code.

Je n'ai pas non plus beaucoup de tests. Majoritairement, je fais des tests sur la gestion de l'inventaire, qui m'a causé quelques soucis et qui a été ce qui m'a décidé à mettre des tests unitaires. Je fais aussi quelques tests sur mon micro-allocateur de mémoire dynamique (celui de z88dk ne me convenant pas).

Lorsque je lance le programme avec une option de compilation, les tests sont exécutés dans une page spéciale, au démarrage du jeu. Je peux ainsi m'assurer que les tests passent et que donc le fonctionnement de mon système d'inventaire et d'allocation sont toujours d'aplomb.

Voilà à quoi ressemble le test des objets, une fois que j'ai mis en place un environnement de tests avec des objets dans des pièces :

    CHECK(object_count_in_room(ROOM(1)) == 2);
    CHECK(object_count_in_room(ROOM(254)) == 1);
    CHECK(object_count_in_room(ROOM(255)) == 0);

Et voilà une capture d'écran lors d'une regression :

Mode automatique

L'autre système que j'ai mis en place est un mode de jeu automatique. Au bout d'un moment, et alors que le nombre d'actions et de pièce commençait à grandir, il me fallait régulièrement jouer toute une première partie du jeu. Je vérifiais les mouvements, les portes et changements de pièce, la prise d'objet dans l'inventaire, l'utilisation d'un objet.

Ça a rapidement été long, pas très amusant et source d'erreurs : est-ce que je fais bien les mêmes étapes ? Est-ce que j'ai encore envie de le faire parce que ça m'ennuie ? Est-ce que quelque chose ne va pas casse pile la fois où j'aurai la flemme de conduire les tests ?

Solution : automatiser le test.

Lorsque je compile le jeu avec le mode automatique inclue, je déroule un petit script qui va exécuter les actions à ma place. C'est assez simpliste, je n'ai pas de retour d'erreur automatisé. Mais au moins, si je vois quelque chose d'étrange, ou bien si le personnage se retrouve bloqué sur une étape, je peux le voir rapidement. Et je peux alors conduire un test manuel pour comprendre dans les détails ce qu'il se passe.

Il n'y a pas beaucoup d'étapes dans ce test automatique, car c'est un peu fastidieux à maintenir. J'ai hésité un moment à rendre le système plus malin, avec une création de script depuis les données du jeu. Par exemple en trouvant le chemin pour aller d'un point A à un point B automatiquement. Mais je ne suis pas allé jusque là, j'ai trouvé un compromis avec un système qui « tente » d'aller vers une position, mais de manière simpliste, que je dois aider manuellement parfois.

Mais que de temps gagné au final !

Voici à quoi ressemble le début du script, qui est stocké dans un tableau de caractères dans le code source :

unsigned char script[] =
        {
                'W', 'P', 4, // Wait page 4 (test page)
                'W', 'T', 20,// Wait frames
                'K', ' ',    // Press ' '
                'W', 'P', 0, //
                'K', ' ',    // Press ' '
                'W', 'P', 1, //
                'K', 'A',    // Press 'A'
                'W', 'T', 5,
                // Go to Kitchen
                'K', KEY_UP,
                'K', KEY_UP,
                'K', KEY_UP,
                'K', KEY_UP,
                'G', 'R', 2,// Go to Room 2

Conclusion

J'ai déjà évoqué mon goût pour les outils et les automatisation dans les articles précédents. L'automatisation des tests est un outil de plus pour se simplifier la vie. Cela demande un peu d'effort en amont, mais force parfois à mieux réfléchir son code pour le rendre flexible, ce qui est bénéfique lors de la mise au point du jeu, et permet un gros gain de temps sur la durée du projet, pour peu que l'on trouve le bon équilibre entre le temps passé à créer les outils et le gain de temps espéré grâce à eux.

La Maison dans la colline, partie 6

2023-05-04T00:00:00+02:00

Dans ce sixième article de la série sur le jeu « La maison dans la colline », il va être question des structures du jeu, de portage et de « binarisation ».

Les structures

« La maison dans la colline » est un jeu programmé en grande partie en C. L'idée derrière est de pouvoir porter assez facilement sur une autre machine qui n'aurait potentiellement pas le même processeur, c'est aussi une manière de faciliter les itérations. Le jeu manipulant des objets, des pièces pour circuler, un personnage, il est intéressant de pouvoir se reposer sur des structures de données et de les manipuler, de les faire évoluer, sans avoir à adapter un code assembleur en parallèle (même s'il existe des assembleurs qui peuvent faciliter ces opérations).

Les pièces

La première structure que je présente est celle des pièces de la maison et des portes qui les relient. Ces données sont fixes et pourraient se situer en ROM si je jeu était sur ROM.

typedef struct Door {
    unsigned char position[2];
    unsigned char destination_room;
    unsigned char destination_position[2];
} Door;

Une porte a une position dans la pièce et amène vers une pièce de destination (identifiée par un octet) à une position donnée dans cette pièce de destination.

typedef struct Room {
    unsigned char id;
    unsigned short shift_to_next;
    unsigned short shift_to_doors;
    unsigned char position[2];
    unsigned char size[2];
    unsigned char enter_text;
    unsigned char door_count;
    Door* doors;
    unsigned char data[];
} Room;

Une pièce est un peu plus complexe. Elle est identifiée par un octet (id) qui est suivi par deux nombres de 16 bits qui sont en fait des déplacements en mémoire. shift_to_next est un offset de chaînage vers la pièce suivante. Toutes les données des pièces sont contiguës en mémoire formant une liste chaînée unidirectionnelle. Ainsi, avec un pointeur vers une structure Room, si on avance de shift_to_next octets, on arrivera sur la pièce suivante dans les données.

shift_to_doors est un peu plus complexe. C'est une indication qui permet de construire le pointeur doors un peu plus loin dans la structure.

Comme on peut le voir, la structure Room se termine par un tableau de taille non spécifiée d'octets. Dans ce tableau se trouvent les données graphiques de la pièce suivies par les données des portes présentes dans la pièce. Ces deux données sont de taille variable et s'il est facile de connaître l'emplacement des données graphiques (c'est data), il est plus compliqué de connaître le début des portes qui suivent. Surtout que les données graphiques sont compressées.

Il y aurait plusieurs autres manières de faire. J'aurais pu mettre les portes (dont les données ne sont pas compressées) en premier et calculer le déplacement à partir du nombre de portes qui est une donnée connue. Mais les portes ont connu différentes implémentations et se sont finalement retrouvées là. Puis la fin du projet est arrivée et elles y sont restées.

La position et la taille (size) de la pièce indiquent la façon dont elle doit-être affichée à l'écran. enter_text est un identifiant vers le texte qui apparaît à l'écran en entrant. Et door_count comme son nom l'indique, précise le nombre de portes présentes dans la pièce.

Les données graphiques d'une pièce sont compressées selon un schéma RLE. Lorsqu'on entre dans un pièce ces données sont décompressées dans une zone temporaire et envoyées à l'affichage.

Les objets

La structure qui décrit les objets est la suivante. Là encore, ce sont des données fixes.

typedef struct Object {
    unsigned char name_id;       // the resource id for the text in the inventory. Used also to designate the object.
    unsigned char char_mode;     // what mode for the display
    unsigned char character;     // what char to display
    unsigned char properties;    // object properties
    unsigned char room_id;       // initial room
    unsigned char position[2];   // initial position in the room
    unsigned char action_text_id;// text id when the action is done on the object
} Object;

Magnifique, le code est commenté.

Un objet est donc identifié par un identifiant name_id qui est aussi l'identifiant du texte qui y est associé. C'est un choix que j'ai regretté, il aurait été bien plus pratique d'avoir un identifiant pour l'objet lui-même séparé du texte qui le décrit. Plus loin, on voit un autre identifiant du texte écrit lorsque l'on effectue une action. Là encore, c'est assez peu flexible et cela m'a obligé à ne considérer qu'une seule action par objet. Je m'en suis sorti et on dit que les contraintes amènent de la créativité.

char_mode et character donnent les informations d'affichage. Il n'y a pas de couleur car les objets ont une couleur fixe dans ce jeu, pour indiquer que des actions peuvent être faites dessus.

properties indique ce que l'on peut faire de l'objet : est-ce qu'on peut le prendre, est-ce qu'on peut le lire, est-ce que c'est un déclencheur d'évènement, est-ce que l'on peut marcher dessus, est-ce qu'il est transformable en un autre objet et enfin, est-ce que c'est un téléporteur.

Les téléporteurs sont en fait les portes. Initialement, j'avais un système spécifique de traitement des portes. Je l'ai plus tard unifié avec le traitement des objets de manière générale.

L'objet a aussi un pièce (room_id) et un emplacement (position) qui désignent l'endroit où se trouve l'objet en début de jeu. Cette information est immuable et servira lorsque l'on relance le jeu à tout remettre en place. Au début du jeu, un tableau des localisations réelles des objets est créé en mémoire et ce tableau qui sera modifié en fonction des actions.

Il existe deux pièces spéciales dans le jeu. Un pièce « nulle part » dans laquelle sont déplacés les objets qui ne sont plus valides (par exemple, une clé après avoir été utilisée). La seconde pièce est « l'inventaire ». Cela permet de s'assurer qu'un objet est toujours dans une pièce. Prendre un objet, c'est changer sa pièce courante pour celle de l'inventaire. En échangeant ses informations avec l'objet qu'il remplace dans l'inventaire, ce dernier est naturellement posé dans la pièce.

La binarisation

Partie logique

Si au début du développement il est possible d'indiquer directement dans le code les pièces (non compressées) et les objets, ça se révèle rapidement impraticable. Pour mettre au point le jeu, un éditeur est plus pratique. Cependant je n'avais non beaucoup de temps à consacrer au développement d'un éditeur de jeu.

Dans ces cas là, une manière classique de faire est de travailler sur des fichiers texte que l'on transpose dans le format binaire attendu par le jeu. D'où le terme « binarisation ». Un autre terme existe : « cooking »... et probablement d'autres.

Voici à quoi ressemble la première pièce du jeu :

Room ; Entrée
Id: 1
Position: 4,8
Size: 9,15
EnterText: 42

Description
#########
####D####
#       #
#       #
##      #
#       #
#       #
E       #
E       #
##     ##
##     ##
#       #
#   i   #
####F####
#########

Doors
D:3|E^
E:2|E<
F:255|A>

Objects
i:G'10,68,None,9 ; Apparition

Locks
F:18,56

EndRoom

Tous les # sont des emplacements bloquants : des murs ou des objets de décors. Les autres caractères (souvent des lettres) sont des emplacements spéciaux décrits à la suite de la partie graphique. Ainsi, on voit trois portes, un objet et un verrou.

Les portes sont suivies d'un petit code qui indique la pièce d'arrivée et un emplacement sous la forme d'une lettre (que l'on trouvera dans cette pièce) ainsi qu'une direction naturelle pour le sprite du personnage.

Les objets sont suivis d'informations graphiques (G'10,68 signifie : caractère numéro 68 dans la palette G'10), des propriété et d'un identifiant de texte. Ce qui suit le point virgule est un commentaire, il n'est pas lu.

Toutes ces données sont traitées et envoyées dans un fichier de données qui sera inclus au jeu.

Partie graphique

La parte graphique est elle aussi binarisée. Pour cela, j'utilise Pixelorama avec une palette d'objets graphiques et je dessine la pièce. La binarisation s'occupe de découper cela en morceaux de 10 pixels par 8 afin de construire la liste des caractères à redéfinir.

C'est à moi de m'assurer que les données logiques et graphiques sont cohérentes. Entre autre que les tailles de pièces soient identiques. Il y aurait de la marge pour aller plus loin avec un éditeur mais encore une fois, c'était dans un délai trop court pour cela. Peut-être plus tard ?

La suite ?

En effet, l'idée que j'avais en essayant de construire des structures réutilisables et flexibles étaient de pouvoir les... réutiliser. Et pourquoi pas étendre le jeu ou bien en faire un autre sur le même principe ? Avec cette fois un peu plus de temps à passer sur les outils.

Pourquoi pas. C'est une idée que je garde dans un coin de la tête.

La Maison dans la colline, partie 5

2023-02-23T00:00:00+01:00

Dans ce cinquième article, je vais aborder la méthodologie que j'ai appliquée pour le développement de « La maison dans la colline ».

La planification

Dans un premier temps, j'avais jeté sur papier (électronique) la liste des fonctionnalités que je voulais implémenter, en partant de l'idée générale du jeu et en descendant successivement sur ce dont je pensais avoir besoin. Puis j'ai segmenté cette liste en thèmes, comme par exemple « mouvements du personnage » ou bien « gestion de l'inventaire ».

Ces fonctionnalités ont besoin les unes des autres, je suis descendu jusqu'aux briques de bases, comme « afficher quelque chose à l'écran » ou bien « lire une touche du clavier ». Entre toutes ces fonctionnalités, j'ai créé des dépendances : afficher un personnage nécessaire de savoir afficher quelque chose à l'écran. L'animer nécessite de savoir l'afficher. Et ainsi de suite.

Mes dépendances ne sont pas complètes. J'ai celles qui concernent les premières tâches à effectuer, mais c'est tout. Inutile de travailler sur celles qui viendront bien plus tard, et ce pour une raison très simple : il est très probable qu'elles changent au fur et à mesure que j'avance dans le développement. Voire pour certaines, qu'elles disparaissent.

La qualité progressive

Dernière étape, pour chaque fonctionnalités, séparer des niveaux de qualité. Par exemple, je sais que je vais un personnage avec un affichage fin, et animé. Mais je ne sais pas encore trop ce que ça donne d'un point de vue jeu, est-ce qu'il me faut un sprite de 8 pixels de large ou de 16 pixels de large ? J'ai même joué avec l'idée à un moment qu'il fasse 8 de large de côté, mais 16 de large de face.

Je sais que dessiner un sprite va me prendre du temps, surtout que ça n'est pas mon domaine. Je ne veux pas avoir à le refaire trop de fois. Donc dans les premiers niveaux de qualité, je note que je vais afficher des caractères prédéfinis de l'ordinateur.

Je note ensuite que je pourrais tenter avec un personnage fixe. Puis enfin un personnage animé. Cela me donne trois étapes de qualité pour cette fonctionnalité. Et celles-ci ne seront pas forcément exécutées consécutivement. C'est important car le temps de la jam est limité et je fais ça sur mon temps libre, qui est très variable. Si la fin arrive avant qu'un niveau de qualité soit atteint, ce n'est pas grave, j'aurais tout de même quelque chose de moins joli que prévu, mais quelque chose quand même.

Je fais de même avec les fonctionnalités : je les classe par importance, mêlée de difficulté. Un personnage qui se déplace, c'est essentiel. Parmi les interactions avec les objets, j'en avais initialement prévus beaucoup plus que ce qui est dans le jeu à la fin. Quant à l'audio... je n'ai pas eu le temps et j'ai laissé de côté.

De même j'avais prévu quelques scènes graphiques d'illustration en « haute résolution ». C'est passé à la trappe.

Sur le long terme

À chaque fois que je termine une fonctionnalité, je reviens sur le document et j'ajuste. En voyant le jeu progresser, je comprends qu'il y a des choses que je voulais faire qui ne vont pas avec le reste. Ou parfois, je vois qu'il me manque un morceau, que j'avais oublié quelque chose.

Ce document va souvent être modifié. Je garde l'idée générale du jeu, les grandes lignes. Mais je me laisse aussi porter par ce qu'il devient. Ça m'évite de me bloquer sur quelque chose trop longtemps alors que ça ne fonctionne pas, que ce soit techniquement ou en game design.

Il ne faut pas hésiter à couper par manque de temps, ou parce qu'on a vu trop gros pour la machine. À modifier parce que ça ne convient plus. Ou parce qu'une nouvelle idée arrive. Ce dernier cas est à évaluer avec prudence ceci dit : il faut l'intégrer correctement à l'existant, et à l'état actuel du projet. Les idées arrivent toujours plus nombreuses et plus rapidement que leur temps de développement nécessaire.

La programmation

Niveau programmation, j'applique là aussi une démarche itérative « par petits pas ». En reprenant l'affiche, par exemple, je commence par m'adresser directement à l'EF9345, à travers une liste d'affichage, avec une position et un caractère fixes. Puis j'extrais la position pour qu'elle devienne variable, mais toujours localement. Puis je la passe par paramètre de la liste d'affichage. Et enfin je l'injecte depuis le programme principal, avant de répéter la même démarche pour le caractère affiché.

L'idée ici est de vérifier que le code fonctionne sur un cas simple, s'assurer qu'on a bien compris le problème. Dans le cas de l'EF9345, être certain qu'on a bien compris son fonctionnement par exemple. Puis petit à petit, on généralise, si nécessaire, avant d'extraire les données variables.

Cela permet de valider chaque étape individuellement et d'éviter les bugs dus à un développement avec beaucoup de changements différents. Cela permet aussi de s'arrêter en chemin. Soit pour passer à autre chose que l'on développe en parallèle car en lien. Ou tout simplement parce que c'est l'heure de manger, et qu'il est toujours préférable de laisser le programme dans un état fonctionnel sur lequel on peut reprendre plus tard.

Et enfin, parce que parfois, on s'aperçoit qu'il n'est pas nécessaire de généraliser plus avant. Ou alors pas tout de suite. Et peut-être jamais. La fonctionnalité arrive à un point satisfaisant.

Conclusion

S'il faut retenir une chose de cette méthodologie, c'est le concept d'avancée graduelle. Faire des « petits pas », monter petit à petit en qualité et savoir s'arrêter.

La Maison dans la colline, partie 4

2023-02-20T00:00:00+01:00

Dans ce quatrième article concernant le développement de « La maison dans la colline », je vais aborder quelques points de programmation. Deux points en particulier : la structure générale du programme, puis les listes d'affichage.

Structure générale

Un jeu vidéo, c'est un programme qui ne s'arrête pas. Enfin si... quand on a fini de jouer. Mais il s'oppose aux programmes en « batch » qui doivent résoudre une fonction à partir de données en entrée. Un jeu vidéo se situe donc dans la classe des applications qui font évoluer un état en fonction des entrées de l'utilisateur.

Ainsi, un tel programme peut se résumer à cette structure :

int main()
{
    while(running())
    {
        read_input();
        update_state();
        display_state();
    }
}

Autrement dit : tant que le logiciel tourne, on lit les entrées, on met à jour les états du jeu, on affiche l'état du jeu (on peut aussi diffuser le son, mais ce jeu n'en n'a pas) et on recommence.

Voilà la base.

Au deuxième étage, le jeu est constitué de « pages ». Il y a la page d'accueil, avec le titre, la page d'introduction, qui donne le texte de début, le jeu en lui-même, et le texte de fin. Comme le jeu est à tout moment dans une seule de ces pages, j'utilise pour les représenter une paire de fonctions. L'une est appelée lorsque l'on entre dans la page, et l'autre à chaque mise à jour, en boucle, tant que cette page est active.

Fonction d'entrée

La fonction d'entrée permet de changer le contexte du jeu, de mettre l'écran dans les bonnes conditions. Par exemple, voici la fonction d'entrée de la page de titre :

void page_title_enter(PageContext* context) __z88dk_fastcall
{
    initialize_40_long();       // Initialisation du mode 40 colonne format long de l'EF9345
    clear_40_long();            // Effacement de l'écran dans ce mode

    // Affichage du titre
    set_print_attributes(M40LONG_COLOR_FG_WHITE, M40LONG_DOUBLE_HEIGHT);
    const char* title = extract_string_from_id(TEXT(0));
    print_at(2, 12, title);
    print_at(2, 13, title);

    // Affichage de l'auteur
    set_print_attributes(M40LONG_COLOR_FG_WHITE, 0);
    const char* author = extract_string_from_id(TEXT(71));
    print_at(20, 17, author);

    // Affichage du PRESS START
    set_print_attributes(M40LONG_COLOR_FG_WHITE | M40LONG_FLASH, 0);

    const char* press = extract_string_from_id(TEXT(1));
    print_at(2, 22 + 8, press);
}

Quelques commentaires :

le paramètre context n'est pas utilisé ici. Nous verrons dans la fonction suivante son utilité. À vrai dire, je ne l'ai jamais utilisé dans les fonctions d'entrée et il devrait probablement être enlevé.
__z88dk_fastcall est une annotation pour la suite z88dk qui indique au compilateur que le pointeur passé en argument devra être passé dans HL, plutôt que par la pile. Nous verrons plus tard que c'est bien pratique lorsque l'on mélange C et assembleur.
les chaînes de caractères sont appelées via un système d'accès à des ressources. J'en parlerai probablement dans un autre article plus tard.

Fonction de mise à jour

L'autre fonction qui décrit une page est celle de la mise à jour. Elle sera appelée en boucle tant que la page est active. Contrairement à ce que j'indiquais au tout début de l'article, il n'y a pas de séparation entre la mise à jour et l'affichage. Dans ce programme, la fonction de mise à jour s'occupe des deux étapes.

Voici par exemple la fonction de mise à jour pour l'écran de titre :

void page_title_update(PageContext* context) __z88dk_fastcall
{
    if (context->just_pressed_key != 0)
    {
        context->command = CHANGE;
        context->command_param = INTRODUCTION_PAGE;
    }
}

Commentaires :

ici, le context est utilisé. On peut voir qu'il sert de communication avec l'état extérieur à la page.
en lecture, le context fourni une information sur une touche du clavier éventuellement appuyée.
en écriture, le context permet de donner une information à transmettre à l'extérieur. Ici, l'information est celle d'un changement de page.

En effet, au-dessus des pages, il y a un petit superviseur, qui n'est en fait rien d'autre que la boucle principale du jeu. Celle-ci va s'occuper de peupler le context avec les informations systèmes, dont les touches du clavier, puis va vérifier si la page en cours a donné une commande. Il y a trois commandes possibles :

CHANGE : qui indique une page de destination, et qui provoquera donc un changement de page. Ici, lorsqu'une touche est appuyée, on passe à la page d'introduction du jeu.
RUN : qui indique que la page actuelle doit continuer à être appelée, c'est la page active.
STOP : qui demande l'arrêt du programme. C'est une commande que j'ai utilisée en début de développement pour certains tests, mais que j'ai arrêté d'utiliser. Le programme ne s'arrête pas.

Voilà pour la structure générale du jeu. Passons maintenant aux listes d'affichage.

Les listes d'affichage

Comme je l'avais mentionné dans un article précédent, je voulais dans ce jeu avoir un affichage rapide avec lequel le scintillement de mise à jour était, au moins dans la majorité des cas, invisible. Et cela signifie une chose : il faut afficher vite, et au bon moment.

Si la mise à jour de l'écran se fait au fil de la mise à jour de l'état du jeu, il y a de bonnes chances qu'une mise à jour de l'affichage arrive au mauvais moment. De plus, l'EF9345 est pleinement efficace en début de traçage de l'écran, dans la zone de bord haute. Par la suite, il commence à être occupé avec la génération de l'image et a moins de temps à consacrer aux données qui arrivent depuis le Z80.

Il y a deux outils classiques pour cela :

la synchronisation verticale, qui permet de savoir quand le processeur vidéo commence une nouvelle image,
les listes d'affichage (Display Lists en anglais), qui sont des listes de commandes préparées pour être exécutées le plus vite possible. Ou en tout cas, « assez vite »

Mise en place

Par bonheur, le VG5000µ est conçu de manière à être mis au courant d'une synchronisation verticale. En effet, le signal de synchronisation, envoyé par l'EF9345, est branché sur l'interruption (IRQ) du Z80. Comme je l'avais abordé dans l'article sur les hooks de la ROM du VG5000µ, le système appel une emplacement en RAM avant d'effectuer son affichage. Il est possible remplacer l'instruction RET initialement positionné à cette adresse par un saut (JMP xxxx) vers l'adresse que l'on veut.

Et c'est une des premières opérations que fait le programme : une mise en place d'un routage vers l'exécution des listes d'affichage en cours. La routine dépile aussi l'adresse de retour sur la pile, afin de désactiver complètement l'affichage géré par la ROM.

On est donc en contrôle complet de l'affichage du VG5000µ. Une lourde responsabilité !

Gestion de listes

Il y a de nombreuses manières différentes d'implémenter des listes d'affichage, en fonction des besoins en vitesse balancés avec la place prise et probablement d'autres paramètres encore.

Dans ce programme, les listes d'affichage sont formées par une suite d'appels, au sens machine (CALL) vers de fonctions spécialisées. Ce sont des listes chaînées qui ont le format suivant :

l'adresse du lien vers l'élément suivant, ou zéro pour la fin de liste,
l'adresse d'appel,
les paramètres de l'appel.

Ajouter un élément à la liste d'affichage est donc ajouter à la liste une nouvelle adresse d'appel ainsi que des arguments, puis ajuste le lien de la chaîne.

Rejouer une liste consiste à parcourir la liste et appeler les fonctions spécialisées en fournissant les paramètres.

Tout cela est stocké dans l'espace de la RAM que la ROM utilise normalement pour traiter l'affichage. Il y a là plein de place inutilisée.

J'ai considéré un temps utiliser aussi l'espace des variables internes du BASIC, mais z88dk en utilise une partie, par exemple pour la lecture des touches, que je n'ai pas réécrite. Il est cependant possible d'utiliser cette partie avec un peu plus d'efforts.

Un exemple

Dans la fonction d'affichage de l'écran titre plus haut, il est cette ligne :

    set_print_attributes(M40LONG_COLOR_FG_WHITE, M40LONG_DOUBLE_HEIGHT);

Cette fonction set_print_attributes n'agit pas directement sur l'EF9345. Si on regarde son implémentation, on peut voir qu'elle se contente d'ajouter à la liste d'affichage un appel différé vers la routine spécialisée :

void set_print_attributes(unsigned char a, unsigned char b)
{
    params[0] = a;
    params[1] = b;
    add_to_display_list(dl_set_attributes, 2, (void*) params);
}

Les trois paramètres indiquent :

l'adresse de la routine spécialisée,
la taille des paramètres, en octets,
les paramètres, sous forme d'un buffer qui sera copié dans la liste d'affichage.

Au prochain traçage de l'écran, la routine sera alors appelée. Dans ce cas précis, c'est une routine en assembleur.

    ; Sets the A and B attributes to used for KRF
    ; Parameters are A then B
_dl_set_attributes:
    ef9345_addr EF9345_SEL|REG_R3_CMDST ; Loads A
    ld          a,(hl)
    ef9345_data a
    call        wait_impl
    ef9345_addr EF9345_SEL|REG_R2_CMDST ; Loads B
    inc         hl
    ld          a,(hl)
    ef9345_data a
    call        wait_impl
    ret

Mais il est possible d'appeler une fonction C annotée avec l'attribut __z88dk_fastcall vu plus haut. Ainsi, la fonction C recevra le buffer de paramètre naturellement. Il n'existe qu'une seule fonction dans le programme qui utilise cette méthode, car j'ai progressivement réécrit les autres en assembleur. C'était cependant bien pratique pendant le développement.

Cette fonction s'occupe de l'affichage des pièces, et commence comme ceci :

void dl_display_room(const RoomNew** p_room_param) __z88dk_fastcall
{

Conclusion

Le système de page est simple et efficace dans le cadre de ce jeu. Et le système de liste d'affichage a bien joué son rôle : l'affichage du jeu est rapide et agréable. Il a fallu quelques ajustements sur matériel réel sur quelques synchronisation, car j'envoyais parfois les commandes trop vite, ce qui est accepté par les émulateurs, mais pas par un vrai VG5000µ.

Dans le prochain article, je compte parler de la méthodologie de développement que j'ai utilisé sur le jeu. À la prochaine !

Récréation 3D, Micral N

2023-02-15T00:00:00+01:00

Je l'avais brièvement mentionné il y a presque un an : j'ai eu la chance de pouvoir travailler avec l'association M05.COM à l'analyse et restauration d'un exemplaire de « Micral N ».

Entre deux analyses, j'ai reproduis cet exemplaire en modèle 3D, que je présente ici dans un rendu assez simple.

J'y voyais deux intérêts. Le premier est que c'est pour moi une façon d'étudier l'aspect extérieur d'une machine. Dans le cas de celle-ci, est-ce que j'ai bien vu tous les détails ? Est-ce que j'ai bien vu toutes les LEDs et tous les interrupteurs. L'exercice de modélisation force à se pencher sur les détails.

En comparant les photos, on peut aussi voir les différences entre différents exemplaires. Par exemple, l'exemplaire de l'association a un interrupteur ajouté sur la droite du panneau de contrôle par rapport aux autres exemplaires dont les photos sont disponibles.

Le deuxième intérêt est que cette modélisation pourra servir pour l'émulateur « grand public » (toute proportion gardée), afin de manipuler le clone virtuel de cette machine.

L'exemplaire original, lui, peut-être vu dans cet article de blog sur le site de l'association.

La Maison dans la colline, partie 3

2023-01-26T00:00:00+01:00

Suite de la série sur le développement du jeu La maison dans la colline sur VG5000µ. Après, un exposé du contexte dans la première partie, puis un aperçu des outils utilisés dans la seconde partie, cet article aborde l'idée du jeu et de son évolution au fur et à mesure du développement.

La première idée

LE VG5000µ est une machine que je commence à bien connaître, et, comme expliqué dans le premier article, j'étais en train d'approfondir les capacités du VDP lorsque ce petit défi a commencé. Je voulais me servir des mes nouvelles connaissances et je suis parti sur l'idée de faire un affichage « fin » et sans clignotement.

L'idée de faire un jeu d'aventure graphique me trottait dans la tête depuis quelques temps, et c'est un genre qui collait bien à mes objectifs. Peu de mouvements à l'écran, donc l'affichage pourrait être maîtrisé.

Initialement, le jeu se passe dans un manoir, c'est-à-dire un lieu avec de nombreuses pièces. Et puis, c'est le classique des jeux graphiques ou textuels, repris aussi par des standards comme « Alone in the Dark » en jeu vidéo, ou « Mansions of Madness » en jeu de plateau. Les jeux où le but est de sortir d'une maison fermée ne manquent pas.

Rapidement, je fais quelques croquis pour me fixer une idée de ce à quoi le jeu ressemblerait. Un peu de place pour l'affichage de la pièce courante vue de dessus, de la place pour un texte et un inventaire.

Creuser les idées

Dans ce genre de jeux, il s'agit de résoudre des énigmes qui prennent la forme de trouver les bons objets pour les amener aux bons endroits. Il peut y avoir quelques énigmes plus complexes à résoudre, mais je veux m'arrêter là. Le temps va passer vite, et il faut rester sur du faisable, et sachant que ça sera déjà probablement trop.

Je lance quelques idées d'objets. Une torche électrique. Une boite d'allumettes. Ah, donc autant remplacer la torche pas une lanterne à allumer. Des livres. Des clés. C'est vague, mais cela me permet de définir quels types d'interactions le personnage du jeu peut avoir. Ah, et des portes aussi.

Au tout début, les interactions sont nombreuses : prendre, lire, utiliser, combiner, poser, ouvrir... Mais je sens que cela va faire beaucoup. Je voudrais aussi essayer que le jeu soit jouable avec la manette, à un seul bouton (ce ne sera pas le cas au final). Cette contrainte me fait réfléchir à réduire le nombre d'interactions, ou en tout cas de faire en sorte qu'elles soient automatiques : si je fais une action sur un livre, c'est pour le lire. Si je fais une action devant une porte en ayant une clé, c'est pour l'ouvrir. Et ainsi de suite. Mais pour le moment, je ne creuse pas plus avant. Je laisse cette idée mûrir.

Je veux aussi me détacher des jeux d'époque dont une partie de la difficulté est de comprendre comment manipuler le jeu. De ce côté-ci, je veux apporter de la modernité (toute relative) : en jouant, les objets sur lesquels ont peut agir doivent être facilement identifiables, et les actions possibles indiquées en fonction du contexte. Ça va probablement raboter la durée du jeu, mais cela sera beaucoup plus agréable.

Concernant la durée d'ailleurs, je ne vise pas quelque chose de très long. Les quelques personnes susceptibles de jouer à ce jeu ne cherchent probablement pas une expérience de douze heures. Ni même d'une heure. Trente minutes pour quelqu'un qui ne connaît pas la solution, ça semble bien. Même si je cherche à ce que le jeu soit agréable à jouer et un bon moment à passer, c'est avant tout une preuve de concept d'affichage sur VG5000µ. Et c'est un hobby à mes heures perdues.

Ci-dessous, une maquette préliminaire du jeu avec des essais de rendu. On y voit un essaie de personnage plus large. Les portes sont différentes aussi.

Évolutions

Toutes ces idées, je les notes sur un carnet (électronique), et je n'hésite pas à les annoter, les modifier, les corriger, en fonction des développements, du temps qui passe, des choses plus faciles à programmer que d'autres, des simplifications,... Cette espèce de document de design est un document vivant, que j'adapte au fur et à mesure.

Je commence à coller un scénario sur mes éléments de gameplay, afin d'expliquer les contraintes. Pourquoi est-ce que le personnage ne peut pas sortir de la maison une fois qu'il y est entrée. Que s'est-il passé dans les différentes pièces.

En retour, le scénario influe sur le design. Comment est-ce que j'agence les pièces, quels objets vont dans quelles pièces, qu'est-ce que je fais faire aux gens qui jouent ?

C'est allers et retours entre conception du jeu, de niveaux, du scénario et du programme nourrissent peu à peu ces différentes parties et les font avancer de concert.

Le manoir initial se transforme en une maison à moitié troglodyte, car c'est un moyen assez « simple » d'avoir un environnement d'intérieur de maison et de grotte dans un espace assez restreint. C'est un peu tiré par les cheveux mais bon, on est dans du jeu vidéo rétro. Je me trouve même assez sobre par rapport à certaines productions.

Petit à petit se construit aussi un double objectif afin de pouvoir terminer le jeu. Sortir de la maison, mais aussi pouvoir reprendre la voiture qui nous a amené sur les lieux.

J'ajoute aussi un peu de « lore » avec quelques objets qui ne sont pas nécessaires, mais qui font transparaître une histoire assez simple, mais je pense suffisante pour l'ambition toute relative de ce jeu. J'ai donc écrit un petit background sur les évènements passés de cette maison. Qui sait ? Peut-être que je compléterai l'histoire grâce à d'autres jeux dans le futur.

Léger

La constante, c'est de rester léger. Comme je l'ai évoqué, c'est un petit défi de programmation hobbyiste. Il ne faut surtout pas hésiter à couper, et donc prévoir des choses de manières à ce qu'elles puissent facilement être enlevées en modifiées.

Je suis assez satisfait du résultat, même si j'y vois plein de petites erreurs, ou maladresses, en y jouant.

Mattel Aquarius, scan des touches en assembleur

2023-01-19T00:00:00+01:00

Le scan du clavier, sur Mattel Aquarius, à lieu dans la ROM à l'adresse $1e80. Cette fonction traite les minuscules, les majuscules mais aussi les raccourcis BASIC, en injectant au fur et à mesure les touches nécessaires comme si elles avaient été tapées au clavier.

C'est beaucoup trop pour un scan de clavier dans un jeu, et peut même poser quelques soucis. Mais c'est une bonne base pour écrire une routine de lecture de clavier, car la lecture des valeurs des touches n'est pas forcément très simples.

Ce que nous apprends la lecture de la routine en ROM est qu'il semble falloir attendre une stabilité dans les valeurs avant d'accepter la touche. En effet, la routine fait plusieurs lectures et ne considère la touche appuyée que si cette lecture est stable.

Voici une version de la routine, où j'ai enlever ce qui était traitement de raccourcis BASIC, ainsi que le traitement des touches de modifications. Ainsi, la traduction ne se fait qu'avec les touches minuscules.

Attention, je n'ai pas encore testé cette routine sur du matériel réel !

La routine

Dans cette version, le décodage de la touche est faite par rapport aux minuscules. En changeant vers la fin la valeur de HL de lower_key_table-1 vers upper_key_table-1, il est possible d'obtenir un décodage avec des majuscules.

Il est aussi possible de ne traiter que des codes de touches, sans traductions. Dans ce cas là, il suffit de remplacer les trois instructions après accept_key par un simple LD A, E.

Les deux emplacements en RAM, qui commencent ce code source, doivent être en RAM et être adaptés à votre programme.

latest_keycode_pressed: EQU     0380eh
keyword_delay_value:    EQU     0380fh

lower_key_table:        EQU     01f38h
upper_key_table:        EQU     01f66h

check_key:
    EXX

    LD         BC,0xff
    IN         A,(C)
    CPL
    AND        0x3f
    LD         HL,latest_keycode_pressed
    JR         Z,no_key_scanned            ; ?No row were selected, quick skip?
    LD         B,0x7f                      ; Input row 7
    IN         A,(C)
    CPL
    AND        0xf                         ; Only 4 keys in lower bits
    JR         NZ,decode_key_scan
    LD         B,0xbf                      ; Input rows 6 to 0

loop_input_rows:
    IN         A,(C)
    CPL
    AND        0x3f                        ; 5 keys in lower bits
    JR         NZ,decode_key_scan
    RRC        B
    JR         C,loop_input_rows

no_key_scanned:
    INC        HL
    LD         A,0x46
    CP         (HL)                        ; Compare with delay
    JR         C,return_no_key_value
    JR         Z,reset_latest_key
    INC        (HL)                        ; Increment delay

return_no_key_value:
    XOR        A
    EXX
    RET

reset_latest_key:
    INC        (HL)
    DEC        HL
    LD         (HL),0x0
    JR         return_no_key_value

decode_key_scan:
    LD         DE,0x0

count_row:
    INC        E
    RRA
    JR         NC,count_row
    LD         A,E                         ; E is the active row

count_add_column:
    RR         B
    JR         NC,keycode_found
    ADD        A,0x6                       ; Add 6 for each column
    JR         count_add_column

keycode_found:
    LD         E,A
    CP         (HL)                        ; HL = 0380eh
    LD         (HL),A
    INC        HL
    JR         NZ,new_key_delay            ; That's a new key, we need a bit of selay
    LD         A,0x4
    CP         (HL)
    JR         C,commit_key_delay_continued
    JR         Z,accept_key                ; Wait if over, accept key!
    INC        (HL)                        ; Increment delay from 4 to 6 iteratively
    JR         return_no_key_value

commit_key_delay_continued:
    LD         (HL),0x6                    ; Set the delay for the second pass
    JR         return_no_key_value

new_key_delay:
    LD         (HL),0x0
    JR         return_no_key_value

accept_key:
    LD         IX,lower_key_table-1
    ADD        IX,DE
    LD         A,(IX+0x0)                  ; Read decoded Key value

return_key_value
    EXX
    RET

Mattel Aquarius, entrées des commandes BASIC

2023-01-18T00:00:00+01:00

Commençant à étudier le Mattel Aquarius afin de participer à la nouvelle session de « Retro Programmers United for Obscure Systems », et devant le manque de documentation, j'ai regardé ce qu'il y avait dans la ROM. Et c'est un BASIC Microsoft qui y est implémenté, ce qui est bien pratique puisque c'est un BASIC que j'ai bien étudié à travers le VG5000µ.

J'ai donc ressorti ma trousse à outils et voici la liste des points d'entrées des commandes et fonctions du BASIC.

La première colonne est le token BASIC, la seconde l'adresse du point d'entrée en ROM et la troisième le nom.

Les commandes

    128     $0c21         end
    129     $05bc         for
    130     $0d13         next
    131     $071c         data
    132     $0893         input
    133     $10cc         dim
    134     $08be         read
    135     $0731         let
    136     $06dc         goto
    137     $06be         run
    138     $079c         if
    139     $0c05         restore
    140     $06cb         gosub
    141     $06f8         return
    142     $071e         rem
    143     $0c1f         stop
    144     $0780         on
    145     $07b5         lprint
    146     $1b15         copy
    147     $0b3b         def
    148     $0b6d         poke
    149     $07bc         print
    150     $0c4b         cont
    151     $056c         list
    152     $0567         llist
    153     $0ccd         clear
    154     $1c2c         cload
    155     $1c08         csave
    156     $1a4f         pset
    157     $1a4c         preset
    158     $1ad6         sound
    159     $0bbd         new

Les fonctions

    178     $14f5         sgn
    179     $15b1         int
    180     $1509         abs
    181     $3803         usr
    182     $10a8         fre
    183     $0b2e         lpos
    184     $0b33         pos
    185     $1775         sqr
    186     $1866         rnd
    187     $1385         log
    188     $17cd         exp
    189     $18d7         cos
    190     $18dd         sin
    191     $1970         tan
    192     $1985         atn
    193     $0b63         peek
    194     $0ff3         len
    195     $0e29         str
    196     $1084         val
    197     $1002         asc
    198     $1013         chr
    199     $1021         left
    200     $1050         right
    201     $1059         mid
    202     $4ec5         point

Cela peut aider à donner des points d'entrée pour comprendre comment fonctionne la machine.

La Maison dans la colline, partie 2

2023-01-06T00:00:00+01:00

Suite de la série sur le développement du jeu La maison dans la colline sur VG5000µ. Après, la première partie, qui donnait le contexte de création, voici donc la deuxième partie, où j'aborde les outils de développement utilisés.

Les bases

Lorsque je développe un logiciel, je veux pouvoir me consacrer sur un temps contiguë maximum au cœur du projet. Même, et peut-être surtout, lorsque ce développement est un hobby, et que j'ai peu d'heures à y consacrer, ici et là en fonction de mon temps libre.

Ainsi, une fois le projet en développement, lorsque j'ai une petite demi-heure par-ci ou une grosse heure par là, je veux pouvoir m'installer et me consacrer à la valeur de ce projet. À son développement concret.

Pour moi, cela signifie que tout ce que je peux automatiser et qui me permettra de profiter de ces temps là au maximum doit l'être fait en amont. Si je dois cliquer sur des boutons, faire des manipulations, lancer ou configurer des logiciels à chaque fois que je fais un essai, voire même à chaque fois que je débute une session, c'est un temps précieux qui est inutilisé. Chaque manipulation est aussi une occasion de faire une erreur.

Dans le passé sur ce site, j'ai déjà présenté quelques outils destinés à me faciliter la tâche. Et dès les essais sur l'EF9345 dont je parlais dans l'article précédent, j'ai remis en place un script qui permet de lancer l'émulateur automatiquement, configuré avec lancement du chargement.

Comme je me doutais que le programme allait gagner en taille, j'ai ajouté au script une manière de passer l'émulateur en vitesse accélérée le temps du chargement.

Ainsi, dès que je termine une compilation, je n'ai que quelques secondes à attendre avant de retrouver le jeu, prêt à être testé, dans l'émulateur.

Le framework

Afin de pouvoir itérer sur le jeu, particulièrement sur son gameplay, j'ai choisi de développer dans un mélange de C et d'assembleur. Le C permet des modifications simples de morceaux de code sans trop se poser de questions bas niveau. L'assembleur permet d’accélérer certaines parties une fois qu'elles sont fixes, ainsi qu'un accès rapide au matériel.

Car en effet, si j'ai choisi de faire un jeu d'aventure graphique, je tiens à deux choses au niveau de l'affichage :

que l'affichage d'une pièce soit très rapide (si ce n'est immédiat),
que les mouvements à l'écran ne provoquent aucun clignotement

Difficile voire impossible à faire cela en BASIC. Plus facile à faire en C, mais c'est l'assembleur qui me permettra de vraiment réaliser ces objectifs.

De même, je voulais initialement que le jeu tienne sur une machine sans extension mémoire. Malheureusement, je ne réaliserai pas cet objectif. De peu...

z88dk

Quelques temps (années ?) auparavant, j'avais croisé le chemin de z88dk, un framework de programmation en C dédié aux machines Z80. Cela me semblait être une bonne occasion pour l'essayer, avoir l'espoir qu'il vienne avec des fonctionnalités intéressantes qui me feraient gagner du temps.

Après tout, il y a des outils de création de programme assemblés dans une suite complète, une bibliothèque C pour Z80, un support VG5000µ et un fichier crt.s déjà configuré et configurable. Ça, se sont les avantages.

Après usage pendant toute la durée du projet, voici les inconvénients :

le programme principal qui appelle les autres pour la compilation n'a pas une syntaxe d'option standard, et cela me posera des problèmes avec cmake,
le compilateur par défaut n'est pas le meilleur, je m'en rendrai compte beaucoup plus tard, vers la fin du projet. Il est possible d'utiliser un compilateur alternatif, qui optimise visiblement mieux. Malheureusement, les deux ne se comportent pas tout à fait de la même façon, et j'ai préférer ne pas changer en chemin. On verra pour un futur projet peut-être,
le support VG5000µ est axé sur une utilisation en mode texte, et passe par le système implémenté par la ROM, sans accès direct à l'EF9345. Ce n'est pas cohérent avec ce que je veux faire, et je n'utiliserai finalement aucune fonction spécifiquement dédiée au VG5000µ.

Au final, je ne suis pas entièrement convaincu par z88dk, qui à l'air de prendre une orientation plutôt CP/M et machined un peu plus puissantes qu'un VG5000µ.

Gestion de la construction

Pour le gestionnaire de construction de version, je suis parti sur cmake. C'est très probablement surdimensionné, mais je connais son utilisation classique. Ici, je voulais pousser plus loin et aborder sa configuration de chaîne de compilation « exotique ».

J'ai beaucoup appris sur cmake au passage ; ma solution finale n'est pas entièrement solide, je confirme à nouveau que Stack Overflow n'est d'aucune aide dès que vous avez un soucis qui n'est pas basique, que la documentation de cmake est toujours peu aidante... et qu'un Makefile tout simple aurait été probablement tout aussi efficace. Mais je m'emmêle toujours les pinceaux avec un Makefile dès que je quitte les règles de bases.

cmake est probablement trop automatique sur certains points, et il n'est pas toujours facile de lui faire comprendre que la buildchain utilisé ne se comporte pas tout à fait comme ce à quoi il s'attend.

Enfin maintenant c'est fait, et même si je dois corriger certaines petites choses au niveau des dépendances entre les .c, les .h et les .asm, ça marche globalement bien.

Éditeur de code

cmake était surdimensionné ? Que dire de l'éditeur de code que j'ai utilisé. CLion... vim ou visual studio code auraient suffit. Et il m'est arrivé d'utiliser vim pendant le développement pour quelques modifs rapides. Mais là encore, je connais bien CLion, ses outils, sa configuration, et l'habitude, ça compte.

De toute façon, mes outils d'automatisation ne sont dépendants ni de cmake, ni de clion, ce sont donc des choix indépendants.

Paré au départ !

Ou presque. J'ai cité les outils de développement principaux. Mais je parlais en introduction d'automatiser la mise en place de l'environnement de développement. Pour cela, j'utilise le terminal kitty associé à un script. Lorsque je lance ce script, le terminal se met en place avec les bon terminaux ouverts dans les bons répertoire, et des outils textes déjà lancés (ranger pour la gestion de fichier, lazygit pour la gestion de version, nb pour la prise de notes, le script d'automatisation à l'écoute).

Ainsi, démarrer une session depuis un ordinateur fraîchement allumé me prend deux clics pour avoir l'intégralité de l'environnement en place, et j'ai tout ce qu'il me faut pour la session. Cela aurait été un seul si je n'avais pas choisi Clion.

Alors... clic, clic... et la suite au prochain épisde.

Plouf ... in space

2023-01-03T00:00:00+01:00

En attendant de revenir sur le déroulé du développement de « La maison dans la colline », voici un article beaucoup plus court pour présenter ma contribution à la session la plus récente de « Retro Programmers United for Obscure Systems », consacrée à Exelvision.

La découverte de la machine

Exelvision, une entreprise française, a produit au milieu des années 80 une série de machines assez originales. Ce sont des machines de type familial, mais avec un look un peu pro, un choix audacieux mais probablement désastreux d'une connectique sans fil pour le clavier et les joysticks, de la synthèse vocale, et des capacités graphiques plutôt correctes.

Pour ce challenge, je me suis orienté vers la première de ces machines, l'EXL 100, dont vous pouvez trouver une présentation détaillée sur ce site.

C'est une machine que je ne connaissais pas vraiment. Ou tout du moins, je ne m'étais pas penché sur ces caractéristiques, son architecture ni même sur les périphériques disponibles. Et la surprise fut là.

Côté processeur principal, je savais qu'il faisait dans l'original, un TMS 7020. Côté RAM, tout est côté vidéo, associée à un TMS 3556, non accessible directement par le TMS 7020. Ça promet. Toute cette place mémoire, 32 ko tout de même, hors de porté du bus principal. Et en RAM principale ? ... 2 ko. Deux tout petits kilo octets, déjà très occupés par le système.

Je me tourne vers le BASIC pour découvrir la machine. Celui-ci est disponible sur cartouche. Et ses données sont bien en VRAM, le seul endroit où il y a de la place. Les performances sont en adéquation. C'est lent. Pas très lent, il y a pire, mais lent tout de même.

La machine peut bien supporter des extensions mémoires, mais l'architecture laisse peu de place au doute : c'est une machine qui est faite pour lancer ses programmes sur cartouches en priorité, à moins de lui adjoindre l'extension disquettes, qui fait entrer la machine dans une toute autre dimension.

Ces matériels ne sont pas très courant, et semblent complexifier la machine, je décide donc de cibler l'EXL100 de base, sans extension.

Les deux premières pistes

La première piste que j'explore est technique : celle de proposer le logiciel sur cartouche. L'avantage me semble être une rapidité d'exécution. L'inconvénient est que je n'ai aucune idée de comment fonctionne la ROM de la machine, de ce qu'il faut pour la faire reconnaître. Ça se trouve bien entendu, mais je ne connais pas non plus l'assembleur TMS 7020. Je laisse l'idée rapidement de côté, il y a trop d'inconnues pour moi sur cette machine.

La seconde piste est logicielle : écrire une machine virtuelle qui tiendrait dans la petite RAM de la machine pour exécuter un byte code présent dans la VRAM. L'idée me plaît bien et j'y réfléchi un temps tout en consultant les documentations de la machine. Mais encore un fois, je m'aperçois des particularités de la machine. Je crains le hors sujet.

Au final, faisons simple : un petit jeu en BASIC pour s'entraîner. Et si j'ai le temps, loger un peu d'assembleur pour accélérer certaines parties.

Plouf

Puisque j'ai besoin de creuser ma connaissance de la machine, je ne peux pas me lancer dans quelque chose de compliqué. Je vais donc chercher dans les classiques. Après quelques hésitations, je choisi la bataille navale. C'est un jeu qui peut se représenter avec des graphismes détaillé tout comme en caractères, c'est assez simple à programmer. Petit inconvénient, il me faudra une IA pour un jeu à une seule personne.

Je cherche un petit twist tout de même pour ne pas aller dans le trop classique et je me dis que faire bouger les bateaux entre deux tours pourrait être sympa sans trop complexifier le jeu. Là encore, c'est débrayable, si je n'ai pas le temps, je ferai sans.

Et donc c'est parti.

Le BASIC

La plupart des BASICs de l'époque se ressemblent, souvent parce qu'ils sont soient des adaptations du BASIC Microsoft, soit parce qu'ils ont été créés avec une syntaxe similaire, ou en tout cas en suivant cette branche d'évolution du BASIC.

Sans être complètement différent, le BASIC Exelevision a des particularités. Entre autre, il a un concept de routines appelables sans tenir compte de son numéro de ligne. Pratique à première vue. De plus, dans ces routines, les variables sont locales. C'est plutôt attrayant.

Rapidement, les routines semblent être une fausse bonne idée. En premier lieu, même si le numéro de ligne n'a pas d'importance, elles doivent absolument se trouver à la fin du programme, sous peine d'erreur (et les erreurs sont sous forme de nombres seulement, mieux vaut avoir le manuel sous les yeux). Et puis la localité des variables est tout ou rien. Et on ne peut pas passer de tableaux à ces routines.

Au final, je ne garde qu'une paire de fonctionnalités sous forme de routines. Le reste sera fait avec ce bon vieux GOSUB et des numéros de ligne.

Le BASIC permet aussi un traitement d'exception, avec de la récupération d'erreurs. C'est plutôt pas mal... mais je ne penserai à m'en servir que tard dans le développement. Ce BASIC semble cependant un peu capricieux, avec des commandes qui parfois ne veulent pas être sur la même ligne et parfois oui... je n'ai pas vraiment compris les raisons.

Le démarrage d'un programme après un RUN est assez long, et de plus en plus long avec l'avancée du projet. J'acquière la certitude que RUN effectue une vérification du programme. Peut-être pas une compilation, quoi que je n'en sais rien, mais il est capable de détecter avant démarrage les erreurs de numéros de lignes dans les GOTO/GOSUB, et les mauvais appariement de boucles FOR/NEXT.

C'est pratique pour le premier cas, parfois un peu obscure pour le second, car la ligne en erreur n'est pas toujours celle où se trouve vraiment l'erreur.

Cependant, c'est une fonctionnalité notable, car peu présente, voire pas, sur d'autres BASIC de cette époque.

Le jeu

Je n'ai pas grand chose à dire sur le jeu lui-même. La principale difficulté est d'arriver à caser deux grilles à l'écran. L'algorithme de déplacement et collision des bateaux me pose aussi quelques soucis, et debugguer n'est pas des plus plaisants, même sur émulateur. Cette machine est peu utilisée, peu connue, et le manque d'outils se fait cruellement sentir.

Mais je crois bien que ça sera le cas à chaque fois pour ces Game Jams, étant donné que le but est d'aller sur des machines sur lesquels il y a peu de développement.

Mon principal problème est la vitesse. Le jeu est affreusement lent. Vraiment. Le fait que les bateaux bougent et collisionnent pour faire demi tour demande de longs calculs. Un temps, j'imagine couper les collisions et dire que après tout, ce sont des sous-marins et qu'ils peuvent passer l'un sur l'autre.

Cependant, cela complexifie la compréhension du jeu, ainsi que la gestion des tirs, qui peuvent toucher plusieurs sous-marins en même temps. Je décide donc qu'il est temps de s'essayer à un peu d'assembleur.

Optimisations assembleur

Le TMS 7020, de la série TMS 7000, est un processeur connu, même si pas aussi utilisé dans les ordinateurs personnes que le Z80 ou le 6809. Il est donc supporté par des assembleurs et en particulier par celui-ci, que je connais déjà. Parfait.

J'avais déjà commencé à lire des ressources sur la programmation de cette machine et ses 128 registres. Quel luxe... ou presque, car c'est dans cette mémoire interne que se loge la pile aussi. Ça reste quand même bien spacieux.

Et au final, c'est un processeur plutôt agréable. Très simple à programmer. La plus grosse difficulté étant plutôt, à nouveau, de comprendre l'environnement de la machine, les registres à préférer et/ou à laisser tranquille. Comment discuter avec le processeur vidéo et accéder à la VRAM. Mais là encore, il y a de nombreux exemples dans de la documentation.

La machine, bien que peu connue et peu dynamique, a eu déjà eu des retro-développeurs dans le passé proche. La route est pavée. Un peu laissée à l'abandon, mais pavée quand même, et c'est agréable. Merci à eux.

Au final, transférer en assembleur mes routines les plus coûteuses se révèle extrêmement bénéfique. J'en aurais bien transféré plus, mais d'après la documentation, j'ai évalué à un peu moins de 500 octets la place disponible de manière « sûre ». On devrait pouvoir pousser un peu plus, mais je n'avais pas le temps de pousser les tests. Restons prudent.

... in Space

Pendant le développement, j'ai souvent hésité. Est-ce que ce sont des bateaux ? Est-ce que ce sont des vaisseaux spaciaux ? Initialement, je comptais redéfinir des caractères afin d'avoir un affichage un peu plus joli. Le temps manquant, je suis resté sur le jeu de caractères disponibles dans le BASIC, qui heureusement à quelques caractères permettant de tracer des lignes en mode basse résolution.

Pas non plus le temps d'enjoliver en utilisant un peu de mode haute résolution, qui peut se partager l'écran sur cette machine avec le mode texte. L'essentiel du développement se fait pendant mes vacances de fin d'années, et donc juste à la fin de la période de la Game Jam.

Donc bateau ou vaisseau... cela n'a pas vraiment d'importance en soi.

Oui mais, dans cette Game Jam, même si on n'en est qu'à la deuxième session, il est de « tradition » de pousser un peu la qualité en ayant une couverture de jeu, une illustration, un manuel, ou un peu de tout ça. Et les jeux de l'époque misaient beaucoup sur ce packaging pour faire travailler l'imagination.

Donc je dois choisir. Et je choisi l'espace... même si le fond de l'écran pendant le jeu reste bleu foncé. Les vaisseaux ne sont pas coulés après avoir été touchés, mais désactivés, ce qui me donne une justification au RADAR, qui réagi aux morceaux de vaisseaux touchés.

Il me reste une IA à bricoler. Je fais simple : si le RADAR ne donne pas d'information, le coup prochain se fera au hasard. S'il donne une information, le tir se fera d'autant de cases que la distance indiquée par le RADAR, réparties en horizontal et en vertical. Cela ne prend pas en compte le déplacement des vaisseaux, ni les touches précédentes, mais après quelques parties, je juge que c'est suffisant pour mettre une petite pression à l'humain.

Conclusion

Une machine originale, qui demande vraiment à y revenir. Un jeu qui ne vole pas très haut, mais qui a été intéressant à optimiser et comme toujours, à terminer et présenter.

Si vous aussi vous voulez jouer avec des torpilles photoniques, c'est par ici.

Inifinite Turtles, un jeu avec des tortues jusqu'en bas.

2022-12-22T00:00:00+01:00

Le jeu « Inifinite Turtles », de Charlie Brej, est un casse-tête de programmation. De manière classique dans ce type de jeu, vous êtes exposés à des problèmes de plus en plus complexe à résoudre, en ayant à votre disposition de nouvelles briques du système.

En ce sens, il se rapproche des jeux de Zachtronics comme Shenzhen I/O, de Human Resource Machine ou bien d'autres, à un niveau de réalisation moins poussé tout en étant tout à fait acceptable.

Dans « Infinite Turtles », votre terrain est une grille de positions avec quatre « portes » aux points cardinaux. Ces portes sont des entrées ou des sorties par lesquels vont transiter des jetons numérotés.

À votre charge d'acheminer les jetons grâce à des tapis roulants à travers la grille.

Chaque niveau vous indique l'objectif à atteindre et vous donne, pour les premiers niveaux, des indications sur le fonctionnement du jeu, ainsi qu'une nouvelle brique fonctionnelle.

Ces briques fonctionnelles occupent un espace sur la grille. Elles réalisent une fonction simple, comme par exemple un aiguillage, un clonage du jeton ou encore un filtre.

De plus, chaque niveau réalisé devient une nouvelle brique fonctionnelle que vous pouvez utiliser pour résoudre d'autres niveaux. Et bien entendu, le jeu est construit de manière à ce que les nouvelles fonctions servent dans les problèmes suivants.

Enfin, pour vous aider à la réalisation du niveau, un batterie de tests est disponible, que vous pouvez exécuter plus ou moins rapidement, afin d'aider à mettre au point la solution.

Et enfin, un score vous indique l'efficacité en temps et en briques utilisées et vous pouvez le comparer aux autres joueurs.

Des tortues jusqu'en bas

Le titre du jeu ne fait pas référence à une tortue de type de celle utilisée dans le langage Logo, mais à la cosmogonie qui dit que la Terre repose sur une tortue, elle même reposant sur une tortue,... et tout ceci jusqu'en bas.

Le thème est introduit dès le début dans les explications par les dialogues des personnages qui animent la narration, qui sont toujours par couple identique mais de tailles différentes.

Ainsi, le jeu introduit l'utilisation de briques fonctionnelles qui utilisent elles-mêmes d'autres briques fonctionnelles qui utilisent, etc.

Tout dans la synchro

La difficulté des problèmes n'est pas tant de les résoudre fonctionnellement, mais de les placer sur une grille restreinte. En effet, rapidement, la place se fait rare, et l'utilisation des briques déjà faites est nécessaire.

Cependant, le système que crée le jeu est très dépendant des synchronisations. En effet, les jetons arrivent avec un tempo déterminé par les tests et leur temps de trajet sur les tapis roulants est entièrement dépendant de la longueur de ces trajets, y compris des trajets dans les briques internes.

Dès les premiers niveaux, les défis proposés sont clairs : il va falloir trouver des moyens de synchroniser tous ces jetons pour qu'ils arrivent face au briques fonctionnelles au moment voulu. Le jeu guide vers des systèmes de synchronisation que l'on découvre et que l'on pourra appliquer plus tard.

Mais ces systèmes prennent de la place, beaucoup de place, car basé sur de l'envoi de messages par jetons. Ils nécessitent donc des tapis roulants encombrants.

Et donc ?

Je n'ai pas terminé tous les niveaux du jeu. Je suis allé assez loin, mais au bout d'un moment, j'avais l'impression que le problème à résoudre était essentiellement du routage de jeton et comment faire tenir le tout dans la grille.

Les fonctions d'édition avancées de la grille, qui ne sont pas présentée dès le début, ne sont pas toujours très agréable non plus. Quand on veut essayer différents type de routages afin de voir celui qui prend le moins d'espace, le comportement des tapis roulant est rapidement agaçant.

Un autre défaut, mais moindre, est la progression des niveaux, qui mériterait plus de fluidité. Les problèmes par lesquels ont passe ont un objectif, on le sent bien, mais on passe parfois du coq à l'âne, sur des voies que l'on sent se rejoindre au loin, mais qui produisent une sorte de « task switching » peu agréable.

Malgré ces petits soucis, et sur la vingtaine de niveaux que j'ai pu résoudre, j'ai trouvé le jeu amusant et plutôt original. Le modèle d'automation et le type de programmation qu'il induit sont plutôt originaux, avec une petite histoire métaphysique pour enrober le tout.

C'est un jeu qui se défend tout à fait dans sa catégorie, et si vous êtes curieux et aimez les jeux d'énigmes logiques, cela pourra vous plaire.

La Maison dans la colline, partie 1

2022-12-22T00:00:00+01:00

En juin 2022, sur Facebook, Olipix lance un groupe avec l'objectif de donner un peu d'activité à des ordinateurs qui n'en n'ont pas beaucoup. En effet, si quelques anciennes machines bénéficient de nombreux nouveaux logiciels homebrew toujours de nos jours, certaines autres ont une base d'utilisateurs beaucoup plus restreinte. Et souvent une ludothèque maigrichonne.

Initialement, je n'ai pas trop prêté attention à l'initiative. J'étais justement en train de nettoyer mon compte Facebook avec l'idée de ne plus y mettre les pieds, tout en gardant un accès minimale « au cas où ». Mais quand on m'avertie qu'un vote a désigné le VG5000µ comme première machine, je dresse l'oreille.

Ça tombe bien, je m'étais remis à l'étude du VG5000µ après le hiatus de l'étude du Micral N. C'est une excellente occasion pour relier les deux activités : continuer l'exploration de la machine, tout en développant un jeu.

Reste à trouver l'idée. J'aimerais quelque chose qui pousse un peu les capacités d'affichage de la machine. En attendant, je commence à mettre en place une chaîne d'outils de développements avec comme premier objectif le développement d'un programme de tests des différentes possibilités graphiques de l'EF9345.

L'idée derrière la batterie de tests est de documenter l'utilisation de ce processeur graphique en publiant les sources, de démontrer ses différents modes (ce qui a déjà été fait par le passé), et de proposer des tests pour pouvoir travailler les détails des timings et les commandes non implémentées actuellement dans les deux émulateurs du VG5000µ (dcvg5k et MAME).

Je n'ai pas encore terminé cette batterie de tests, puisque je suis passé entre temps sur le développement du jeu. Je publierai ça sous peu, même si pas terminé, accompagné d'articles.

En attendant, en voici une copie d'écran.

Utilisation de z88dk pour le VG5000

2022-07-03T00:00:00+02:00

Encore ?! Oui... encore. Une nouvelle manière de gérer la construction d'un programme VG5000µ. Après la version Sublime Text et z80asm en 2018, puis la version Visual Studio Code et sjasmplus en 2020, je voulais essayer autre chose.

J'avais laissé de côté Sublime Text et z80asm pour deux raisons : le changement de license de Sublime Text que je n'avais pas apprécié, et le côté très simpliste de z80asm, dont je touchais des limites.

Pour un nouveau projet, je voulais utiliser z88dk, un kit de développement pour machines Z80, avec du support C et ASM, ainsi que des bibliothèques standards. Je voulais aussi approfondir ma connaissance du support de toolchains avec CMake.

Alors oui, cmake pour un tout petit projet pour des machines des années 80, ça fait un peu surdimensionné... Je le concède. Et ça n'enlève en rien mon envie de fouiller de ce côté.

Un exemple, qui peut servir de base, est disponibles sur GitLab et GitHub. Il y a quelques limitations quand à l'environnement supporté, car je n'ai testé que sur mon ordinateur de développement.

Mais l'essentiel est là, et peut éviter des heures de recherches entre la documentation de CMake et StackOverflow, la première était connue pour son aridité et le second pour, en ce qui concerne CMake, ses 99% de réponses fausses, ou tout du moins obsolètes.

Par la suite, je vais décrire les différents éléments qui forment le projet CMake.

CMakeLists.txt

Tout projet cmake a pour point d'entrée un fichier CMakeLists.txt.

cmake_minimum_required(VERSION 3.20)

Tout d'abord, on indique la version minimale de cmake à utiliser. Il est toujours préférable de mettre celle sur laquelle on a validé le fonctionnement, car cmake évolue souvent et tenter d'en mettre une plus ancienne est acrobatique.

list(APPEND CMAKE_MODULE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/cmake/")

Je vais avoir besoin d'ajouter des scripts de description de machine et de compilateur localement, car non reconnus nativement, du moins aujourd'hui, par cmake. J'indique donc que certains scripts se trouvent dans le répertoire locale cmake/, en modifiant la variable CMAKE_MODULE_PATH.

project(vg_tests C ASM)

Je déclare ensuite le nom du projet vg_tests, ainsi que les langages de programmation supportés.

# If need for cmake debug, the next line can help
# set(CMAKE_VERBOSE_MAKEFILE 1)

Comme indiqué, mettre la variable CMAKE_VERBOSE_MAKEFILE à 1 permet d'avoir des informations sur les actions qui sont faites lors de la génération du projet. Très pratique pour comprendre quelles sont les lignes de commandes générées, avec leurs options. Essentiel pour mettre au point quand on tâtonne.

set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ../output)

La variable CMAKE_RUNTIME_OUTPUT_DIRECTORY indique où sont les artefacts de sortie. Dans notre cas, c'est là que se trouveront les .k7 utilisables pour le vg5000µ (ou les .wav, si vous le désirez).

set(SOURCE_FILES src/main.c src/auxiliary.asm)

SOURCE_FILES est une variable interne à ce script. C'est une habitude que de passer par une variable intermédiaire pour spécifier la liste des fichiers sources. Dans certains cas, on peut avoir besoin de la réutiliser.

Ici, je vais compiler et assembler un fichier C et un fichier assembleur.

add_executable(${PROJECT_NAME} ${SOURCE_FILES})
target_compile_options(${PROJECT_NAME} PRIVATE -I$ENV{Z88DK_HOME}/include -Isrc/ -vn -m)
target_link_options(${PROJECT_NAME} PRIVATE -m -create-app -subtype=default)

La déclaration de l'exécutable utilise la variable PROJECT_NAME, qui prend le nom spécifié dans project() au tout début, et y associe la liste des fichiers sources.

Puis sont définies les options de compilations et les options pour l'éditeur de liens. La nature des options ne sont pas du domaine de cet article. Elles seront transmises à zcc, qui est la commande générique pour toutes les opérations de construction dans z88dk.

# Fixes the k7 format for old z88dk versions.
set(INPUT_FOR_FIX ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/${PROJECT_NAME}.k7)
set(ZERO_FILE ${CMAKE_SOURCE_DIR}/zero-file)
set(OUTPUT_FOR_FIX ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/${PROJECT_NAME}.fix.k7)

add_custom_command(OUTPUT k7_fix
        DEPENDS ${PROJECT_NAME}
        COMMAND ${CMAKE_COMMAND} -E cat ${INPUT_FOR_FIX} ${ZERO_FILE} > ${OUTPUT_FOR_FIX}
        )

add_custom_target(${PROJECT_NAME}-fix ALL DEPENDS k7_fix)

La version actuelle de z88dk a un bug au niveau de la génération des données du VG5000µ. Il manque des octets à la fin, qui sont attendues par la ROM pour valider la fin du fichier.

J'ai soumis un fix, qui a été accepté, mais le temps que cela soit déployé partout, j'ajoute cette custom_target, qui utilise une custom_command. Le fichier zero-file est le fichier nécessaire à l'ajustement, et ne contient que des 0.

Compilation croisée

Lancer cmake tel quel ne va pas fonctionner, car par défaut, cela utilisera les outils de compilation de la machine hôte. Il faut donc spécifier une environnement de compilation croisée, c'est-à-dire les outils pour compiler pour une machine cible, et non la machine hôte.

Pour cela, cmake a un mécanisme de déclaration de compilation croisée. Lors de l'initialisation de cmake, il faut spécifier la variable CMAKE_TOOLCHAIN_FILE. Ici, cmake -DCMAKE_TOOLCHAIN_FILE=z88dk-vg5000.cmake.

Ici, on entre un peu dans le tâtonnement. Ce que j'expliquer fonctionne, mais est-ce que c'est carré ? C'est une bonne question.

Voici l'explication du fichier z88dk-vg5000.cmake.

set(CMAKE_SYSTEM_NAME vg5000)
set(CMAKE_SYSTEM_PROCESSOR Z80)
set(CMAKE_C_COMPILER_ID z88dk)
set(CMAKE_ASM_COMPILER_ID z88dk)

En premier lieu, on fourni des valeurs à des variables internes de cmake indiquant le nom du système, le processeur, et des identifiants du compilateur et de l'assembleur. Ces variables seront utilisées par cmake pour déterminer quels fichiers de description il doit chercher.

Il n'est pas toujours très clair de savoir quelle variable influe sur quoi. Il faut se fier aux messages d'erreurs lorsqu'un fichier n'est pas trouvé...

set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY)

Cette variable indique à cmake si, pour valider le fonctionnement de la chaîne de compilation, un essai se fera sur une bibliothèque ou sur un exécutable. L'exécutable, pour être validé, doit être lancé. Comme je ne définie pas de moyen de lancer l'exécutable, je demande à ne faire l'essai de compilation que sur une bibliothèque, ce qui est en fait le défaut lors d'une compilation croisée.

set(TOOLCHAIN_PREFIX z88dk)
set(CMAKE_C_COMPILER ${TOOLCHAIN_PREFIX}.zcc)
set(CMAKE_ASM_COMPILER ${TOOLCHAIN_PREFIX}.zcc)

Ici, j'indique le nom des compilateurs et assembleur. Pour cmake, tout ce qui prend une source et sort un fichier objet est un compiler. Pour z88dk, je passe par le frontend zcc plutôt que les exécutable eux-mêmes, ce qui semble être préféré dans la documentation (et dans la façon dont est construit le paquetage).

set(CMAKE_DEPENDS_USE_COMPILER True)

J'indique aussi à cmake d'utiliser le compilateur pour trouver les dépendances entre les fichiers.

set(CMAKE_C_COMPILE_OBJECT  "<CMAKE_C_COMPILER> +vg5k <DEFINES> <INCLUDES> <FLAGS> -o <OBJECT> -c <SOURCE>")
set(CMAKE_C_LINK_EXECUTABLE "<CMAKE_C_COMPILER> +vg5k <FLAGS> <OBJECTS> -o <TARGET> <CMAKE_C_LINK_FLAGS> <LINK_FLAGS> <LINK_LIBRARIES>")

set(CMAKE_ASM_COMPILE_OBJECT  "<CMAKE_C_COMPILER> +vg5k <DEFINES> <INCLUDES> <FLAGS> -o <OBJECT> -c <SOURCE>")

On y est presque. Dans un cas classique où le compilateur se comporte de manière classique (disons comme un gcc, un clang ou autre), on pourrait se passer de ces lignes. Mais zcc à besoin comme premier paramètre de la plateforme cible (+vg5k ici).

J'indique donc à cmake comment générer la ligne de commande pour les fichiers C et ASM, avec une syntaxe de template.

set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE NEVER)

Et enfin, je demande à cmake de ne pas chercher à résoudre les commandes find_library, que je n'utiliserai pas.

Et ce n'est pas fini !

Le fichier de compilation croisée indique que l'on compile pour VG5000µ. Mais cmake ne connait pas cette plateforme, et va donc chercher un script qui lui en dirait plus.

Ce que j'ai fait n'est probablement pas entièrement correct, car j'associe la plateforme avec la chaîne de compilation. Et je fais ça dans le fichier cmake/Platform/vg5000.cmake.

set_property(GLOBAL PROPERTY TARGET_SUPPORTS_SHARED_LIBS FALSE)

z88dk ne supporte pas un systmème de bibliothèque dynamiques (style DLL, so ou dynlib).

set(CMAKE_C_OUTPUT_EXTENSION .o)

z88dk ne reconnaît que l'extension .o comme fichiers objets. On indique donc à cmake de produire des fichiers objets avec cette extension.

set(CMAKE_SYSTEM_INCLUDE_PATH $ENV{Z88DK_HOME}/include)
set(CMAKE_SYSTEM_LIBRARY_PATH $ENV{Z88DK_HOME}/lib)
set(CMAKE_SYSTEM_PROGRAM_PATH $ENV{Z88DK_HOME}/bin)

Ces variables ont l'air d'être les pendants des CMAKE_FIND_ROOT_PATH_MODE_* indiqués dans le fichier de compilation croisée. Le fonctionnement n'est pas hyper clair.

Voilà, à présent cmake sait compiler un fichier C avec z88dk pour VG5000µ.

Et l'assembleur ?

Pour une raison que je n'ai pas creusé, mais probablement concernant la séparation des plateformes des compilateurs, le support d'un assembleur nécessite un autre fichier, différent du précédent vg5000.cmake.

C'est dans cmake/Compiler/z88dk-ASM.cmake que cmake va chercher l'outil pour traiter l'ASM pour z88dk. Ce qui se tient. Pourquoi est-ce qu'il ne va pas chercher z88dk-C.cmake au même endroit, cela m'échappe...

Le contenu est strictement identique à celui du fichier vg5000.cmake, puisque l'on s'adresse au même outil zcc.

Et la cerise optionnelle

Le fichier z88dk-clion.yaml est un fichier qui ajoute un support de z88dk (assez succin) à Clion. Par défaut, lors de la génération de cmake, l'IDE va essayer de trouver un certain nombre d'information en interrogeant le compilateur. Les #define par exemple, ou les répertoires d'inclusion par défaut.

Mais zcc ne réagissant par bien à la question, Clion affiche un warning. Il est cependant possible de lui indiquer manuellement les informations recherchées, et c'est le but de ce fichier. Cependant, sa description tombe hors du sujet de cet article.

Conclusion

Ça a été une aventure, comme à chaque fois que l'on sort des sentiers battus avec cmake. J'y ai appris un peu plus de choses, ce qui était probablement l'objectif initial. Et j'ai une façon de générer un programme VG5000µ à partir de tout outil qui utilise cmake, ce qui couvre aussi Visual Studio Code.

Apprendre l'assembleur... mais comment ?

2022-03-05T00:00:00+01:00

Il y a peu, j'ai eu une discussion à propos de l'apprentissage de l'assembleur. La discussion était partie de l'envie d'une personne de créer un jeu sur MSX, mais directement au niveau de la machine, plutôt que de passer par un langage de haut niveau, comme le BASIC natif. Et pourquoi pas. Une donnée importante : la personne en question connaît déjà la programmation, c'est donc un abord de nouveau langage dont on parle, et non des concepts généraux du développement d'un programme.

Lorsque l'on aborde un langage de plus haut niveau, que ce soit BASIC ou Pascal, on va se concentrer sur la manière d'exprimer des concepts dans ce langage en particulier. Lorsque l'on connaît déjà un autre langage de même famille (large), il s'agit même souvent de comprendre quelle sont les particularité du langage appris.

Lorsque l'on aborde une machine en particulier dans un langage de haut niveau, il s'agit en suite de connaître les bons appels, les bonnes fonctions, particulières à cette machine.

Mais comment démarrer en assembleur ? Avec l'assembleur, toute la couche d'abstraction est retirée, il n'y a plus de concept de variables, de fonctions, de structures de données, on se retrouve face à face à la machine. Cela implique en premier lieu qu'apprendre l'assembleur, c'est apprendre le fonctionnement particulier de cette machine, et même pas seulement du fonctionnement du processeur.

Quand on regarde les ressources qui enseignent l'assembleur, que ce soit pour une machine ou seulement un processeur, on se retrouve avec une structure assez similaire où il est d'abord expliqué l'arithmétique et la logique binaire, la représentation des entiers, puis sont abordés les registres et globalement l'architecture du processeur. Ce sont des dizaines de pages à comprendre, suivre... et la plupart du temps sans exercice pratique, sans mise en application. Cela semble sous-entendre que pour démarrer la moindre opération, il faut lire une centaine de pages.

Lorsque l'on a déjà des connaissances sur d'autres machines et processeurs similaire, cela peut aller vite. Mais lorsque c'est le premier abord du mode du bas niveau, c'est beaucoup à ingurgiter et probablement très démotivant.

Je me suis posé la question de comment pourrait être abordé la question, j'ai pris quelques notes et je vais m'essayer à l'exercice dans des articles qui suivront. Mon objectif est de pouvoir construire de la connaissance sur la programmation en assembleur pour des personnages qui n'en n'auraient jamais fait.

Voyons ce que cela donne...

Baisse de régime... en apparence.

2022-03-04T00:00:00+01:00

Après une grosse activité sur le VG5000µ principalement, il y a eu bien moins d'article sur Triceraprog, et la troisième vidéo sur les langages de programmation qui est prévue depuis deux ans n'est toujours pas là. Mais que se passe-t-il ?

En Janvier 2021, l'association M05.COM m'a proposé de travailler sur le projet de restauration et de documentation d'un « Micral N ». Toute l'année 2021, avec d'autres membres de l'association, nous nous sommes plongé dans la compréhension de cette machine historique, ainsi que dans la création d'une version virtuelle qui a permis d'en comprendre les détails.

C'est une activité passionnante, j'ai appris énormément de choses et j'ai même pu écrire (ou porter) une poignée de logiciels pour cette machine. Forcément, mes autres sujets en ont pâti et le VG5000µ est un peu en pause. Mais il est toujours sur mon bureau prêt à reprendre du service.

La communication des avancées sur le « Micral N » ayant besoin d'être coordonnée avec l'association, je ne parle pas des avancées sur Triceraprog. En tout cas pas pour le moment, à part la petite présentation du 8008 que j'ai écrite il y a quelques mois.

Un live Twitch est visible où nous présentons la machine. Malheureusement un peu gâché par des problèmes de micros.

J'ai hâte de pouvoir parler de cette machine plus en détails.

Récréation 3D, Apple II

2021-12-15T00:00:00+01:00

L'un des tout premiers micro ordinateurs de très grande popularité, particulièrement aux États-Unis. L'Apple II.

Voici une recréation en synthèse, avec un moniteur ambre posé lui-même sur une paire de lecteurs Disk II.

Récréation 3D, CDC 6400

2021-11-18T00:00:00+01:00

Le langage Pascal, nommé ainsi en référence à Blaise Pascal, concepteur de la Pascaline, a été développé sur une machine nommée CDC 6400. C'est une machine de type mainframe, un gros truc, même si la version 6400 est une version allégée d'une autre de la gamme, et dont l'unité de mémoire adressée a une largeur de 60 bits.

Voici une recréation en synthèse, où l'on voit en premier lieu la console avec ses deux écrans ronds, hérités des écrans de RADARs. Les calculs sont fait dans les grosses armoires que je n'ai pas détaillées.

Brève présentation de l'Intel 8008

2021-11-01T00:00:00+01:00

Le 8008 d'Intel est un processeur assez particulier. C'est le premier micro-processeur 8 bits, et on peut même dire : le premier micro-processeur tout court. Son grand frère, le 4004, étant plutôt considéré comme un micro-contrôleur. D'autres sites expliquent le pourquoi de cette distinction.

Je veux ici me pencher sur le 8008 sous certains aspects techniques. Une brève introduction d'une puce qui va en générer d'autres (8080, 8086, Z80,...)

Cette puce, je l'ai étudiée à travers son utilisation dans le Micral N de la R2E, mais ceci est une autre histoire. Le 8008 est rapidement utilisé dans une série de micro-ordinateurs (le terme apparaît avec le Micral N) sur un cours laps de temps. Dans le désordre, MCM/70, SCELBI, Intellec-8, Mark-8, MCS 8, Bill-1,... Certaines de ces machines reçoivent très rapidement une mise à jour vers le 8080, beaucoup plus flexible. Cependant, c'est bien avec le 8008 que cela commence.

La puce

Et le voici en image de synthèse. Ou du moins, dans l'un des boîtiers existant, car il en existe plusieurs. C'est celui que j'avais en référence, et c'est donc celui que j'ai modélisé.

Une première chose étonnante : pas de masse. Le 8008 prend du +5V et du -9V. Il semble que la raison soit une volonté d'être compatible avec des circuits électroniques 5V, mais avec un besoin d'une tension totale de 14V... Ce n'est pas trop mon rayon, alors je laisse ça en note. Pour plus de précisions, jusqu'au niveau transistor, je vous dirige vers l'analyse en anglais de Ken Shirriff.

Branchements

Mis à part VCC et VDD, les deux tensions nécessaires, le 8008 communique avec l'extérieur à travers 16 autres broches.

À noter que le 8008 travaille en « logique physique inversée » par rapport aux signaux logiques : le 0 logique est à +5V, le 1 logique est entre ~0.8V et -9V.

Broche de synchronisation

En entrée, le 8008 reçoit en entrée deux horloges déphasées, de même fréquence (500 kHz) : Ø1 et Ø2. Ces deux horloges lui permettent de cadencer les opérations internes.

À partir de ces impulsions, le 8008 forme en sortie le signal SYNC/ qui est haut pendant un premier cycle Ø1, Ø2, puis bas pendant un second cycle Ø1, Ø2. Le tout forme un état processeur complet.

Vu qu'il y a un temps de 2µs entre deux fronts de Ø1, cela signifie qu'un état du 8008 dure 4µs.

Broches d'états

Trois autres broches en sortie : S1, S2 et S3, forment un triplet indiquant dans quel état le processeur se trouve.

Les états sont les suivants : T1 et T1I, T2, T3, T4, T5, WAIT et STOPPED.

Les états T1 et T2 forment ensemble une demande d'information au reste du système. Lors de T1, le 8008 place la partie basse de l'adresse de l'information à obtenir sur les broches d'entrées/sorties. Lors de T2 y est placée la partie haute de l'adresse, ainsi que deux bits indiquant le type de cycle actuel et donc la nature de la donnée attendue : est-ce une instruction, une lecture ou une écriture de donnée en mémoire, ou une opération d'entrée/sortie ?

Cette manière de placer une adresse sur le bus se fera toujours de la même manière lors de différents cycles d'une instruction, et toujours sur les états T1 et T2 : d'abord les 8 bits bas de l'adresse, puis les 6 bits haut (le 8008 a un espace d'adressage de 14 bits), complétés par 2 bits indiquant au système ce que ce couple d'information représente.

T1I est une variante de T1 qui est utilisée lorsque le processeur a validé une interruption. L'état est le même que T1 à l'exception du traitement du compteur d'instruction (le registre interne PC), qui n'est pas avancé. Après T1I, le 8008 passera à un état T2.

Lors de l'état T3, le processeur lit la donnée obtenue. Si c'est une instruction à exécuter, celle-ci est stockée pour les états suivants, sauf pour l'instruction HLT, qui est immédiate.

Les états T4 et T5 sont des états supplémentaires qui existent dans certaines instructions.

Et chaque instruction peut répéter l'ensemble de ces états dans l'ordre pour compléter son exécution. L'instruction INr (incrément d'un registre) va s'exécuter en un seul cycle avec les états T1, T2, T3, T4 et T5, pour un total de 5 états. L'instruction JMP (branchement à une adresse absolue) aura besoin de trois cycles : le premier et le second avec T1, T2 et T3, le troisième avec T1, T2, T3, T4 et T5, pour un total de 11 états.

Broches d'entrée

Le 8008 possède deux broches en entrée en plus des deux phases d'horloges : INTERRUPT/ et READY/.

`READY/`

La broche READY/ permet de synchroniser le temps que prend l'acquisition d'une donnée avec le 8008. En effet, le cycle T3 s'attend à pouvoir lire une donnée sur les broches d'entrées/sorties. L'emplacement de cette donnée a été complètement caractérisée (emplacement et nature) lors du cycle T2.

Pour être certain que le monde extérieur est prêt, le 8008 ne passera de l'état T2 à T3 que si READY/ est au 1 logique. Dans le cas contraire, il se placera dans l'état WAIT et patientera... Dès que READY/ est signalé par le reste du système, le 8008 reprend sa course en passant vers l'état T3.

`INTERRUPT/`

La broche INTERRUPT/, comme son nom l'indique, place le 8008 dans un état d'interruption. La gestion des interruptions par le 8008 est très rudimentaire. Lorsqu'une instruction est terminée, si INTERRUPT/ est signalée, alors le processeur passe en état T1I plutôt que T1.

Et c'est tout !

C'est aussi le seul moyen pour le processeur de sortir de l'état STOPPED si une instruction HLT (halt) a été exécutée. Et de la même manière, le premier état sera alors T1I.

Comme indiquée plus haut, la différence entre l'état T1 et T1I est que pour T1, le registre PC est incrémenté après l'émission de l'adresse. Pas dans le cas de T1I. L'idée est pour le système de placer sur le bus lors d'un état T1I une instruction particulière, généralement RST (Restart).

L'instruction RST est une instruction d'un octet de taille qui permet de brancher sur une sous-routine (comme un CAL) à une des 8 adresses multiples de 8 en mémoire. Elle est faite pour être utilisée dans ce contexte.

Le 8008 doit donc être aidé par le reste du système pour gérer des interruptions. Le processeur lui-même ne fait que le strict minimum...

Les broches d'entrées/sorties

Il reste 8 broches à décrire, et celles-ci fonctionnent en entrée comme en sortie. Elles forment l'interface d'échange de données entre le 8008 et le reste du système. Ces broches ne sont pas spécialisées : toute donnée passe par là, que ce soit un morceau d'adresse, une données à échanger avec la mémoire ou avec un périphérique.

Comme indiqué plus haut, une combinaison de l'état courant du 8008 et des deux bits hauts placés en T2 sur ces broches permet de déterminer la fonction de ces 8 broches.

Sur T1 et T2, ce sont des broches en sortie qui indiquent deux morceaux d'adresse ainsi que la nature du cycle. Sauf dans le cas d'une données adressée à un périphérique, qui se trouvera en cycle T1 du second cycle.

En T3, ce sont des broches en entrée qui vont y lire une donnée... ou rien (dans le cas de OUT lors du second cycle).

Les broches ne servent pas lors des autres états.

Les registres

Le 8008 possède des registres accessibles par le code utilisateur, ainsi que quelques registres internes, non accessibles.

Passons sur la plupart des registres internes, qui servent au fonctionnement... interne (deux registres temporaires, celui d'instruction, de cycle,...) mais arrêtons nous sur une particularité : le pointeur d'instruction, généralement nommé PC sur les micro-processeurs, n'est pas accessible au code exécuté !

Le PC

En premier lieu, il faut dire que ce registre n'existe pas vraiment. Le 8008 possède une mémoire de 8 x 14 bits organisée en pile, munie de son pointeur de pile. L'adresse pointée est le PC actuel. Lors d'un branchement, l'adresse pointée est mise à jour, avec une mise à jour potentielle du pointeur dans le cas d'instruction d'appel de sous-routine (CAL par exemple).

Cela signifie au passage que le 8008, sans aide externe et avec ses seules instructions, ne peut pas dépasser une profondeur d'appel de plus de 8. Ou plutôt, il peut, mais la mémoire étant cyclique, il ne pourra pas remonter correctement.

Et le contenu de cette mémoire est parfaitement inaccessible. Il n'y a pas d'instruction permettant de lire le contenu de la pile, ni le niveau du pointeur.

Les autres registres

Les registres accessibles sont A, B, C, D, E, H et L. Rien de très étonnant si vous connaissez le Z80 par exemple.

A est l'accumulateur. Toutes les opérations logiques et arithmétiques se font par rapport à A, et le résultat potentiel est stocké dans A. Sauf pour les opérations d'incréments et décréments, qui ne peuvent être appliqués que sur les registres généraux qui suivent.

B, C, D et E sont 4 registres généraux. On peut copier le contenu de n'importe lequel vers n'importe quel autre (y compris l'accumulateur). On peut même copier le contenu d'un registre vers lui-même. Et c'est d'ailleurs, par convention, la copie de A vers A (LAA) qui forme l'instruction NOP du 8008.

H et L sont 2 autres registres généraux qui se comportent comme les précédents, mais qui ont une capacité supplémentaire. Pris ensemble, ils forme HL, nommé aussi M, un pseudo registre de pointeur vers la mémoire.

Ainsi, l'instruction LAM copie le contenu du pseudo registre M vers l'accumulateur. Autrement dit, l'octet pointé par la paire HL est chargée dans A.

Mot de la fin.

Le 8008, conçu et construit par Intel, est avant tout une commande pour reproduire dans un petit volume les fonctionnalités d'un appareil existant. C'est sous cet aspect qu'il est à comprendre et comprendre une partie des choix techniques et donc de ses limitations.

Récréation 3D, Pascaline

2021-10-19T00:00:00+02:00

Depuis longtemps, très longtemps, les humains cherchent des moyens pour aider aux calculs. Blaise Pascal fut de ceux-ci, lorsqu'il conçu un modèle fonctionnel d'une machine mécanique permettant d'additionner et de soustraire des nombres.

La Pascaline devient la première machine à calculer de bureau commercialisée (même si elle le fut à très peu d'exemplaires).

En voici une modélisation que j'ai terminée récemment.

VG5000µ, Schémas de principe mis à jour en v1.4

2021-04-29T00:00:00+02:00

Il y a deux ans et demi, je publiais ici une remise au propre du schéma de principe de la documentation du VG5000µ.

Cette première version a été mise à jour avec la découvertes d'erreurs, ou de précisions à apporter.

Cette fois-ci, c'est l'œil exercé de 6502man du forum system-cfg qui, lors de la réparation d'un VG5000µ, m'a fait parvenir des corrections. Et je le remercie ici à nouveau.

Les modifications par rapport à la v1.3 sont :

retirer la broche A14 de la ROM 7802 et les broches A13 des deux RAM en accès direct par le Z80, 7804 et 7805. Du copier coller raté très probablement.
correction d'un inversion des broches 26 et 28 sur la ROM 7802. Le +5V arrive sur 28.
inversion des broches 4 et 5 de la porte NAND fournie par 7812. Les broches indiquées sur les versions précédentes sont fidèles au schéma de la documentation, mais le relevé sur le matériel montre le contraire. Il est possible qu'il existe différente carte mère, mais je donne la priorité à un relevé vérifié. D'un point de vue logique, inverser les branches d'une porte NAND ne change rien.
ajout de la mention 4Mhz sur la sortie HP du VDP 7801, pour plus d'information lors de la recherche de panne.

Ce qui donne, mis à jour.

La platine principale

Image cliquable pour une version en haute définition. (mise à jour 29 avril 2021)

La platine K7/Son

Image cliquable pour une version en haute définition. (mise à jour 9 sept. 2018)

Note

Le schéma a été mis à jour dans un nouvel article.

Programmer sur Nintendo Switch en BASIC

2021-03-28T00:00:00+01:00

« Petit Computer » est un environnement de programmation qui est apparu initialement sur la Nintendo DSi. Cet environnement se programme dans un dialecte de BASIC du nom de « Smile BASIC ». Et c'est sous le nom « Smile BASIC v4 » qu'il est disponible en version numérique sur l'eShop de la Nintendo Switch.

Après un lancement un peu chaotique en Europe au printemps 2020, à cause d'une erreur dans la classification d'âge il semblerait, il a été à nouveau disponible. Une fois téléchargé et après avoir branché un clavier et une souris en USB sur la Switch, la console se transforme en ordinateur programmable en BASIC. Et c'est amusant !

Un environnement presque à l'ancienne...

Au démarrage, on est pris en main avec des explications sur l'environnement. Les explications ne sont pas très poussées, et même après avoir parcouru le très bavard tutoriel, je pense que des apprentis programmeurs resteront un peu sur leur faim.

Ah, une autre précision : le logiciel n'existe qu'en anglais et en japonais.

Niveau documentation, le site officiel donne une référence plutôt complète, et trois PDFs d'explications parcellaires qui donnent quelques idées du fonctionnement.

Très pratique cependant, l'aide en ligne est disponible et est très complète. F1 après un mot clé donne les explications. F1 sans mot clé amène au manuel général.

Malgré tout cela, au début, on retrouve un peu la sensation d'une machine à l'ancienne : il semble y avoir plein de possibilités, mais il va falloir les découvrir en tâtonnant, et faisant des essais. En ce sens, « Smile BASIC » est ludique.

Cloud et Partage

Moyennant l'achat d'un « ticket » supplémentaire à l'achat du logiciel, on peut sauvegarder et surtout partager ses créations sur un serveur dédié à la communauté Smile BASIC. Et puisqu'il y a partage, il est aussi possible de télécharger les créations des autres, pour s'en inspirer, les modifier ou tout simplement y jouer.

Sans le ticket, on ne pourra charger qu'une seule création toutes les huit heures, et pas partager les siennes.

Par contre, pas moyen d'échanger des données avec le monde extérieur, comme un PC. Ou du moins pas simplement. Ce qui est créé dans Smile BASIC reste dans Smile BASIC. Cela inclus le code BASIC tout autant que les musiques, sprites,...

Ça ressemble à quoi ?

Lorsque l'on passe en mode « création », on arrive sur un écran qui ne dépayse pas lorsque l'on est habitué de vieilles machines.

La résolution de l'écran est de 400 par 240, mais cela peut se changer jusqu'à du 720p.

Note: mes captures bavent à cause de mon périphérique d'acquisition, ce n'est pas le cas de l'image en sortie de la Switch, qui est très bonne.

En mode direct, on peut taper des commandes et voir le résultat. Il est possible de dessiner grâce à des primitives telles que point, ligne, cercle, rectangle ou triangle. Le système propose aussi un système de sprites avec collisions possibles et de la composition de plans d'affichages.

Cela peut commencer très simple, mais être poussé assez loin.

Et pour créer ces sprites, ou n'importe quel dessin, un logiciel de pixel art est disponible sur F10.

La programmation est sans numéro de ligne. On bascule dans un éditeur de texte pour entrer un programme résident. Il est possible de sauver les fichiers bien entendu, et d'en rappeler d'autres. Le tout, comme je le mentionnais, avec une aide en ligne.

Conclusion pour le moment

« Smile BASIC » est plutôt sympathique. On est un peu perdu en arrivant dessus la première fois, mais à force d'essais, de lectures de la référence et de l'aide en ligne, on peut commencer à faire des petites choses sympa.

Le système, bien qu'assez complet, n'est pas là pour pousser la Switch à fond, ce n'est pas le but. L'idée est plutôt de s'amuser à programmer dans un environnement simple, avec des outils et ressources clés en main (il y a aussi des effets sonores et des musiques disponibles de base).

La communauté à l'air assez réduite hors Japon cependant, c'est un peu dommage, mais assez compréhensible.

Automatisation : utilisation de Visual Studio Code

2020-12-27T00:00:00+01:00

Il y a presque trois ans (déjà !), j'avais mis en place un environnement de programmation pour me permettre de mettre au point un programme en assembleur Z80 et de l'envoyer vers MAME, afin de réduire le nombre d'opérations manuelles. Le tout à partir de Sublime Text 3.

Peut-être parce que la documentation de cet éditeur n'est pas des plus détaillée, ou peut-être parce que c'est avant tout un éditeur de texte, les extensions autour de l'assembleur Z80 sont peu nombreuses. C'est plutôt du côté de Visual Studio Code que ces extensions sont apparues.

Récemment, j'ai donc fait deux changements dans ma chaîne de mise au point pour VG5000µ. Tout d'abord, j'utilise à présent Visual Studio Code comme éditeur, et ensuite, j'ai changé d'assembleur.

Visual Studio Code

Tout comme Sublime Text 3, l'important pour moi est que l'éditeur puisse fonctionner sur diverses plateformes, et entre autre sur celle que j'utilise pour mes projets rétro : Ubuntu Linux. De ce côté, c'est ok.

Pour la syntaxe colorée, j'utilise le plugin Z80 Macro-Assembleur. Le plugin apporte aussi un « problem matcher », qui est la façon pour l'éditeur de savoir si des erreurs ont été levées lors de phase de construction.

Il offre aussi un support d'Intellisense, mais que je n'ai pas encore mis en fonctionnement. A priori, ça ne fonctionne pas tout seul.

J'ai aussi ajouté Z80 Assembly meter qui permet d'évaluer le nombre de cycles pris par du code sélectionné, avec une option MSX qui allonge d'un cycle les instructions, ce qui est aussi valable pour le VG5000µ.

L'assembleur

Auparavant, j'utilisais l'assembleur z80asm livré avec l'environnement z88dk. C'était un choix historique venant de mes essais en C sur le Z80. Cet assembleur fonctionne bien, mais est très minimaliste. En effet, un assembleur derrière un compilateur n'a pas besoin de beaucoup d'aides, le compilateur pouvant générer le code in extenso.

Lorsque l'on met au point du code à la main, rapidement, pouvoir écrire des macros, manipuler des adresses via des expressions, devient un outil nécessaire.

C'est vers sjasmplus que je me suis tourné. Comme souvent, l'assembleur est fait avec une machine particulière en tête, ici la ligne des Spectrum. Mais ce n'est pas bien grave. L'assembleur a des macros, est assez souple sur la syntaxe, a pas mal d'instructions pour déclarer ce que l'on veut faire.

La tuyauterie

Voici le fichier tasks.json que j'ai écris. Il est probablement perfectible car je ne connais pas toutes les subtilités de Visual Studio Code, mais il fait l'affaire pour le moment.

Pour le fonctionnement du script vgboot.lua, je vous renvois à cet article. Le script n'a pas bougé depuis.

    "version": "2.0.0",
    "tasks": [
        {
            "label": "sjasmplus - Build",
            "type": "shell",
            // Options: No fake instructions, Warning as Errors, Multi arg is ',,'
            "command": "sjasmplus --syntax=FLwa ${fileBasename} --raw=${fileBasenameNoExtension}.bin --lst",
            "problemMatcher": [
                "$errmatcher-sjasmplus"
            ],
            "group": {
                "kind": "build",
                "isDefault": true
            },
            "options": {
                "cwd": "${relativeFileDirname}"
            }
        },
        {
            "label": "sjasmplus - Run on Mame",
            "type": "shell",
            "command": "mame64 vg5k -ramsize 48k -nomax -window -autoboot_delay 0 -autoboot_script vgboot.lua -debug -debugger none -natural",
            "problemMatcher": [
                "$errmatcher-sjasmplus"
            ],
            "dependsOn": [
                "sjasmplus - Build"
            ],
            "options": {
                "cwd": "${relativeFileDirname}"
            }
        },
        {
            "label": "sjasmplus - Debug on Mame",
            "type": "shell",
            "command": "mame64 vg5k -ramsize 48k -nomax -window -autoboot_delay 0 -autoboot_script vgboot.lua -debug -debugger qt -natural",
            "problemMatcher": [
                "$errmatcher-sjasmplus"
            ],
            "dependsOn": [
                "sjasmplus - Build"
            ],
            "options": {
                "cwd": "${relativeFileDirname}"
            }
        }
    ]
}

La suite

Les environnements pour des machines connues vont encore plus loin, avec par exemple de l'intégration de debugger directement dans Visual Studio Code. Il y a aussi un support de tests unitaires, qui me plaît bien. Reste qu'il faut faire quelques branchements pour que cela fonctionne pour un VG5000µ. Je ne sais pas encore si j'irai vers là.

VG5000µ, Set Point assembleur depuis le BASIC

2020-12-16T00:00:00+01:00

Cet article est la suite de deux précédents articles. Le premier, en plusieurs parties, était l'implémentation de l'affichage d'un « gros pixel » sur l'écran du VG5000µ. Le second était celui sur la possibilité (ou plutôt la difficulté) d'ajouter des commandes au BASIC du VG5000µ.

Il existe cependant une façon d'ajouter des commandes au BASIC... ou presque. Cette possibilité est évoquée brièvement dans le livre « Clefs pour VG5000 » page 98. À charge au lecteur de se débrouiller.

Cette méthode, indiquée dans le livre, est à vrai dire celle qui est utilisée par l'implémentation BASIC de la machine. Chaque routine d'instruction démarre avec HL qui pointe dans le buffer du texte BASIC sur l'octet suivant le token d'instruction, et donc sur ses éventuels paramètres.

C'est donc le cas, comme les autres, de l'instruction CALL. La routine de l'instruction se charge de lire l'adresse puis de l'appeler. Par lecture de ce paramètre, HL a été positionné après celui-ci et c'est donc dans cet état que la routine utilisateur est appelée.

Exemple

Voici un exemple rapide d'une commande qui peut s'appeler par CALL &"7000",X,Y, X et Y étant les coordonnées du point à afficher. La routine setpoint est celle de l'article cité au début.

L'idée derrière le premier jp est de commencer par une série de jp qui amène aux différentes routines qui seront donc CALL &"7000", CALL &"7003", CALL &"7006",...

On peut même aller jusqu'à mettre l'adresse dans une variable pour obtenir quelque chose comme CALL SP,X,Y (les variables ont deux caractères maximum significatif sur VG5000µ).

    defc chkchr = $8
    defc getbyt = $0086

    org     $7000
entry:
    jp      call_setpoint

call_setpoint:
    push    bc          ; Sauvegarde des registres, sauf HL, dont on a besoin
    push    af
    push    de

    rst     chkchr      ; Il doit y avoir une virgule, ou c'est une erreur de syntaxe
    defb    ','

    call    getbyt      ; Puis une expression 8 bits entière pour la première coordonnée X dans A et (D)E
    push    de          ; Sauve cette valeur sur la pile

    rst     chkchr      ; Il doit y avoir une virgule, ou c'est une erreur de syntaxe
    defb    ','

    call    getbyt      ; Puis une expression 8 bits entière pour la seconde coordonnée Y dans A et (D)E

    ex      (sp), hl    ; Récupère la coordonnée X (dans L) en échange du pointeur sur le texte BASIC
    ld      h, a        ; Place la coordonnée Y dans H

    call    setpoint    ; Appel l'affichage du point avec les coordonnées dans HL

    pop     hl          ; Restaure les registres, dont HL
    pop     de
    pop     af
    pop     bc

    ret

D'autres choses ?

Le livre indique aussi la possibilité d'utiliser deint ($0083). Ce n'est cependant pas possible directement. Cette fonction prend ce qui est dans l'accumulateur flottant et le place en tant qu'entier dans DE. Mais il faut donc au préalable charger l'accumulateur flottant.

C'est possible avec eval_num_ex ($284d), qui doit donc être appelé au préalable, car c'est cette routine qui analyse l'expression et vérifie qu'elle est numérique.

Conclusion

Grâce à cette méthode, il est donc possible de créer une petite bibliothèques de routines assembleurs appelable avec des paramètres depuis le BASIC.

VG5000µ, le commentaire de la ROM

2020-12-12T00:00:00+01:00

Le 8 avril 2017, un message sur le forum system-cfg posait la question de l'existence d'un commentaire extensif de la ROM du VG5000µ. J'y répondais que j'avais quelques notes.

Depuis, sur ce site, j'ai décortiqué un certain nombre de parties, par curiosité personnelle, ou pour répondre à des questions qui se posaient sur le même forum. Au fur et à mesure, je me suis embarqué dans le commentaire exhaustif de la ROM.

Le commentaire

Ce fut long, plutôt long.

Et je publie le résultat aujourd'hui. Ce résultat prend la forme principale de deux fichiers de commentaires, l'un pour la ROM 1.0 et l'autre pour la ROM 1.1. Le tout est disponible ici sur GitHub.

Ce que je ne publie pas aujourd'hui est l'outil qui permet de prend la ROM d'un côté, le fichier de commentaires de l'autre et qui génère un listing assembleur commenté qui peut-être assemblé à nouveau. Cet outil, que j'ai développé en parallèle, nécessite un bon coup de nettoyage avant publication. Peut-être que je le publierai avant son nettoyage complet, mais je dois au moins effectuer une relecture de sécurité.

Terminé ?

Les commentaires ayant été écrits sur une durée de trois ans, et malgré une passe de relecture récente, il reste probablement des incohérences de nommage, et peut-être aussi quelques fautes de frappe ou d'orthographe par-ci par-là. Il est tout à fait possible de me les mentionner.

Dans le futur, en fonction d'autres développement autour du VG5000µ, il est possible que je revienne dessus et que je corrige ou que j'augmente les informations.

Il y a aussi parfois des noms d'articles entre crochets. Il s'agit d'articles que j'ai prévu de faire, s'ils ne le sont pas déjà, sur ce site. On verra...

C'est en français !

Oui. C'est en français. Comme la machine. J'ai hésite à taper les commentaires en anglais ou en français. Au final, je suis parti pour le français en essayant de ne pas utiliser trop d'anglicismes, à part les évidents du domaine.

Si quelqu'un veut se lancer dans une traduction dans une autre langue, la licence est « Attribution - Partage dans les Mêmes Conditions 4.0 International » (CC BY-SA 4.0). Allez-y !

VG5000µ, Schémas de principe mis à jour

2020-11-17T00:00:00+01:00

Il y a deux ans, je publiais ici une remise au propre du schéma de principe de la documentation du VG5000µ.

Alors que je finalise le commentaire de la ROM, je me suis aperçu qu'il y avait une erreur au niveau du décodage des entrées sorties. C'est à présent corrigé (ainsi que sur l'article original).

Au niveau de 7807, j'avais inversé les entrées \RD et \WR, ce qui n'avait pas de sens pour l'entrée C du 74LS138.

J'en ai profité pour améliorer la nomenclature des signaux au niveau de ce même composant, en cohérence avec le datasheet.

La platine principale

Image cliquable pour une version en haute définition. (mise à jour 17 nov. 2020)

La platine K7/Son

Image cliquable pour une version en haute définition. (mise à jour 9 sept. 2018)

Note

Le schéma a été mis à jour dans un nouvel article.

VG5000µ, deux mises à jour sur MAME

2020-09-06T00:00:00+02:00

Lors du commentaire systématique de la ROM du VG5000µ, je suis arrivé sur les routines de lecture et écriture sur cassette. Comme d'habitude, afin de vérifier le fonctionnement de la machine, je fais des tests. Si je fais parfois des tests sur le matériel réel, la plupart du temps, un test sur émulateur suffit, voire est beaucoup plus simple, permettant de dérouler une routine et la suivre avec des données bien choisies.

J'utilise essentiellement MAME pour cela, qui est muni d'un debuggeur qui répond à mes attentes. J'utilise parfois dcvg5k, qui est plus orienté sur une utilisation de la machine simple et pratique.

Cependant, pour la cassette, aucun des deux ne convenait. Les deux émulateurs ne savent lire que le format K7, qui a le mérite d'être extrêmement simple et facilement lisible, mais qui a l'inconvénient d'être inadéquat au bon déroulement des routines de lecture et d'écriture.

La format K7 est une simple liste des octets décodés depuis un enregistrement réel. C'est un format pratique car très compact. L'émulateur dcvg5k s'en sert pour injecter ou extraire les valeurs en court-circuitant la routine de lecture et d'écriture de la ROM. Si j'ai bien compris, l'émulateur intercepte l'exécution normale à des endroits bien choisis et prend la main pour une lecture ou écriture très rapide.

C'est une idée qui se défend pour une utilisation de la machine en évitant des temps d'attentes associés aux cassettes.

Dans mon cas d'étude des routines, c'est par contre hors-jeu. J'ai besoin d'un signal audio. Je me suis donc tourné vers MAME pour voir si je pouvais ajouter le traitement d'un fichier .WAV avec ma ROM 1.1 non modifiée.

Ajout de lecture/écriture audio

La première opération a été d'ajouter le support du format .WAV sur MAME.

Comme on peut l'imaginer, la plupart des services de base existent déjà quelque part dans MAME. C'est l'avantage d'un tel mastodonte. Mais être un mastodonte à aussi un inconvénient : il faut savoir où ça se trouve et comment ça s'utilise.

Une fois trouvé, c'est assez simple. Dans le fichier src/lib/formats/vg5k_cas.cpp, à côté de la déclaration du support du type de fichier K7, il suffit d'ajouter la déclaration du support .WAV. Toute la gestion de fichier et de magnétophone virtuel est alors pris en charge.

CASSETTE_FORMATLIST_START(vg5k_cassette_formats)
    CASSETTE_FORMAT(vg5k_k7_format)
    CASSETTE_FORMAT(wavfile_format)
CASSETTE_FORMATLIST_END

Premiers problèmes

Je me doutais que cela n'allait pas fonctionner directement, puisque la machine était annotée comme ne fonctionnant pas, à cause d'un problème de lecture à 1200 bauds. J'avais comme deuxième objectif de corriger cela, afin de pouvoir analyser les routines complètement.

Avec la prise en charge du format .WAV, l'émulation réussi à lire un fichier audio sans soucis. Mais méfiance, la routine du VG5000µ se sert de l'amorce du fichier, une suite de signaux haut/bas, pour se calibrer.

Le deuxième test est donc de sauver un fichier .WAV puis de le recharger. Et là, cela ne fonctionne pas. Le fichier est bien sauvé, mais impossible à relire.

En examinant le fichier obtenu, je vois que les timings sont complètement farfelus. Ils ne correspondent pas à la théorie décrite dans le manuel technique, ils ne correspondent ni à 1200 bauds ni à 2400 bauds, et ils ne correspondent pas à la comparaison avec des fichiers écrits par du matériel réel.

Le moteur démarre

Au passage, les manipulations sous MAME sont pénibles, car la gestion du contrôle du moteur du magnétophone n'est pas là. Là encore, la plus grande partie du temps passé est de comprendre comment MAME gère le système. Au final, tout est là, il suffit de le brancher sur le bon signal envoyé sur le port I/O de la cassette.

Chose faite en modifiant la fonction void vg5k_state::cassette_w(uint8_t data) de src/mame/drivers/vg5k.cpp et en y ajoutant cette ligne :

m_cassette->change_state(BIT(data, 1) ? CASSETTE_MOTOR_ENABLED : CASSETTE_MOTOR_DISABLED , CASSETTE_MASK_MOTOR);

J'en profite pour réécrire cette petite fonction pour faire ressortir un peu mieux la sémantique des données envoyées sur le port I/O.

À présent, les fonctions d'accès à la cassette (CLOAD, CSAVE et les autres) contrôlent le moteur simulé du lecteur dans MAME, est c'est bien plus pratique à utiliser !

Le Z80 doit attendre

Retour sur les problèmes de timings. Je vous évite tout le cheminement et les tests quand soudain me vient un doute. Est-ce que l'émulation tourne à la bonne vitesse ? Oui, la fréquence déclarée pour le Z80 est la bonne (même si techniquement, elle devrait découler de celle du VDP), mais cela ne suffit pas !

En effet, le VG5000µ insère un état WAIT supplémentaire pendant sa phase M1 (fetch). Et ça change tout.

Un petit détour par le Z80 ici. Lors de la phase M1 (opcode fetch), qui s'opère en 4 cycles d'horloge, le 2 premiers cycles placent l'adresse du PC sur le bus d'adresse puis signalent une requête de lecture mémoire. Lors du cycle 3 (T3), la valeur de l'instruction est lue depuis le bus de données. Les cycles T3 et T4 conjointement servent pour le rafraîchissement des mémoires dynamiques, laissons ça de côté.

Le Z80 prévoit que le matériel puisse ne pas être prêt à temps pour livrer sur le bus de données l'instruction lue en cycle T3. La ligne WAIT est donc vérifiée à la fin de T2. Si la ligne est validée, alors le Z80 passe en mode WAIT en ajoutant des cycles supplémentaires d'attente, jusqu'à ce que la ligne WAIT soit relâchée.

Et le driver MAME ne respecte pas ça.

Le VG5000µ tourne trop vite ! Les timings sont faux et l'écriture sur cassette ne fonctionne pas. Reste à savoir comment corriger ça.

À la recherche du cycle en plus

Une première piste est d'aller voir comment est gérée cette fonctionnalité dans l'émulation Z80 de MAME. Mauvaise nouvelle, elle ne l'est pas. Ou plutôt, la ligne WAIT est bien émulée, mais uniquement entre les instructions. Cela est bien assez nécessaire, il semblerait, pour l'émulation de son utilisation par des périphériques qui demandent au Z80 d'attendre.

Mais la détection au cycle T2 de la phase M1 n'est pas là. C'est d'ailleurs indiqué dans les commentaires comme une amélioration possible... Que je ne me sens pas d'ajouter.

Deuxième piste : allez voir ce que font les autres. Côté Amstrad CPC et MSX, les tables de timings d'opcode sont ajustées. Il semblerait qu'il y ait d'autres raisons que ce seul état d'attente, même si c'est une des raisons. Les réutiliser seraient une option... pourvu qu'elles soient utilisables, ce que je trouve un peu lourd à vérifier.

Reste que cela m'ennuie car ce n'est pas vraiment ce qu'il se passe dans la machine. Je fouille encore. Je trouve un driver qui annonce que faute d'avoir trouvé comment faire, la machine est trop rapide...

Et enfin, je trouve une solution qui me plaît, utilisée par un autre driver. Utiliser une fonction de rappel sur le rafraîchissement des mémoires dynamiques, qui, étonnamment, est émulée par MAME. Il suffit alors, dans cette fonction de rappel, de dire à l'émulateur du Z80 qu'il devra exécuter un cycle de plus.

void vg5k_state::z80_m1_w(uint8_t data)
{
    m_maincpu->adjust_icount(-1);
}

Ça fonctionne !

Et tout à coup, tous les timings cassette que je surveillais sont corrects ! La sauvegarde génère un fichier audio qui ressemble à quelque chose (même s'il est bien trop carré pour être pris pour un vrai signal sorti d'une machine réelle, mais ce n'est pas bien grave), et surtout, ce fichier est relu sans problème par l'émulateur.

Et ceci est à 2400 bauds comme à 1200 bauds.

Les fichiers sont aussi compris par l'utilitaire de transformation en format K7 qui accompagne dcvg5k.

Des fichiers audio écrits depuis un vrai VG5000µ sont lus aussi. Il me reste le dernier test : lire sur du vrai matériel un fichier audio écrit par MAME. J'ai bon espoir que cela fonctionne, mais faute d'avoir effectué de vrais tests, le driver reste en non fonctionnel.

Support de la touche DELTA

Le VG5000µ possède sur son clavier cette touche non nommée qui est juste désignée par un triangle dans la documentation, connue aussi sous le nom de touche DELTA.

Puisque j'étais dans MAME, pourquoi pas ajouter cette fonctionnalité ? En effet, le soft reset qui consiste à remettre le PC à 0, ce que fait MAME par défaut, ne permet pas de simuler le soft reset tel qu'implémenté sur la machine à travers la touche DELTA.

Or, ce soft reset peut-être routé vers une routine utilisateur pour d'autres usages, comme par exemple, relancer directement un programme.

Une touche à part

Cette touche est à part dans sa connexion au système. Chaque touche du clavier forme une matrice qui est lue à travers le bus d'entrée/sortie du Z80. Mais pas celle-ci.

La touche DELTA est (presque) directement branchée à la ligne NMI du Z80. Autrement dit, appuyer sur la touche provoque une interruption non masquable dans le Z80. Par défaut, cette interruption appelle une routine qui vérifie si la touche CTRL est aussi appuyée et dans ce cas, provoque un soft reset. Tout ceci après avoir appelé une potentielle routine utilisateur qui, de base, ne fait rien.

Comme d'habitude, tout cela est bien entendu pris en charge par MAME, reste à savoir comment. Je suis allé voir du côté d'ancien matériels, où les switchs étaient branchés directement sur des fonctions, sans vraiment constituer un clavier.

La solution trouvée est la suivante. Tout d'abord, déclarer un nouveau port d'entrée/sortie qui associe au changement d'état d'une touche (j'ai choisi la touche End/Fin du clavier, mais c'est configurable par l'utilisateur) une fonction de rappel.

    PORT_START("direct")
        PORT_BIT( 0x01, IP_ACTIVE_LOW, IPT_KEYBOARD)        PORT_CODE(KEYCODE_END)                              PORT_NAME("DELTA")          PORT_CHANGED_MEMBER(DEVICE_SELF, vg5k_state, delta_button, 0)

La fonction de rappel signale tout simplement la ligne NMI du Z80 pendant un bref instant :

INPUT_CHANGED_MEMBER(vg5k_state::delta_button)
{
    if (!newval) {
        m_maincpu->pulse_input_line(INPUT_LINE_NMI, attotime::zero);
    }
}

Et voilà. La touche DELTA est émulée. On peut vérifier le fonctionnement des routines utilisateur sur CTRL+DELTA.

Attention, elle ne l'est que lorsque le clavier est en more réel dans MAME, et non en mode naturel, ce dernier mode cherchant une correspondance naturelle entre le clavier de l'hôte et la machine émulée.

C'est où ?

Les deux patchs ont été intégrés dans la branche principale de MAME, c'est donc dès à présent disponible sur le dépôt, ou bien dans une future version officielle de MAME.

VG5000µ, deux routines (quasi) identiques

2020-08-16T00:00:00+02:00

Hier, en continuant le commentaire systématique de la ROM du VG5000µ, j'ai eu une impression de déjà-vu. Il me semblait bien avoir déjà commenté la partie « redéfinir un caractère étendu » (commandes SETE et SETG en BASIC).

L'impression persiste, voire s’accroît, au fur et à mesure et je me décide à aller voir dans ce que j'ai déjà commenté. J'ai commencé, lentement, ce commentaire en août 2017, avec moult pauses, mais aussi du « butinage ». Il y a donc des parties que je ne me rappelle plus avoir déjà traitées.

Et effectivement, un peu plus loin, je vois des commentaires similaires à ceux que je suis en train d'écrire. Les termes sont un peu différents, car au fil des commentaires, j'ai fait évoluer certains termes ou la manière de commenter, mais en regardant de plus près, oui, c'est évident, il y a deux fois la même routine dans la ROM.

Je ne sais pas si c'est quelque chose de connu, alors voici mes commentaires.

Le VDP

Le Video Display Processor du VG5000µ, un EF9345, est utilisé par le BASIC de manière généralement indirecte. Les commandes comme les changement de couleur, de type de caractères ou encore de position du curseur, modifient des registres internes en RAM. Ces registres sont juste des emplacements réservés dans la RAM principale, celle accessible au Z80, ils n'ont rien de spécial.

Ces registres se trouvent à partir de $47fa et pointés en tout temps par le registre IX.

Le BASIC maintient aussi une représentation de l'écran, en $4000, et afficher quelque chose en BASIC revient à modifier cette représentation d'écran, en se basant sur les registres BASIC.

À chaque rafraîchissement demandé par le VDP, via l'IRQ du Z80 et si le BASIC considère qu'il est temps de mettre à jour l'affichage, un transfert des données est fait vers le VDP.

C'est le fonctionnement de base.

Cependant, la ROM contient aussi des routines qui s'adressent directement au VDP. On peut envoyer un caractère dans la mémoire écran du VDP sans passer par la représentation maintenue par le BASIC. Bien évidemment, si on laisse faire le rafraîchissement du BASIC, cette donnée sera écrasée rapidement. On peut aussi lire un caractère depuis la mémoire écran du VDP.

Ces quatre routines, putahl, putici, getahl et getici ne sont jamais utilisées par la ROM. Ce sont des routines mises à disposition pour l'utilisateur à une adresse fixe, dont le seul code est un branchement à l'implémentation.

Une autre routine mise à disposition est setext, qui s'occupe de la redéfinition d'un caractère texte ou graphique dans le VDP. Le VDP est en effet configuré par défaut pour offrir 4 « polices de caractères », dont 2 en ROM, et 2 en RAM (celle accessible directement par le VDP). Les deux en RAM peuvent être modifiées via cette routine setext en fournissant le numéro du caractère à changer et 10 octets qui représentent les 10 lignes d'affichage du caractère.

setext se trouve en $001b et branche immédiatement sur son implémentation en $0d85.

setext vs. SETE(T/G)

Le BASIC offre deux commandes pour redéfinir les caractères : SETET, pour redéfinir un caractère texte, et SETEG, pour redéfinir un caractère graphique. La différence entre caractère texte et graphique sort du périmètre de cet article.

Du point de vue de l'interpréteur BASIC, il n'y a qu'une seule commande SETE, qui vérifie si le caractère suivant est T ou G. On pourrait dire que la dernière lettre de la commande est vue par l'interpréteur comme son premier paramètre.

L'exécution de SETE se trouve en $0ced dans la ROM BASIC.

On pourrait s'attendre à ce que SETE utilise la routine setext. Ou bien que les deux routines aient une partie commune. Ce n'est pas le cas.

Des 141 octets de l'implémentation de setext, environ 100 (à la louche) sont strictement identiques dans SETE, routine qui elle pèse 160 octets (en incluant sa routine annexe, qu'elle est la seule à appeler).

Différences

Les deux routines font la même chose, dans le même ordre :

Couper le rafraîchissement de l'écran depuis sa représentation RAM,
Déterminer si on veut un caractère graphique ou texte,
Récupérer le numéro du caractère,
Envoyer les commandes au VDP pour préparer la définition,
Envoyer les 10 lignes au VDP,
Rétablir le rafraîchissement de l'écran.

Pour setext, c'est très simple, les informations sont dans le registre A pour le caractère et son type, et HL pointe vers les données.

Pour SETE, c'est un peu plus complexe. Le type de caractère est déterminé par la présence de T ou G, il y a une vérification de la validité du premier paramètre de la commande (numéro de caractère), puis la chaîne de caractères de description, suite de nombres hexadécimaux en ASCII, doit être décodée. C'est la raison pour laquelle la routine est plus longue.

Cependant, le corps de la routine qui envoie toutes les commandes est identique, à la récupération de la donnée prêt. Et bien que les deux routines utilisent bien les mêmes appels pour envoyer une commande au VDP ou attendre que celui-ci soit prêt à recevoir une commande, il doit bien y avoir une centaine d'octets pouvant être mis en commun.

Pourquoi ?

Je n'ai pas d'explication à la duplication de cette routine. Il reste un peu de place inutilisé dans la ROM, et peut être qu'il n'était plus nécessaire d'optimiser la place prise et que c'est juste resté « comme ça ».

Ce n'est pas, à mon avis, une question de performances avec setext qui serait plus rapide. Elle l'est, en effet, mais pourrait l'être encore plus. En effet, setext garde de SETE le fait de « retourner » chaque octet des descriptions de ligne pour les passer d'une visualisation humaine au format demandé par le VDP. La suite de commandes à envoyer pourraient aussi être rendue plus rapide à l'aide d'un buffer de commandes et l'utilisation de la routine regst.

Amélioration ?

Une amélioration possible de la ROM serait de réécrire ces deux routines. Il y aurait peut-être même moyen de profiter de la place gagnée pour caser deux commandes PSET et PRESET, qui font cruellement défaut sur le VG5000µ.

Considérations sur le langage LOGO

2020-08-15T00:00:00+02:00

Quand je vois passer des mentions du langage LOGO, elles sont généralement peu flatteuses. C'est compréhensible, la plupart des personnes qui se souviennent de ce langage de programmation y ont été exposées pendant leurs jeunes années d'études, lors du Plan Informatique pour Tous. Peu sont ceux qui ont creusé plus tard ce qu'ils avaient découverts au moyen d'ordinateurs poussifs et de cours pas toujours maîtrisés par des enseignants pas toujours bien convaincus.

Mes quelques souvenirs de séances en salle informatiques sont plutôt sur des activités de manipulation du crayon optique sur « Colorpaint ». Je ne sais plus si j'ai fait du LOGO en classe, mais c'est probable. Je me souviens cependant avec netteté la rencontre avec un professeur, lors de la fréquentation d'un « club informatique » pendant des vacances, qui pour une raison ou une autre (mon intérêt enthousiaste à la programmation ?) m'a donné quelques cours de LOGO. Et lors d'une conversation dans laquelle j'avais du mentionner que je programmais en BASIC, il m'a dit cette phrase qui est restée gravée dans ma mémoire « le LOGO est bien plus puissant que le BASIC ».

Je me souviens que cette phrase m'avait intriguée, mais pas forcément convaincue. Et de retour chez moi, j'ai continué mes aventures en BASIC. J'ai croisé LOGO quelques autres fois, de loin, sans m'y attarder.

Ce n'est que beaucoup plus tard, quand j'ai commencé à faire de la programmation mon métier, que j'ai repensé à cette phrase. J'ai regardé ce qu'était LOGO de manière plus expérimentée et j'ai compris. J'ai compris la justesse de l'assertion. LOGO était bien autrement plus puissant que le BASIC. Mais d'une manière que je ne pouvais pas comprendre auparavant.

C'est que la notion de « puissance » appliquée à un langage, ainsi qu'à son environnement, revêt de nombreux aspects. Cela peut être la vitesse d'exécution du programme, la facilité d'écriture, les possibilités d'interactivité avec la machine, la diversité des structures de code et de données.

Sur des ordinateurs 8 bits, la vitesse d'exécution du BASIC l'emporte haut la main, même sur des BASIC interprétés comme ils l'étaient en majorité.

Sur la facilité d'écriture, le BASIC est aussi très simple. C'était son but initial. LOGO n'est pas particulièrement complexe à écrire, mais comporte quelques étrangetés syntaxiques et pièges dont je parlerai dans un autre article. Et LOGO est aussi un peu plus verbeux.

En possibilité d'interaction avec la machine, BASIC l'emporte probablement. Tous les LOGO ne se valent pas, mais l'orientation pédagogique sur les machines 8 bits poussaient les concepteurs à offrir essentiellement des manipulations de l'écran via la tortue, et quelques sons. BASIC, en tant que porte d'entrée de la machine, était souvent dotés des instructions nécessaires pour en démontrer ses capacités. Avec de notables exceptions cependant, mais ceci est une autre histoire.

Vient ensuite la structure de code et de données. Et c'est là que LOGO renverse BASIC d'une pichenette. Le BASIC de l'époque est très linéaire, son édition se fait encore par numéro de lignes, sans labels. La structuration est possible bien entendu, mais les outils sont maigres. Niveau structure de donnée, le BASIC connaît le tableau multidimensionnel de taille fixe... et c'est tout.

LOGO arrive avec ses fonctions qui supportent la récursivité, avec des contextes locaux, un nommage des procédures et une édition sans numéro de lignes, qui facilite les mises au point.

Côté données, LOGO connaît la liste. Et avec une liste dynamique, de nouveaux horizons s'étendent. Des listes de nombres, des listes de mots, des listes de listes, des listes de commandes à exécuter...

L'expressivité du langage est beaucoup plus intéressante, et les programmes plus concis, plus clairs. C'est en ce sens que LOGO était bien plus puissant.

Mais tout ceci nécessite de la puissance de calcul et de la mémoire que les machines familiales de l'époque n'ont pas. Et cette malheureuse empreinte qui va rester principalement : on ne fait rien de bien sérieux avec LOGO.

Pour donner un petit aperçu de LOGO et de son évolution, j'ai réalisé une petite vidéo (moins de 10 minutes) que vous pouvez voir ici.

(billet posté aussi sur mon blog perso).

Récréation 3D, Cartouche Atari 800

2020-06-08T00:00:00+02:00

J'avais une cartouche « Atari Writer » qui traînait sur le bureau depuis quelques temps, et je voulais faire un exercice rapide de modélisation avec Blender.

Cela donne cette image, assez simple, mais qui a été un bon exercice.

VG5000µ, nombres aléatoires

2020-05-10T00:00:00+02:00

Comment donc les nombres aléatoires sont-ils générés sur un VG5000µ. C'est ce que je vous propose de suivre aujourd'hui en décortiquant le code.

Afin de suivre, il est important de comprendre comment les nombres sont stockés sur VG5000µ, et je vous propose pour cela un petit détour par cet article.

Petit rappel avant de commencer : un générateur de nombres aléatoires est une procédure qui émet une suite de nombres sur un intervalle, cette suite tentant d'avoir des propriétés intéressantes qui donnent l'illusion de l'aléatoire. La suite est cependant parfaitement définie, même si pas toujours simple à suivre, et c'est ce que nous allons voir par la suite.

L'initialisation

Tout commence très tôt pour le générateur de nombres aléatoires. Dès l’initialisation de la machine, une série de valeurs est copiée depuis la ROM vers les variables systèmes. Cela se passe en $1071, juste après l'initialisation de l'affichage.

             ld       hl,initvalues
             ld       bc,$0065
             ld       de,ramlow
             ldir

Il y a donc 101 valeurs ($65) copiées depuis initvalues ($1194) vers ramlow ($4830). Parmi celles-ci, les suivantes sont copiés vers $4844 et nous intéressent aujourd'hui.

             defb     $00,$00,$00
             defb     $35,$4a,$ca,$99
             defb     $39,$1c,$76,$98
             defb     $22,$95,$b3,$98
             defb     $0a,$dd,$47,$98
             defb     $53,$d1,$99,$99
             defb     $0a,$1a,$9f,$98
             defb     $65,$bc,$cd,$98
             defb     $d6,$77,$3e,$98
             defb     $52,$c7,$4f,$80

Les trois premiers octets sont les trois index avec lesquels le générateur va jouer. Nous les appellerons les trois seeds. Suivent 8 nombres plutôt grands, positifs et négatifs (le premier vaut -26514538). Et enfin vient le nombre d'origine, qui vaut 0.8116351366043091, que vous pouvez retrouver sous sa forme arrondie en tapant PRINT RND(0) dès l'allumage du VG5000µ.

Cette table n'est pas la seule qui va être utilisée par le générateur. Il en existe une autre, qui sera utilisée depuis la ROM, en $093d, d'une longueur de 3.

             defb     $68,$b1,$46,$68
             defb     $99,$e9,$92,$69
             defb     $10,$d1,$75,$68

L'instruction RND

L'instruction RND commence en $090d par un petit préambule qui vérifie l'argument passé à la fonction. Cet argument est disponible dans FAC, l'accumulateur flottant (voir précédemment)

inst_rnd:    rst      getsign
             ld       hl,rnd_seed_2
             jp       m,reseed
             ld       hl,rnd_gen
             call     hl_to_fac
             ld       hl,rnd_seed_2
             ret      z

Ce préambule teste en premier lieu le signe de l'argument. S'il est négatif, la routine branche vers reseed, que nous verrons plus loin. C'est au passage un comportement qui n'est indiqué ni dans le manuel d'utilisation du VG5000µ, ni dans les « Clés pour VG5000 », qui donnent de fausses informations (je vous laisse regarder).

Dans le cas du branchement, HL point vers la seed 2 (et je ne vois aucun intérêt à ce que cela ne soit pas fait après le branchement...)

Si l'argument est nul ou positif, alors la nombre pointé par HL, qui est la variable système du dernier nombre généré ,est copié dans FAC. Souvenez-vous, c'est à cette adresse qu'a été placé à l'initialisation le nombre 0.8116351.

On refait pointer HL vers la seed 2 puis, si l’argument était 0, on sort de la routine immédiatement (le flag Zéro a été conservé depuis rst getsign).

Le calcul

Puisqu'on est à présent dans le cas où l’argument est positif, il convient de générer un nouveau nombre. Ce nouveau nombre est basé sur, d'une part, le nombre généré précédemment, et d'autre part, les trois index qui avaient été initialisés à zéro (voir ci-dessus).

Première étape

             add      a,(hl)
             and      a,$07
             ld       b,$00
             ld       (hl),a
             inc      hl

             add      a,a
             add      a,a
             ld       c,a
             add      hl,bc
             call     hl_to_bcde
             call     fp_mul

La première section du code précédent récupère l'index seed 2 en l'incrémentant de 1. En effet, A contient 1 depuis l'appel à getsign. Le résultat est pris modulo 8 et remonté en RAM.

Au passage, B est initialisé à 0 pour que BC puisse servir d'index, et HL va pointer un cran plus loin, sur le début de la table des coefficients initialisés au boot (la table des 8 valeurs).

La seconde section calcul le pointeur dans cette table en quadruplant A, qui est l'index, en format BC comme index à ajouter au pointeur de base HL.

L'appel hl_to_bcde copie le nombre pointé dans la table vers BCDE, puis l'appel à fp_mul effectue la multiplication avec le contenu de FAC.

Résumé : cette première étape est donc une multiplication du précédent nombre généré par un autre nombre, fixe, pris dans une table dans 8 valeurs tour à tour.

Le tout premier appel à RND(1) va multiplier 16129081 ($98 $76 $1c $39) avec0.8116351366043091($80 $4f $c7 $52`).

Cela donne 13090929 ($98 $47$c0 $71). Cela peut se vérifier dans FAC ($49e6). Attention, le nombre est octet par octet dans le sens inverse à celui que j'utilise ici.

Seconde étape

             ld       a,(rnd_seed_1)
             inc      a
             and      a,$03
             ld       b,$00
             cp       a,$01
             adc      a,b
             ld       (rnd_seed_1),a

             ld       hl,rnd_add - 4
             add      a,a
             add      a,a
             ld       c,a
             add      hl,bc
             call     fp_add_hl
afterreseed: call     fac_to_bcde

La seconde étape se divise elle aussi en deux sections.

Dans la première section, on récupère la seed 1, qui est incrémentée de 1 et modulo 4. Cependant, la valeur 0 est interdite. Par une comparaison avec 1 et un ajout à 0 (via B) avec retenue, si l'index était à 0, alors il est poussé à 1.

C'est donc en fait un index modulo 3 que l'on obtient.

Et cet index forme un pointeur via HL de manière similaire à l'étape précédente, dans la table de trois valeurs de la ROM mentionné au début de l'article.

Cette valeur est alors ajoutée à FAC. L'appel à fp_add_hl se charge de l'étape intermédiaire de chargement de la valeur dans BCDE. Puis le résultat est ramené dans BCDE.

Le label est un branchement venant du reseed que nous verrons plus loin.

Résumé : cette seconde étape est une addition du nombre obtenue à la première étape avec un des trois nombres pris dans la deuxième table, pris tour à tour.

Le tout premier appel additionne 13090929 ($98 $47 $c0 $71 ) avec 4.626181e-08 ($68 $b1 $46 $68). Ce second nombre est bien trop petit par rapport au premier. Cette addition ne change rien... dans ce cas-ci. Nous verrons plus tard à quoi cette addition peut servir.

Troisième étape

             ld       a,e
             ld       e,c
             xor      a,$4f
             ld       c,a

Dans cette troisième étape, le générateur fait des mélanges. Les 8 bits de poids les plus faibles sont mis de côté et les 8 bits de poids fort sont placés dans les 8 bits de poids faible.

Les 8 bits mis de côté sont XORés avec b01001111. Ce qui signifie que certains bits sont inversés. Puis le résultat est placé dans les 8 bits de poids fort.

Cette opération ne me semble pas avoir de sens arithmétique. Cela semble être juste un mélange. Peut-être pour amener de l'entropie dans les bits de poids faible... Peut-être.

Résumé : cet étape mélange les parties de la mantisse et change quelques bits.

Le nombre est à présent 12501063 ($98 $3e $c0 $47).

Étape intermédiaire

             ld       (hl),$80
             dec      hl
             ld       b,(hl)
             ld       (hl),$80

Cette étape profite que HL pointe actuellement (depuis la récupération de FAC dans BCDE) sur l'octet après FAC pour préparer le terrain pour plus tard. Cet octet contient le complément à 1 du bit de signe du nombre de FAC. En mettant cet octet à $80, on force la valeur à être positive.

HL pointe ensuite sur l'octet précédent, l'exposant, et met celui-ci à $80, c'est-à-dire $2^ 0$ (voir l'article sur les nombres, toujours).

Résumé : le nombre final sera un nombre positif et l'exposant est fixé à $2^0 = 1$.

Pas d’influence, pour le moment sur le nombre tenu dans BCDE.

Quatrième étape*

             ld       hl,rnd_seed_0
             inc      (hl)
             ld       a,(hl)

             sub      a,$ab
             jr       nz,rnd_cnt
             ld       (hl),a
             inc      c
             dec      d
             inc      e

C'est la dernière étape du calcul. Dans la première partie, la seed 0 est incrémentée et récupérée dans A.

Si la soustraction par 171 ($ab) n'est pas nulle, on branche plus loin à l'étape finale. Sinon, le résultat (0) est replacé dans la seed 0. C'est donc un compteur jusqu'à 171 qui, lorsqu'il atteint cette valeur, modifie légèrement la mantisse.

Le premier et le troisième octets de la mantisse sont incrémentés, celui du milieu décrémenté, sans se soucier de débordements éventuels.

Résumé : une fois tous les 171 tirages, la mantisse est modifiée légèrement.

Comme ici, c'est le premier tirage, il ne se passe rien.

Étape finale

rnd_cnt:     call     bcde_norm
             ld       hl,rnd_gen
             jp       cpy_faclsb_hl

La mantisse a été générée, l'exposant est là. Mais tout nombre dans FAC en sorti de routine doit être normalisé.

Comme indiqué dans l'article précédent sur la représentation des nombres, cela signifie que la mantisse et l'exposant vont être modifiée afin d'obtenir une mantisse avec un premier bit à 1 implicite, lui-même remplacé par le bit de signe.

MAIS ! Il y a un twist ! La routine bcde_norm n'attend pas en entrée un nombre BCDE, mais une mantisse 32 bits CDEB. L'exposant du nombre actuel va donc se retrouver... en partie la moins significative du nombre, afin de nourrir, en quelque sorte, la partie droite de la mantisse lors de l'éventuel décalage vers la gauche.

C'est peut-être un peu obscure : je donne un exemple dans le résumé.

En sortie de normalisation, le nombre est bien dans FAC. Le contenu de FAC est alors copié à l'emplacement du dernier nombre généré.

C'est terminé !

Résumé : mise en forme du nombre, à la fois dans FAC comme résultat de la fonction, et de côté pour servir de base au prochain nombre généré (ou pour être retourné en case de RND(0)).

Nous en étions à $98 $3e $c0 $47. Mais la normalisation s'attend à une mantisse 32 bits, et c'est donc comme ça que va être perçue la mantisse : $3e $c0 $47 $98.

La normalisation doit déplacer la mantisse à gauche jusqu'à ce que le bit de poids fort soit à 1. Il va falloir deux étapes pour cela :

de $3ec04798 à $7d808f30, puis
de $7d808f30 à $fb011e60

Comme le bit de poids fort du dernier octet n'est pas à 1, il n'y a pas d'arrondi. Cet octet est abandonné, le bit de signe et l'exposant corrigé par le nombre d'étapes ($80 - 2 donne $7e).

Au final, nous avons obtenu : $7e $7b $01 $1e, soit 0.245121

Suppléments

Re-seed

Si l'argument de RND() est négatif, alors un branchement a lieu sur une routine de réinitialisation du générateur.

reseed:      ld       (hl),a
             dec      hl
             ld       (hl),a
             dec      hl
             ld       (hl),a
             jr       afterreseed

À l'arrivée dans cette partie, HL pointe sur seed 2 et A est égal à $FF. Ce qui a pour résultat de mettre les trois octets à $FF.

Le branchement ramène dans le générateur à la fin de la seconde étape, c'est-à-dire après la multiplication et l'addition. Ce qui est dans FAC (l'argument négatif de RND()) est ramené dans BCDE et le reste des étapes est effectué.

C'est donc une nouvelle séquence qui démarre, dépendante de l'argument passé à RND().

Cas de l'addition

Revenons sur la seconde étape, l'addition avec un nombre tout petit. Dans l'exemple que nous avons suivi pendant l'article, l'addition ne servait à rien, car la différence entre les exposants était trop grand et donc le nombre à addition non significatif.

La question à se poser est donc : dans quels cas ces nombres deviennent-ils significatifs ?

Le plus petit d'entre eux est : $68 $46 $b1 $68 qui a pour exposant $68. C'est-à-dire $80 - 24.

Il faut donc un nombre strictement inférieur à $00 $00 $00 $80 (0.5) pour que l'addition soit intéressante.

Sauf que... juste avant l'addition, la multiplication a été faite avec un nombre dont l'exposant était au minimum $98. Puisque dans une multiplication, les exposants s'ajoutent, cela implique que seuls des nombres avec un exposants à '$68' initialement vont être assez petits après la multiplication et être modifiés par l'addition.

C'est quelque chose de facile à déclencher en modifiant à la main le dernier nombre généré en mémoire. Mais est-ce que cela se passe si on laisse le générateur se dérouler normalement ?

Un expérience simple avec un debuggeur en mettant un point d'arrêt dans le code d'addition et en faisant tourner le générateur montre que... non. Cela n'arrive pas. Ou alors assez rarement pour résister à l'expérience.

Il est temps de se poser la question des bornes maximales et minimales des nombres générés.

Mais vu la longueur de l'article, ce sera pour le prochain...

VG5000µ, jouer avec les nombres

2020-05-09T00:00:00+02:00

Suite à l'article précédent, j'ai mis sur le dépôt GitHub un petit utilitaire Python qui reproduit les conversions entre la valeur du nombre et son codage en 4 octets.

Parfois, voir du code est plus simple qu'un long discours.

Et parce qu'on ne sait jamais trop quel sera la vie future du dépôt, voici le code des deux principales fonctions de l'outil.

import math


def get_byte(number):
    """Takes the current number, and returns the next byte encoding it with the reminder of the number to encode. """

    number *= 256
    result = int(number)
    return result, (number - result)


def encode(number):
    """Gets a number, returns it's encoded four bytes (memory layout, so exponent at the end)."""

    # If the number is zero, the encoding is immediate.
    # In fact, only the exponent has to be 0.
    if number == 0:
        return [0, 0, 0, 0]

    # Gets the sign from the number for later encoding
    sign = 0x80 if number < 0 else 0

    # We encode only positive numbers
    number = abs(number)

    # Shift the number so that the first fractional part bit
    # of the mantissa is 1 (0.1 binary is 0.5 decimal)
    exp = 0
    while number >= 0.5:
        number /= 2
        exp += 1
    while number < 0.5:
        number *= 2
        exp -= 1

    # Gets the three bytes encoding the mantissa
    o1, number = get_byte(number)
    o2, number = get_byte(number)
    o3, number = get_byte(number)

    # Clears the most significant bit
    # and replace it by the sign bit
    o1 &= 0x7F
    o1 |= sign

    # Encode exponent
    exp += 128

    # Returns an array (Z80 memory layout)
    return [o3, o2, o1, exp]


def decode(encoded):
    """ Takes four encoded bytes in the memory layout, and returns the decoded value. """

    # Gets the exponent
    exp = encoded[3]

    # If it's 0, we're done. The value is 0.
    if exp == 0:
        return 0

    # Extract value from the exponent
    exp -= 128

    # Extract the sign bit from MSB
    sign = encoded[2] & 0x80

    # Sets the most significant bit implied 1 in the mantissa
    encoded[2] = encoded[2] | 0x80

    # Reconstruct the mantissa
    mantissa = encoded[2]
    mantissa *= 256
    mantissa += encoded[1]
    mantissa *= 256
    mantissa += encoded[0]

    # Divide the number by the mantissa, corrected
    # by the 24 bits we just shifted while reconstructing it
    mantissa /= math.pow(2, 24 - exp)

    # Apply the sign to the whole value
    if sign:
        mantissa = -mantissa

    return mantissa

VG5000µ, traitement des nombres

2020-05-08T00:00:00+02:00

Lors d'une discussion sur le forum system-cfg à propos de la fonction RND une question a été posée sur le format des nombres dans le VG5000µ. C'est une question qui revient et que je voulais documenter pour mémoire, me posant régulièrement la question et oubliant juste après...

Différents formats

Distinguons déjà deux choses : les nombres manipulés par le système, et les nombres manipulés par le BASIC. Les premiers sont de diverses formes en fonction des besoins, de type entier, signé ou pas, sur 8 ou 16 bits la plupart du temps. Il n'y a pas grand chose à dire sur eux.

Les seconds sont ceux manipulés par le BASIC, qui est un BASIC Microsoft sur VG5000µ, et ce qui sera valide dans cet article le sera pour d'autres machines avec BASIC Microsoft et un processeur Z80. Au moins dans les grandes lignes, mais pour ce que j'ai vu en comparant une paire d'entre eux, souvent jusque dans les détails. Ces BASIC ne différent que de petites modifications ici ou là, de l'ordre de l'optimisation.

Le BASIC lui-même traite plusieurs types de nombres. On a déjà vu la manière dont il traitant de manière particulière les numéros de lignes après un GOTO ou un GOSUB dans l'article sur l'arrangement des lignes.

Le format qui nous intéresse aujourd'hui est celui utilisé pour les calculs, ainsi que celui utilisé dans les variables numériques. Dans l'article sur les variables, j'étudiais comment les variables étaient créées, avec leur nom suivis de 4 octets. Mais que contiennent ces 4 octets ?

Le format flottant

Tous les nombres traités par le BASIC VG5000µ pour les calculs et les variables sont dans un format a virgule flottante. C'était déjà le cas avec le BASIC créé initialement à Dartmouth. L'idée était que les utilisateurs n'avaient pas à se poser de question sur le format interne, et pouvaient utiliser les nombres naturellement.

Plus tard, pour des raisons de performance (vitesse et consommation mémoire), des versions de BASIC ont ajouté un typage sur ces nombres. Comme le suffit % des variables numériques qui indiquent que la variable contient un nombre entier.

Sur le VG5000µ, pas de typage de nombre. Tout est au même format. Je nommerai ce format le format BCDE par la suite. BCDE car il est manipulé la plupart du temps à travers cette paire de registres (BC et DE). BCDE désigne donc aussi l'emplacement du nombre traité dans certaines situations.

Pour les calculs, le BASIC utilise un accumulateur flottant, que je nommerai FAC par la suite (Floating point ACumulator). L'essentiel du format est le même que lorsqu'il est au format BCDE.

L'accumulateur FAC est l'endroit où se situe « le nombre en cours ». À la sortie d'une fonction, le résultat s'y trouve et est donc disponible pour les calculs ou fonctions suivants.

Ainsi, dans une expression comme INT(4 * 0.2), le FAC va d'abord contenir 4, puis après la multiplication 0.8, puis après INT(), contiendra 0. Des instructions comme PRINT ou LET (explicite ou implicite), iront chercher cette valeur pour la traiter.

Les mouvements

Puisque BCDE et FAC sont étroitement liés, il existe des fonctions pour transférer le contenu de BCDE vers FAC (\$05d2) et inversement (\$05dd). Il est possible aussi de récupérer dans BCDE un nombre pointé par HL (\$05e0), et de monter dans FAC un nombre pointé par HL (\$05cf), en utilisant BCDE au passage.

Le format

Voici en premier lieu un tableau auquel je vais me référer pour expliquer le format.

B	C	D	E
Exp.	S\|MSB	Milieu	LSB
$49e9	$49e8	$49e7	$49e6

Exp. est l'exposant du nombre (la puissance de 2 par laquelle est multipliée la mantisse).
MSB (Most Significant Byte), Milieu et LSB (Least Significant Byte) forment la mantisse.
S est le bit de signe et se trouve en bit 7 du MSB.
Les adresses représentent les positions dans FAC l'accumulateur flottant.

Attention : les adresses indiquées partent de la plus haute à la place basse. Lorsque vous inspectez la mémoire octet par octet, que ce soit dans FAC ou pour une valeur de variable, le nombre est donc dans l'autre sens EDCB, avec l'exposant en dernière position.

La mantisse

La mantisse couvre donc 23 bits. Le 24ième bit, le plus significatif, est implicitement à 1. Dans le format codé, il est donc remplacé par un bit de signe. Un bit à 1 indique un nombre négatif, positif sinon.

La mantisse est lue comme 0.1xxxxxx xxxxxxxx xxxxxxxx en binaire. Les x étant pris dans les 23 bits formés par MSB, Milieu et LSB.

L'exposant

L'exposant est centré sur 128 (ou $80 en hexadécimal). Cela signifie que 128 est l'exposant nul. Pour 129 l'exposant est 1, 127, et pour l'exposant est -1.

La valeur 0 ($00) pour l'exposant est spéciale : elle représente le nombre 0. Peu importe les autres octets, la valeur est nulle. Dans certains codage de nombre flottants, cet exposant zéro est utilisé pour représenter des valeurs particulières qui viennent compléter celles accessibles depuis un exposant non nul. Ici, ce n'est pas le cas. Un exposant à 0 signifie le nombre 0.

La valeur du nombre

La valeur du nombre représenté est égal à : $-1 . signe . 2^{exp.} . mantisse$.

Ceci mérite quelques exemples.

Exemple 1 : 0, codé 00 xx xx xx. Comme je l'ai écrit ci-dessus, peut importe la valeur des autres octets. Si l'exposant est à 0, c'est le nombre 0.

Exemple 2 : 1, codé 81 00 00 00. En effet, 1 est égal à $b0.1 . 2^1$ (je préfixe les nombres en binaire par b, pour faire la différence avec les nombres en base 10 que je ne préfixe pas).

L'exposant est donc 1, codé en 128 + 1 = 129, \$81 en hexadécimal. La mantisse est 'b0.1', codé en 00 00 00 puisque le premier 1 est implicite dans le codage.

Example 3 : 2, codé 82 00 00 00. Sur le même principe, 2 est égal à $b0.1 . 2^2$. Donc exposant 2 donne \$82 et la mantisse est là aussi 0 puisque b0.1 est implicite.

Exemple 4 : -2, codé 82 80 00 00. Le code est similaire à celui de 2, mais le bit de signe négatif est placé sur le 7ième bit de l'octet le plus significatif de la mantisse.

Exemple 5 : 0.1', code ``7d 4c cc cc. Là, c'est un peu plus compliqué. 0.1 n'est pas une valeur qui tombe juste en binaire. Puisque la précision est limitée, il faut bien s'arrêter quelque part ; il faut bien comprendre que le nombre 'retenu' n'est pas vraiment 0.1, juste un nombre approchant.

Le nombre s'écrit $2^{-3} . b0.110011001100110011001100$... ; 128 - 3 donne \$7d en hex. Une fois enlevé le premier bit de la mantisse, le reste s'écrit comme indiqué.

Aparté 1

Il est possible d'écrire

LET A = 0.1
PRINT A

Et le nombre affiché sera bien 0.1. Pourtant, ce n'est pas le nombre encodé, qui est plus quelque chose comme : 0.09999999403953552

Mais ce nombre est arrondi lors de l'affichage.

Aparté 2

À noter aussi que chaque opération effectuée par le BASIC, qui en interne utilise 32 bits, se termine par un encodage du nombre, qui est arrondi aux 24 bits disponibles. Si les calculs ont besoins de plus de 24 bits significatifs, alors les résultats ne seront pas exacts. Il faut se méfier des nombres flottants.

Aparté 3

Rappelez-vous qu'en lisant la mémoire octet par octet, les nombres codés vont apparaître dans l'autre sens. Ainsi, si vous assignez à une variable le nombre 1 et que vous regardez dans la section de variable la valeur suivant le nom, vous y verrez 00 00 00 81.

Aparté 4

En examinant la mémoire de FAC et en traçant les opérations, vous pourrez constater que l'octet suivant (\$49ea) bouge aussi. Il s'agit d'un octet utilisé pour stocker le signe des opérations. En effet, afin de faire des opérations sur les mantisses, il faut en extraire le bit de signe et y remettre le bit implicite. Un bit de signe est stocké à cet endroit (attention, il s'agit de son complément).

Une opération

Pour se faire une idée de comment sont traités les nombres, je vous invite à suivre le processus d'addition.

Tout commence en $0705 par la récupération sur la pile du nombre qui vient d'être décodé depuis la ligne du BASIC. Dans FAC est déjà positionnée l'opérande précédente de l'opération.

eval_add:    pop      bc
             pop      de
             jp       fp_bcde_add

La nouvelle opérande est maintenance dans BCDE dans le format expliqué dans les paragraphes précédents. Il faut donc maintenant ajouter BCDE et FAC.

En $0310, la routine commence par un test. Si l'exposant, qui est initialement dans B, est égal à 0, on peut s’arrêter là. Ajouter 0 à FAC signifie ne pas le modifier. Le retour est immédiat :

fp_bcde_add: ld       a,b
             or       a,a
             ret      z

Deuxième cas simple, si la valeur de l'exposant de FAC est 0, le résultat est le nombre présent dans BCDE, il suffit donc de le transférer dans FAC et c'est terminé :

             ld       a,(fac_exp)
             or       a,a
             jp       z,bcde_to_fac

L'étape suivante est de s'assurer que le nombre dans FAC a un exposant plus grand que celui de BCDE. Si ça le cas, c'est parfait, sinon, on échange les deux nombres. L'opération utilise la pile temporairement. A qui contient la différence entre les deux exposants, prend la valeur de son opposée, pour rester cohérente.

             sub      a,b
             jr       nc,no_swap
             cpl
             inc      a
             ex       de,hl
             call     fac_to_stck
             ex       de,hl
             call     bcde_to_fac
             pop      bc
             pop      de

À ce niveau, on a :

dans FAC le nombre dont l'exposant est le plus grand,
dans BCDE, le nombre dont l'exposant est le plus petit,
dans A, la différence entre ces deux exposants.

Si le nombre d'exposant le plus petit est insignifiant par rapport au plus grand, on peut s'arrêter là, le résultat de l'addition sera le plus grand des grands nombres. Puisque les nombres sont codés sur 24 bits significatifs, si la différences entre les exposants est de 25 ou plus, on peut sortir de la fonction :

no_swap:     cp       a,$19
             ret      nc

À présent que les nombres sont en place et qu'il est intéressant de les additionner, il faut les préparer. Pour le moment, le bit de signe est toujours codé dans les deux nombres. Ils sont aussi potentiellement à des exposants différents. Deux raisons pour lesquelles on ne peut pas additionner les mantisses pour le moment.

La première opération est d'extraire les signes et de renvoyer une indication sur l'opération à faire. Plus d'explication sur cette indication juste après.

Puis d'aligner les deux mantisses sur l'exposant le plus grand.

             push     af
             call     ext_sign
             ld       h,a
             pop      af
             call     div_mant

Je n'entre pas dans la routine ext_sign, mais voici ce qu'elle fait. Elle prend le bit 7 de l'octet le plus significatif de FAC et le remplace par le 1 implicite de la mantisse codée. Le bit de signe est inversé et est mis de côté, dans l'octet suivant l'exposant de FAC.

Puis la même opération est faite sur BCDE : extraction de signe, remplacement par 1. Le signe n'est pas mis de côté, mais est utilisé pour renvoyer dans A une indication : 0 si les signes étaient identiques, 1 s'ils étaient opposés.

Cette indication, qui est sauvée dans H pour pouvoir récupérer la valeur de AF sauvée sur la pile (A contient la différence entre les exposants), servira bientôt.

L'opération div_mant décale vers la droite la mantisse de BCDE d'autant de positions qu'indiquées par A. Attention : en sortie de cette fonction, la mantisse est disponible sur CDEB.

En effet, l'exposant n'est plus nécessaire, puisqu'il est identique à celui de FAC. On peut donc réutiliser B pour récupérer les bits résultants du décalage à droite et éviter de perdre trop de précision. La mantisse est temporairement sur 32 bits (même si seuls 24 sont toujours significatifs, puisque issus du nombre initial).

Il reste donc à passer à l'addition... enfin presque.

Dans la partie suivante, on récupère dans A l'indicateur donné précédemment par les signes. Si les signes étaient identiques, on passe à la suite. S'ils étaient différents, c'est une soustraction qui sera faite, en allant vers min_bcde.

             ld       a,h
             or       a,a
             ld       hl,fac_lsb
             jp       p,min_bcde

Pourquoi cette différence de traitement en fonction des signes ?

Si les signes des deux nombres sont positifs, il faut additionner les mantisses et le nombre sera positif.
Si les signes des deux nombres sont négatifs, on peut aussi additionner les mantisses comme des nombres positifs, et pendre l'opposée du tout. $(-a) + (-b)$ est la même chose que $-(a+b)$.
Si les signes des deux nombres sont opposés, on peut soustraire les mantisses et corriger le signe du résultat. En effet $a + (-b)$ est la même chose que $(a - b)$ et $(-a + b)$ est la même chose que $-(a-b)$.

Le cas de l'addition des mantisses est le suivant :

             call     add_bcde
             jr       nc,round
             inc      hl
             inc      (hl)
             jp       z,overflow
             ld       l,$01
             call     shft_right
             jr       round

Après l'appel à add_bcde qui ajoute la mantisse CDE avec celle de FAC octet par octet, un test est fait sur la retenue. Si l'addition n'a pas générée de retenue, alors on va vers la routine d'arrondi de FAC, qui terminera l'opération.

S'il y a eu une retenue, il faut augmenter l'exposant de 1, ce qui est fait en pointant HL un cran plus loin que la mantisse et augmentant la valeur de l'exposant qui s'y trouve. Si cette incrémentation a ramené l'exposant à 0, c'est qu'il était déjà à son maximum. Le nombre est trop grand, une erreur de dépassement de capacité est lancée.

Sinon, il faut corriger la mantisse avec un décalage vers la droite de 1 bit (paramètre indiqué par L) puis brancher vers la routine d'arrondi.

Le cas de la soustraction des mantisses est le suivant :

min_bcde:    xor      a,a
             sub      a,b
             ld       b,a
             ld       a,(hl)
             sbc      a,e
             ld       e,a
             inc      hl
             ld       a,(hl)
             sbc      a,d
             ld       d,a
             inc      hl
             ld       a,(hl)
             sbc      a,c
             ld       c,a
             call     c,compl2

Toute la première partie, jusqu'au call, est la soustraction de la mantisse de 'FAC' par la mantisse 'CDEB' octet par octet. Le résultat se trouve dans 'CDE'. L'exposant du nombre final est toujours celui de FAC.

Si le résultat de la soustraction est positif, alors il ne se passe rien de plus. Si une retenue a eue lieu pendant la soustraction, alors on prend son opposée en appelant compl2, afin de rendre la mantisse positive. Cette routine inverse aussi le bit de signe qui avait était extrait dans l'octet suivant FAC.

La routine qui suit dans le code étant la normalisation et arrondi d'un nombre, pas besoin de brancher, c'est terminée.

Oui mais le signe ?

Les opérations pour obtenir le signe du résultat final ne sont pas forcément évidente à suivre. Voici ce qu'il se passe :

Dans le cas où on a utilisé l'addition des mantisses, le signe de FAC a été extrait de la première opérande.
- Dans le cas $a + b$, $a$ était positif, et le résultat est positif.
- Dans le cas $-a-b$ qui est devenu $-(a+b)$, $a$ était négatif, et ce signe négatif sera hérité par le résultat. Transformant $a+b$ en $-(a+b)$.
Dans le cas où on a utilisé la soustraction des mantisses, là encore, le signe de FAC a été extrait de la première opérande.
- Dans le cas $a - b$, le signe du résultat dépend de cette opération. Si $a > b$, compl2 n'a pas été appelé et le résultat est positif. Dans le cas contraire, compl2 a changé le bit de signe et le résultat est bien négatif, puisque la mantisse est positive.
- Dans le cas $-a+b$, qui a été exécutée comme $-(a-b)$, initialement, le signe de FAC portait l'indication négatif, et le résultat de la soustraction l'aura, en fonction des deux cas, laissé comme tel, ou inversé.

Re-codage final

La routine qui suit, de normalisation, s'assure que le bit de poids fort est toujours 1 (si ce n'est pas possible, c'est que le nombre est 0) et ajuste l'exposant en conséquence, puis arrondi le nombre. L'arrondi peut générer un dépassement de capacité.

L'addition n'a pas besoin de normalisation. Le résultat de l'addition des mantisses assure toujours que le bit de poids fort est 1 (au moins l'un des deux nombres était normalisé avec un bit de poids fort à 1, et si les deux l'étaient, alors cela a provoqué l'augmentation de l'exposant et le bit de poids fort est toujours 1, la retenu de 1 + 1 en binaire).

Le résultat de l'addition est à présent dans FAC, place à la suite des opérations...

Récréation 3D, Tortue Jeulin

2020-01-29T00:00:00+01:00

Depuis quelques temps, je planche à mes heures perdues sur ma prochaine vidéo. Et le sujet est le langage de programmation Logo. Après avoir survolé le BASIC, cela me semblait une suite logique.

En me plongeant dans l'univers Logo, j'ai cherché à mieux connaître le robot qui y est associé : la tortue Jeulin. Et j'ai été très étonné de voir aussi peu de ressources dessus. Et pourtant, il semble qu'elle ne soit pas si rare chez les collectionneurs.

Grâce à l'aide de photographie envoyées sur le forum system-cfg par Fool-DupleX (merci à lui), j'ai tenté une modélisation. Ça m'a pris... un certain temps.

Le résultat n'est pas correct au milimètre, mais donne une relativement bonne idée.

VG5000µ, les hooks d'entrées/sorties

2019-09-22T00:00:00+02:00

Pour ces quatre nouveaux hooks, je ne suis pas très inspirés. Il s'agit de hook destiné au traitement des entrées sorties. Trois d'entre eux sont appelés lors d'une impression de caractères, le quatrième pour de l'acquisition.

Routines en sorties

Voici les trois premières :

$47DF, prthk : début de commande PRINT.
- Est appelé en tant que première instruction de l'exécution de l'instruction PRINT.
- À ce moment là, HL pointe vers les arguments de PRINT et le flag Z est à 1 s'il n'y a rien dans ces arguments.
- Si vous rendez la main à la routine, elle déroulement l'affichage.
$47E2, outhk : début d'impression de caractère -> pour rerouter vers de nouvelles sorties
- Est appelé pour chaque caractère envoyé sur un périphérique de sortie (en $3bd0)
- La variable système (prtflg) désigne le périphérique.
- Le caractère à afficher est dans le registre A.
- Attention, ce caractère est à comprendre par rapport aux modes d'affichage : est-ce qu'on est en caractères normaux ? semi-graphiques ? redéfinis par l'utilisateur ?
$47E5, crdhk : début de retour chariot -> pour rerouter vers de nouvelles sorties
- Est appelé par chaque demande de retour à la ligne lors de l'émission des caractères sur le périphérique (en $3c57).
- N'est pas appelé lors d'un retour chariot dans l'éditeur par contre.
- La variable système (prtflg) désigne le périphérique.

La variable système (prtflg) désigne le périphérique en sortie selon les valeurs suivantes :

0 - L'écran
1 - L'imprimante
255 - La cassette (en écriture)

Les appels aux hooks se situent avant le tri vers les trois routines. La sélection ne se fait pas systématiquement dans le même ordre, ce qui signifie que les valeurs 2 à 254 n'envoient pas au même endroit pour les différentes fonctions.

Le retour chariot enverra sur l'imprimante et la sortie de caractère sur la cassette. PRINT ne considère que deux cas, l'imprimante et l'écran, et s'occupera de la position du chariot ou du curseur suivant le cas. Pour l'affichage en lui-même, c'est la routine d'envoi de caractère et de retour chariot qui sont utilisés.

Ainsi, si vous voulez supporter un nouveau périphérique en sortie, il faudra probablement effectuer un premier traitement au niveau du PRINT suivant si vous voulez être traité comme un écran ou une imprimante ; puis rendre la main, ou bien tout faire seul et jeter la première adresse de retour de la pile.

Du côté de la sortie de caractère et du retour chariot, il vous faudra prendre la main et jeter la première adresse de retour de la pile quoi qu'il arrive.

N'ayant pas de périphérique à tester (on pourrait imaginer une sortie série), je n'ai pas essayé.

Précautions

Pendant l'exécution d'une routine de sortie, n'appelez-pas les routines de la ROM qui elles-mêmes font de l'affichage. Vous vous appelleriez vous-même...

De toute façon, les routines d'affichages ne sont pas ré-entrantes et ne supportent pas d'être exécutées dans deux contextes simultanément. Cela explique pourquoi, si vous avez essayé comment moi d'utiliser des routines d'affichage pendant l'interruption d'affichage, des choses étranges se produisent.

En effet, si l'interruption à lieu pendant que la ROM est en train d'exécuter une de ces routines (un PRINT tout simplement), il y a de bonnes chances que cela se passe mal. Même si vous sauvez tous les registres. Le contexte est beaucoup plus gros que ça, avec des buffers de constructions de chaînes.

Mieux vaut avoir vos routines d'affichages spécialisées.

Routine en entrée

Pour l'entrée, il n'y a qu'un hook, celui de l'instruction INPUT :

$47EB, inphk : début de commande INPUT
- Appelé en second lors de l'exécution de l'instruction BASIC INPUT, la première instruction étant la vérification que INPUT n'a pas été appelée en direct, hors programme.
- Comme pour PRINT, HL pointe sur les arguments.
- La variable système (getflg) désigne le périphérique en entrée. 0 pour le clavier, 255 pour la cassette. Il n'y a pas de périphérique écran en entrée...

Il est donc possible d'aller router l'INPUT vers un nouveau périphérique externe.

Le manque d'idée...

Oui... décidément, comme je n'ai pas de nouveau périphérique à router, je manque d'idée. Le programme que j'écris se contente donc de compter les appels aux différents hooks puis d'offrir une routine pour afficher les compteurs.

Installation

    defc out_number = $0726
    defc out_str = $36aa

    defc xcursor = $4805

    defc prthk = $47df
    defc outhk = $47e2
    defc crdhk = $47e5
    defc inphk = $47eb
    defc inthk = $47D0

    org $7A00           ; Spécification de l'adresse mémoire d'implentation

    push AF             ; Sauvegarde des registres sur la pile
    push HL

    ld   hl, call_text  ; Affichage du CALL pour la routine d'Affichage
    call out_str

    ld   hl, call_routine
    call out_number

    ld A,$C3            ; Mise en place des JP
    ld (prthk), A
    ld (outhk), A
    ld (crdhk), A
    ld (inphk), A

    ld HL,prt_routine   ; Mise en place des adresses de saut
    ld (prthk+1),HL

    ld HL,out_routine
    ld (outhk+1),HL

    ld HL,cr_routine
    ld (crdhk+1),HL

    ld HL,inp_routine
    ld (inphk+1),HL

    pop HL              ; Restauration des registres depuis la pile
    pop AF

    ret                 ; Retour au programme appelant

call_text:
    defm "CALL ", $00

Dans cette première partie, on effectue comme d'habitude l'installation des routines. Comme il y a quatre routines à mettre en place, on me d'un coup les quatre JP , puis dans la foulée les quatre adresses.

Mais auparavant, on affiche à l'écran un message indiquant l'instruction CALL à lancer pour provoquer l'affichage des compteurs.

Comme indiqué ci-dessus, appeler les routines d'affichages textes et nombres pendant une interruption ne fonctionne pas sans de nombreuses précautions. J'ai donc préféré offrir une routine qui affiche les compteurs sur un appel explicite. Et plutôt que de placer cet appel à une adresse fixe, elle est à la suite des autres routines. Son adresse étant variable en fonction des modifications des autres routines, je m'aide en affichant l'adresse à appeler.

Comptage

Le comptage se résume à quatre fois la même routine, à l'adresse de la variable de comptage près.

prt_count:
    defw    $0000
out_count:
    defw    $0000
cr_count:
    defw    $0000
inp_count:
    defw    $0000

prt_routine:
    push hl

    ld   hl, (prt_count)
    inc  hl
    ld   (prt_count), hl

    pop  hl
    ret

out_routine:
    push hl

    ld   hl, (out_count)
    inc  hl
    ld   (out_count), hl

    pop  hl
    ret

cr_routine:
    push hl

    ld   hl, (cr_count)
    inc  hl
    ld   (cr_count), hl

    pop  hl
    ret

inp_routine:
    push hl

    ld   hl, (inp_count)
    inc  hl
    ld   (inp_count), hl

    pop  hl
    ret

Au tout début, je réserve quatre emplacements de 16 bits pour les compteurs. Puis viennent les quatre routines qui chacune va augmenter le compteur associer lors d'un appel.

Prenons prt_routine. Tout d'abord, HL est sauvegardé. Comme d'habitude au début d'une instruction, ce registre pointe vers la ligne en train d'être exécutée, il est essentiel de préserver sa valeur.

HL est ensuite chargé avec la valeur de compteur, cette valeur est incrémentée puis replacée dans le compteur.

On restaure HL et on revient. Vraiment simple.

L'affichage des compteurs

La dernière partie est une routine qui sera appelée explicitement par un CALL pour afficher la valeur des compteurs.

call_routine:
    push hl
    push bc
    push de
    push af

    ld   hl, (xcursor)
    push hl

    ld   hl, $0020
    ld   (xcursor), hl
    ld   hl, (prt_count)
    call out_number

    ld   hl, $0120
    ld   (xcursor), hl
    ld   hl, (out_count)
    call out_number

    ld   hl, $0220
    ld   (xcursor), hl
    ld   hl, (cr_count)
    call out_number

    ld   hl, $0320
    ld   (xcursor), hl
    ld   hl, (inp_count)
    call out_number

    pop  hl
    ld   (xcursor), hl

    pop  af
    pop  de
    pop  bc
    pop  hl

    ret

Vu qu'on appelle out_number, mieux vaut sauver pour commencer tous les registres (sauf IX et IY, mais ces registres sont particuliers pour la ROM). On les restaure en fin de routine.

Puis on récupère les coordonnées du curseur dans HL. Attention ici, l'adresse xcursor contient une valeur sur 8 bits. Elle est suivi par ycursor qui contient aussi une valeur sur 8 bits. Grâce au LD HL, (xcursor), c'est donc les coordonnées X et Y qui sont chargées dans HL en une seule instruction.

Ces coordonnées seront elles-aussi restaurées en fin de routine. Pour remettre le curseur là où il se situait avant le CALL.

Vient ensuite une répétition de quatre fois la même séquence, aux valeurs près.

Tout d'abord, HL prend les coordonnées d'affichages du nombre que l'on va écrire. Dans la valeur sur 16 bits, Y arrive en premier, suivi de X. Ainsi $0020 signifie ligne 0, colonne 32.

Cette position est placée dans la variable système (xcursor). HL prend ensuite la valeur du compteur à afficher, et enfin CALL out_number se charger d'afficher le nombre entier contenu dans HL à la position courante.

BASIC

Voici un programme BASIC qui va monter la routine en mémoire. Suivi d'un RUN pour l'exécuter puis du CALL pour lancer le hook.

10 CLEAR 50,&"79FF"
20 S=&"7A00"
30 READ A$
40 IF A$="FIN" THEN END
50 A$="&"+CHR$(34)+A$+CHR$(34):A=VAL(A$)
60 POKE S,A
70 S=S+1
80 GOTO 30
300 DATA F5,E5,21,37,7A,CD,AA,36,21,6D,7A,CD,26,7,3E,C3,32,DF,47,32
310 DATA E2,47,32,E5,47,32,EB,47,21,45,7A,22,E0,47,21,4F,7A,22,E3,47
320 DATA 21,59,7A,22,E6,47,21,63,7A,22,EC,47,E1,F1,C9,43,41,4C,4C,20
330 DATA 0,0,0,0,0,0,0,0,0,E5,2A,3D,7A,23,22,3D,7A,E1,C9,E5
340 DATA 2A,3F,7A,23,22,3F,7A,E1,C9,E5,2A,41,7A,23,22,41,7A,E1,C9,E5
350 DATA 2A,43,7A,23,22,43,7A,E1,C9,E5,C5,D5,F5,2A,5,48,E5,21,20,0
360 DATA 22,5,48,2A,3D,7A,CD,26,7,21,20,1,22,5,48,2A,3F,7A,CD,26
370 DATA 7,21,20,2,22,5,48,2A,41,7A,CD,26,7,21,20,3,22,5,48,2A
380 DATA 43,7A,CD,26,7,E1,22,5,48,F1,D1,C1,E1,C9
1000 DATA FIN
RUN
CALL &"7A00"

Pour éviter d'avoir à tout rentrer au clavier, voici le fichier .k7. À charger avec CLOAD, suivi d'un RUN et du CALL &"7A00".

Une fois le programme chargé et les routines installées via le CALL, vous pouvez regarder les effets sur les compteurs avec un programme similaire à celui qui suit (pensez à faire un NEW pour partir à vide) :

10 CALL xxxxx
20 PRINT "HELLO"
30 INPUT A$
40 INPUT A$
50 CALL xxxxx

En remplaçant bien entendu les xxxxx par la valeur indiquée lors du CALL &"7A00"

Le résultat

Et voici le résultat d'une session comme indiquée ci-dessus.

VG5000µ, les hooks d'appel

2019-09-09T00:00:00+02:00

Dans la série des hooks sur VG5000µ, voyons en cette fois la paire probablement la plus simple. Ça sera donc rapide.

Le hook CALL

Du nom de calhk et d'adresse $47D3, ce hook est utilisé en interne par la commande BASIC CALL.

Le code de cette instruction est extrêmement simple :

inst_call:   call     eval_num_ex
             call     deint_impl
             ld       a,$c3
             ld       (calhk),a
             ld       (calhk+1),de
             jp       calhk

En premier, l'argument passé à CALL est évalué, puis est ensuite transformé en entier sur 16 bits.

Cette adresse, précédée par l'opcode pour JP à une adresse absolue 16 bits est placée dans le hook calhk. La routine saute enfin vers cette adresse, qui agit comme un tremplin vers l'adresse indiquée à l'instruction CALL.

Comme c'est le RET de la routine appelée qui fera office de RET pour l'ensemble de l'instruction CALL, la préservation de l'environnement est à la charge de la routine appelée. Essentiellement, il vous faut préserver HL, qui pointe sur la fin de l'instruction. Si vous ne le faite pas, il y a de bonnes chances que vous obteniez un Erreur de Syntaxe en retour d'instruction.

Pour un exemple d'utilisation, voyez les articles précédents, qui montent une routine assembleur en mémoire puis l’appellent.

Récupérer des paramètres

Que HL pointe juste après le CALL se révèle pratique pour récupérer des arguments potentiels. Dans l'article sur les hooks de périphériques, j'étais allé chercher un argument de type chaîne de caractères. Cette fois, je vais aller chercher trois arguments de type nombre. Le premier entier sur 8 bits, le second sur 16 bits, et le troisième un nombre quelconque (dans les limites du VG5000µ).

Les deux premiers arguments seront obligatoires, le troisième optionnel.

Grâce à ça, il est possible d'ajouter des commandes au BASIC, sans leur donner un nom cependant.

    defc out_number = $0726
    defc out_fp = $0731
    defc deint_impl = $2552
    defc eval_num_ex = $284d
    defc type_eq_num = $2850
    defc read_expr = $2861
    defc getbyt_impl = $2aa5
    defc out_str = $36aa

    org $7A00           ; Spécification de l'adresse mémoire d’implantation

cmd_routine:
    rst  $08            ; Vérification obligatoire du caractère qui suit
    defb ','

    call getbyt_impl    ; Récupération d'un entier 8 bits dans A
    ld   C,A            ; Sauvegarde du premier paramètre dans C
    ld   B,$00          ; BC contient le premier paramètre

    rst  $08            ; Vérification obligatoire du caractère qui suit
    defb ','            ; La virgule de séparation

    push BC             ; Sauvegarde du premier paramètre dans la pile

    call eval_num_ex
    call deint_impl     ; Lecture d'un entier signé 16 bits dans DE

    push DE             ; Sauvegarde du second paramètre dans la pile

    ld   A,'('
    rst  $18            ; Affichage de la parenthèse ouvrante

    ex   (SP), HL       ; Récupération du deuxième paramètre, sauvegarde du pointeur
    call out_number     ; Affiche le contenu de HL

    ld   A,','
    rst  $18            ; Affichage de la virgule

    pop  HL
    ex   (SP), HL       ; Récupération du premier paramètre, sauvegarde du pointeur
    call out_number     ; Affiche le contenu de HL

    pop  HL             ; Récupération du pointeur d'exécution

    rst  $10            ; Lecture du caractère suivant
    jr   Z,no_third     ; Fin de la ligne, il n'y a pas de troisième paramètre

    dec  HL             ; Sinon, on revient en arrière pour vérifier le caractère suivant
    rst  $08
    defb ','            ; Qui doit être une virgule

    ld   A,','
    rst  $18            ; Affichage de la virgule

    call read_expr      ; Lecture du troisième paramètre comme une expression

    push HL             ; Sauvegarde du pointeur d’exécution

    call type_eq_num    ; Vérification du type de paramètre (numérique)
    call out_fp         ; Construction de la chaîne de caractères correspondant au nombre
    call out_str        ; Affichage de la chaîne

    pop  HL             ; Restauration du pointeur d’exécution

no_third:
    ld   A,')'
    rst  $18            ; Affichage de la parenthèse fermante

    ret

C'est assez long, il y a peut-être plus optimisé, le principal ici est que la suite d'instructions soit lisible et que les morceaux différents allant chercher les arguments puissent être pris indépendamment pour réutilisation.

Le code est commenté, mais nécessite peut-être quelques autres éclaircissement :

rst $08 vérifie que le caractère codé juste après le RST est pointé par HL. Si ce n'est pas le cas, une erreur de syntaxe est levée. Le DEFB qui suit le RST est bien entendu sauté, le retour de la routine se fait juste après. La ROM se sert beaucoup de cette séquence pour vérifier la syntaxe de commandes et d'expressions.
rst $18 affiche le caractère présent dans A.
read_expr évalue une expression de n'importe quel type et met le résultat dans l'accumulateur flottant.
eval_num_ex lire une expression (via read_expr) et vérifie dans la foulée si elle est numérique.
getbyt_impl appelle eval_num_ex, la converti en entier, et vérifie que le résultat tient sur 8 bits. Le résultat est dans A.
deint_impl effectue une troncature entière sur 16 bits du nombre présent dans l'accumulateur flottant. Le résultat est dans DE.
out_number affiche le nombre (entier positif) présent dans HL.
out_fp écrit dans un buffer temporaire une chaîne représentant le nombre présent dans l'accumulateur flottant. Le pointeur vers la chaîne est renvoyé dans HL et la chaîne se termine par 0.
out_str affiche la chaîne pointée par HL se terminant par 0.

On notera au passage que lors de l'affichage, les deux premiers paramètres sont inversés... c'était juste plus simple à écrire.

Le hook `RST`

Le second hook d'appel est rsthk, à l'adresse $47DC. Son fonctionnement n'est pas atteignable depuis le BASIC.

La fonction RST du Z80 est une sorte de CALL sur 1 octet. Il permet de brancher à une série de 8 adresses prédéfinies : $0000, $0008, $0010, $0018, $0020, $0028, $0030, $0038. Suivant la syntaxe de l'assembleur, soit l'adresse, soit le numéro du restart (entre 0 et 7) est accepté.

Toutes ces adresses sont allouées à des fonctions souvent appelées, cela permet de gagner de la place. Comme il n'y a pas beaucoup d'instructions possibles entre deux adresses de restart, la routine est souvent placée ailleurs, et certains emplacements sont remplis avec des données.

Par exemple, entre RST $00, qui fait un démarrage complet de la machine et RST $08, qui fait un test de syntaxe, se situe la chaîne ".1.1" pour la ROM 1.1. C'est cette chaîne qui est affichée au démarrage de la machine.

Les différents RST

Puisqu'on y est, voici les différents RST sur VG5000µ, brièvement.

$00 : redémarrage complet de la machine
$08 : vérification de la présence d'un caractère pointé par HL, ou lancement d'une erreur de syntaxe (pour vérifier une virgule entre deux arguments par exemple)
$10 : acquisition d'un caractère depuis la chaîne pointée par HL (avec quelques flags concernant sa nature, et en sautant les espaces)
$18 : envoie d'un caractère sur le périphérique sélectionné (écran, imprimante, modem)
$20 : comparaison de HL et DE, qui a lieu très souvent.
$28 : renvoie -!, 0 ou 1 en fonction du signe de l'accumulateur flottant
$30 : libre
$38 : vecteur d'interruption (utilisé par l'affichage)

Un `RST` libre

Le restart $30 est donc libre, et son code est le suivant :

usrrst:      jp       rsthk

Net et précis. Il suffit donc d'ajouter en rsthk un JP suivi d'une adresse absolue, et vous pouvez alors utiliser RST $30 dans vos routines pour un appel très fréquent.

Cependant, il y a une limite : il n'existe qu'un seul hook libre pour tout le monde. À garder en tête si vous mélanger des routines qui veulent chacune utiliser cette instruction.

À noter aussi que si RST $30 ne prend qu'un octet dans votre routine, le saut utilise deux indirections pour un total de 31 T States contre 17 pour un CALL.

Le résultat

Voici le résultat de l'appel de la routine via CALL avec décodage de paramètre.

VG5000µ, les hooks de périphériques

2019-09-05T00:00:00+02:00

L'article précédent présentait un accrochage sur un hook d'interruption. Dans cet article, je vais regarder du côté des hooks de commandes de périphériques.

Ces hooks sont initialisés différements des 10 premiers, selon le code qui suit :

             ld       a,$c3
             ld       (inst_lpen),a
             ld       (inst_disk),a
             ld       (inst_modem),a
             ld       hl,no_device
             ld       ($47f2),hl
             ld       ($47f5),hl
             ld       ($47f8),hl

L'instruction placée au début de chaque vecteur de redirection est un JP et l'adresse par défaut est celle d'une routine indiquant que le périphérique n'est pas géré.

Il s'agit d'une extension de commandes mise à disposition par le VG5000µ, permettant de traiter les commandes LPEN, MODEM et DISK. Il est d'ailleurs amusant de voir que dans le manuel d'utilisation, ces trois commandes sont mentionnées dans le rappel des instructions reconnues, mais qu'elles ne sont pas décrites.

Dans la table des instructions, le décodage de ces tokens envoie directement sur chacun des trois vecteurs, sans traitement particulier. C'est donc du code de décodage de paramètres qu'il faut écrire si l'on veut traiter ces instructions.

Mise en place de la routine

Le code est similaire à celui de la mise en place de la routine sur l'interruption. Seule l'adresse du hook change.

    defc dskhk = $47f4  ; Adresse du hook

    org $7A00           ; Spécification de l'adresse mémoire d'implémentation

    push AF             ; Sauvegarde des registres sur la pile
    push HL

    ld A,$C3            ; Mise en place de la routine sur le HOOK
    ld (dskhk),A        ; Il y a normalement déjà un 'JP' ici, mais on s'en assure
    ld HL,cmd_routine
    ld (dskhk+1),HL     ; l'adresse de la routine


    pop HL              ; Restauration des registres depuis la pile
    pop AF

    ret                 ; Retour au programme appelant

cmd_routine:
    ret

Passons donc rapidement sur la partie la plus intéressante : le traitement de l'instruction.

Traitement de l'instruction

Lorsque l'interpréteur appelle la routine associée à une instruction, plusieurs choses sont mises en place. Les principales sont :

HL pointe vers la chaîne en train d'être interprétée, sur le prochain caractère à lire,
Le flag "Z" est à 1 si l'on est à la fin de la chaîne,
L'adresse de retour sur la pile est positionnée pour traiter l'instruction suivante.

Le contrat en sortie est :

HL doit pointer sur le caractère après le dernier consommé par l'instruction,
S'il s'agit d'une fonction, son résultat doit être dans l'accumulateur flottant (numérique, ou pointeur de chaîne).

Pour s'amuser avec le paramètre, je vais écrire le décodage d'un paramètre de type chaîne, qui sera ensuite affiché à l'écran, suivi par un message.

    defc type_eq_str = $2851
    defc read_expr = $2861
    defc out_str = $36aa
    defc out_str1 = $36ad

cmd_routine:
    push HL             ; Sauvegarde du pointeur d'exécution

    call read_expr      ; Lecture de l'expression suivant la commande
    ex (sp), hl         ; Remplacement de la valeur du pointeur d'exécution

    call type_eq_str    ; Vérification du type du paramètre
    call out_str1       ; Affichage de la chaîne

    ld hl, answer
    call out_str        ; Affichage du message de la commande

    pop HL              ; Récupération du pointeur d'exécution

    ret

answer:
    defm " <-- PARAM", $00

La structure est assez simple, car les routines nécessaires sont toutes disponibles dans la ROM.

Tout d'abord, on sauve le pointeur vers la chaîne interprétée. HL est actuellement sur le début du paramètre de DISK (en tout cas, ce qui suit).

L'appel à read_expr se charge de lire une expression valide (ou échouer avec une erreur). À la sortie de la routine, HL est positionné à la fin de ce qui a été consommé par l'expression.

Ce pointeur est celui qu'il faudra conserver pour l’interpréteur. Du coup, on échange la valeur précédente de HL actuellement sur la pile avec la nouvelle valeur. Hop, le tour est joué.

L'appel à type_eq_str vérifie si le type de l'expression est bien une chaîne, et affiche un message d'erreur sinon (et dans ce cas l'interprétation est arrêtée immédiatement).

Si c'est bien une chaîne, l'appel à out_str1 affiche le résultat de l'expression de type chaîne de caractères qui vient d'être évaluée.

L'appel à out_str qui suit affiche la chaîne terminée par un 0 définie dans le programme.

Et voilà, voir le résultat à la fin de l'article.

BASIC

Voici un programme BASIC pour charger et lancer la routine.

10 CLEAR 50,&"79FF"
20 S=&"7A00"
30 READ A$
40 IF A$="FIN" THEN END
50 A$="&"+CHR$(34)+A$+CHR$(34):A=VAL(A$)
60 POKE S,A
70 S=S+1
80 GOTO 30
300 DATA F5,E5,3E,C3,32,F4,47,21,10,7A,22,F5,47,E1,F1,C9,E5,CD,61,28
310 DATA E3,CD,51,28,CD,AD,36,21,23,7A,CD,AA,36,E1,C9,20,3C,2D,2D,20
320 DATA 50,41,52,41,4D,0
1000 DATA FIN
RUN
CALL &"7A00"

Pour éviter d'avoir à tout rentrer au clavier, voici le fichier .k7. À charger avec CLOAD, suivi d'un RUN et du CALL &"7A00".

Le résultat

VG5000µ, les hooks

2019-08-31T00:00:00+02:00

Pour cet article, nous allons laisser de côté la partie BASIC-80 pour regarder du côté d'un fonctionnement spécifique au VG5000µ. Pas que le principe soit original, il est présent dans de nombreuses machines, mais que les capacités sont diverses suivant les différentes machines.

Les « hooks » (la traduction de « crochet » me semble un peu hasardeuse, une « accroche » me semble un peu meilleur) est un moyen qu'offre le système pour intervenir lors de certaines opérations en augmentant le fonctionnement de la ROM. En y mettant son grain de sel en quelque sorte.

Plus prosaïquement, les « hooks » sont des appels à des adresses précises, en RAM, à des routines qui peuvent être modifiées. Il peut s'agir aussi sur d'autres machines de récupérer dans une variable système une adresse d'indirection. Sur le VG5000µ, toutes les adresses de « hooks » sont fixes.

Les « hooks » sont parfois aussi appelés vecteurs d'indirection. Ou bien tout simplement vecteurs.

L'initialisation des « hooks »

L'initialisation des « hooks » arrive très tôt dans l'initialisation de la machine, juste après la détection de la mémoire disponible.

             ld       a,$c9
             ld       hl,inthk
             ld       b,$1e

hk_ini_lop:  ld       (hl),a
             inc      hl
             djnz     hk_ini_lop

             ld       a,$c3
             ld       (inst_lpen),a
             ld       (inst_disk),a
             ld       (inst_modem),a
             ld       hl,no_device
             ld       ($47f2),hl
             ld       ($47f5),hl
             ld       ($47f8),hl
             ld       hl,resetlang
             ld       ($47ef),hl
             ld       (nmihk),a

A prend la valeur C9, qui est le code pour l'instruction RET sur Z80. HL est initialisé à inthk, qui est le premier hook d'une plage consécutive. Et B prend $1e, la taille de cette plage.

La première étape est de remplir cette plage avec des RET. Cette plage contient les 10 premiers hooks, que sont les suivants.

$47D0, inthk : interruption masquable
$47D3, calhk : vecteur CALL
$47D6, sonhk : vecteur de générateur de son
$47D9, plyhk : début de commande PLAY
$47DC, rsthk : vecteur pour l'instruction RST utilisateur
$47DF, prthk : début de commande PRINT
$47E2, outhk : début d'impression de caractère
$47E5, crdhk : début de retour chariot
$47E8, inlhk : début de lecture d'une ligne
$47EB, inphk : début de commande INPUT

Chaque hook fait 3 octets de long, nous verrons pourquoi plus loin. Et pour le moment tous remplis de RET. Un CALL à ces adresses ne fait donc rien d'autre que de revenir à l'appelant immédiatement.

A prend ensuite la valeur C3, qui, suivi d'une adresse sur deux octets, est un JP absolu à cette adresse. Les hooks lpnhk, dskhk et modhk sont remplis avec ce jp no_device, qui est un branchement vers l'erreur indiquant que le périphérique n'est pas géré.

Plus étonnant est la valeur que prend le hook nmihk, qui est appelé en cas d'interruption non masquable. Cette interruption est appelée lors de l'appui sur la touche Delta du VG5000µ. La routine resetlang met le système en anglais au niveau des messages et du clavier puis ressort de l'interruption. Et c'est tout.

À vrai dire, cela ne dure qu'un instant. Juste après, le VG5000µ initialise sa partie graphique puis remplace le hook par une nouvelle valeur :

             ld       hl,test_reset
             ld       ($47ef),hl

Cette nouvelle routine test_reset vérifie si la touche Ctrl est appuyée. Si ce n'est pas le cas, la routine sort immédiatement. Sinon, un reset à chaud a lieu.

Mise en place d'une routine

« Accrocher » une routine est assez facile, et demande juste quelques précautions. Afin de prendre un premier exemple, je vais accrocher une routine sur l'interruption qui provoque l'affichage sur le VG5000µ.

Rapidement, dans le VG5000µ, le processeur graphique est la cause d'une interruption INT à chaque rafraîchissement. C'est la seule raison, de base, qui provoque cette interruption.

Lors de l'interruption, le PC est branché en $0038 et la première instruction y est call inthk. On a donc une possibilité d'agir lors de l'interruption, avant que le rafraîchissement potentiel de l'écran n'ait lieu (il n'a pas lieu à chaque fois).

Le code nécessaire pour une routine de « hook » est en deux parties. La première se charge de modifier le branchement du « hook » vers notre routine. La seconde est la routine elle-même.

Commençons par la première partie. À noter que pour être propre, il faudrait effectuer un chaînage en faisant appeler à notre propre routine une routine éventuellement déjà installée. Je ne m'en occuperai pas ici.

    defc inthk = $47D0  ; Adresse du hook

    org $7A00           ; Spécification de l'adresse mémoire d'implémentation

    push AF             ; Sauvegarde des registres sur la pile
    push HL

    ld A,$C3            ; Mise en place de la routine sur le HOOK
    ld (inthk),A        ; le 'JP'
    ld HL,int_routine
    ld (inthk+1),HL     ; et l'adresse


    pop HL              ; Restauration des registres depuis la pile
    pop AF

    ret                 ; Retour au programme appelant

int_routine:
    ret

Le programme est directement commenté. Si depuis le BASIC, ce programme est injecté et appelé, alors... il ne se passera pas grand chose de visible, mais en réalité, le RET de int_routine sera appelé à chaque interruption.

Une routine plus intéressante

Pour rendre les choses plus intéressantes, voici une routine à installer qui affiche à l'écran une petite barre qui tourne.

    defc screen = $4000

int_routine:
    push AF             ; Sauvegarde de AF

    ld  A,(IX+$00)
    dec A
    jp nz, no_display   ; Respect du timer de rafraîchissement

    push HL             ; Sauvegarde de HL

    ld A,(count)        ; Compteur du caractère à afficher
    inc A
    cp A, $4            ; S'il est à la dernière position, on boucle
    jp nz, display
    ld A, $0

display:
    ld (count),A        ; Mise à jour du compteur

    ld HL,cursor        ; Récupération du caractère à afficher
    add A,L
    ld L,A
    ld A,(HL)

    ld HL,screen + 32   ; Affichage
    ld (HL), A

    ld (ix+$01),$01     ; Force le ré-affichage

    pop HL              ; Restauration des registres depuis la pile
no_display:
    pop AF

    ret

count:
    defb 0
cursor:
    defb $2F, $60, $5C, $7C     ; Les 4 caractères qui forment l'animation

Il faut veiller dans cette routine à bien préserver les registres utilisés, nous sommes ici en pleine interruption, nous n'avons aucune connaissance du contexte.

La lecture de la variable système à travers le registre IX permet de savoir si le système va considérer un rafraîchissement de l'affichage. La commande DISPLAY du BASIC influe directement sur une valeur de compteur qui, lorsqu'il arrive à zéro, provoque éventuellement un affichage avant de revenir à sa valeur spécifiée.

L'affichage n'est cependant pas systématique. Le bit 0 de la variable système qui suit le compteur doit être à 1 pour que l'affichage est vraiment lieu. Et l'on trouve parsemé dans la ROM des ld (ix+$01),$01 qui signifient qu'un rafraîchissement de l'écran est demandé. Ce que je fais à la fin de la routine.

La partie après PUSH HL est un bête compteur cyclique de 0 à 3, qui est ensuite utilisé pour pointer dans un tableau de 4 caractères provoquant l'animation.

L'adresse écran est calculé en dur et on y place directement le caractère. Puis le contexte est restauré.

Une dernière note pour comprendre l'affichage du VG5000µ dans sa ROM BASIC. La ROM maintient en $4000 une image logique du contenu de l'écran, et un ensemble de variables systèmes, pointées en tout temps par IX. Lorsqu'un rafraîchissement à lieu, tout ce contenu est envoyé vers le processeur graphique pour une grande (et lente !) mise à jour.

Il se peut donc que des modifications aient lieu en mémoire graphique côté processeur qui ne soient pas répercutées tout de suite vers le processeur graphique.

Mais tout ceci est une autre histoire qui n'est pas le sujet ici.

Le test

Voici un programme BASIC qui va monter la routine en mémoire. Suivi d'un RUN pour l'exécuter puis du CALL pour lancer le hook.

10 CLEAR 50,&"79FF"
20 S=&"7A00"
30 READ A$
40 IF A$="FIN" THEN END
50 A$="&"+CHR$(34)+A$+CHR$(34):A=VAL(A$)
60 POKE S,A
70 S=S+1
80 GOTO 30
300 DATA F5,C5,D5,E5,3E,C3,32,D0,47,21,14,7A,22,D1,47,E1,D1,C1,F1,C9
310 DATA F5,DD,7E,0,3D,C2,3A,7A,E5,3A,3C,7A,3C,FE,4,C2,28,7A,3E,0
320 DATA 32,3C,7A,21,3D,7A,85,6F,7E,21,20,40,77,DD,CB,1,C6,E1,F1,C9
330 DATA 0,2F,60,5C,7C
1000 DATA FIN
RUN
CALL &"7A00"

Pour éviter d'avoir à tout rentrer au clavier, voici le fichier .k7. À charger avec CLOAD, suivi d'un RUN et du CALL &"7A00".

La suite

Nous avons vu un exemple de mise en place de routine sur un « hook » du VG5000µ. Dans les articles suivant, j'irai examiner les autres « hook » et dans quels contextes ils sont appelés.

VG5000µ, les chaînes de caractères

2019-08-22T00:00:00+02:00

Dans l'article précédent, on avait vu la création d'une variable dans la zone principale de la mémoire. Cette variable a par défaut un contenu nul, et ne s'occupe pas de savoir si ce contenu est un nombre ou une chaîne de caractères. Les quatre octets de contenus qui suivent les deux octets du nom sont donc tous les quatre à $00.

Pour qu'une valeur soit associée à une variable, il faut une instruction d'assignation, directement via LET (éventuellement de manière implicite), plus indirectement avec une instruction FOR, ou encore plus indirectement par un couple READ/DATA.

Dans tous les cas, la valeur à assigner à la variable est le résultat de l'évaluation d'une expression, c'est-à-dire le résultat d'un calcul numérique ou d'une opération à partir de chaînes.

Afin de comprendre comment sont créées et stockées les chaînes de caractères, c'est donc du côté de l'évaluation d'expression qu'il faut commencer.

Évaluation d'expression

L'évaluation d'une expression commence en $2861 et nous n'allons pas nous y attarder. Nous suivons la piste immédiatement vers la routine de lecture d'une valeur depuis le buffer d'entrée. Cette routine se situe en $28d8 et commence comme suit :

parse_value: xor      a,a
             ld       (valtyp),a

             rst      chget

             jp       z,missing_op
             jp       c,str_to_num

             cp       a,'&'
             jp       z,str_hex_dec

             call     a_to_z_2
             jr       nc,str_to_var

             cp       a,'+'
             jr       z,parse_value

             cp       a,'.'
             jp       z,str_to_num

             cp       a,'-'
             jr       z,str_to_min

             cp       a,'"'
             jp       z,str_to_str

             cp       a,$b7 ; 'NOT'
             jp       z,str_to_not

             cp       a,$b4 ; 'FN'
             jp       z,str_to_fn

             sub      a,$c3 ; 'SGN'
             jr       nc,str_to_func

Voici toute une série de tests pour déterminer ce que contient l'opérande pointée actuellement par HL.

On remarque au tout début que la valeur par défaut de l'expression en cours est mis à 0 (c'est-à-dire : valeur numérique).

Puis le premier caractère est lu et la suite de tests ressemble à ceci :

Est-ce qu'on est à la fin de la ligne ? Alors il manque quelque chose...
Est-ce que c'est un chiffre ? Alors on commence à convertir l'entrée en nombre
Est-ce que ça commence par & ? Alors on commence à décoder un nombre hexa
Est-ce que c'est une lettre ? Alors on va lire une variable
Est-ce que c'est un '+' ? On l'ignore et on boucle un caractère plus loin
Est-ce que c'est un '.' ? Alors on commence à convertir l'entrée en nombre
Est-ce que c'est un '-' ? Alors on démarre une sous-expression qui sera inversée
Est-ce que c'est un '"' ? Alors on décode une chaîne !
Etc... (les trois derniers cas sont pour NOT, une fonction utilisateur, ou une fonction prédéfinie, puis on continue avec le traitement des parenthèses)

D'après cette liste, on part donc vers str_to_str.

Les chaînes à la chaîne

Arrivée dans str_to_str, on a HLqui pointe vers une chaîne qui commence avec des guillemets. La première étape va être de chercher la fin de la chaîne et de compter le nombre de caractères.

str_to_str:  ld       b,'"'

             ld       d,b
direct_str:  push     hl

             ld       c,$ff
loop_str:    inc      hl
             ld       a,(hl)
             inc      c

             or       a,a
             jr       z,create_str
             cp       a,d
             jr       z,create_str
             cp       a,b
             jr       nz,loop_str

create_str:  cp       a,'"'
             call     z,skipch

             ex       (sp),hl
             inc      hl
             ex       de,hl

             ld       a,c

Cette routine commence par placer le caractère guillemets dans les registres B et D. Les caractères présents dans B et D sont des terminateurs potentiels. Cette routine est en effet appelée par un autre chemin directement en direct_str avec d'autres terminateurs possibles.

Note : ces autres terminateurs possibles sont : et ',' dans le cas où la chaîne est lue par une instruction READ depuis une séquence de DATA.

La suite du préambule de la routine se fait en poussant sur la pile le pointeur sur la ligne en exécution et en initialisant C avec -1. C est le compteur de caractères. Au passage, on peut en déduire que les chaînes de caractères auront donc comme longueur maximale 255.

Puis débute la boucle loop_str, qui commence par avancer le pointeur HL sur le caractère suivant, récupère la valeur de ce caractère dans A et incrémente le nombre de caractères.

Le premier test vérifie si A est nul. Si c'est le cas, on a atteint la fin de la chaîne et il est temps de la créer. De même que si le caractère est égal à l'un des deux terminateurs. Dans le cas contraire, la boucle est bouclée et le caractère suivant traité.

Note : mais et s'il y a plus de 255 caractères avant de trouver un terminateur ? Ça ne se passe pas très bien... Il n'y a pas de tests et vous pouvez vérifier (c'est un peu long) qu'il peut se passer des choses étranges.

Avant de créer la chaîne, il faut mettre les choses en place. Si le dernier caractère sont des guillemets, une routine va les consommer et ignorer tout ce qui est inintéressant, pour recaler HL sur la prochaine valeur ou instruction.

Ce pointeur est échangé avec le haut de la pile, qui contenait le début de la chaîne. Ce début de chaîne est avancé de 1 pour ignorer les premier guillemets (le chemin READ s'arrange pour mettre HL au bon endroit en sachant qu'il sera incrémenté ici).

Puis le pointeur de début de chaîne est transféré dans DE et le nombre de caractères lus dans A.

Création de la chaîne temporaire

À présent que l'on sait où est la chaîne (pointée par DE) et combien de caractères elle contient, l'étape suivant consiste à l'extraire dans un endroit où l'évaluation de l'expression ou l'assignation pourra la trouver.

             call     crt_tmp_str
cpy_to_pool: ld       de,dsctmp

             ld       hl,(temppt)
             ld       (faclo),hl

             ld       a,$01
             ld       (valtyp),a

             call     cpy_detohl_4
             rst      de_compare

             ld       (temppt),hl
             pop      hl
             ld       a,(hl)
             ret      nz

             ld       de,$001e
             jp       error_out

Tout commence par un appel à crt_str_dsc qui créé un descripteur temporaire de chaîne à l'adresse dsctmp ($499b). Dans ce buffer qui sert aux opérations sur les chaînes, la routine placera en premier octet la taille de la chaîne, puis rien de spécial, puis la valeur de 'DE' sur les deux derniers octets.

Les descripteurs de chaînes font donc 4 octets, dont le deuxième est inutilisé.

Puis, DE prend la valeur de dsctmp, le buffer temporaire qui vient d'être initialisé, et HL la valeur contenue dans la variable système temppt. Ce pointeur est initialisé par le BASIC vers le buffer tempst, qui est un buffer de 120 octets réservé.

Ce pointeur est placé dans l'accumulateur flottant, qui maintient en fait toute valeur courante d'une expression, qu'elle soit numérique (lorsque (valtyp) vaut 0) ou chaîne (lorsque (valtyp) vaut 1).

Et d'ailleurs, (valtyp) passe à 1 pour indiquer la nature du contenu de l'accumulateur flottant.

L'appel suivant est une routine qui copie 4 octets pointés par DE vers ce qui est pointé par HL. Autrement dit, le descripteur de chaîne qui vient d'être créé est copié vers le buffer temporaire pointé par HL.

Comme dsctmp est placé astucieusement après le buffer tempst, si jamais, après copie, HL est égal DE, alors c'est qu'on a atteint la fin de l'espace de travail, une erreur est latente, traitée un peu plus loin. Comme 120 (la taille du buffer) est divisible par 4 (la taille des descripteurs) on est assuré de tomber juste, et que HL ne dépasse jamais DE.

En attendant de traiter l'erreur, il s'agit de mettre les choses en ordre. La variable système (temppt) est mise à jour avec la nouvelle valeur de HL, puis on récupère le pointeur sur la ligne depuis la pile, et le caractère pointé par HL est placé dans A, tout est prêt pour continuer le décodage.

Enfin, on sort de la routine si la dernière comparaison n'était pas nulle (il reste de la place dans le buffer temporaire) ou bien on saute vers une erreur indiquant à l'utilisateur que l'opération sur les chaînes de caractères était trop complexe.

Note : il existe 30 emplacements de descripteurs de chaîne dans le buffer temporaire avant que la routine ne laisse tomber avec un message d'erreur. En sachant qu'une expression comme PRINT "ABC" + "CDE" + "DEF" en consomme 2, ça laisse de la marge...

Association de la variable

Pour l'association de la variable avec sa valeur, voyons le cas de l'instruction LET (qui est de toute façon appelée par FOR et READ).

Passons rapidement sur le début de l'instruction LET qui récupère l'adresse de la variable à gauche du signe égal selon la méthode décrite dans l'article précédent, appel l'évaluation de ce qui est à droite du signe égal, et vérifie que les types sont cohérents des deux côtés (soit numérique, soit chaîne de caractères).

Une fois tout ceci en place, l'association de la chaîne elle-même a lieu :

let_string:  push     hl
             ld       hl,(faclo)
             push     hl
             inc      hl
             inc      hl
             ld       e,(hl)
             inc      hl
             ld       d,(hl)

             ld       hl,(txttab)
             rst      de_compare
             jr       nc,crtstrentry

             ld       hl,(strend)
             rst      de_compare
             pop      de
             jr       nc,pop_string

             ld       hl,dsctmp
             rst      de_compare
             jr       nc,pop_string

             defb     $3e
crtstrentry: pop      de
             call     bc_from_tmp
             ex       de,hl
             call     save_str
pop_string:  call     bc_from_tmp
             pop      hl
             call     cpy_detohl_4
             pop      hl
             ret

En début de routine, HL pointe vers la variable à gauche du signe =, on sauve cette adresse sur la pile pour plus tard.

Puis on récupère dans HL la valeur de la dernière expression évaluée, qui est dans l'accumulateur flottant. On pousse aussi cette valeur sur la pile et on va chercher deux octets plus loin le pointeur vers la chaîne de caractère elle-même, qui est placée dans DE.

À présent, il s'agit de savoir où sont situés ces octets de chaînes. Le premier cas est une comparaison avec (txttab). Si les caractères sont avant, c'est qu'ils sont dans les variables systèmes, et donc dans un endroit volatile, il va donc falloir les copier ailleurs et c'est ce que va faire le saut en crtstrentry.

Note : si vous vous amusez avec les pointeurs de zones mémoire du BASIC pour déplacer le contenu du code, gardez en tête que pour le BASIC, une chaîne située avant le code est volatile.

Le second test vérifie si la chaîne se situe avant (strend). Si c'est le cas, c'est que la chaîne se trouve dans le programme.

Note : en toute rigueur, la comparaison aurait du être faite avec (vartab), car il n'y a pas de contenu de chaînes entre (vartab) et (strend). En regardant d'autres dérivés du BASIC-80, je pense qu'il s'agit d'une adaptation un peu hâtive, car d'autres BASIC-80 semblent placer leurs chaînes différemment. Même si le pointeur de comparaison n'est pas exactement le bon, le test fonctionne néanmoins, et ce n'est pas plus lent.

Si la chaîne se trouve dans le programme, on va pouvoir conserver ce pointeur sans dupliquer les octets ailleurs. En effet, un programme n'est pas volatile et le moindre changement dans le listing efface toutes les variables. On est donc assuré que les chaînes de caractères présentes dans le programme lorsque celui-ci tourne restent en place.

Note : cela donne quelques contraintes si vous vous amusez à modifier le listing en cours de route depuis le programme qui tourne...

Le troisième test, enfin, vérifie si le contenu de la chaîne ne serait pas par hasard dans un autre buffer temporaire, celui où l'on met le descripteur temporaire (et qui se situe juste avant dsctmp)

Note : ce troisième test est étrange. Ce buffer est situé dans les variables système et donc est déjà avant le code BASIC. Je ne vois donc pas comment on peut arriver ici. Je pense que c'est un reliquat d’adaptation du BASIC-80 où le buffer temporaire se situe après le code BASIC.

Le defb $3e est un instruction morte permettant d'éviter l'exécution du POP DE qui suit. En effet, ce POP DE pour récupérer le pointeur sur le descripteur de chaîne a déjà été fait lorsqu'on arrive par là.

crtstrentry replace le pointeur HL sur les informations de la chaîne temporaire la plus récente (la plus en haut du buffer temporaire), puis cette adresse et échangée avec celle tenue dans DE qui est aussi le pointeur vers ce même descripteur.

Note : ici, je ne sais pas dans quel cas HL et DE peuvent être différent. L'idée est d'enlever le descripteur de chaîne du buffer temporaire en ajustant le pointeur sur ce buffer (temppt), le buffer temporaire étant manipulé comme une pile, la routine bc_from_tmp est en quelque sorte le pop de cette pile, dont la valeur part dans BC, mais avec une sécurité. Si le pointeur HL n'est pas celui qui était attendu DE alors le pop n'a pas lieu, c'est juste une récupération de la valeur en haut de la pile.

Avec les informations récupérées, un appel à save_str est effectué, et nous verrons ça juste après.

Dans tous les cas, la description de chaîne la plus récente du buffer temporaire est à nouveau récupérée, l'adresse de la variable popée de la pile dans HL et le descripteur temporaire copié vers la valeur de cette variable.

Après une remise en ordre de la pile, on rend la main, la variable est maintenant associée à la valeur de la chaîne.

Et la création ?

Dans le cas où la chaîne de caractères doit être sauvée quelque part, alors un appel à save_str est fait.

save_str se situe en $3646 et est comme suit :

save_str:    ld       a,(hl)
             inc      hl
             inc      hl
             push     hl

             call     alloc_str_mem

             pop      hl

             ld       c,(hl)
             inc      hl
             ld       b,(hl)

             call     crt_str_dsc

             push     hl
             ld       l,a
             call     copy_str
             pop      de

             ret

En entrée, HL pointe vers un descripteur de variable de type chaîne. Le premier des 4 octets contient donc le nombre de caractères, qui est récupéré dans A. Puis HL est positionné sur le premier octet de l'adresse du contenu et cette adresse est poussée sur la pile.

L'appel à alloc_str_mem vérifie ensuite s'il reste assez de place dans la mémoire dédiée aux chaînes pour ajouter A octets.

Si la routine de vérification ressort, c'est qu'il y a de la place (une erreur aurait été immédiatement émise sinon) et une chaîne de A caractères a été allouée, (fretop) ajusté, et DE pointe vers cette nouvelle allocation.

On récupère alors HL pour obtenir dans BC l'adresse actuelle du contenu de la chaîne.

Un appel à crt_str_dsc crée une nouveau descripteur dans le buffer temporaire avec DE comme pointeur de contenu.

Puis copy_str est appelé après avoir sauvé le pointeur vers le nouveau descripteur dans la pile et mis la taille de la chaîne dans L.

Je ne copie pas le code de copy_str ici. Il est extrêmement simple et copie L caractères de la zone pointée par BC vers la zone pointée par DE. Autrement dit, de la chaîne source vers l'emplacement nouvellement alloué.

Au retour, DE prend la valeur du nouveau descripteur de chaîne, qui est actuellement dans le buffer temporaire et sera récupéré par la fin de la routine de l'instruction LET.

Ouf!

Ramasse miettes

En fait... ce n'est pas tout à fait complet. Lors de la tentative d'allocation de chaîne alloc_str_mem, s'il n'y a plus de place dans la mémoire dédiée, un ramasse miettes est lancé (garbage collection). Cette routine va compacter la mémoire des chaînes de caractères en comblant les trous des données qui ne sont plus valides, d'anciennes valeurs de chaînes qui ne sont plus pointées par aucune variable.

C'est un gros morceau qui doit parcourir les variables mais aussi les tableaux, je laisse ça de côté (pour le moment ?).

À la fin de cette routine, l'allocation est tentée à nouveau. Si lors de cette nouvelle tentative, il n'y a toujours pas assez de mémoire, alors l'erreur est vraiment lancée.

Un peu de BASIC

C'est un peu la tradition de ces articles, voyons maintenant un programme en BASIC qui affiche la valeur des variables. Puisque toutes les variables sont effacées au démarrage d'un programme, il est nécessaire d'en initialiser dans le programme.

10 DEFFNPK(P)=PEEK(P+1)*256+PEEK(P)
20 PRINT"1":A$="ABC"
30 GOSUB 1000
40 PRINT"2":B$="DEF"
50 GOSUB 1000
60 PRINT"3":A$=""
70 GOSUB 1000
100 END
1000 VT=FNPK(&"49D8")
1010 AT=FNPK(&"49DA")
1020 FOR PT=VT TO AT-1 STEP 6
1030 T1=PEEK(PT)
1040 T2=PEEK(PT+1)
1050 IF (T2 AND 128)=0 THEN 1100
1060 PRINT CHR$(T1 AND 127);
1070 PRINT CHR$(t2 AND 127);
1080 PRINT "$="+CHR$(34);
1090 GOSUB 2000:PRINT CHR$(34)
1100 NEXT PT
1200 RETURN

2000 V=FNPK(PT+4)
2000 C=PEEK(PT+2)
2010 IF C=0 THEN RETURN
2020 V=FNPK(PT+4)
2030 FOR I=1 to C
2040 PRINT CHR$(PEEK(V+I-1));
2050 NEXT I
2060 RETURN

Va afficher

1
A$="ABC"
2
A$="ABC"
B$="DEF"
3
B$="DEF"

La partie du programme entre 10 et 100 s'occupe de manipuler des variables et d'appeler l'affichage de leur contenu.

La partie entre 1000 et 1200 regarde la liste des variables comme dans l'article précédent, mais ne sélectionne que celles de types chaînes de caractères.

La partie à partir de 2000 va chercher le nombre de caractères et le pointeur vers les données pour afficher le tout, caractère par caractère.

VG5000µ, les variables en mémoire

2019-08-22T00:00:00+02:00

Pour terminer cette série sur la gestion de la mémoire par le BASIC sur VG5000µ, j'aborde la manière dont sont stockées les variables en mémoire.

Les variables systèmes

On l'a vu dans l'article sur la cartographie de la mémoire, il y a six variables systèmes intéressantes sur ce sujet :

(vartab) est la première adresse d'une variable. C'est ici que sont stockés les noms des variables numériques (avec leur valeur) ou chaînes (avec un pointeur vers leur contenu),
(arytab) est la première adresse de stockage du contenu des tableaux dimensionnés par DIM (ou bien les tableaux crées par défaut par le BASIC avec un DIM implicite), avec leur nom, leur taille, et leur contenu (ou pointeurs),
(strend) est la première adresse de la zone libre de stockage, tout ce qu'il y a à partir de cette adresse et « au-dessus » jusqu'à la pile (pointée par le registre SP) est la mémoire BASIC « libre » (ce qui n'est pas tout à fait vrai puisque la mémoire pour les chaînes de caractères est séparée).
(stktop) est le haut de la pile, l'adresse un octet au-dessus est la première adresse de la zone réservée pour les chaînes de caractères.
(fretop) est le pointeur de la zone libre pour les chaînes de caractères. L'adresse juste au-dessus contient le début des données de chaînes de caractères,
(memsiz) est l'adresse la plus haute adressable par le BASIC, et aussi le haut de l'espace réservée aux chaînes de caractères (inclus).

Une première constatation est qu'il y a deux mémoires réservées au BASIC, disjointes. La première est celle qui contiendra tous les noms des variables et les contenus numériques. La place restante de cette zone est donnée par la fonction FRE(0) (la valeur du paramètre importe peu, seul son type importe).

La seconde est celle qui contiendra tout le contenu des chaînes de caractères, dans des variables ou dans des tableaux. L'espace restant dans cette zone est donné par la fonction FRE(" ") (la encore, seul le type du paramètre compte). L'espace est fixe, de 50 octets au démarrage de la machine, et déterminé par le premier paramètre de la commande CLEAR. Faire un CLEAR 0 est tout à fait possible, mais alors vous ne pourrez plus stocker de chaîne de caractères.

Création d'une variable

Aparté sur la commande `LET`

Dans le BASIC tel qu'il a été créé à l'université de Dartmouth, chaque ligne doit contenir une commande et une seule. La définition et l'assignation d'une variable se font avec la commande LET. Cette obligation de commande a un avantage sur l'analyse du programme BASIC par un compilateur ou un interpréteur : s'il n'y a pas de commande, c'est une erreur de syntaxe, et il n'y a pas d'exception.

Le BASIC de Microsoft a relaxé cette obligation en rendant la commande LET optionnelle, et cette exception a été conservée par de nombreux BASIC par la suite. Mais pas partout, sur un ZX81 par exemple, chaque nouvelle ligne demande d'entrer une instruction via la touche du clavier correspondante, et le LET est obligatoire.

Lorsque l'instruction LET est optionnelle, le décodage du BASIC lors de la tokénisation est plus complexe : il faut vérifier que ce qui est trouvé sur la ligne ne correspond à aucune instruction et dans ce cas-ci, faire comme si une instruction LET était présente. C'est du code en plus pris dans la ROM.

Avant tout, que cherche-t-on ?

Lorsque BASIC rencontre une variable, il lui faut toujours en premier lieu vérifier son existence. En effet, la première assignation de valeur à une variable vaut création avec une valeur par défaut.

Et pour savoir si cette variable existe, il faut en connaître le nom. C'est la première partie de la routine qui se trouve en $38da.

getvar:      xor      a,a

             ld       (dimflg),a
             ld       c,(hl)
get_id:      call     a_to_z
             jp       c,stx_err_prt

             xor      a,a
             ld       b,a
             ld       (valtyp),a

             rst      chget
             jr       c,idnum_trail
             call     a_to_z_2
             jr       c,id_end

idnum_trail: ld       b,a
idtrail_skp: rst      chget
             jr       c,idtrail_skp

             call     a_to_z_2
             jr       nc,idtrail_skp

id_end:      sub      a,$24
             jr       nz,num_vrble

             inc      a
             ld       (valtyp),a
             rrca
             add      a,b
             ld       b,a
             rst      chget
num_vrble:   ld       a,(subflg)

En premier lieu, (dimflg) est mis à zéro. Cette variable sert lorsque l'on manipule un tableau. Comme on n'a pas encore cette information, la routine part sur du non tableau.

Note : il se peut que A soit différent de 0, lorsque l'on arrive par l'instruction DIM, qui saute par-dessus le XOR A,A, mais laissons ça de côté, le fonctionnement de DIM est de l'acrobatie en assembleur Z80...

HL pointe, comme souvent lors de décodage d'une ligne, sur l'emplacement de la ligne en cours d'exécution. Si on est arrivé ici, c'est que l'on s'attend à trouver un nom de variable à cet endroit. Le premier caractère est donc lu dans C, puis il est vérifié que ce caractère est une lettre. En effet, chaque identifiant doit commencer par une lettre.

Si ce n'est pas le cas, un saut vers le traitement d'une erreur de syntaxe est fait immédiatement.

Donc le cas contraire, tout comme la routine s'initialise dans un mode non tableau, elle part du principe que la variable est numérique. On place donc 0 dans (valtyp), dans lequel est tenu à jour en tout temps le type de l'expression en cours. 0 dans (valtyp) signifie numérique.

Par RST CHGET, un potentiel second caractère pour le nom de la variable est lu. Cette routine chget renvoie le caractère lu dans A et l'accompagne de quelques informations. Si le flag Carry est à 1, cela signifie que le caractère est un chiffre. La routine en profite pour traiter ce cas en sautant plus loin, un chiffre en deuxième caractère est valide.

Si ce n'était pas un chiffre, on vérifie que c'est une lettre. Note au passage : la première fonction A_TO_Z lit un caractère depuis ce que pointe HL, A_TO_Z_2 fait la même vérification mais depuis le caractère déjà présent dans A.

Si ce second caractère n'est pas une lettre, alors on doit avoir le nom de l'identifiant, on passe à la suite en id_end.

Le LD B,A sauve le second caractère de la variable s'il existe. B avait été initialisé à 0 peut avant.

Entre idtrail_skp et id_end (exclu), une boucle saute tous les caractères qui sont soit des chiffres, soit des lettres. En effet, il est tout à fait valide d'avoir des noms de variables plus long que deux caractères. Même si les caractères surnuméraires sont ignorés.

Arrivé en id_end, on vérifie le dernier caractère lu. Est-ce un $, si non, on saute plus loin en num_vrble, la variable est bien numérique. Dans le cas contraire, 1 est mis dans (valtyp) pour désigner un type chaîne de caractères.

Puis le second caractère de la variable, qui avait été sauvé dans B est augmenté de $80 (A égal à 1 après RCCA vaut $80). C'est comme cela que les variables de types chaînes de caractères sont identifiées : le second octet de leur nom a le bit 7 à 1.

Lorsque l'on arrive dans num_vrble, on a dans C le premier caractère de la variable, dans B le second caractère de la variable, porteur de l'information de type chaîne, et (valtyp) qui contient aussi le type de la variable.

Aparté sur les noms de variables longs

Dans le BASIC original, la simplicité voulu par le langage avait amené les auteurs à ne permette des noms de variables qu'à une seule lettre, éventuellement suivie par un chiffre. Plus tard, les variables de type chaînes ont été ajoutées, et le nombre de caractères étendus.

Dans le monde de la micro-informatique 8 bits, il n'y a pas beaucoup de place en RAM, et cette limite est soit conservée, soit relaxée par l'intermédiaire du système permissif des noms longs, dont seuls les premiers caractères sont significatifs.

Sur VG5000µ, ce sont les deux premiers caractères qui comptent. D'ailleurs, tous les noms de variable en interne ont deux caractères, le second caractère étant éventuellement égal à $00.

Je trouve cette idée de caractères significatifs désastreuse. Si elle part de l'idée que l'on peut utiliser des noms de variables plus expressifs, elle n'en n'offre pas les moyens, car absolument aucun test n'est fait sur ces caractères supplémentaires. D'expérience, il est facile, dans un programme un peu long, de ne plus faire attention au fait que deux noms longs possèdent les deux mêmes premiers caractères.

Et si l'on y fait attention, il faut alors trouver un autre nom pour éviter la collision, et ce nom perd souvent en signification claire, et par la même perd l'intérêt des noms longs.

Pour qui est-ce ?

Il existe quelques contraintes sur les variables, et c'est dans l'aiguillage suivant qu'elles sont traitées.

num_vrble:   ld       a,(subflg)
             dec      a
             jp       z,aryvar

             jp       p,simplevar


             ld       a,(hl)
             sub      a,' ('
             jp       z,subscript

simplevar:   xor      a,a

La variable système (subflg) sert à plusieurs choses. Ici, elle donne une indication sur une contrainte au niveau de la variable attendue. Si (subflg) est à 1, c'est que l'on s'attend à un tableau, le branchement est alors vers la recherche d'une variable tableau.

Si (subflg) est supérieur à 1, alors c'est que les tableaux sont interdits, on saute donc vers simplevar. Les deux cas d'interdictions sont la variable d'index d'un FOR et la variable paramètre d'une fonction DEFFN.

S'il n'y a pas de contrainte sur cette variable, mais que l'on trouve une parenthèse ouvrante à la suite de la variable, alors c'est qu'il y a un index, et l'on va vers cette routine.

Et dans le cas contraire, il s'agit d'une variable simple. Ouf!

Dans le cas simple

Comme cet article va être assez long comme ça, on traitera les tableaux une autre fois. À présent que l'on sait que l'on a affaire à une variable simple (pas un tableau), que l'on a son nom et son type, il est grand temps de vérifier si elle existe !

La première partie de cette recherche consiste à initialiser le domaine de recherche et... de vérifier si par hasard on ne serait pas en train d'évaluer une fonction DEFFN.

simplevar:   xor      a,a
             ld       (subflg),a
             push     hl

             ld       d,b
             ld       e,c

             ld       hl,(prmnam)
             rst      de_compare
             ld       de,prmval
             jp       z,pop_hl_ret

             ld       hl,(arytab)
             ex       de,hl
             ld       hl,(vartab)

Tout d'abord, (subflg) est remis à 0. Le contexte a bien été traité et ne doit plus l'être. Puis le PUSH HL sert à sauver le pointeur vers la ligne tokenisée en court.

Le nom de la variable, présente dans BC est placée dans DE pour utiliser la comparaison entre DE et HL.

HL prend la valeur de la variable système (prmnam) (parameter name), qui contient, s'il y a lieu, le nom de la variable qui sert de paramètre à une fonction DEFFN en train d'être évaluée.

Si la variable que l'on cherche est celle du paramètre d'une fonction que l'on est en train d'évaluer, il faut la traiter spécialement, car le nom de cette variable ne doit pas affecter une variable du même nom hors de la fonction.

Le traitement spécial consiste à, si DE et HL sont égaux, sortir immédiatement de la routine de recherche, en faisant pointer DE sur la variable système prmval. Ce buffer de 4 octets contient la valeur actuelle du paramètre de la fonction, et DE est le pointeur que renvoie la routine de recherche de variable pour identifier la valeur cherchée.

Dans le cas d'une recherche générique, DE est initialisé avec (arytab) et HL avec (vartab), les deux bornes de la mémoire contenant les variables simples.

Cette fois on cherche !

Ça y est, après tous ces préparatifs, on arrive au point de la recherche de la variable dans la mémoire ! Et pour cela, la routine va dérouler une boucle qui va cherche parmi tous les variables existantes une dont le nom correspond.

next_var:    rst      de_compare
             jp       z,no_var_yet

             ld       a,c
             sub      a,(hl)

             inc      hl
             jp       nz,var_diff

             ld       a,b
             sub      a,(hl)
var_diff:    inc      hl
             jp       z,var_found

             inc      hl
             inc      hl
             inc      hl
             inc      hl
             jp       next_var

En début de boucle, une comparaison entre HL et DE est faite. Si les deux sont égaux, c'est qu'on a fini la recherche. En effet, tout au long de la boucle, HL, parti de (vartab), va être incrémenté. DE représente la limite haute, qui ne bouge pas.

Si la recherche est terminée sans avoir trouvé la variable, alors on saute en no_var_yet, il va falloir la créer. En effet, tout accès à une variable en BASIC induit sa création si elle n'existe pas encore.

En se souvenant que BC contient le nom de la variable inversé, le premier caractère, dans C est soustrait de celui pointé par HL. S'ils sont différents, c'est qu'on n'a pas trouvé la variable pour le moment, on saute plus loin.

Si le premier caractère correspond, on fait le même test avec le second caractère. Si ces deux tests passent, alors on a trouvé le nom, on saute en var_found.

Sinon, on saute les quatre octets suivants, qui contiennent la valeur de la variable, et on boucle.

Note : comme le nom de la variable en interne est modifié en fonction de son type, cette recherche montre bien que les variables A et A$ sont deux variables différentes. De même que les fonctions, que l'on n'a fait qu'effleurer. Dans la cas d'une fonction définition par DEF FN A(...), c'est le premier des deux octets qui porte un bit 7 à 1, et qui défini donc une troisième espace de nom.

Le cas où les deux octets aurait un bit 7 à 1 pourrait définir une fonction sur des chaînes de caractères. Mais ce cas n'est pas permis par le BASIC sur VG5000µ.

Création de la variable

De la section précédente, on peut sortir soit en ayant trouvé la variable, soit en ne l'ayant pas trouvé. Si la variable n'est pas trouvé, il faut la créer et l'initialiser puis enchaîner sur la section où la variable est trouvée... si elle a pu être créée bien entendu.

Comme c'est assez long, voyons ça en plusieurs partie. Tout d'abord, la création elle-même, avec un petit plot twist.

no_var_yet:  pop      hl
             ex       (sp),hl

             push     de
             ld       de,from_eval
             rst      de_compare
             pop      de
             jp       z,ret_null

             ex       (sp),hl
             push     hl

             push     bc
             ld       bc,$0006
             ld       hl,(strend)
             push     hl
             add      hl,bc

             pop      bc
             push     hl
             call     mem_move_ckk
             pop      hl

             ld       (strend),hl
             ld       h,b
             ld       l,c
             ld       (arytab),hl

Tout d'abord, on récupère le pointeur sur la ligne évaluée qui était depuis la pile et on l'échange avec la valeur actuellement en haut de la pile. C'est un pas de danse assez classique en Z80 qui permet d'aller récupérer la valeur en deuxième position sur la pile.

Puis on sauve la valeur de DE (qui contient (arytab)) avant d'y mettre une valeur spécifique : l'adresse d'une instruction de retour après un CALL particulier. Cette adresse est le chemin que prend l'appel à la récupération d'une variable lors de l'évaluation d'une expression.

Si on vient de là, alors c'est un cas spécifique, et on saute à la section ret_null qui est un raccourci qui renvoie directement la valeur nulle à l'appelant. Et tout ceci sans créer de variable ! Après tout, pourquoi créer une variable qui a sa valeur par défaut ? Nous verrons ret_null plus loin.

Dans le cas où l'on ne vient par d'une évaluation, alors l'adresse de retour est remise à sa place sur la pile et on y repousse le pointeur sur la ligne exécutée.

Il s'agit maintenant de vérifier s'il y a de la place en mémoire pour créer la variable. Une variable a besoin de 6 octets en mémoire, et c'est donc avec 6 qu'est initialisé BC (après avoir été sauvé sur la pile, car BC contenait une information importante : le nom de la variable).

Ici, il faut suivre... HL est initialisé avec (strend), c'est-à-dire la première adresse libre en mémoire principale et on lui ajoute 6 via BC. Au passage, sur la pile est poussé (strend), qui est récupéré dans BC, puis l'adresse (strend) + 6 est poussée sur la pile.

On résume, par ordre croissant, on a :

Dans DE se trouve (arytab)
Dans BC se trouve (strend)
Dans HL se trouve (strend) + 6

Sur la pile on a (strend) + 6 en première position de POP.

Tout est prêt pour appeler mem_move_chk qui va déplacer la zone comprise entre DE et BC, c'est-à-dire toute la mémoire des tableaux, vers une zone dont l'adresse de fin sera HL. Autrement dit, les tableaux sont poussés de 6 octets pour faire de la place pour la nouvelle variable.

Cette routine de déplacement commence aussi par une vérification que la place nécessaire est disponible. Dans le cas contraire, une erreur est levée et le processus est arrêté.

Après le déplacement de la mémoire pour faire de la place, les variables (strend) et (arytab) sont ajustées à leur nouvelles valeur.

clear_mem:   dec      hl
             ld       (hl),$00
             rst      de_compare
             jr       nz,clear_mem

             pop      de
             ld       (hl),e
             inc      hl
             ld       (hl),d
             inc      hl

À présent qu'un emplacement est libre pour la variable, on parcourt son emplacement pour y placer des $00 avec cette boucle.

Puis on récupère le nom de la variable dans DE et on enregistre ce nom dans les deux premiers octets des 6 octets tout neufs.

La variable est à présent créée. Il ne reste plus qu'à retourner un pointeur avec l'emplacement de sa valeur à l'appelant.

var_found:   ex       de,hl
             pop      hl
             ret

DE prend la valeur de HL qui pointe juste après le nom de la variable, donc sur les 4 octets de sa valeur.

Puis HL récupère sa valeur de pointeur d'exécution et la routine se termine.

Retour de variable non définie

On l'a vu juste avant, si, lors de l'évaluation d'une expression, une variable n'est pas trouvée, le BASIC ne va pas créer cette variable et se contentera de renvoyer la valeur nulle pour le type demandé.

Nous pouvons le confirmer avec cette petite expérience :

10 DEFFNPK(P)=PEEK(P+1)*256+PEEK(P)
20 PRINT FNPK(&"49D8"), FNPK(&"49DC")
30 PRINT A
40 PRINT A$
50 PRINT NPK(&"49D8"), NPK(&"49DC")

Donne :

Le nombre à droite est (vartab) et ne bouge pas, puisque le listing ne bouge pas. La valeur de droite est la valeur de (strend) et reste constante entre le premier et le second affichage. Aucune variable n'a été créée par les accès à A et A$.

La différence de 12 octets correspond à la variable créé par la fonction elle-même et à la variable paramètre de cette fonction. En effet, et c'est assez étrange, alors que la recherche de variable dans une fonction est court-circuitée, comme expliqué plus haut, le BASIC créé tout de même une variable vide, qui ne sera pas utilisée.

Du coup, si vous voulez éviter de perdre 6 octets, prenez comme non de paramètre de vos fonction une variable utilisée ailleurs. Elle ne sera pas modifiée.

Changeons un peu l'expérience et cette fois, donnons les valeurs nulles (0 pour un nombre, "" pour une chaîne) spécifiquement aux deux variables (le LET est optionnel, mais je le laisse pour être clair sur la signification de la création de la variable).

La valeur de (vartab) est différente par rapport au premier test car le programme est un peu plus long. Néanmoins, sa valeur ne change pas avant et après la création des variables, ce qui donne une référence. Il y a toujours 12 octets pour les variables créées par la fonction.

Par contre, (strend) augmente de 12 octets avant et après les assignations. Les variables ont bien été créées.

Et cette valeur nulle ?

ret_null:    ld       (fac),a
             ld       hl,null_str
             ld       (faclo),hl
             pop      hl
             ret

Lors du branchement vers ret_null, A avait été mis à 0, c'est donc cette valeur que l'on met dans l'accumulateur flottant, qui contient la valeur de l'expression évaluée. Lorsqu'on lit une chaîne, ce sont dans les deux premiers octets de ce même accumulateur que se trouve un pointeur vers la chaîne évaluée. On y place un pointeur vers une chaîne nulle (null_str contient un $00).

POP HL récupère le pointeur sur la ligne en exécution. Pas besoin de mettre en place DE, car cette branche de la routine n'est appelée qu'en cas d'évaluation d'expression, et comme l'adresse de retour a été enlevée de la pile pour comparaison et n'y a pas été remis, le retour ne se fait pas à l'appelant direct (qui irait chercher la valeur de la variable retournée) mais à son appelant précédent (l'évaluateur).

Est-ce que cette optimisation acrobatique était bien nécessaire ? Je n'ai pas la réponse.

Reset de la mémoire

Une dernière chose avant de clore cet article. Le BASIC du VG5000µ efface toutes les variables lorsqu'un programme est lancé avec RUN. On est assuré que la mémoire est « effacée » (le contenu est toujours là, seul les pointeurs sont réinitialisés). Les valeurs spécifiées par un CLEAR sont par contre conservées.

De même, les variables sont effacées au moindre changement dans le listing.

Un peu de BASIC

Et pour terminer, un petit listing BASIC qui va afficher les variables présentes en mémoire... et donc du programme en cours d'exécution.

10 DEFFNPK(P)=PEEK(P+1)*256+PEEK(P)
20 VT=FNPK(&"49D8")
30 AT=FNPK(&"49DA")
40 PRINT (AT-VT)/6;" VARIABLE(S)"
50 FOR PT=VT TO AT-1 STEP 6
60 PRINT CHR$(PEEK(PT) AND 127);
70 PRINT CHR$(PEEK(PT+1) AND 127)
80 NEXT PT

Affiche

  4 VARIABLE(S)
 PK
 P
 VT
 AT

Et PT ? Comme la variable est créés après la récupération de AT ((arytab)), cette variable n'est pas vue par le programme, ce qui est tout à fait conforme à ce qui était attendu.

VG5000µ, le BASIC cherche ses lignes

2019-08-16T00:00:00+02:00

Peut-être l'avez vous remarqué, certains programmes en BASIC sont construits avec leur programme principal avec des numéros de ligne « hauts » et ont leurs traitements souvent appelés dans les lignes « basses ».

Ainsi, dans l'article précédent sur le listing, le programme commence par un GOTO 10000 et le décodage de ligne est en 1300. À vrai dire, avant que je ne stocke les adresses des tokens dans un tableau, le décodage systématique de leurs noms étaient dans des lignes encore plus basses.

La raison en est toute simple : lorsque le BASIC sur VG5000µ cherche un numéro de ligne, il le cherche systématiquement depuis le début du programme.

C'est où que ça cherche ?

La routine de recherche de ligne est en $2347 et est appelée par GOTO, RESTORE, RENUM (beaucoup !), LIST, AUTO (à chaque nouvelle ligne), NEW, mais aussi lorsqu'il s'agit d'insérer une nouvelle ligne dans le listing au bon endroit, voire de remplacer une ancienne.

Pour appeler cette routine, il suffit d'assigner à DE le numéro de ligne recherché.

line_search: ld       bc,$0000

             ld       hl,(txttab)
line_search_lp:
             ld       (prelin),bc

             ld       b,h
             ld       c,l
             ld       a,(hl)
             inc      hl
             or       a,(hl)
             dec      hl

             ret      z

             inc      hl
             inc      hl
             ld       a,(hl)
             inc      hl
             ld       h,(hl)
             ld       l,a

             rst      de_compare

             ld       h,b
             ld       l,c

             ld       a,(hl)
             inc      hl
             ld       h,(hl)
             ld       l,a

             ccf
             ret      z

             ccf
             ret      nc

             jr       line_search_lp

Tout commence avec l'initialisation de BC avec $0000 et de HL avec le pointeur de début de listing. Puis débute la boucle de recherche.

En début de boucle, la ligne contenue dans BC est stocké dans une variable système prelin. Cette variable système contiendra en tout temps le dernier numéro de ligne qui a été trouvé dans le listing.

Jusqu'au RET Z, il s'agit de lire le contenu du pointeur de ligne suivante et vérifier s'il est égal à $0000. Si c'est le cas, ce RET Z provoque la fin de la routine. Le Carry Flag est à 0 grâce au OR qui précède, ce qui indiquera que la ligne n'a pas été trouvée.

Pour rappel, une ligne de BASIC stockée en mémoire commence par un pointeur de chaînage vers la ligne suivante, ou $0000 s'il s'agit de la dernière ligne.

On peut être surpris par ce DEC HL avant le retour de la routine, compensé par le premier INC HL juste après le RET Z. Comme le BASIC sauve un octet en fusionnant les 4 octets nuls terminant le chaînage des lignes avec le $00 d'une fin de ligne, le pointeur, qui est un cran après ce $00 de fin de ligne, réintègre le besoin des 4 octets nuls de fin de chaînage.

Mais si on ne sort pas de la routine, alors cet octet n'est pas fusionné, il faut remettre HL à sa place initiale.

Après le RET Z, le numéro de la ligne BASIC, qui est dans la ligne BASIC stockée formé par les deux octets suivants, est lu dans HL. Puis comparé à DE via RST DE_COMPARE.

En se souvenant que le numéro de ligne recherché est dans DE, après cette comparaison, il y a trois cas :

HL et DE sont égaux : on a donc trouvé la ligne. Le flag Z est mis à 1, le Carry Flag est à 0
HL est supérieur à DE : on a trouvé un numéro de ligne plus grand que celui recherché. La ligne recherchée n'existe donc pas. Z est à 0, Carry est à 0 aussi.
HL est inférieur à DE : il faut continuer à chercher. Z est à 0, Carry est à 1.

Après la comparaison, HL est remis à l'adresse sauvée en début de boucle dans BC, pour revenir sur l'adresse de chaînage. Cette adresse est celle de la ligne que l'on vient de valider comme étant la suivante (voire la bonne !), l'adresse est donc lue à nouveau dans HL.

Les lignes suivantes traitent les différents cas de comparaison de ligne.

Tout d'abord le couple CCF / RET Z fait sortir la routine si la ligne a été trouvée. CCF qui inverse la valeur du Carry Flag, le met donc à 1 dans le cas où Z était à 1. En sortie de routine, le Carry Flag à 1 indique que la ligne a été trouvée. HL pointe sur le début de la zone de cette ligne.

Puis le couple CCF / RET NC remet le Carry Flag a son état d'après la comparaison entre HL et DE et le test. Dans le cas où la ligne n'est pas là, on sort de la routine, mais donc cette fois avec le Carry Flag à 0, indiquant que la ligne n'a pas été trouvée. HL pointe alors vers l'adresse de la ligne suivante, et BC sur la ligne précédente. C'est intéressant dans le cas où l'on veut chaîner une nouvelle ligne entre les deux.

Si aucun de ces cas de sortie n'a eu lieu, le JR final repart pour un nouveau tour de boucle.

Et NEXT et RETURN ?

NEXT et RETURN sont deux instructions qui provoquent une rupture de séquence. Autrement dit, suite à leur exécution, l'exécution continue ailleurs. En début de boucle si la boucle n'est pas terminée avec NEXT, ou après le GOSUB dans le cas du RETURN.

Le fonctionnement de ces instructions est différent. FOR et GOSUB vont placer le pointeur sur les instructions en train d'être interprétées dans un endroit sûr. GOSUB le place sur la pile, FOR aussi... si des FOR sont imbriqués, sinon, dans une variable système spécifique (endfor).

Lorsqu'il faut reprendre l'exécution, le pointeur vers l'instruction en cours en remis à la valeur sauvegardée (avec son numéro de ligne correspondant, une autre variable système à garder cohérente, (curlin)) puis le décodage continue.

Par conséquent, les boucles FOR/NEXT et un RETURN ne sont pas affectés par la recherche de numéro de ligne.

Ça optimise ?

Choisir pour des destinations de saut de numéros de lignes les plus proches du début du programme est donc une optimisation. Mais soyons franc, c'est une toute petite optimisation. La recherche par parcours de liste chaînée est rapide en assembleur en comparaison de l’évaluation d'une expression un peu complexe avec des variables à manipuler par exemple.

J'ai pu lire que sur certains BASICs d'autres machines, une optimisation avait été faite par le simple fait de rechercher la ligne de destination par rapport à la ligne actuelle, privilégiant ainsi la localité des sauts. Est-ce que cela serait efficace sur la ROM VG5000µ ? Peut-être... à suivre.

VG5000µ, un listing en BASIC

2019-08-12T00:00:00+02:00

Un programme en BASIC qui ferait un listing de lui-même. Reprogrammer l'instruction LIST. C'est un peu inutile, mais cela est un prétexte pour expliquer comment le programme est stocké en mémoire dans la machine.

Le VG5000µ utilise une version du BASIC-80 de Microsoft. Ce BASIC se retrouve sur d'autres machines dans des versions variées, mais dont on retrouve les grands principes.

Structure générale d'un programme en mémoire

Comme on l'a vu précédemment, le BASIC respecte un pointeur vers le début du programme qui se nomme (txttab), situé en $488E. Par défaut avec la ROM interne du VG5000µ, si aucune extension ne l'a modifié, (txttab) vaut $49FC au démarrage.

Chaque ligne est composée par les éléments suivants :

Une adresse mémoire (sur 2 octets) vers l'emplacement de la ligne suivante, ou $0000 pour marquer la fin de la liste de lignes,
Un numéro de ligne (sur 2 octets) qui correspond au numéro de ligne BASIC,
Un ensemble d'octets représentant le contenu de la ligne, qui se termine pas un $00

Juste après le zéro se trouve la nouvelle ligne, et la ROM maintient les lignes dans l'ordre de leur numéro de ligne BASIC.

L'ensemble des lignes stockées forme donc une « liste chaînée » selon le schéma suivant.

Note : comme la dernière ligne est suivi par le pointeur vers l'adresse $0000, le BASIC en profite pour gagner un octet et ne met pas spécifiquement un $00 à la fin de cette ligne, puisqu'il y en a déjà 4.

Pour notre programme de décodage de ce qui se trouve dans la mémoire, il va donc falloir d'abord aller récupérer l'adresse de (txttab). On pourrait la mettre en dur, mais faisons ça proprement.

Le BASIC sur VG5000µ n'a comme instruction pour lire la mémoire que PEEK, qui ne lit qu'un octet. Qu'à cela ne tienne, voici une petite fonction qui, donnée une variable P pointant sur une zone mémoire, en retourne la valeur entière sur 16 bits qui y est stockée.

DEFFNPK(P)=PEEK(P+1)*256+PEEK(P)

De là, on peut donc partir de (txttab) puis de parcourir tout le chaînage jusqu'à trouver un pointeur nul ($0000).

Ce qui peut donner ça :

10020 DEFFNPK(P)=PEEK(P+1)*256+PEEK(P) : REM Définition de la fonction pour lire un entier sur 2 octets
10030 PT=FNPK(&"488E")                 : REM Récupération de (txttab)
10040 NX=FNPK(PT)                      : REM Lecture du pointeur **next** (ligne suivante)
10050 IF NX=0 THEN 10200               : REM Si ce pointeur est nul, on sort plus loin
10060 PT=PT+2:LI=FNPK(PT)              : REM Sinon, on avant le pointeur de 2 et on lit le numéro de ligne
10070 PRINT LI;" ";                    : REM On affiche le numéro de ligne
10080 PT=PT+2:GOSUB 1300               : REM On avance le pointeur de 2 et on décode la ligne (voir plus loin)
10090 PT=NX                            : REM Passage du pointeur vers la ligne suivante
10100 GOTO 10040                       : REM Et on boucle...

Voici le corps principal du programme écrit. Avec ça, même en ne mettant qu'un RETURN en ligne 1300, vous pouvez voir les numéros de ligne du votre programme s'afficher.

Décodage du contenu des lignes

Les lignes sont formées d'une suite d'octets terminée par un $00, située entre le numéro de la ligne BASIC et l'adresse de début de la ligne suivante.

Le contenu d'une ligne peut contenir des caractères, mais aussi des tokens. Les tokens (jetons en français) représentent les instructions, fonctions et signes reconnus par le BASIC lorsque la ligne a été analysée à l'entrée par le clavier (sur cassette, les tokens sont enregistrés, et donc chargés, directement).

Un token est facilement reconnaissable, son bit de poids fort est à 1. Autrement dit, si le caractère présent est strictmeent supérieur à 127, il s'agit d'un token. D'ailleurs, lorsque l'on entre un programme au clavier, le BASIC fait bien attention de mettre tous les caractères entrés sur 7 bits.

C'est aussi dans ce traitement que le BASIC va chercher, à l'aide d'une liste de mots-clés et signes connus, à reconnaître et donc de tokeniser la ligne. Dès qu'une suite de caractères est un mot-clé ou un signe connu, la suite de caractères est remplacée, dans la chaîne encodée, par son token.

Si les caractères lus ne forment pas un mot connu, ceux-ci sont copiés tels quels dans la ligne encodée.

Par exemple, si BASIC encode la ligne : PRINT"HELLO", le résultat sera la suite $94,'"', 'H','E,'L','L','O','"',$00.

Le décodage

Pour reconstituer la ligne, il s'agit donc de prendre les caractères un par un et de vérifier. Est-ce un token ou pas ? Si ce n'est pas un token, on l'écrit directement à l'écran (ou presque, on va voir plus loin). Si c'est un token, on soustrait 128 à sa valeur pour avoir son index.

Les tokens

Reste à retrouver le token dans la table située en $209E et donc un extrait à partir du début ressemble à cela :

             defb     $c5,$4e,$44,$c6,$4f,$52,$ce,$45,$58,$54      ; .ND.OR.EXT
             defb     $c4,$41,$54,$41,$c9,$4e,$50,$55,$54,$c4      ; .ATA.NPUT.
             defb     $49,$4d,$d2,$45,$41,$44,$cc,$45,$54,$c7      ; IM.EAD.ET.
             defb     $4f,$54,$4f,$d2,$55,$4e,$c9,$46,$d2,$45      ; OTO.UN.F.E
             defb     $53,$54,$4f,$52,$45,$c7,$4f,$53,$55,$42      ; STORE.OSUB
             defb     $d2,$45,$54,$55,$52,$4e,$d2,$45,$4d,$d3      ; .ETURN.EM.
             defb     $54,$4f,$50,$cf,$4e,$cc,$50,$52,$49,$4e      ; TOP.N.PRIN
             defb     $54,$c4,$45,$46,$d0,$4f,$4b,$45,$d0,$52      ; T.EF.OKE.R
             defb     $49,$4e,$54,$c3,$4f,$4e,$54,$cc,$49,$53      ; INT.ONT.IS
             defb     $54,$cc,$4c,$49,$53,$54,$c3,$4c,$45,$41      ; T.LIST.LEA
             ...

Cette table est encodée de la manière suivante : les mots-clés sont les uns à la suite des autres. Chaque premier caractère a son bit de poids fort à 1, ce qui marque la séparation entre les mots.

Faisons un essai : $94 est le token pour PRINT, soit 148 en décimal. 148 - 128 = 20. Mais attention, le premier token est 128, donc il faut commencer à compter à partir de 0. Cherchez le 21ième mot clé et vous lirez .RINT (attention, le .PRINT précédent est le codage de LPRINT)

Pour faire plus simple, vous pouvez aussi compter 21 points.

Dans mon premier essai de programme, j'avais traduit en BASIC ce que fait la ROM en assembleur : à chaque mot-clé, on parcours la table des mots-clés depuis le début. À chaque fois que l'on rencontre un caractère supérieur ou égal a 128, on décroit le numéro du token d'une unité. Arrivé à zéro, on a trouvé, on peut donc recopier à l'écran tous les caractères (sur 7 bits) jusqu'au prochain supérieur ou égal à 128, exclu.

Ça fonctionne. Mais ce qui est très rapide en assembleur demande beaucoup de manipulations au BASIC. Parcourir un long tableau et faire des comparaisons et des tests est très lourd, même en usant de quelques astuces.

Lorsqu'il fallait décoder un token élevé, comme le signe = (token 65) ou la fonction MID$ (token 95, le dernier), le décodage devenait très long, très très long.

J'ai donc finalement opté pour payer le coût de décodage une fois, au détriment d'une consommation mémoire plus importante.

5000 PRINT"INITIALISATION..."                   : REM Affichage d'un message, parce que c'est un peu long
5010 DIM K(95)                                  : REM Il y 96 tokens, de 0 à 95
5020 KT=&"209E"                                 : REM Adresse du début de la table
5030 KW=0                                       : REM Initialisation avec le Keyword 0
5040 K(KW)=KT:KW=KW+1                           : REM Adresse du Keyword courant dans le tableau et augmentation de l'index
5050 KT=KT+1                                    : REM Déplacement à l'adresse suivante de la table
5060 IF PEEK(KT) AND 128 THEN 5080              : REM Si bit de poids fort, on saute
5070 GOTO 5050                                  : REM Sinon, on boucle sur l'avancée dans la table
5080 IF (PEEK(KT) AND 127) = 0 THEN RETURN      : REM Si la caractère est $80, c'est fini !
5090 GOTO 5040                                  : REM Sinon, on boucle sur l'enregistrement de l'adresse

Note : j'aurai pu écrire ça avec une boucle FOR car pour cette ROM là, je connais la taille de la table, qui ne bougera pas, mais je voulais garder ce bout de code flexible. Il fonctionnera pour une autre tableau d'un autre BASIC-80.

Décoder le token revient maintenant à aller chercher son adresse dans la table puis de recopier les caractères jusqu'au premier marquant le début du mot suivant.

1500 REM KT <- ADRESSE TOKEN(V)
1510 KW=V-128                       : REM Calcul du token à partir du caractère lu
1520 KT=K(KW)                       : REM Lecture de l'adresse de son nom en mémoire
1530 REM PRINT(KEYWORD(KT))
1540 R$="":C=PEEK(KT)               : REM Préparation de la chaîne et lecture du premier caractère
1550 R$=R$+CHR$(C AND 127)          : REM Construction de la chaîne
1560 KT=KT+1                        : REM Passage à l'adresse suivante
1570 C=PEEK(KT)                     : REM Lecture du caractère suivant
1580 IF C>127 THEN 1600             : REM Si c'est le mot suivant, on saute plus loin
1590 GOTO 1550                      : REM SInon, on boucle sur la construction
1600 PRINT R$;:RETURN               : REM Le mot est trouvé, on l'affiche et on revient à l'appelant

Note : j'aurai pu afficher directement chaque caractère plutôt que de construire la chaîne au fur et à mesure. Je n'ai pas vérifié ce qui serait le plus rapide. Cette version là use pas mal la mémoire de chaînes de caractère, c'est certain.

Les entiers compactés

Je n'ai aucune idée de si c'est leur nom officiel, mais c'est comme celui que je les appelle. Certains nombres sont encodées par le BASIC dans une forme particulière : le caractère $0E suivi d'un nombre entier codé sur 16 bits (donc deux octets).

En particulier, les numéros de lignes sont codées de cette manière. Ainsi les instructions de saut comme GOTO ou GOSUB n'ont pas à décoder systématiquement le numéro en paramètre. Il a déjà été décodé et stocké dans la ligne.

Afficher un entier compacté n'est pas très compliqué grâce à la fonction de lecture d'un entier sur 16 bits.

2999 REM PRINT(NUM16(I+1))
3000 I=I+1                    : REM I pointe vers le caractère $0E, l'entier est juste après
3010 PRINT(FNPK(I));":";
3020 I=I+2                    : REM On saute les deux caractères lus
3030 RETURN

Note : lorsque le BASIC utilise un entier compacté, il induit aussi une fin d'instruction. Il n'encode donc pas le séparateur ':' éventuel. Je l'affiche donc ici systématiquement, ce qui n'est pas tout à fait correct car il apparaît parfois en fin de ligne. Ce n'est pas syntaxiquement faux non plus.

Les différents cas

Il y a donc trois cas pour un caractère à décoder, auquel j'ajoute une quatrième :

Si le caractère est un token, on le décode,
Sinon, si le caractère est $0E, on décode un entier compacté,
Sinon, s'il est inférieur à 17 ou égal à 30 et 31, c'est un caractère de contrôle, on le remplace par le caractère espace,
Sinon, on le recopie tel quel.

Ce qui donne :

1300 REM DECODE LA LIGNE ENTRE PT ET NX
1310 FOR I=PT TO NX-1                           : REM Décodage sur tout le contenu (voir la note juste après)
1320 V=PEEK(I)                                  : REM Lecture du caractère
1330 IF V AND 128 THEN GOSUB 1500:GOTO 1370     : REM Est-ce un token ?
1340 IF V=14 THEN GOSUB 3000:GOTO 1370          : REM Est-ce un entier comptacté ?
1350 IF V<17 OR V=30 OR V=31 THEN V=32          : REM Est-ce un caractère non affichable ?
1360 PRINT CHR$(V);                             : REM Affichage du caractère
1370 NEXT I                                     : REM Fin de la boucle
1380 PRINT                                      : REM Saut à la ligne quand c'est terminé
1390 RETURN

Note : la ROM ne fait pas tout à fait comme ça, elle décode jusqu'à trouver le $00. Dans la pratique, les lignes sont stockées dans l'ordre du chaînage, par ordre de ligne croissant. Je décode donc entre le début du contenu de la chaîne tokenisé et la ligne suivante.

Conclusion

Voilà donc réunies toutes les pièces qui permettent de lister le programme en mémoire... et donc le programme lui-même.

L'instruction LIST incluse dans la ROM du VG5000µ est meilleure que cela : les commentaires sont affichés d'une couleur différente, il n'y a pas d'espace avant les numéros de lignes, pas de ':' qui traînent derrière les GOTO et GOSUB en fin de ligne.

Mais l'idée était surtout de montrer comment était encodé le listing en mémoire.

Et pour finir, le programme en entier.

10 GOTO 10000

1300 REM DECODE LA LIGNE ENTRE PT ET NX
1310 FOR I=PT TO NX-1
1320 V=PEEK(I)
1330 IF V AND 128 THEN GOSUB 1500:GOTO 1370
1340 IF V=14 THEN GOSUB 3000:GOTO 1370
1350 IF V<17 OR V=30 OR V=31 THEN V=32
1360 PRINT CHR$(V);
1370 NEXT I
1380 PRINT
1390 RETURN

1500 REM KT <- ADRESSE TOKEN(V)
1510 KW=V-128
1520 KT=K(KW)
1530 REM PRINT(KEYWORD(KT))
1540 R$="":C=PEEK(KT)
1550 R$=R$+CHR$(C AND 127)
1560 KT=KT+1
1570 C=PEEK(KT)
1580 IF C>127 THEN 1600
1590 GOTO 1550
1600 PRINT R$;:RETURN

2999 REM PRINT(NUM16(I+1))
3000 I=I+1
3010 PRINT(FNPK(I));":";
3020 I=I+2
3030 RETURN

5000 PRINT"INITIALISATION..."
5010 DIM K(94)
5020 KT=&"209E"
5030 KW=0
5040 K(KW)=KT:KW=KW+1
5050 KT=KT+1
5060 IF PEEK(KT) AND 128 THEN 5080
5070 GOTO 5050
5080 IF (PEEK(KT) AND 127) = 0 THEN RETURN
5090 GOTO 5040

10000 REM DEMARRAGE
10010 GOSUB 5000
10020 DEFFNPK(P)=PEEK(P+1)*256+PEEK(P)
10030 PT=FNPK(&"488E")
10040 NX=FNPK(PT)
10050 IF NX=0 THEN 10200
10060 PT=PT+2:LI=FNPK(PT)
10070 PRINT LI;" ";
10080 PT=PT+2:GOSUB 1300
10090 PT=NX
10100 GOTO 10040

10200 PRINT"FINI"

11000 END

VG5000µ, une Cartographie de la Mémoire BASIC

2019-08-08T00:00:00+02:00

Quand j'ai commencé à étudier les documentations sur le VG5000µ, des incohérences sur certains points me sont apparues. Les différentes sources ne donnaient pas les même renseignements. Ou alors je lisais mal. Mais un truc ne collait pas.

En étudiant la ROM, là encore, ça ne collait pas avec les documentations. Mais le code ne ment pas, j'ai donc débuté une quête de la vérité : que se passe-t-il vraiment ?

... ce n'était peut-être pas si épique, mais bon...

L'anomalie qui m'intéresse aujourd'hui est celle de la gestion de la mémoire par le BASIC. Et voici les pièces qui ont provoqué mon étonnement.

Première pièce

La manuel de l'utilisateur, page 46, indique que le premier paramètre de la commande définit la totalité de l'espace occupé par les chaînes de caractères et doit être compris entre -32768 et 32767. Spécifier une mémoire à réserver négative est un peu étrange, et un test rapide montre que passer une valeur négative est rejetée par le BASIC.

Au passage, un coup d'œil dans la ROM montre que l'instruction CLEAR utilise une routine qui ne décode que des entiers positifs...

Plus étonnant, le second paramètre, qui indique la plus haute adresse possible atteignable par le BASIC doit être inférieur à 32767 pour le VG5000 standard, et 42864 pour l'extension mémoire 16ko. Et ne mentionne pas 32ko d'extension.

42864... Ça ne correspond pas à grand chose. Avec l'extension 16ko, je vois plutôt une adresse maximale à 49151. En effet, la ROM prend les 16 premiers ko, et les 16+16 ko de RAM sont à la suite. 48 * 1024 donne 49152 octets.

Bref, louche. De plus, un essai direct d'un CLEAR 50, 42864 ne fonctionne pas, un paramètre invalide est indiqué. La routine pour décoder le second paramètre étant une routine qui prend des entiers entre -32768 et 32767.

Une cartographie de la mémoire page 86 indique que la mémoire peut bien aller jusqu'à 49151, qu'il faut spécifier cette valeur en complément à 2 sous une forme négative. C'est incohérent avec la description de CLEAR mais l'expérience montre que la cartographie a raison. Elle indique aussi des valeur de pointeur (stktop), (fretop), (arytab) et (txttab), mais n'indique pas où les trouver.

Deuxième pièce

La deuxième source est « Clefs pour VG5000 », un livre des éditions du P.S.I.

Page 15, la description de CLEAR est globalement reprise avec les mêmes renseignements erronés.

Page 69, une cartographie de la mémoire est disponible et indique des noms de variables pointeurs sur des zones mémoire. Plus loin, ces variables systèmes sont décrites, avec leurs adresses. C'est par ici que j'avais commencé à regarder le fonctionnement.

Deux choses me paraissaient bizarre. Une flèche entre arytab et fretop sans nom. Soit. Mais aussi une variable fretop qui est sous la pile. C'est bizarre car le bas de la pile, c'est déjà le registre SP, quel intérêt de garder une information comme ça ? Pour protéger la pile ?

C'est cependant cohérent avec le manuel d'utilisateur et donne une information en plus sur le fait que (memsiz) n'est pas initialisé tout en haut de la RAM disponible mais trois octets avant. Il ajoute une variable de système : (vartab).

C'est à ce moment là que j'ai commencé à étudier la ROM et voir que (fretop) était initialisé avec la valeur (memsiz), et que lors d'allocation de chaînes de caractères, l'algorithme partait du principe que (fretop) était toujours supérieur à (stktop).

En fait, l'erreur d'allocation de chaîne était lancée, si je ne me trompais pas (mais le doute est permis quand on regarde des pages de code assembleur), lorsque (fretop) atteignant (stktop) par le haut. Autrement dit, tant que (fretop)-(stktop) était positif, il y avait de la place. Je détaille ça plus loin.

Et donc, ça ne collait pas avec le schéma.

Les descriptions des variables sont les suivantes :

$488E : adresse de début du programme Basic (txttab)
$4895 : Adresse du haut de la pile (stktop)
$49C3 : adresse du haut de la zone "chaînes" (fretop)
$49D8 : adresse de début de la zone "variables" (vartab)
$49DA : adresse de début de la zone "chaînes" (arytab) (c'est incohérent d'après le schéma, mais on se doute bien que ary signifie array est qu'il s'agit en fait de la zone pour les tableaux DIM)
$49DC : adresse de fin du stockage en cours, n'est pas nommé. Je ne le savais pas à ce moment-là, mais il s'agit de (strend) et c'est le nom qu'il manque entre (arytab) et (fretop)... il faut dire que la description n'est pas hyper parlante. Quel stockage ? En cours de quoi ?

Troisième pièce

Le troisième document dans lequel je me suis plongé est celui du manuel technique, en anglais. Page 6, on trouve le tableau source des deux précédents documents., mais là encore, (fretop) est sous la pile...

Plus loin, page 9, la liste des variables systèmes, là encore probablement la source du livre P.S.I, est donné. On y trouve (txttab), (stktop), (fretop), (vartab), (arytab) avec sa description correcte mentionnant des tableaux, et (fretop), et (strend) indiquant « end of storage in use ».

La description de (strend) est un peu plus éclairante que sa traduction dans le livre P.S.I, même si ça manque de détail. Il n’apparaît pas dans la cartographie de la mémoire.

Il n'y a pas d'autres mentions du fonctionnement des allocations mémoire dans ce document, à part un peu à propos de manipulation de (txttab) et (vartab) quand on veut lancer un programme BASIC depuis un ROM d'extension.

Quatrième pièce

De tous les documents sur le VG5000µ, les plus dignes de confiances, ceux qui vont un peu plus dans le détail et dans lesquels je n'ai jamais trouvé d'erreur jusqu'à maintenant, ce sont les « Technical Bulletin** ». Sur celui du 14 juin 1984, à propos de « BASIC Text Relocation » il est mentionné que (strend) sera bougé, avec (vartab), (arytab) et (temp), si (txttab) est modifié et que le BASIC exécute une des routines qui replace tout ça.

Pas tellement plus d'information cependant.

Dans le bulletin du 11 septembre 1984, une mention de (stktop) et (memsiz) est fait, qui donne les bonnes adresses en fonction des différentes configuration de mémoire.

Au final...

Au final... et bien le mieux est d'aller voir dans la ROM ce qu'il se passe. Et pour chercher, je pars sur deux pistes : où donc est-ce que (fretop) est utilisé, et qu'est-ce que (strend) ?

(fretop) est utilisé a de nombreux endroits, mais quelques-uns de ses usages sont suffisant pour comprendre.

L’initialisation

La fonction suivante est appelé lorsqu'il s'agit de réinitialiser la mémoire. Au lancement de la machine, par un appel à NEW, mais aussi directement en reset_vars lors d'un RUN ou en init_vars lors d'un CLEAR.

reset_mem:   ld       hl,(txttab)          ; $2ed9
reset_mem_2: xor      a,a
             jp       reset_mem_3

reset_mem_4: inc      hl
             ld       (vartab),hl
reset_vars:  ld       hl,(txttab)
             dec      hl
init_vars:   ld       (temp),hl
             ld       hl,(memsiz)
             ld       (fretop),hl
             xor      a,a
             call     inst_restore
             ld       hl,(vartab)
             ld       (arytab),hl
             ld       (strend),hl

Tout commence avec comme point de repère (txttab), qui est le début du programme BASIC en cours.

Le jp reset_mem_3 renvoie en reset_mem_4 après avoir coupé le lien sur la première ligne de BASIC, effaçant par la même occasion l'accès au programme (qui est toujours là...).

Cette gymnastique avec reset_mem_3, qui n'est jamais appelé par ailleurs, vient à mon avis du patch de la ROM 1.1, qui fait tout pour rester stable dans les adresses de routines. Je vérifierai cette théorie plus tard.

(vartab) est placé deux octets plus loin que (txttab) (HL est aussi incrémenté par le code de reset_mem_3)

(temp) est placé un octet avec (txttab)

(fretop) est initialisé à la même adresse que (memsiz), ce qui montre bien que, au moins là, les cartographie mémoire sont fausses.

L'appel à inst_restore est l'exécution de l'instruction RESTORE du BASIC, qui va chercher et stocker la première ligne contenant des DATA.

Puis enfin, (arytab) et (strend) prennent la valeur de (vartab).

Un peu plus loin, les lignes suivantes remettent le registre SP à l'adresse en haut de sa zone, stockée dans (stktop).

             ld       hl,(stktop)          ; $2eff
             ld       sp,hl

La conclusion sur l’initialisation de la mémoire est que les adresses de références sont (txttab), (memsiz) et (stktop). Les autres pointeurs sont placés en fonction de ces adresses.

Vérification mémoire de chaînes

Lorsqu'une chaîne de caractère est sur le point d'être créé, la routine suivante est appelée en premier lieu :

             ld       hl,(stktop)          ; $36bf
             ex       de,hl
             ld       hl,(fretop)
             cpl
             ld       c,a
             ld       b,$ff
             add      hl,bc
             inc      hl
             rst      de_compare
             jr       c,out_str_mem

À l'entrée de cette routine, A contient le nombre de caractères de la chaîne à créer.

Après les trois premières lignes, on se retrouve avec (stktop) dans DE et (fretop) dans HL. Les trois lignes suivantes mettent dans BC l'inverse de A (en complément à 2).

Via le add, HL contient donc (fretop) moins le nombre de caractères dont on a besoin, (le inc qui suit est la correction de la soustraction en complément à 2).

rst de_compare est une routine qui compare les valeurs de HL et DE, si HL est inférieur à DE, alors le flag Carry est levé, ce qui provoque le saut qui suit vers l'erreur indiquant qu'il n'y a pas assez de mémoire dans l'espace réservé aux chaînes de caractères.

Ce qui est important ici, c'est que ce calcul montre que (fretop) doit être supérieur à (stktop). Ce qui montre encore que les schémas sont faux.

FRE(" ")

Dernière vérification, histoire d'être vraiment certain, en analysant la fonction FRE(" "). Cette commande avec une chaîne en paramètre n'est pas documentée dans le manuel d'instruction, mais on la trouve dans les « bulletins ».

Lorsque FRE a un paramètre numérique (peu importe lequel), la fonction renvoie la place restante en mémoire BASIC... pour tout ce qui n'est pas stockage des caractères de chaînes.

Avec un paramètre alphanumérique, FRE renvoie l'espace restant dans la mémoire réservée aux caractères.

Et en voici le code :

inst_fre:    ld       hl,(strend)          ; $38b1
             ex       de,hl
             ld       hl,$0000
             add      hl,sp
             ld       a,(valtyp)
             or       a,a
             jp       z,inst_fre_2
             call     gstrcu
             call     call36e3
             ld       de,(stktop)
             ld       hl,(fretop)
             jp       inst_fre_2

inst_fre_2:  ld       a,l
             sub      a,e
             ld       c,a
             ld       a,h
             sbc      a,d

Tout commence en plaçant (strend) dans DE (via HL). Puis en mettant SP dans HL (via le add).

(valtyp) contient le type de l'expression qui vient d'être évaluée. À l'appel d'une fonction, il s'agit de la valeur du paramètre. Si cette valeur est numérique (= 0), la suite se passe en inst_fre_2 où le résultat de l'opération HL - DE est mis dans le couple de registres A et C.

Au passage, notons que la mémoire restante est calculée comme la différence entre le pointeur de pile courant et (strend), ce qui permet de situer correctement la fonction de (strend) comme marquant la fin (adresse haute) du stockage BASIC « listing + variables + tableaux ».

Si l'expression était alphanumérique, alors il y a deux appels (dont un auquel je n'ai pas encore donné de nom) qui permettent d'appeler le ramasse miettes (Garbage Collection) sur les chaînes de caractères. Passons.

Puis (stktop) est placé dans DE et (fretop) dans HL, avant d'effectuer le même calcul que précédemment HL - DE.

Ce qui montre à nouveau que (fretop) doit être supérieur à (stktop) et qui indique même que cet espace correspond à la zone de mémoire libre pour les chaînes. Autrement dit, (fretop) présente l'adresse la plus basse des chaînes de caractères, toutes stockées au-dessus. Le nom a probablement provoqué la confusion de sa description comme étant l'adresse du haut, mais c'est en fait une zone qui croît vers le bas.

En donc ?

(fretop) est un pointeur qui est valide entre (memsiz) et (stktop). L'espace entre (memsiz) et (stktop) est déterminé par le premier paramètre de CLEAR et (memsiz) est déterminé par le second paramètre de CLEAR.

Et grâce à ces informations, nous pouvons cartographier, la mémoire avec ses pointeurs de manière correcte et complète, du moins je l'espère.

Récréation 3D, Z80 du VG5000µ

2019-06-01T00:00:00+02:00

Deux ans déjà que j'avais créé quelques modèles 3D... Le temps passe vite. Et l'envie m'a repris.

Voici donc une petite recréation du Z80 présent dans le VG5000µ. Fait depuis des images et je ne suis donc pas complètement certains des mesures. J'irai vérifier la prochaine fois que j'en démonte un, si j'y pense.

Update: nouvelle version, corrigée avec des dimensions DIP plus correctes (mais le boitier du SGS est plat... ça fait donc un mélange)

Bonne Année 2019 !

2018-12-31T00:00:00+01:00

Bonjour à tous. Cette année, j'espère pouvoir faire aboutir un projet autour du VG5000µ que j'ai commencé il y a longtemps et que j'avance petit pas par petit pas.

En attendant, je vous souhaite :

10 B$="AAHGGGGGCB00A@GGGGCBCB00998898=<10"
20 LB=LEN(B$)
30 FOR I=1 TO LB STEP 2
40 A=ASC(MID$(B$,I,1))+ASC(MID$(B$,I+1,1))-64
50 PRINT CHR$(A);
60 NEXT I

À essayer sur votre ancienne machine sous BASIC préférée. Ça devrait être portable sur à peu près toutes les machines avec interpréteur BASIC et des capactités par trop limitées sur les chaînes de caractères (adieu ZX81...). Sur certains, il faudra ajouter LET aux lignes 10, 20 et 40 pour les assignations de variable.

VG5000µ, ajouter des instructions au BASIC ?

2018-10-16T00:00:00+02:00

Il y a quelques temps, un message sur le forum Config.cfg demandait s'il était simple ou même possible d'ajouter des instructions supplémentaires à la ROM d'un VG5000µ. C'est une question que je me posais aussi, avec dans l'idée d'ajouter des instructions graphiques utilisant l'implémentation des articles précédents].

J'ai donc continué à étudier la ROM (que je commence à bien connaître maintenant) à la recherche d'une méthode. Et on va voir que ça n'est pas gagné.

Le parseur

Lorsque la touche RET du clavier est appuyée, il se passe plusieurs choses. Tout d'abord, un caractère NUL (valeur 0) est placé dans le buffer d'entrée à l'emplacement du dernier caractère qui n'est pas un espace (adresses $3c4a à $3c56). Le RET à la fin de cette fonction ramène hors de la boucle principal du traitement interactif.

Après un traitement de la protection de programmes qui n'est pas le sujet ici, une fonction cherche si la ligne commence par un numéro de ligne puis débute la transcription de la ligne vers une ligne « tokenisée ». La procédure de tokénisation, en bref, va repérer toutes les instructions, fonctions et opérations connues et les transformer en « tokens » : un octet dont le bit de poids fort est à 1.

Un token permet de prendre moins de place en mémoire et facilite le travail de l'évaluateur.

La procédure saute bien entendu les chaînes de caractères en repérant les paires de guillemets.

Je laisse de côté le traitement de caractères à significations particulières (le ? qui remplace PRINT comme dans la plupart des BASIC par exemple) pour arriver à la recherche principale. Cette routine, qui commence globalement en $23a5, va comparer le contenu des caractères à décoder (en les passant en majuscules si nécessaire) avec une liste de noms et symboles dans une table située en $23a7.

Premier problème, cette liste est figée. Si aucune correspondance n'est trouvée, la routine ne dispose pas de hook pour passer la main à une éventuelle liste gérée par l'utilisateur. Les caractères sans correspondance sont laissés tels quels dans le buffer. Si plus tard, à l'évaluation, ces caractères n'ont pas de sens (ne désignent pas une variable par exemple), une erreur sera émise.

On pourrait alors imaginer se servir d'un autre hook, celui qui est appelé à chaque affichage de caractère ($47e2) ou celui qui est appelé lors d'un retour à la ligne (\$47e5), afin d'ajouter un parsing à la main. Mais pour cela, il faudrait choisir des tokens libres pour les nouvelles instructions ; ce qui amène à étudier les tokens.

Les tokens

Voici la liste des tokens avec leurs valeurs.

Commandes	Support -	Opérateurs	Fonctions
128:END	178:TAB(	185:+	195:SGN
129:FOR	179:TO	186:-	196:INT
130:NEXT	180:FN	187:*	197:ABS
131:DATA	181:SPC(	188:/	198:USR
132:INPUT	182:THEN	189:^	199:FRE
133:DIM	183:NOT	190:AND	200:LPOS
134:READ	184:STEP	191:OR	201:POS
135:LET		192:>	202:SQR
136:GOTO		193:=	203:RND
137:RUN		194:<	204:LOG
138:IF			205:EXP
139:RESTORE			206:COS
140:GOSUB			207:SIN
141:RETURN			208:TAN
142:REM			209:ATN
143:STOP			210:PEEK
144:ON			211:LEN
145:LPRINT			212:STR$
146:DEF			213:VAL
147:POKE			214:ASC
148:PRINT			215:STICKX
149:CONT			216:STICKY
150:LIST			217:ACTION
151:LLIST			218:KEY
152:CLEAR			219:LPEN
153:RENUM			220:CHR$
154:AUTO			221:LEFT$
155:LOAD			222:RIGHT$
156:SAVE			223:MID$
157:CLOAD
158:CSAVE
159:CALL
160:INIT
161:SOUND
162:PLAY
163:TX
164:GR
165:SCREEN
166:DISPLAY
167:STORE
168:SCROLL
169:PAGE
170:DELIM
171:SETE
172:ET
173:EG
174:CURSOR
175:DISK
176:MODEM
177:NEW

On peut remarquer que cette liste comporte plusieurs parties. La première, de 128 à 177, contient des instructions, c'est-à-dire des commandes impératives, sans valeur de retour.

De 178 à 184, il s'agit de commandes de support, qui ne peuvent être trouvées qu'en conjonction de commandes maîtresses. Par exemple THEN avec IF ; TO et STEP avec FOR,...

De 185 à 194, il s'agit d'opérateurs logiques et arithmétiques. Enfin, à partir de 195 jusqu'à la fin, 223, il s'agit de fonctions, qui retournent des valeurs, et qui apparaîtrons donc, au côté des opérateurs, dans des expressions.

On commence à sentir que s'il fallait ajouter des mot-clés, en fonction de leur nature, il faudrait les placer dans le bon groupe. Sauf que cette liste est compacte. On peut imaginer ajouter des fonctions après MID$, mais ajouter une instruction ou un opérateur décalerait toute la table, ce qui poserait un problème de compatibilité au moins avec les programmes enregistrés (les programmes BASIC enregistrés le sont sous forme tokenisée).

L'évaluateur

C'est donc vers l'évaluateur qu'il faut se tourner et se demander comment sont traitées les lignes en BASIC. Et c'est là que vient se planter le dernier clou dans le cercueil de l'ajout de commandes utilisateurs... du moins sans modifier la ROM.

Tout d'abord, examinons le décodage des tokens en $250f.

             sub      a,$80
             jp       c,inst_let           ; Comme tous les tokens sont supérieurs ou égaux
                                           ; à $80, si le caractère est inférieur, c'est le début du nom d'une variable.
                                           ; C'est un LET implicite.

             cp       a,$32
             jp       nc,stx_err_prt       ; Les 50 ($32) premiers tokens seulement sont des instructions
                                           ; Si le token est après, alors c'est une Erreur de syntaxe.

Voilà... la ROM contient en dur les bornes des instructions pouvant être décodées.

Et ce n'est pas fini. Lorsque l'on regarde l'évaluation d'expression en $28d8 :

             xor      a,a
             ld       (valtyp),a           ; Type numérique par défaut
             rst      chget
             jp       z,missing_op         ; Cas où le caractère est NUL
             jp       c,str_to_num         ; Cas où le caractère est un chiffre.
             cp       a,$26
             jp       z,str_hex_dec        ; Saut si sur le point de parser un nombre en hexa (caractère '&')
             call     a_to_z_2
             jr       nc,str_to_var        ; Saut si la valeur est entre A et Z
             cp       a,$b9                ; Token pour '+'
             jr       z,parse_value
             cp       a,$2e                ; Caractère '.'
             jp       z,str_to_num
             cp       a,$ba                ; Token pour '-'
             jr       z,str_to_min
             cp       a,$22                ; Caractère '"'
             jp       z,str_to_str
             cp       a,$b7                ; Token pour 'NOT'
             jp       z,str_to_not
             cp       a,$b4                ; Token pour 'FN'
             jp       z,str_to_fn
             sub      a,$c3                ; Token pour 'SGN', la première des fonctions
             jr       nc,str_to_func

Afin de déterminer le type de valeur à décoder, un certain nombre de tokens est là aussi en dur.

Et donc ?

Et donc tel quel, la ROM ne fourni pas de mécanisme d’extension pour écrire de nouvelles instructions. D'autre part, même s'il reste une trentaine de tokens libres à la fin de la liste, les constantes dans le parseur et dans l'évaluateur exigent que les tailles des groupes du tableau soient respectés.

Reste la possibilité de modifier la ROM pour ajouter les nouvelles instructions, ce qui n'est pas très compliqué, mais qui nécessitera de la conversion au chargement pour être compatible avec des programmes en BASIC enregistrés sur K7.

VG5000µ, Schémas de principe

2018-09-01T00:00:00+02:00

Le schéma de principe scanné depuis la documentation de maintenance trouvée sur le site My VG5000 et reconstitué du VG5000µ m'a souvent aidé à comprendre le fonctionnement de cette machine. Et je remercie l'auteur de ce travail !

Pour contribuer à mon tour à la documentation VG5000µ, j'ai refait les schémas de la platine principale et de la platine k7 au propre, afin d'en augmenter la lisibilité.

Quelques commentaires :

j'ai ajouté en précision les broches non branchées du Z80 et de l'EF9345. Cela montre rapidement les choix hardware du VG5000µ qui ne seront pas contournables sans modification du matériel.
j'ai utilisé les nomenclatures des datasheets des composants, ce qui change un peu la nomenclature originale.
j'ai gardé la disposition générale du schéma, pour ne pas perdre les habitués, mais il peut y avoir quelques changements dans le détail, lorsque je pensais pouvoir améliorer la lisibilité.
j'ai modifié les marquages des portes logiques vers une nomenclature en toute lettre ; par contre, je n'ai aucune idée de la nomenclature officiel pour un Buffer, j'ai mis BUF en attendant.
une porte AND, en sortie des deux portes NAND du 7812 n'avait pas de marquage sur le schéma originel, j'ai retrouvé le composant en suivant le schéma d'implantation (ce n'était pas trop compliqué, puisque qu'il n'y a qu'un seul composant qui fourni des portes AND, mais au moins, c'est vérifié)
le schéma original comporte la plupart des signaux en anglais, sauf quelques-uns (genre RVB), j'ai gardé RVB sur les sorties mais changé en RGB sur la nomenclature EF9345, comme sur la datasheet.
De même il y a un mélange COMMUT.RAPIDE mais SOUND sur la sortie vidéo, j'ai tout unifié en français.
Mais du coup, j'ai des signaux en anglais sur la sortie SON/K7...

Merci à tous les commentateurs du fil de discussion sur System.cfg qui m'ont permis d'améliorer les schémas.

La platine principale

Image cliquable pour une version en haute définition. (mise à jour 29 avril 2021)

La platine K7/Son

Image cliquable pour une version en haute définition. (mise à jour 9 sept. 2018)

Note

Le schéma a été mis à jour dans un nouvel article.

VG5000µ, SetPoint en C

2018-06-25T00:00:00+02:00

Après cette implémentation en assembleur Z80 d'une fonction setpoint qui affiche, de manière assez basique, un point à l'écran, je me pose la question d'utiliser un langage de plus haut niveau... mais pas trop.

J'ai une assez longue expérience du C et la question que je me pose est : qu'est-ce que ça donne de programmer en C pour générer du code sur Z80.

Programmer en C a quelques avantages a priori : c'est nettement plus concis et lisible que de l'assembleur, j'y suis plus habitué et c'est portable sur de nombreuses plateformes. C'est le cas d'autres langages, mais le choix naturel pour moi puisque écrire du C m'est habituel. En tout cas bien plus habituel que d'écrire directement de l'assembleur Z80.

Premier essai

Voici le code C d'un premier essai :

#include <stdint.h> // Afin d'utiliser les types standards

void setpoint(uint16_t x, uint8_t y) // Définition de la fonction
                                     // En entrée, les coordonnées
                                     // Pas de valeur de retour (void)
{
    const uint8_t zx = x / 2;       // Les mêmes calculs qu'en BASIC
    const uint8_t rx = x & 2;

    const uint8_t zy = y / 3;
    const uint8_t ry = y - (zy * 3);

    const uint8_t ch = 1 << (ry * 2 + rx);

    const uint16_t address = 0x4000 + zy * 80 + zx * 2;
    const uint8_t at = *((uint8_t*)address + 1);

    uint8_t old = 64;

    if (at & 0x80 == 0x80) {
        old = *((uint8_t*)address);
    }

    if (old & 0x80 == 0x80) {
        old = 64;
    }

    uint8_t new = ch | old;

    *((uint8_t*)address) = new;
    *((uint8_t*)address+1) = 224;
}

int main() // Je dois ajouter une fonction `main` pour que le fichier CRT puisse en trouver une.
{
    return 0;
}

J'ai globalement laissé les mêmes noms de variable que j'ai utilisé dans la version BASIC, et les mêmes calculs. C'est un portage simple, sans trop se poser de questions.

Le compilateur SCCZ80

Afin de transformer le code C en code machine, il me faut un compilateur qui sache sortir du langage machine Z80. J'en connais deux, mais il en existe d'autres. Le premier fait parti de l'environnement complet z88dk et se nomme SCCZ80. L'autre est SDCC, pour Small Device C Compiler. Ce dernier peut générer du code pour de nombreux microprocesseurs. Il peut être aussi utilisé par l'environnement spécialisé z80 qu'est z88dk.

Je commence avec SCCZ80 : zcc +vg5k -O3 -m c_setpoint_basic.c

+vg5k indique que à la suite que ma plateforme cible est un VG5000µ,
-O3 indique que je veux optimiser le code au niveau maximum,
-m indique que je veux générer un fichier avec des informations sur le résultat,
et enfin le nom du fichier en C.

Pour que la compilation fonctionne, je dois ajouter une fonction main(). En effet, le CRT (C Run Time) va chercher cette fonction main() pour l'appeler au démarrage. Or pour utiliser la fonction -m du compilateur, je dois construire une application complète.

Je pourrais tenter de compiler seulement le fichier .c en fichier objet (.o), malheureusement, comme on va le voir juste après, SCCZ80 appelle de nombreuses fonctions... Bref, c'est plus simple de faire une application complète.

Et cela me permet d'aller voir dans le fichier .map la taille de la fonction setpoint telle que compilée pour ce compilateur.

251 octets.

La fonction écrite à la main fait 196 octets, fonctions de multiplication et division comprises. Ici, c'est 251 octets sans les appels aux nombreuses fonctions donc le compilateur se sert.

Le compilateur SDCC

Avant d'aller plus loin, un petit essai avec SDCC donne 125 octets, auquel il faut ajouter la fonction de division, 42 octets, pour un total de 167 octets. C'est beaucoup mieux. C'est même mieux que le code écrit directement en assembleur, qui ne l'oublions pas utilise une table assez importante pour la division. Le code manuel du setpoint hors appels de fonction reste plus petit.

Par contre, SDCC fait grand usage des registres IX et IY. Et IX est strictement réservé par la ROM du VG5000µ, il faut l'utiliser avec des grandes précautions. Le fichier CRT du VG5000µ le préserve en sauvant sa valeur, et part du principe que l'on configure l'assembleur pour échanger l'utilisation de IY et IX (pour au final ne pas utiliser IX).

Pourquoi c'est si gros ?

Je reviens en premier lieu sur la compilation en SCCZ80. Ce compilateur part sur une stratégie : la compilation d'un programme entier doit donner un exécutable petit. Pour cela, les fonctions les plus courantes sont factorisées dans des routines assembleurs utilisées par le compilateur.

C'est le cas par exemple pour les fonctions de division et de multiplication. Mais c'est aussi le cas pour des services comme « aller chercher un entier sur la pile », utile dans le modèle C pour le passage de paramètres aux fonctions.

En regardant le code généré, on peut voir aussi beaucoup de manipulations de registres pour essayer de faire les calculs sur 8 bits que je demande. Ça à l'air un peu trop complexe. Et si on essayait de partir sur une base de calculs en 16 bits ?

Pour cela, je change les types uint8_t du code source ci-dessus en uint16_t.

216 octets ! Voici qui est beaucoup mieux.

Le compilateur SCCZ80 a donc l'air de mieux travailler avec des entiers de 16 bits. Cela est en partie du à l'utilisation de ces routines annexes, qui sont écrites avec un modèle sur 16 bits en tête. En demandant des calculs sur 8 bits, j'oblige le compilateur à sans cesse passer de 8 à 16 bits et inversement.

Et SDCC ? ... 183 octets. Là, ce n'est pas bon. De son côté, SDCC était plus efficace à faire ses opérations sur du 8 bits.

SDCC contrairement à SCCZ80, a pour objectif principal la vitesse d'exécution, quitte à avoir du code machine plus gros. Pour cela, certaines stratégies sont employées. Ici, tous les calculs sont faits sur place, avec des manipulations de registres, à l'exception notable de la division.

Du coup, travailler sur les registres 16 bits est un peu plus compliqué et cela a un impact direct sur la taille du code.

Est-ce qu'on peut aider ?

Première idée, puisque SDCC passe beaucoup de temps à récupérer les arguments de la fonctions, c'est de repasser ceux-ci sur 8 bits.

void setpoint(uint8_t x, uint8_t y)

Avec moins d'instruction d'accès à la pile, on fait gagner 10 octets à SDCC. Pas négligeable. Côté SCCZ80, c'est un gain de 3 octets. C'est toujours ça.

On peut aussi aider en utilisant une fonction de division par 3 spécialisé, comme en assembleur, sous cette forme :

static uint8_t div3_table[] = {
    0,0,0,1,1,1,2,2,2,3,3,3,4,4,4,5,5,5,
    6,6,6,7,7,7,8,8,8,9,9,9,10,10,10,11,11,11,
    12,12,12,13,13,13,14,14,14,15,15,15,16,16,16,17,17,17,
    18,18,18,19,19,19,20,20,20,21,21,21,22,22,22,23,23,23
};

uint8_t div3(uint8_t dividend)
{
    return div3_table[dividend];
}

La fonction de division générique utilisée pour SCCZ80 fait 37 octets et pour SDCC, 42 octets. La fonction par tableau utilisée ici est plus grosse, mais plus rapide.

Côté SCCZ80, on descend à 212 octets... Soit 1 octet de gain. Pas top. Côté SDCC, ça remonte même à 177 octets (ou 176 en jouant sur les tailles des types entiers).

Conventions d'appel

Lorsque l'on appelle une fonction avec des paramètres, il y a plusieurs moyens de les transmettre. On peut passer par une convention basée sur l'utilisation de registres, ou bien passer par la pile par exemple. Par défaut, les deux compilateurs passent pas la pile. Cependant, on peut indiquer à la fonction que l'on préfère passer par une autre convention lorsqu'il n'y a qu'un paramètre à la fonction.

Pour cela, on modifie la fonction div3 comme ceci :

uint8_t div3(uint8_t dividend) __z88dk_fastcall
{
    return div3_table[dividend];
}

Côté SDCC, la fonction div3 fond grâce au passage du paramètre et de la valeur de retour par le registre l. Plus besoin de mécanisme pour aller chercher la valeur dans la pile, calcul qui était généré de manière assez complexe par SDCC. La fonction passe de 27 octets à... 10 octets !

Le code généré est tout de même étrange :

_div3:
    ld  c, l                ; Sauvegarde de L dans C
    ld  de,_div3_table+0
    ld  l,c                 ; Récupération de C dans L... mais pourquoi ?
    ld  h,0x00
    add hl, de
    ld  l, (hl)
l_div3_00101:
    ret

Ce petit tour de passe-passe entre les registres C et L est inutile. L n'est pas utilisé entre temps, et C n'est pas utilisé ensuite. Voilà de quoi gagner 2 octets supplémentaire en réécrivant la fonction à la main.

Côté appelant, setpoint est aussi un peu simplifié et tombe à 174 octets.

Utilisons SCCZ80 à présent avec la même convention d'appel. La fonction initiale n'était pas très grosse, avec ses 14 octets, elle passe à 14 octets. Mais là encore les compilateur génère des choses étranges :

._div3
    push    hl          ; HL est poussé sur la pile
    ld  de,_div3_table
    pop hl              ; HL est récupéré de la pile
    push    hl          ; pour y être immédiatement remis
    ld  h,0
    add hl,de
    ld  l,(hl)
    ld  h,0
    pop bc              ; pour que la valeur soit ignorée...
    ret

Ces push et pop du registre HL sont rigoureusement inutiles. Il n'y a pas de valeur à préserver. Et au final, le contenu de la pile est extrait dans un registre dont on ne s'est pas servi BC mais qui du coup est invalidé. Ce sont donc 4 octets à économiser (et pas mal de cycles d'exécutions) en enlevant ces instructions. Cela nous amène à 10 octets.

La différence, si on oubli ces instructions inutiles, entre les deux codes générés est le LD H,0 (2 octets) pour s'assurer que la valeur de retour sur 16 bits est valide avec SCCZ80. SDCC ne prend pas cette précaution, à la charge de l'appelant de n'utiliser que la valeur du registre 8 bits L.

Et l'inlining ?

Une possibilité de compilation de l'appel d'une fonction est... de ne pas l'appeler, mais plutôt de faire comme si son code était « sur place ». C'est le mot-clé anglais « inline » qui nous permet de spécifier cela.

Côté positif, si le code de la fonction lui-même est petit par rapport au code nécessaire au passage des paramètres et code de retour, cela peut-être gagnant d'injecter le code sur place. Côté négatif, il est possible que ce code injecté un peu partout fasse augmenter la taille du code final.

inline uint8_t div3(uint8_t dividend)
{
    return div3_table[dividend];
}

Avec SCCZ80, je ne suis pas allé bien loin. L'utilisation de « inline » fait émettre des erreurs au compilateur. Je ne me suis pas penché plus sur le problème.

Avec SDCC par contre, non seulement le mot clé est pris en compte, mais le code est réduit de pas mal : 161 octets. Et forcément, pas de code généré pour div3. C'est plus petit que ce que j'avais écrit à la main (ce qui peut aussi s'expliquer par mes compétences limitées en assembleur Z80).

Conclusion

Le C est utilisable pour générer du code Z80. Les compilateurs utilisent des versions réduites du C actuel, mais néanmoins très corrects. Le bon côté est que le temps d'écriture du code, pour certaines opérations, est réduit, en tout cas pour moi.

Par contre, il est nécessaire de garder le code généré à l’œil. Celui-ci peut rapidement être gourmand ou générer des choses inutiles. Il faut alors se poser la question d'adapter se code et de le passer en assembleur, en perdant au passage la portabilité.

Cette portabilité reste limitée, puisqu'il est nécessaire d'aider fortement le compilateur.

VG5000µ, SetPoint en ASM, afficher le point

2018-05-29T00:00:00+02:00

À présent que l'on sait diviser par 3, reprenons l'affichage d'un point à l'écran. Pour rappel.

En entrée, nous avons : des coordonnées X et Y, comprises entre 0 et 79 pour X et 0 et 74 pour Y.

En effet de bord, c'est-à-dire en modification de l'état de la machine, nous voulons : le point correspondant à l'écran qui prend la couleur d'encre définie.

Pour cette version, la procédure ne prendra pas d'information de couleur, je me contenterai d'utiliser la couleur d'encre 0 (noir) sur fond 6 (bleu), qui est la combinaison à l'initialisation de la machine.

Les étapes, d'après les articles précédents, sont donc :

À partir de X et Y, trouver les coordonnées du caractère à modifier à l'écran
À partir de X et Y, trouver les coordonnées à l’intérieur du caractère semi-graphique
À partir de coordonnées du caractère, calculer l'adresse mémoire écran correspondante
Récupérer les valeurs pour la paire d'adresse mémoire
Si le caractère présent n'était pas un caractère semi-graphique standard, considérer qu'il était complètement éteint (valeur 0 pour le caractère)
Modifier la valeur du caractère récupéré en fonction des coordonnées à l'intérieur du caractère semi-graphique
Modifier la mémoire écran avec les nouvelles valeurs

Comme le code est plutôt long, je vais changer de méthode. Le code entier va suivre, commenté au maximum en ligne.

Le Code

        ; La procédure se nomme 'setpoint' et sera appelée avec `call setpoint`
        ;
        ; Les coordonnées (x,y) du point à allumer sont mises dans, respectivement
        ; L et H. Autrement dit, HL contient yx.
        ;
        ; C'est le format utilisé par la ROM du VG5000µ pour ses coordonnées de
        ; curseur. Autant le garder.
        ;
setpoint:
        ; La procédure sauve tous les registres exceptés IX et IY.
        ;
        ; On pourrait aussi considérer que c'est à l'appelant de veiller à
        ; garder ses registres intègres
        ;
        ; Ce n'est pas le plus efficace, mais pour le moment, c'est le plus sûr.
        push    hl
        push    bc
        push    af
        push    de

        ; Pour le moment :
        ; - HL contient les coordonnées (y,x)
        ; - Les autres registres sont libres

        ld      a,h             ; On travaille sur y
        call    div3            ; Que l'on divise par 3
        ld      d,a             ; Et donc D contient y/3

        ld      a,l             ; On travaille sur x

        ; La ligne suivante ne fonctionne que si C (le Drapeau de retenue)
        ; est bien à zéro (ce qui est assuré avec le div_3 utilisé)
        ; Sinon, il faudrait utiliser `srl a`, qui est codé sur deux octets plutôt que 1
        rra                     ; On divise A par 2
        ld      e,a             ; Et donc E contient x/2

        ; À ce point :
        ; - DE contient les coordonnées (y/3,x/2)
        ; - HL contient toujours les coordonnées (y,x)
        ; - Les autres registres sont libres

        ; B sera utilisé temporairement
        ld      a,l             ; On travaille à nouveau sur x
        and     $01             ; On ne garde de A que le bit de poids faible.
        ld      b,a             ; Et donc B contient x modulo 2 (le reste de la division entière par 2)

        ld      a,h             ; On travaille à nouveau sur y
        sub     d               ; On soustrait D, qui contient y/3 (partie entière)
        sub     d               ; Une seconde fois
        sub     d               ; Puis une troisième fois.
                                ; Et donc A contient y modulo 3

        ; On remarque ici qu'une fonction qui retournerait en même temps le quotient
        ; ET le reste de la division entière pourrait faire gagner un peu de temps...

                                ; On travaille dessus immédiatement sur (y modulo 3)
                                ; Dorénavant, j'utiliserai le signe % pour modulo.

        add     a               ; A contient à présent (y % 3) * 2
        add     b               ; A contient à présent (y % 3) * 2 + (x % 2)

        ; Petit point :
        ; - A contient la puissance de 2 nécessaire à trouver le bon caractère
        ; - DE contient toujours les coordonnées (y/3,x/2)
        ; - BC ne contient plus rien d'intéressant
        ; - HL ne contient plus rien d'intéressant
        ;   À vrai dire, HL n'est plus utile depuis le ld a,h précédent

        or      a               ; Équivalent à cp $0 mais plus conci et rapide
                                ; Le résultat de cette comparaison de A avec 0
                                ; va être conservé par les drapeaux jusqu'au
                                ; JR suivant, car les instructions LD n'altèrent
                                ; par les drapeaux.

        ; Il faut à présent calculer la valeur 2 à la puissance A

        ld      b,a             ; On charge B avec la valeur A. B va servir de
                                ; compteur de boucle.
        ld      a,1             ; On initialise le résultat à 1

        jr      z,no_power      ; Si A était égal à zéro, on n'a rien besoin
                                ; de calculer, donc on passe à la suite.

        ; La boucle suivante décale vers la gauche le contenu de A de 1 position
        ; Autrement dit, A est multiplié par 2 à chaque tour de boucle.
        ; À la fin de la boucle, A contient donc 2 puissance B.
power_of_2:
        rla                     ;
        djnz    power_of_2

no_power:
        ; A contient l'index du caractère semi-graphique à aller chercher.
        ; On sauve cette valeur pour plus tard dans la pile.
        push af

        ; Petit point :
        ; - HL est libre
        ; - BC est libre
        ; - DE contient les coordonnées (y/3, x/2)
        ; - A est sauvé sur la pile, on pourra donc l'utiliser pour des calculs

        ; L'objectif est à présent d'aller calculer l'adresse mémoire du caractère
        ; à changer dans la plage mémoire dédiée en RAM.

        ; La fonction de multiplication que j'utilise ici, et qui n'aura pas
        ; son article dédié, utilise HL et DE. DE est transféré dans BC.
        ld      b,d
        ld      c,e

        ; Et donc à présent DE est libre
        ; Et BC contient (y/3, x/2)

        ; Le premier calcul à faire est (y/3)*80
        ld      h,80            ; H contient 80
        ld      e,b             ; E contient y / 3

        call    mult            ; Appel de la multiplication
                                ; À présent, HL contient (y/3)*80

        ; Le second calcul à faire est d'arrondir X à l'entier pair
        ; inférieur le plus proche. Pour cela, (x/2)*2, en utilisant
        ; une division entière donne le ŕésultat.

        ld      a,c             ; A contient x/2 (division entière)
        add     a               ; A contient (x/2)*2 (division entière)

        ; Petit point :
        ; - HL contient le déplacement mémoire sur le début de la ligne
        ; - A contient le déplacement en colonnes sur la ligne
        ; - BC est libre
        ; - DE est libre

        ; Il faut donc additionner HL et A pour avoir l'index mémoire.
        ; Le Z80 ne peut pas faire ça directement. Il faut donc charger
        ; A dans un registre 16 bits. BC par exemple.
        ld      b,0
        ld      c,a

        add     hl,bc           ; HL contient à présent (x/2)*2 + (y/3)*80

        ; On se ressert de BC pour indiquer la base de l'adresse mémoire vidéo
        ; auquel on ajoute l'index, pour obtenir l'adresse mémoire dans HL.
        ld      bc,$4000
        add     hl,bc

        ; Il est temps d'aller chercher les informations déjà présentes
        ; en mémoire. Pour cela, on a besoin des deux adresses HL et HL+1
        ; (voir les articles sur l'agencement de la mémoire vidéo)
        ld      b,h
        ld      c,l

        inc     bc              ; BC contient HL + 1

        ld      a,(bc)          ; A contient donc la valeur d'attribut du caractère
        bit     7,a             ; Ce qui nous intéresse est sont bit numéro 7
        jr      z,set_base_char ; S'il est à 0, ce n'est pas un caractère semi-graphique

                                ; Sinon, on a besoin de connaître la valeur actuelle de ce
                                ; caractère

        ld      a,(hl)          ; On récupère la valeur du caractère semi-graphique
                                ; actuellement à l'écran dans A

        ; Si le caractère fait partie de la place 64 à 127 (les caractères pleins)
        ; alors on continue plus loin.
        bit     7,a
        jr      z,char_ok

set_base_char:
        ld      a,64            ; Dans le cas où le caractère à l'écran n'était pas
                                ; semi-grapique plein, on part sur une base du
                                ; caractère 64, qui est le caractère semi-graphique
                                ; 'tout éteint'
char_ok:
        pop     de              ; Recupération dans D de l'index du caractère calculé.
                                ; Cette valeur vient du 'push af' effectué plus haut.

        or      d               ; Une opération bit à bit 'OU' entre l'ancienne valeur
                                ; et le nouvel index donne le nouveau caractère.

        ld      (hl),a          ; Ce caractère est placé à l'écran

        ld      a,224           ; Et dans cette implémentation, on fixe les attributs
        ld      (bc),a          ; selon les valeurs de couleurs à l'allumage du VG5000µ
                                ; Une amélioration sera d'aller chercher dans les variables
                                ; systèmes quels sont les couleurs courantes.

        ; La routine se termine, on restitue la valeur de tous les registres
        ; utilisés pour revenir à l'appelant.
        pop de
        pop af
        pop bc
        pop hl


        ret

div3:                           ; Entrée: registre A, Sortie: valeur divisée par 3, dans A
        exx                     ;
        ld      hl,div3_table
        ld      b,0
        ld      c,a
        add     hl,bc
        ld      a,(hl)

        exx                     ;
        ret

div3_table:
        defb    0,0,0,1,1,1,2,2,2,3,3,3,4,4,4,5,5,5 ; 18
        defb    6,6,6,7,7,7,8,8,8,9,9,9,10,10,10,11,11,11
        defb    12,12,12,13,13,13,14,14,14,15,15,15,16,16,16,17,17,17
        defb    18,18,18,19,19,19,20,20,20,21,21,21,22,22,22,23,23,23

mult:                           ; Entrée, registre H et registre E
                                ; Sortie, le registre HL comtient le résultat
                                ; de l'opération H * E
                                ; Utilise HL, B, DE
        ld      d,0
        ld      l,d
        ld      b,8
mult_loop:
        add     hl,hl
        jr      nc,mult_skip
        add     hl,de
mult_skip:
        djnz    mult_loop
        ret

Comment est-ce que ça s'utilise ?

Cette routine s'utilise donc en mettant dans HL les coordonnées (y, x) du point à afficher. Elle pourrait être améliorée en déterminant si on veut afficher ou éteindre le point, spécifier les couleurs ou les récupérer des variables systèmes. Il y a probablement quelque optimisations qui trainent.

Toujours est-il que par rapport à la routine est basique, l'exécution sera beaucoup plus rapide. Il serait possible d'être encore plus réactif en s'adressant directement au processeur vidéo. Mais je préférais utiliser le buffer vidéo en RAM pour plus de simplicité. Une implémetnation utilisant le processeur vidéo peut se trouver dans la bibliothèque d'affichage de Z88DK pour le VG5000µ. Z88DK est tout un système, basé sur un compilateur C, pour programmer les machines Z80.

Pour revenir à l'utilisation de cette routine, voici un exemple qui affiche plusieurs lignes horizontales à l'écran.

        org     $7000

        ; Sauvegarde des registres utilisés.
        push    hl
        push    bc

        ld      h,$0A           ; La coordonnée y est 10 ($A en hexa)
        ld      b,25            ; On prépare une boucle de 25 itérations
loop_1:
        ld      c,b             ; Sauvegarde temporaire de la boucle externe
                                ; afin de préparer une boucle interne

        ld      l,$10           ; La coordonnée x est 16 ($10 en hexa)
        ld      b,40            ; On prépare une boucle de 40 itérations
loop_2:
        call    setpoint        ; On affiche un point
        inc     l               ; On incrémente la coordonnée x de 1
        djnz    loop_2          ; Et on boucle
                                ; Ce qui affiche une ligne de 40 pixels de large
                                ; à la coordonnée y courante.

        ld      b,c             ; Récupération de l'index de boucle externe

        inc     h               ; On incrémente la coordonnée y deux fois
        inc     h               ; on "saute" donc une ligne.

        djnz    loop_1          ; Et on recommence ceci 25 fois.
                                ; On affiche donc 25 lignes les unes sous les autres
                                ; séparées à chaque fois par une hauteur d'un pixel

        ; Restauration des registres utilisés et retour à l'appelant
        pop     bc
        pop     hl

        ret

Résultat

VG5000µ, SetPoint en ASM, diviser par 3 sans diviser

2018-04-15T00:00:00+02:00

Les trois derniers articles sur la division on permit de s'attarder sur trois manière de diviser un nombre entier par 3.

la première méthode effectuait une série de soustractions,
la seconde méthode utilisait la méthode scolaire,
la troisième méthode se servait de divisions par 4.

La méthode de cet article, qui sera le dernier avant de revenir à l'affichage d'un point, va diviser grâce à, globalement, une seule addition. Oui ! Une seule addition.

L'idée

Au tout début de la série d'articles sur la division, j'ai mis en place un système de tests pour m'assurer que mes bouts d'assembleurs faisaient ce qu'il étaient censés faire. Et pour cela, je comparais une série de divisions avec un tableau de résultats.

Mais alors, pourquoi ne pas utiliser un tableau de résultats directement ? On stock quelque part le résultat de toutes les divisions par 3 des nombres entiers de 0 à 255, et on va piocher dedans. Facile à implémenter, ultra rapide.

La contrepartie, évidemment, c'est que cela va prendre un peu de place. Mais voyons ce que cela donne.

Le code

Nul besoin d'une longue explication pour cette méthode. L'entier à diviser (le dividende) est dans le registre A, on l'ajoute à l'adresse du tableau des résultats pré-calculés, on récupère la valeur dans A et voilà !

div3_5:                         ; Entrée: registre A, Sortie: valeur divisée par 3, dans A
        exx                     ; Utilisation des registres secondaires
        ld      hl,div3_table   ; Chargement dans HL de l'adresse de la table des résultats
        ld      b,0             ; Mise à 0 de B
        ld      c,a             ; Placement de la valeur de A dans C
                                ; On a donc à présent le registre BC qui contient le dividende
        add     hl,bc           ; Addition du dividende et de l'adresse du tableau
        ld      a,(hl)          ; Récupération du résultat

        exx                     ; Échange des registres secondaires
        ret                     ; Retour à l'appelant.

div3_table:                     ; La table des résultats
        defb    0,0,0,1,1,1,2,2,2,3,3,3,4,4,4,5,5,5
        defb    6,6,6,7,7,7,8,8,8,9,9,9,10,10,10,11,11,11
        defb    12,12,12,13,13,13,14,14,14,15,15,15,16,16,16,17,17,17
        defb    18,18,18,19,19,19,20,20,20,21,21,21,22,22,22,23,23,23
        defb    24,24,24,25,25,25,26,26,26,27,27,27,28,28,28,29,29,29
        defb    30,30,30,31,31,31,32,32,32,33,33,33,34,34,34,35,35,35
        defb    36,36,36,37,37,37,38,38,38,39,39,39,40,40,40,41,41,41
        defb    42,42,42,43,43,43,44,44,44,45,45,45,46,46,46,47,47,47
        defb    48,48,48,49,49,49,50,50,50,51,51,51,52,52,52,53,53,53
        defb    54,54,54,55,55,55,56,56,56,57,57,57,58,58,58,59,59,59
        defb    60,60,60,61,61,61,62,62,62,63,63,63,64,64,64,65,65,65
        defb    66,66,66,67,67,67,68,68,68,69,69,69,70,70,70,71,71,71
        defb    72,72,72,73,73,73,74,74,74,75,75,75,76,76,76,77,77,77
        defb    78,78,78,79,79,79,80,80,80,81,81,81,82,82,82,83,83,83
        defb    84,84,84,85,85,85

Les instructions utilisées

Il n'y a pas vraiment de nouvelles instructions utilisées ici, mais de nouvelles formes :

Comme on ne peut pas additionner directement les registres HL et A, on doit passer la valeur de A dans un registre 16 bits. BC est souvent utilisé, mais ça aurait pu être DE.
Comme on ne peut pas charger le contenu de A directement dans BC, on le fait en deux étapes. Le registre 16 bits BC est constitué des deux registres 8 bits B et C. On place donc 0 dans B et C prend la valeur de A.
LD A,(HL) récupère la valeur pointée par le registre HL, plutôt que la valeur de HL. C'est-à-dire que l'octet à l'adresse mémoire pointée par HL est récupérée, puis chargé dans A.

C'est mieux du coup ?

D'un point de vu code de la fonction elle-même, c'est nettement mieux, 11 octets seulement. Par contre suivi d'un tableau de 255 octets. C'est donc à la fois le code le plus concis jusqu'à maintenant, mais aussi la fonction la plus grosse dans sa globalité.

Il est possible cependant de la réduire dans le cas présent. En effet, comme on ne divise que des numéros de lignes, on pourrait s'arrêter à 75 résultats. Cela donne 86 octets, c'est toujours plus imposant que les autres versions, mais un peu mieux.

Attention aussi, l'accès au tableau n'est pas protégé. S´il est plus petit que 255, rien n'empêche l'appelant de passer une valeur qui va déborder. Cela donnera des résultats faux.

D'un point de vu rapidité c'est constant et rapide : 15 cycles. Comme c'est une fonction très courte, il est possible aussi, au besoin, de l'inliner, c'est-à-dire de faire l'opération à l'endroit où elle est nécessaire plutôt que d'appeler une fonction. Cela économise le temps de mise en place et de retour de la fonction (les EXX et RET). On tombe alors à 10 cycles, que l'on peut potentiellement améliorer en utilisant les valeurs de registres au moment de l'appel.

Difficile de faire plus rapide comme méthode (à quelques astuces potentielles prêt).

Que choisir ?

C'est la question. Nous voici avec quatre méthodes pour diviser par trois. Deux sont des méthodes générales de division, deux sont spécialisées dans la division par 3. La première question à se poser est donc de savoir de quoi on a besoin.

Ensuite, nous avons des fonctions qui ont des compromis en terme de taille et de rapidité.

C'est ici qu´utiliser une fonction s'avère utile. Pour le moment, le choix n'a pas d'importance. Les quatre fonctions demandent un dividende dans A et retournent le résultat dans A. Il est donc possible de remplacer l'une par l'autre et de continuer le développement de l'affichage du point.

Il sera temps, ensuite, de choisir quelle méthode sera la plus adéquate.

Spoiler : probablement aucune de celles-ci en l'état, car nous allons avoir besoin du reste de la division par 3...

À la prochaine !

VG5000µ, SetPoint en ASM, diviser encore plus vite

2018-04-08T00:00:00+02:00

Dans le dernier article, j'avais cherché une version plus rapide pour effectuer une division par 3, toujours dans l'optique d'afficher un point à l'écran en transcrivant la routine écrite en BASIC vers de l'assembleur Z80.

Le résultat était mitigé : une routine en moyenne plus rapide et plus stable, mais sur le domaine de définition considéré (le nombre de lignes graphiques du VG5000µ), pas entièrement gagnante.

Dans cet article, je vais donc étudier une autre manière de faire, un peu différente. Alors que les deux premières implémentations permettait de diviser par n'importe quel nombre de 1 à 255, cette nouvelle version est spécialisée dans la division par 3.

Est-ce que cette spécialisation permettra de gagner en performance et/ou en taille ?

L'idée

Le Z80 n'a pas d'instruction pour diviser de manière générale, cela a déjà été mentionné dans les articles précédents. Par contre, il est tout à fait possible de diviser par des multiples de 2. Il suffit de décaler un nombre d'un bit vers la droite pour diviser un nombre entier codé en binaire par 2.

Exemple :

$00010010_{2}$ (18 en base 10) décalé vers la droite une fois donne $00001001_{2}$ (9 en base 10).

Il faut donc trouver une manière d'exprimer une division par trois à partir de divisions par des multiples de 2 aidées d’additions ou soustractions.

Le calcul est le suivant : on remarque tout d'abord que n'importe quel nombre entier n peut s'écrire sous la forme $n = 4\times a + b$, avec $b$ inférieur à 4. Autrement dit, sous forme d'une division par 4 plus le reste de la division entière. Trouver $a$ et $b$ est donc simple. $a$ est le résultat de la division entière (quotient) de $n$ par $4$. $b$ le reste de la division entière de $n$ par $4$.

Sous cette forme, par exemple, $15$ s'écrit $4\times3 + 3$.

Puisque l'on veut diviser n par 3, écrivons le résultat à partir de cette forme $\frac{n}{3} = \frac{4\times a + b}{3}$

On n'est pas très avancé, il faudrait trouver dans l'expression un terme ou une forme que l'on connaît déjà qui nous permettrait de converger vers le résultat.

Sortons $a$ de la fraction : $\frac{n}{3} = \frac{3\times a}{3} + \frac{a + b}{3} = a + \frac{a + b}{3}$.

Ça c'est intéressant. Le résultat que l'on cherche est égal à $a$, donc le résultat de la division par $4$ additionné à... un quelque chose. Et ce quelque chose est un nombre que l'on voudrait diviser par 3 !

Appelons ce nombre $n_{1}$, cela donne : $\frac{n}{3} = a + \frac{n_{1}}{3}$.

Ce terme $\frac{n_{1}}{3}$ peut lui-même être écrit sous la forme : $\frac{n_{1}}{3} = \frac{4\times a_{1} + b_{1}}{3} = a_{1} + \frac{a_{1} + b_{1}}{3}$, c'est-à-dire sous la forme d'une division par 4 de $n_{1}$ et d'un quelque chose d'autre.

Et ainsi de suite... Jusqu'à ce que $n_{i}$ soit inférieur ou égal à 3. Dans ce cas, il y a deux cas : soit $n_{i} = 3$ et diviser ce nombre par $3$ donne $1$. Soit $n_{i} < 3$ et ce nombre divisé par $3$ donne $0$.

Exemple

Revoyons l'exemple avec 15 (pour plus de cohérence, j'ajoute l'indice 0 aux premiers termes) :

$\frac{15}{3} = \frac{4\times a_{0} + b_{0}}{3}$. On trouve les termes de la division par 4 : $a_{0} = 3$, $b_{0} = 3$

Donc $\frac{15}{3} = 3 + \frac{3 + 3}{3} = 3 + n_{1}$.

Il s'agit donc à présent de trouver $\frac{n_{1}}{3} = \frac{3 + 3}{3} = \frac{6}{3} = \frac{4 \times a_{1} + b_{1}}{3}$.

Comme $6 = 4 \times 1 + 2$, on a $a_{1} = 1$ et $b_{1} = 2$.

Donc $\frac{n_{1}}{3} = 1 + \frac{1 + 2}{3} = 1 + \frac{3}{3}$. On est dans le cas où le nombre restant est égal à $3$, on sait calculer facilement sa division par $3$, c'est $1$.

Si on remonte tout ça dans l'expression initiale on a donc :

$\frac{15}{3} = 3 + (1 + (1)) = 5$

L'implémentation

Pour cette implémentation, mis à part le dividende, nous avons besoin :

d'un résultat intermédiaire dans lequel on va additionner les différents termes $a_{i}$ au fur et à mesure des itérations
- dans l'exemple précédent, on y mettra la première fois $3$, puis on y additionnera $1$
- j'utiliserai pour ça le registre E.
d'un dividende intermédiaire à diviser par 3 (les termes $n_{i}$)
- ce nombre est le dividende donné au début
- puis il est remplacé par la somme du quotient et du reste de la division par 4 du dividende actuel
- j'utiliserai pour ça le registre A.

J'aurai aussi besoin d'autres registres pour la division intermédiaire par 4.

Les opérations seront :

Tant que le dividende actuel (A) est supérieur à 3 :
- On sauve le dividende dans B.
- On divise A par 4 (stocké temporairement dans D)
- On ajoute A au résultat intermédiaire E
- On récupère le dividende depuis B vers A
- On prend le reste de la division de A par 4, qui reste dans A
- On ajoute D à A, ce qui donne le nouveau dividende A
Si A est égal à 3, on ajoute 1 au résultat E. Sinon rien.

Cette valse des registres est nécessaire car quelques opérations opérations utilisées ne sont possible, sur Z80, que sur l'accumulateur, et pas sur les autres registres.

Le code

div3_4:                         ; Entrée: registre A, Sortie: valeur divisée par 3, dans A
        exx                     ; Utilisation des registres secondaires
        ld      c,3             ; Initialisation du diviseur
                                ; Il est fixe dans cette implémentation
                                ; mais est nécessaire pour la comparaison
        ld      e,0             ; Initialisation du résultat

div3_4_loop:
        cp      c               ; Comparaison de `C` et `A`
                                ; le registre `A` est implicite, le Z80
                                ; ne peut comparer qu'avec le registre A
        jr      c,div3_4_exit   ; Branchement si A est inférieur à C (donc A < 3)
        jr      z,div3_4_end    ; Branchement si A est égal à C (donc A = 3)

div3_4_cont:
        ld      b,a             ; A est sauvé dans B
        srl     a               ; A est décalé d'un bit vers la droite
        srl     a               ; A est décalé d'un bit vers la droite
                                ; Ces deux décalages forment une division par 4
        ld      d,a             ; Le résultat de la division entière est
                                ; stockée dans D
        ld      a,e             ; A prend la valeur du résultat intermédiaire A
                                ; C'est nécessaire pour faire l'addition suivante.
                                ; Le Z80 ne sait additionner qu'avec l'accumulateur
                                ; quand on traite des valeurs sur 8 bits.
        add     a,d             ; On ajoute le résultat de la division et
                                ; le résultat intermédiaire.
        ld      e,a             ; Ce résultat intermédiaire et remis dans E
        ld      a,b             ; Le dividende actuel est mis dans A afin de faire
                                ; l'opération suivante.
        and     $03             ; Calcul du reste de la division par 4
        add     a,d             ; On ajoute à ce reste le quotient de la division
                                ; Et donc A contient le nouveau dividende.
        jr      div3_4_loop     ; C'est donc reparti pour un tour.

div3_4_end:
        inc     e               ; On arrive ici si le dernier dividende est 3.
                                ; dans ce cas, on ajoute 1 au résultat final.
div3_4_exit:
        ld      a,e             ; Le résultat final est stocké dans A
        exx                     ; Échange des registres secondaires
        ret                     ; Retour à l'appelant.

Les instructions utilisées

Les instructions déjà utilisées dans les articles précédents ne sont pas répétées ici, les nouvelles sont :

srl décale le registre indiqué de 1 bit vers la droite. Le bit sortant est stocké dans le drapeau de retenu, mais ici, on ne l'utilise pas.
and effectue une opération bit à bit entre l'accumulateur et l'opérande. Le résultat de chaque bit est 1 uniquement si les bits de chaque terme étaient 1 sur la même position.
- Exemple : 11111000 and 00011111 donne 00011000, car seuls le 2 bits centraux sont à 1 dans les deux termes.
- Ici, on s'en sert pour prendre le reste de la division par 4. Pourquoi est-ce que ça donne ce résultat est laissé en exercice.

Bon alors, c'est mieux ?

Un petit calcul donne pour cette troisième version :

29 octets. Encore plus grand.
Le nombre d'étapes maximum à faire donne 84 cycles. C'est un peu mieux. Dans le domaine de définition de l'affichage d'un point, le nombre à diviser le plus grand est 75, et cela donne alors 56 cycles.

Ce qui fait que la première version n'est plus rapide que pour les nombres jusqu'à 5. Cette version est intéressante et offre un bon compromis entre taille du code et vitesse d'exécution. Au détriment de la flexibilité, puisque le calcul n'est valable que pour une division par 3.

Le principe de l'algorithme pourrait être étendu à plus de nombres, mais au prix d'un taille plus grande et d'un fonctionnement un petit peu plus long. De toute façon ici, on ne s’intéresse qu'à une division par 3.

La fois prochaine, on verra une dernière manière de faire, et puis on reviendra à l'étape suivante de l'affichage d'un point.

VG5000µ, SetPoint en ASM, diviser plus vite

2018-03-29T00:00:00+02:00

Dans le dernier article, j'avais écrit une première manière d'effectuer une division, en spécialisant la routine pour une division par 3 puisque c'est ce qui m'intéresse pour afficher un point à l'écran du VG5000µ.

Pour référence, cette routine nécessitait 15 octets en mémoire et son exécution pouvait prendre jusqu'à 695 cycles, ce qui est plutôt grand.

Micro optimisation

La première optimisation est une micro optimisation. On appelle micro optimisation une amélioration de la routine par un détail de fonctionnement, plutôt que par une réflexion sur l'ensemble de la méthode.

Ici, l'idée est de remplacer le couple push bc / pop bc en début et fin de la routine par un couple exx / exx. L'instruction exx du Z80 effectue un renommage des registres BC, DE et HL. Ces registres (ainsi que d'autres, mais qui ne sont pas touchés par cette instruction) existent en deux exemplaires dans le Z80. Un exemplaire de chaque registre est utilisé pendant que l'autre ne l'est pas. Il est possible d'échanger les rôles de ces paires.

On peut imaginer un aiguillage devant les registres. Le flux de données est aiguillé soit vers l'un des registres de la paire, soit vers l'autre. L'instruction exx s'occupe de modifier l'aiguillage des registres BC, DE et HL. Les registres inactifs sont nommés BC', DE' et HL'.

Puisqu'en entrée de la routine, je n'utilise que le registre A, mais que j'ai besoin des autres registres pour les calculs, je peux préserver les valeurs que les registres ont en entrée de fonction en utilisant l'autre série de registres.

Les instructions push bc et pop bc prennent chacun 3 cycles à s'exécuter. exx n'en prend qu'un. On passe donc de 6 cycles à 2, pour un gain de 4.

Ce n'est pas grand chose par rapport au temps d'exécution de la routine elle-même, c'est donc une micro optimisation. Mais elle est simple à faire. La routine passe de 15 octets à 13.

Une autre micro optimisation consiste à éviter un test en initialisant B à -1 plutôt que 0. Mais comme ce n'est pas sur cette routine avec des micros optimisations que l'on va vraiment gagner, je laisse de côté.

Division comme à l'école

La première méthode de division, celle de l'article précédent, se faisait par soustractions successives. Tant que l'on pouvait soustraire le diviseur du dividende, on le faisait, tout en comptant le nombre de fois que cette soustraction était faite. Ce nombre de soustractions est le résultat de la division.

Ce n'est pas comme cela que vous avez appris à diviser à l'école. Si on a appris la même méthode, à quelque chose comme ce qui suit.

Pour diviser (en base 10), 424 par 3, on pose :

Puis on regarde si l'on peut diviser le premier 4 du dividende par 3. Oui, cela donne 1. On pose donc 1 dans le résultat et le résultat de la soustraction sous le 4 :

   421 | 3
  -3   |---
   -   | 1
   1   |

On passe au chiffre suivant, que l'on descend au niveau du 1. Cela donne 12, que l'on essaye de diviser par 3. Ok, cela donne 4, que l'on note dans le résultat. Le reste de la soustraction est noté sur la gauche du trait vertical :

   421 | 3
  -3   |---
   -   | 14
   12  |
  -12  |
   --
    0

On passe au chiffre suivant, que l'on descend au niveau du 0. Cela donne 1. On essaye de diviser par 3. Cela donne 0, car 1 est plus petit que 3. On note donc 0 à la suite du résultat, on soustrait sur la gauche (on soustrait 0 du coup) :

Il n'y a plus de chiffre à traiter au dividende. Le résultat de la division est dans 140, et le reste 1.

Faire une division avec cette méthode, c'est dérouler un algorithme. Et on peut transposer ça à l'ordinateur. On ne peut pas utiliser de division en base 10 puisque c'est exactement ce qu'on essaie ici d'implémenter. Mais sous forme binaire, le processeur a les instructions nécessaires.

Faisons un essai. Divisons $101_{2}$ par $10_{2}$ (en binaire, indiqué par le petit 2, donc 5 par 2 en décimal) selon la même méthode.

   101 | 10
       |----
       |

On commence donc par prendre $1_{2}$ et essayer de diviser par $10_{2}$. Mais... il n'y a pas d'instruction de division sur le Z80 ! Qu'à cela ne tienne, nous sommes en binaire, et les deux seuls résultats possibles en binaire sont $0_{2}$ et $1_{2}$.

Autrement dit, soit le nombre que l'on considère est plus petit que le diviseur et le résultat est $0_{2}$, ce qui implique que l'on ne soustrait rien du tout au dividende. Soit le résultat est $1_{2}$, ce qui implique que l'on soustrait le diviseur au dividende.

Puis on adjoint à ce résultat le chiffre binaire suivant.

Autrement dit, nous n'avons besoin que de décalages et de soustractions.

   101 | 10
  -0   |----
   -   | 0
   10

On considère donc $10_{2}$ qui n'est pas plus petit que le diviseur (il est même égal). Le résultat à retenir est donc 1 et l'on soustrait le diviseur :

On considère $1_{2}$, qui est plus petit que le diviseur. On ne soustrait donc rien, on note 0 et... c'est terminé.

Le résultat de $101_{2}$ divisé par $10_{2}$ est donc $10_{2}$, reste $1_{2}$. Soit en base 10 : 5 divisé par 2 est égal à 2 reste 1.

Algorithme

Pour implémenter cet algorithme, j'ai besoin de plusieurs choses:

De quoi retenir le nombre à considérer en cours,
De quoi retenir ce qu'il reste du dividende à considérer,
Le diviseur,
De quoi retenir le résultat en cours.

Pour se simplifier la vie, on va considérer les 8 bits du dividende, même s'ils commencent par des 0. Lorsque l'on pose une division manuellement, on sait que des zéros en début de nombre donnent des zéros en début de résultat. Aucun de ces zéros ne sont significatifs.

Pour notre calcul, il est plus simple de dérouler l'algorithme sur l'intégralité du nombre en binaire.

Cela donne donc cela:

Initialiser un registre comme compteur de bits à 8 (on a 8 bits à traiter)
Initialiser un registre contenant le diviseur
Initialiser un registre contenant le dividende (il est initialement dans A, mais ce registre, l'accumulateur, va être nécessaire pour certaines opérations)
Initialiser un registre à 0 pour retenir le reste

Ensuite, tant que le compteur de bits est positif, on déroule ce qui suit:

On décale les bits du résultat de 1 vers la gauche en insérant un 0 à droite
- par exemple, si le résultat est actuellement 101, il devient 1010
On décale les bits du dividende de 1 vers la gauche aussi, en insérant un 0
- même chose
On décale les bits de l'accumulateur de 1 vers la gauche, mais en insérant cette fois le bit qui est sorti du dividende par la gauche lors de l'opération précédente
- par exemple, si le dividende était 11000000, il a été décalé en 10000000 et le 1 est sorti
- si l'accumulateur contenait 00000010, il est décalé en 00000101.
On compare le contenu de l'accumulateur avec le diviseur.
Si l'accumulateur est égal ou plus grand que le diviseur:
- on soustrait le diviseur de l'accumulateur
- on ajoute 1 au résultat courant
Sinon, rien... vu qu'on a décalé le résultat, il contient un 0 en dernière position.
On décrémente le compteur de bits.

Registres

Les registres utilisés sont les suivants :

B est utilisé pour le compteur de bits.
- C'est un choix naturel sur le Z80 qui permet d'utiliser l'instruction DJNZ qui décrémente B et fait un saut conditionnel si B n'est pas égal à 0.
C contient le diviseur.
D contient le dividende (il faut donc y transférer A).
E contient le résultat (qu'il faut donc initialiser à 0).

Le code

div3_3:                         ; Entrée: registre A, Sortie: valeur divisée par 3, dans A
        exx                     ; Utilisation des registres secondaires
        ld      b,8             ; Initialisation du compteur de bits à 8
        ld      c,3             ; Initialisation du diviseur
        ld      d,a             ; Transfert du dividende dans D
        xor     a               ; Mise à 0 de l'accumulateur
        ld      e,a             ; Mise à 0 du résultat

div3_3_loop:
        sla     e               ; Décalage de E vers la gauche
                                ; Le drapeau `Carry` contient le bit fort de E (qui est 0)
        sla     d               ; Décalage de D vers la gauche
                                ; Le drapeau `Carry` contient le bit fort de D
        rla                     ; Décalage de A vers la gauche, avec récupération de la
                                ; valeur de `Carry`
        cp      c               ; Comparaison de C et A
        jr      c,div3_3_skip   ; Si C est plus grand que A, saut plus loin
        sub     c               ; Sinon, A est réduit de la valeur de C
        inc     e               ; Et E est augmenté de 1
div3_3_skip:
        djnz    div3_3_loop     ; B est décrémenté et s'il n'est pas égal à 0,
                                ; on repart en début de boucle

div3_3_end:
        ld      a,e             ; Le résultat est transféré dans A

        exx                     ; Échange des registres secondaires
        ret                     ; Retour à l'appelant.

Les instructions utilisées

Les instructions déjà utilisées dans les articles précédents ne sont pas répétées ici, les nouvelles sont :

exx a déjà été expliqué en début d'article sur la micro optimisation.
xor effectue une opération de ou exclusif pour chaque bit de même position entre l'accumulateur et le registre mentionné.
- Dans un ou exclusif, le résultat est 1 uniquement si l'on des deux bits est à 1.
- C'est impossible ici puisque l'opération est effectuée entre l'accumulateur et... l'accumulateur.
- Le résultat est de mettre l'accumulateur à 0.
- C'est un idiome classique, car un LD A,0 prend deux octets en mémoire et deux cycles, alors que XOR A ne prend qu'un seul octet et 1 cycle.
xor a suivi de ld ?,a entre registre. C'est aussi un schéma classique.
- Transférer entre deux registres prend un octet et un cycle, on profite donc d'avoir initialisé l'accumulateur pour initialiser un autre registre à la même valeur de manière efficace.
djnz, comme indiqué au-dessus, effectue plusieurs opérations. Tout d'abord, B est décrémenté. Puis si B est égal à zéro, l'instruction se termine. Sinon, un branchement à lieu à l'adresse indiquée en paramètre.

Et c'est mieux ?

Un petit calcul donne pour cette nouvelle version :

23 octets... c'est moins bien que 12 octets avec les deux micro optimisations, certes.
Entre 103 et 111 cycles en fonction du nombre de 1 dans le résultat.

Niveau vitesse, c'est beaucoup moins qu'avant la méthode précédente ! La routine est peut-être deux fois plus grosse, mais elle est beaucoup plus stable en temps d'exécution et en moyenne plus rapide.

Oui mais attention ! Si elle est plus rapide dans le cas général, dans le cadre de l'affichage d'un point, le nombre maximal à diviser est 75. Et pour 75, la vitesse de la première version est de 215. En fait, pour tout dividende inférieur à 36, la première version de la division par 3 est plus rapide.

Note de fin d'article : on peut micro-optimiser le code ci-dessous en se passant de E et en stockant le résultat dans D au fur et à mesure de son décalage (qui libère de l'espace au fur et à mesure). Cela évite deux LD et un SLA, ce qui rend la fonction compétitive plutôt vers 34.

Visite au Computer History Museum

2018-03-28T00:00:00+02:00

La semaine dernière, profitant d'un voyage à San Francisco, j'ai allongé un peu mon séjour pour pousser jusqu'à Mountain View et aller visiter un musée qui semblait fort intéressant. Le Musée de l'Histoire des Ordinateurs, ou dans le texte « Computer History Museum »

Première chose à savoir si vous êtes à San Francisco même, que vous choisissiez le train (pas cher, mais long, avec changement) ou la voiture (plus cher, un peu moins long), prévoyez le trajet pour ne pas arriver trop tard. En effet, le musée ferme assez tôt : 17h.

En voiture, tant qu'à visiter, vous pourrez faire un détour par la 280 pour passer par des endroits sympas ou la 1 pour des endroits encore plus sympa, à l'aller ou au retour. Ou opter par la 101 pour aller au plus direct (mais potentiellement aussi plus encombrée, vérifiez avant de partir).

De notre côté (puisque nous étions deux), nous avons opté par un peu de balade sur le chemin.

Arrivé au musée et ayant acquitté notre droit d'entrée, après une petite explication de l'agencement à l'accueil et la remise d'un plan, nous voici parti pour une aventure d'environ quatre heures.

Coup de bol ? Ce jour là, des étudiants du coin faisaient une démonstration à l'entrée d'appareils fonctionnels et d'artefacts divers (comme un reste de Silicon après découpage de Wafers). Les visiteurs pouvaient donc goûter au plaisir de perforation d'une carte (c'est un plaisir quand c'est dans un musée...).

Puis la visite commence. Un petit film d'introduction peut être visionné, mais je ne l'ai pas fait, j'avais hâte de voir du concret.

L'exposition principale est divisée en 20 zones thématiques et globalement chronologique. Globalement car les époques recouvertes par les thèmes se superposent dans l'histoire des ordinateurs. La première zone est consacrée au calcul, le besoin initial à la base de tout ça. Règles à calcul, bouliers (que l'on peut manipuler), métier de « calculateur » permettant de dresser les tables de fonctions.

Mais encore calculatrices, mécaniques tout d'abord puis électroniques (mais non programmables). Et que serait cet endroit sans la réplique de la sous-partie de démonstration de la Machine à Différences de Charles Babbage ? Près de là, les plans de la Machine Analytique du même inventeur, bien entendu avec mention des travaux d'Ada Lovelace.

Suit un très intéressant reportage sur la culture d'entreprise d'IBM au début du XXième siècle. Le musée est comme cela ponctué de nombreux reportages ou extraits de films, interviews et reportages d'époque. Il y en a vraiment beaucoup et malgré les quatre heures de visite, je n'ai pas tout pu regarder.

Ce passage est dans la zone 2, consacrée aux cartes perforées, dont IBM fut un grand fournisseur.

De là, on passe en zone 3, consacrée aux calculateurs analogiques et des « batailles » qui s'ensuivent entre les modèles numériques et les modèles analogiques, ainsi que des fusions entre les deux systèmes.

Une machine analogique câblée nous montre bien la similitude avec l'état de certaines bases de code actuelles...

Peut-être préférez-vous le câblage suivant.

Les zones suivantes sont consacrées à la naissance des ordinateurs ainsi qu'à l'histoire des premières compagnies à se lancer dans le secteur. On y trouve quelques ordinateurs à lampes de dimensions conséquentes, comme des morceaux d'ENIAC.

Le musée présente aussi des blocs de bases d'un ordinateur dans leurs formes d'alors, et rappellent que des pistes initiales se tournaient vers la mécanique. Sur l'image suivante, une porte logique mécanique à gauche (a priori un inverseur), et une additionneur/soustracteur à lampe à droite.

La zone suivante, la 6, nous amène aux besoins de calculs en temps réel et nous rappelle les besoins de l'armée, toujours très gourmande en calculs pour la balistique. Et très avide d'information à des fins de surveillance dans une époque de guerre froide. Des éléments du système SAGE sont exposés.

Tout cela demande de la puissance de calcul grandissante, et nous entrons à présent dans la zone 7, dédiée aux Mainframes. L'IBM 360 y trône en bonne place, avec ses beaux dérouleurs de bande rouge et bleus.

Et avec des possibilités de calculs grandissante vient les besoins en stockage grandissants eux aussi. La zone 8 s'intéresse à la mémoire, qu'elle soit persistante ou non. En partant de quelques artefacts très lointains, comme un système de stockage d'information Inca utilisant des cordes, on arrive sur des systèmes plus récents. Un mur de stockage présente de nombreux systèmes : lecteurs de disquettes, cartouches, cassettes, disques magnétiques...

Tout ça, c'est bien beau, mais sans logiciel, cela ne va pas bien loin. C'est la zone 9 qui présente la programmation. Le musée est principalement focalisé sur le matériel, et si le logiciel est toujours dans l'air, ce n'est pas sont point central (voir plus loin pour la section déportée du musée). À un mur, une fresque généalogique des différents langages de programmation s’étale sur quelques mètres. C'est une version cependant très simplifiée, même si les jalons essentiels sont là.

Une film explicatif constitue la principale attraction de la zone. Il faut dire que ce n'est pas si évident de montrer du logiciel dans un contexte de vieilles machines dont la plupart ne fonctionnent pas et qui étaient utilisées principalement pour des calculs scientifiques, militaires et des traitements administratifs.

Ah si, tout de même, un badge DECUS rappelle que le principe du partage de logiciel via des sources de code ouvertes ne date pas d'hier, puisque le groupe a été créé en 1961 et que la pratique le précédait.

Si les Mainframes, c'était du trop petit pour vous, la zone 10 en remet une couche avec une présentation de Super Ordinateurs. Forcément, vu la place que cela prend, il n'y a pas beaucoup de pièces. On y trouve aussi un cluster de PCs. Bien entendu, que serait une section Super Ordinateurs sans Cray.

Un film rapide retrace au passage la vie de Seymour Cray et des particularités de ses ordinateurs.

Ils ont plein de petites LEDs qui clignotent et des petits leviers tous sympas, ils sont tout minis se sont les... Minis Ordinateurs de la zone 11. Des PDP-8, PDP-11, du HP, du CDC, un modèle de PDP-8 qui a servi pour des opérations chirurgicales du cerveau et a permis d'effectuer celles-ci avec endormissement du patient (car donc, apparemment, auparavant, le patient devait rester réveillé...)

Bien évidemment, la section évoque UNIX et présente un manuel d'époque.

Puis l'on passe en zone 12, consacré à la logique numérique au cœur du fonctionnement de toutes ces machines jusqu'à nos tablettes et téléphones actuels. Quelques portes logiques peuvent être actionnées avec des interrupteurs (dommage, le Flip Flop ne fonctionnait pas à cause d'un bouton défectueux). Un film présente les étapes de fabrication d'un circuit intégré, et l'on peut regarder à la loupe plusieurs générations de ces puces. Quelques wafers de différentes tailles accompagnent le tout.

La zone 13 est consacrée à la robotique et à l'intelligence artificielle, avec de nombreux robots vintage en exposition. Mes photos de cette section étant toutes floues, passons.

En zone 14, on découvre la thématique de la création artistique à travers l'outil informatique. Ici, à côté d'un cube de PIXAR, de système SUN, de tables traçantes et de synthétiseurs, on trouve une machine au logo qui aura marqué une époque en image numérique.

J'y ai découvert aussi un accessoire pour Commodore 64 que je ne connaissais pas du tout. Le Incredible Music Keyboard, qui se place au dessus de la coque d'un C64 pour le transformer en synthétiseur. J'aurais du mieux regarder la chaîne 8-Bit Keys, qui en fait une présentation.

La zone 15 s'intéresse au périphériques d'entrées et sorties. Le coin est plutôt fourni en périphériques exotiques, dont beaucoup étaient des idées... intéressantes. Et dont d'autres ont eu plus de succès. Et quoi de mieux pour accueillir le visiteur dans cette zone que le très à propos Xerox Alto.

La zone 16 est consacrée aux jeux vidéo. Pas de trucs renversants à ce niveau-là, beaucoup de musées de vieilleries informatiques se focalisant essentiellement sur le matériel de jeu, il est difficile de faire original. Trois pods de démonstrations permettent de jouer à des jeux assez différents : un jeu d'aventure textuel, Spacewar! et PAC-MAN. Les trois en « reproduction » (plutôt des recréations que de l'émulation j'ai l'impression... mais je n'en sais rien).

Bref, passons ici aussi.

La zone 17 présente l'ordinateur personnel. Le Micro, ça y est, l'ère grand public (ou presque) commence. C'est un IBM PC qui nous reçoit dans la zone. Vu la taille de ces nouvelles machines, de nombreuses pièces différentes sont présentées. Apple I et II, TRS-80, Commodore PET, Atari 800XL, Lisa,...

Mais aussi de l'exotisme (vu des Etats-Unis), avec un Smaky, un Amstrad 464, du Spectrum,... Un clone russe de ZX Spectrum.

Et un Thomson TO7-70 ! Malheureusement un peu dans l'ombre.

Et puisqu'on est dans l'ordinateur français, un petit Micral.

Toute une partie est à l'honneur du Do It Yourself de l'époque : ces machines que l'on pouvait recevoir en kit, ou bien dont on ne recevait que des parties essentielles, à compléter ensuite, en suivant éventuellement un plan dans un magazine.

Ici, un Altaïr 8800 côtoie (mais de pas trop près) un Imsai 8080. Mais aussi un EDUC-8 Australien (que je ne connaissais pas), une carte KIM-1 et de nombreux autres.

De la zone 17 on passe à la zone... 18 ! Celle-ci présente l'informatique mobile. En partant des portatifs initiaux (et de publicités où l'on voit des utilisateurs suer avec le sourire en traînant une mallette de plomb signe de leur modernité), on passe par les ordinateurs portables de différentes époques et les organiseurs personnels.

Le pôle interactif offre de soulever un Osborne 1 dans sa malette, pour juger du temps pendant lequel nous aurions pu garder le sourire en se baladant avec. On est loin des quelques centaines de grammes de tablettes actuelles.

La zone 19 présente la mise en réseau, en commençant par le commencement : la mise en relation de personnes à distance. Télégraphe, puis téléphone, avec des cartes de l'évolution des lignes reliant les continents.

Un petit bouton permet de retrouver le délicieux son d'une communication entre ordinateurs via Modem.

Est exposée aussi une des premières armoire à serveurs de Google, tout un tas de modems, de routeurs et autres matériels de communication. Des initiatives aussi, comme les ordinateurs communautaires hippies.

Côtés ordinateurs associés à cette thématique, un NeXT Cube, mais aussi un Minitel, expliquant que bien avant l'essor grand public d'Internet, en France, il était possible d'aller chercher des renseignements en ligne ou de réserver un train.

La dernière zone, la vingtième est une zone tournée vers l'avenir. Principalement un film interviewant quelques personnalités de la Silicon Valley. J'avoue ne pas l'avoir regardé. on sort avec cette zone de l'Histoire pour entrer dans l'actuel, et l'actuel est tous les jours.

C'est ainsi que se termine la visite de l'exposition principale. Mais pas du musée.

PDP-1 et Spacewars!

Si la quasi totalité des machines exposées ne sont pas en fonctionnement, le musée possède deux salles consacrées à deux machines emblématiques restaurées et en état de fonctionnement.

La première salle est celle du PDP-1.

La vénérable machine n'est cependant allumée que deux fois par mois à un horaire bien précis... Et le jour de ma visite n'était pas un jour de démonstration. C'est dommage, mais tant pis.

La démonstration consiste, entre autre, à lancer le jeu Spacewars! Il est même possible d'y jouer, avec des contrôles déportés dans la zone visiteur. Le stylo optique est aussi fonctionnel.

IBM 1401

La seconde salle est encore plus vaste et est utilisée pour une installation d'IBM 1401. Un film explique l'histoire de sa restauration, qui aura été longue et fastidieuse.

Là encore, il faut tomber le bon jour et la bonne heure pour la démonstration. C'était le bon jour, mais nous sommes arrivés après la mise en route, qui a lieu le matin.

Mais même éteinte, la machine est impressionnante.

Le reste

Et ce n'est pas fini. Mais le musée allait fermer 30 minutes après et j'ai parcouru le reste un peu plus rapidement. J'ai dédié la majeure partie du temps restant à l'exposition sur Ada Lovelace, qui présente quelques manuscrits de sa main et lettres de Charles Babbage à son attention. Qui retrace aussi en quelques panneaux sa vie.

À côté, une mini expo sur les transports automatisés, qui me semble est surtout une excuse pour présenter la voiture toute ronde de chez Google.

Le dernier grand espace est dédié au logiciel sous différents aspects : jeu, musique, image, connaissance, simulation, industrie textile. Chaque poste montre l'évolution du travail dans ces domaines avec l'arrivé de l'informatique. Par exemple en juxtaposant le développement de pellicule en chambre noir et Photoshop.

Exposition plutôt bien faite, mais que j'ai traversée un peu en coup de vent. Je n'étais pas venu pour cela.

Conclusion

Ce musée est fantastique. Les quatre heures passées, nullement suffisante pour tout voir dans les détails, sont passées très rapidement. Beaucoup de pièces intéressantes, des explications, des films d'archive, des reportages,...

Si vous passez dans le coin, n'hésitez-pas !

VG5000µ, SetPoint en ASM, diviser

2018-03-06T00:00:00+01:00

À présent que j'ai un garde fou pour vérifier que je ne fais pas d'erreur d'inattention, me voilà près à diviser des nombres. Pour rappel j'ai besoin de diviser des nombres afin de faire les calculs permettant d'affiche le bon pixel à l'écran.

Pour second rappel, le Z80, au cœur du VG5000µ (et de beaucoup d'autres ordinateurs de l'époque) n'a pas d'instruction de division.

La division

Lorsque je divise de manière entière a par b, je veux trouver le nombre c tel quel $c * b = a$. Comme la division ne tombe pas toujours juste, j'ai aussi un reste r tel que $c * b + r = a$.

Autrement dit, combien de fois dois-je additionner b pour obtenir a (au reste près). Une manière de trouver le résultat est de soustraire b à a autant de fois que l'on peut sans passer sous 0.

Par exemple, $\frac{21}{7}$ se trouve comme ceci :

21 - 7 = 14
14 - 7 =  7
 7 - 7 =  0

Il y a trois soustractions, et donc $\frac{21}{7} = 3$

Un autre exemple avec $\frac{17}{3}$ :

17 - 3 = 14
14 - 3 = 11
11 - 3 = 8
 8 - 3 = 5
 5 - 3 = 2

Il y a cinq soustractions, et il reste 2 à la fin, dont la soustraction de 5 donnerait -3. On s'arrête donc et $\frac{17}{3} = 5 + \frac{2}{3}$

Un problème majeur de cette façon de faire est que plus le résultat est grand, plus il a fallu de calculs pour le trouver. Si on divise de grands chiffres par de petits, cet algorithme est lent.

Il est par contre très facile à programmer. La séquence donne ceci :

Mettre le dividende (le nombre à diviser) dans A
Mettre le diviseur dans C
Mettre 0 dans B
Tant que A est supérieur à C
- Soustraire C à A et mettre le résultat dans A
- Ajouter 1 à B
Le quotient (le résultat de la division entière) est dans B
Le reste de la division entière est dans A

Implémentation par soustractions

Il y a des limitations bien entendu à faire cette division sur des registres 8 bits. Je ne pourrai pas traiter des nombres supérieurs à 255. Pour afficher un point, je n'en ai pas besoin, c'est donc très bien.

Tout d'abord, je renseigne mon système de tests avec mes nouvelles informations :

div3_input_data:
        defb    0,2,10,21,255
div3_reference_data:
        defb    0,0,3,7,85

div3_params:
        defw    div3_input_data
        defw    div3_reference_data
        defw    div3
        defm    "DIV3\0"

Et j'ajoute le test à la liste :

test_suite:
        ld      hl,id_params
        call    prepare_test

        ld      hl,div2_params
        call    prepare_test

        ld      hl,div3_params
        call    prepare_test

        ret

Ce qui me permet de mettre au point le code et le vérifier :

div3:                   ; Entrée: registre A, Sortie: valeur divisée par 3, dans A
        push    bc              ; J'utilise les registres B et C, je les préserve
                                ; Le temps de l'opération
        ld      c,3             ; Le registre C contient le diviseur
        ld      b,0             ; Le compteur B est préparé pour retenir
                                ; Le nombre de soustractions effectuées

div3_loop:
        cp      c               ; A et C sont comparés
        jr      c,div3_end      ; Si A était plus petit que C, alors une retenue a eu lieu
                                ; le calcul est terminé
                                ; Attention, ici C signifie Carry (retenue)

        sub     c               ; C est soustrait de A
        inc     b               ; B est augmenté de 1
        jr      div3_loop       ; La boucle est relancée

div3_end:
        ld      a,b             ; Le résultat de la division est dans B, il est placé dans A
                                ; À noter que A contenait le reste de la division.
                                ; Cela pourra être intéressant pour plus tard.

        pop     bc              ; Les registres B et C sont restaurés
        ret                     ; Et la fonction est terminée

Les instructions utilisées

Les instructions déjà utilisées dans les articles précédents ne sont pas répétées ici, les nouvelles sont :

cp: permet de comparer le registre A (qui est implicite et donc non noté) et le registre indiqué (ici, C). La comparaison se fait par soustraction de A et du registre, mais le résultat n'est pas retenu, seuls les drapeaux de résultat de l'opération le sont. Ainsi, en cas d'égalité par exemple, le drapeau Z sera à 1 (Zéro, car la soustraction de deux nombres égaux donne zéro). Ici, on cherche s'il y a eu une retenue, ce qui indique que le nombre dans le registre spécifié était plus grand que le nombre dans A, et donc le résultat de la soustraction était négatif.
sub: effectue une soustraction simple. On avait précédemment vu sbc, qui faisait une soustraction en tenant compte de la retenue du calcul précédent. sub n'en tient pas compte et soustrait simplement le registre mentionné du registre A, qui est implicite.

Résultat

Voici donc une première implémentation de division par 3, qui peut être généralisée à une division par n'importe quel nombre (inférieur à 255)

Pour référence futur, le code de la fonction nécessite 15 octets de langage machine. L'exécution de la fonction nécessite $15 + 8 * q$ cycles processeur, où $q$ est le quotient, résultat de la division. Au pire, pour $\frac{255}{3}$, la fonction prend donc 695 cycles. Ce qui n'est pas négligeable.

Nous verrons plus tard si l'on peut faire mieux.

VG5000µ, SetPoint en ASM, vérifier les résultats

2018-02-21T00:00:00+01:00

Après avoir mis en place une vérification (légère) de l'intégrité de la pile, je passe à la vérification de la validité de l'appel d'une fonction.

Le fonctionnement du test est assez simple : je prends une suite de nombres, j'appelle une fonction avec en paramètre chacun de ces nombres, je vérifie que le résultat est conforme à ce que j'attendais.

Par exemple, si je veux tester une fonction diviser par 2 (division entière), je peux utiliser la suite de nombre 0, 10, 32, 255 et comparer les résultats respectifs avec 0, 5, 16, 127 (255 étant impair, le résultat de la division entière est 127, avec un reste égal à 1).

Encore plus simple qu'une division par 2, il y a la fonction identité : celle qui renvoie le paramètre sans le toucher. Tester cette fonction permet de se concentrer sur le développement du test.

La fonction en elle-même est très simple :

identity:               ; Entrée: registre A, Sortie : registre A, inchangé
        ret             ; Retour immédiat, on ne touche à rien

La boucle de test

La boucle de test initialise deux pointeurs de données qui vont être augmentés en parallèle. La donnée source sera envoyée à la fonction, via le registre A, puis le résultat, mis dans le registre A aussi, sera comparé à la valeur attendue.

Il nous faut donc en premier lieu la liste de ces valeurs :

identity_input_data:
        defb    0,10,32,255
identity_reference_data:
        defb    0,10,32,255

La boucle en elle-même ressemble à cela :

        ; Fonction de test
test:
        ld      hl,identity_reference_data      ; HL pointe sur les résultats de références
        ld      de,identity_input_data          ; DE pointe sur les données en entrées

        or      a,a         ; Effacement du drapeau de retenue (voir article précédent)
        sbc     hl,de       ; Par soustraction des deux valeurs, on obtient le nombre de valeurs
                            ; de la série.

        ld      b,h
        ld      c,l     ; BC contient le nombre de valeurs à tester

        ld      hl,identity_reference_data      ; HL est pointe à nouveau sur le résultat de référence

test_loop:
        ld      a,(de)      ; Chargement dans l'accumulateur de la valeur pointée par DE
        call    identity    ; Appel de la fonction
                            ; Au retour de la fonction, A contient le résultat de la fonction

        cpi             ; Compare A avec (HL), incrémente HL et décrémente BC
                        ; Si BC passe à 0, le bit d'overflow (V) est mis à 0 ; 1 sinon
                        ; Si A et (HL) sont identique, le flag Zero est mis à 1

        jr      nz,test_failed  ; Si A et (HL) étaient différent, saute à test_failed

        inc     de              ; Sinon, incrémente DE manuellement

        jp      v,test_loop     ; S'il reste des valeurs (BC > 0), on boucle
                                ; DE et HL pointant à présent sur la paire de valeurs suivantes

        ld      hl,test_pass_msg        ; Arrivée ici, toutes les paires de valeurs ont été
                                        ; vérifiée avec succès. HL pointe donc sur le message
                                        ; de succès.
        jr      print_test_result_msg   ; Et on saute à l'affichage.

test_failed:
        ld      hl,test_fail_msg        ; Arrivée ici, une comparaison a échouée, HL pointe
                                        ; donc sur le message d'échec.

print_test_result_msg:
        call    print_str               ; On affiche le message contenu dans HL
        ret                             ; Le test est fini !

test_pass_msg:
        defm "Pass!\r\0"

test_fail_msg:
        defm "Fail!\r\0"

Les instructions utilisées

Les instructions déjà utilisées dans l'article précédent ne sont pas répétées ici, les nouvelles sont :

defb : qui est une directive pour l'assembleur, indiquant de réserver de la place mémoire et de l'initialiser avec les octets qui suivent,
cpi : instruction de comparaison qui effectue plusieurs actions d'un coup, comme indiqué dans le commentaire ci-dessus. Cela contraint l'utilisation des registres HL, BC et A, qui sont spécialisés ainsi (HL pour un pointeur de mémoire, BC comme compteur et A pour l'accumulateur).
inc : incrémente la valeur du registre en paramètre, c'est-à-dire lui ajoute 1.
jp : saut (jump) au label indiqué. La différence avec l'utilisation de jr est dans l'encodage de l'adresse de destination. Sans entrer dans le détail, jr est plus condensé que jp, car il n'encode pas l'adresse complète mais seulement un déplacement court. Cependant, il n'est pas possible d'utiliser le drapeau de dépassement de capacité (V) n'est pas utilisable avec jr.

Et la division par 2 ?

À présent, il devient facile de tester différentes fonctions. Il suffit de la fonction elle-même, de la paire de liste de valeurs, et de remplacer l'appel de le fonction dans le test.

div2:                   ; Entrée: registre A, Sortie : valeur divisée par 2, dans A
        or      a       ; Effacement du drapeau de retenue
        rra             ; Rotation du registre A vers la droite, en passant par la retenue
        ret

div2_input_data:
        defb    0,10,32,255
div2_reference_data:
        defb    0,5,16,127

Et par exemple, si vous aviez, par étourderie comme moi, utilisé rrca plutôt que rra, le test échoue sur la division par 255.

Généralisation

Mais changer les pointeurs à chaque test de fonction, ça n'est pas pratique. C'est la grande différence entre des tests automatisés, qui peuvent rester à demeure et que l'on peut lancer régulièrement pour s'assurer que l'on construit un programme sur des fondations solides, et le test manuel, de temps en temps, pour s'assurer du fonctionnement en un point donné, et que l'on doit remettre en place manuellement à chaque fois.

Bref, il me faut généraliser ça avec, par exemple, la boucle de test qui prendrait en entrée les pointeurs nécessaires. Et pourquoi pas, même, un nom explicatif de la fonction testée sur le moment.

Ce que je voudrais, c'est quelque chose comme ceci :

test_suite:
        ld      hl,id_params
        call    prepare_test

        ld      hl,div2_params
        call    prepare_test

        ret

id_params:
        defw    identity_input_data
        defw    identity_reference_data
        defm    "IDENTITY\0"

div2_params:
        defw    div2_input_data
        defw    div2_reference_data
        defm    "DIV2\0"

Il faut pour cela adapter un peut la routine test pour aller piocher les valeurs depuis HL, qui devient le paramètre d'entrée.

Tout d'abord, la préparation des paramètres du test va mettre sur la pile les paramètres indiqués.

Note : il y a de multiples choix pour passer les paramètres des tests à la fonction. Mais aussi beaucoup de contraintes sur les instructions disponibles. Passer par la pile grâce à une fonction d'aide est assez simple à implémenter et lisible. Mais loin d'être le plus rapide.

prepare_test:
        ld      b,3                 ; B sert de compteur, on va mettre les trois premières adresses sur la pile
prepare_test_loop:
        ld      e,(hl)              ; Récupération de la première partie de l'adresse
        inc     hl
        ld      d,(hl)              ; Récupération de la seconde partie de l'adresse
        inc     hl

        push    de                  ; DE contient l'adresse, qui est poussée sur la pile

        djnz    prepare_test_loop   ; DJNZ décrémente B et, si B n'est pas égal à zéro, retourne au label indiqué
                                    ; C'est la manière canonique d'effectuer des boucles

        push    hl                  ; La dernière adresse est poussée directement, car elle pointe sur la chaîne de caractères,
                                    ; sans indirection.

        jp      test                ; ici, on devrait faire un CALL à la routine de test. Mais ce CALL serait immédiatement
                                    ; suivi d'un RET. Dans ce cas-ci, on peut remplacer le CALL par un JP.
                                    ; Si vous avez bien compris ce que font CALL, RET et JP, alors vous devriez comprendre
                                    ; pourquoi.

À présent, à l'appel de la routine test, il y a sur la pile, dans l'autre du plus « haut » vers le plus « bas » : l'identifiant sous forme de chaîne de caractères, l'adresse de la fonction à appeler, le pointeur de données de références, le pointeur de données en entrée.

Il s'agit de récupérer tout cela.

Voici le début de la routine modifiée, le reste ne change pas :

test_sep_msg:
        defm ": \0"                 ; Une chaîne de caractère, voir plus loin
test:
        pop     hl                  ; La première opération consiste à afficher l'identifiant
        call    print_str

        ld      hl,test_sep_msg     ; Suivi de la nouvelle chaîne de caractère, pour afficher les deux points
        call    print_str

        pop     hl                  ; La valeur suivante récupérée est l'adresse d'appel de la fonction
                                    ; Les appels indirects sur un Z80 ne sont pas naturels, il n'existe pas de CALL
                                    ; à une adresse non préalablement fixée.

        ld      (call_func+1), hl   ; Du coup, on profite du fait d'être en RAM pour modifier le code à la volée
                                    ; en modifiant directement l'adresse du CALL à la fonction.
                                    ; Cela ne serait pas possible avec un programme en ROM par exemple, mais il
                                    ; existe plusieurs autres possibilités (utilisation de vecteurs et
                                    ; modification manuelle de la pile par exemple)

                                    ; Ce genre de manipulation vient avec des contraintes, mais qui dans notre cas
                                    ; sont tout à fait acceptables.

        pop     hl                  ; Récupération de l'adresse des données de référence
        pop     de                  ; Récupération de l'adresse des données en entrée

        push    hl                  ; Sauvegarde temporaire de HL

        or      a,a                 ; Le calcul du nombre de données, comment avant
        sbc     hl,de

        ld      b,h
        ld      c,l

        pop     hl                  ; Récupération de la sauvegarde temporaire de HL

test_loop:
        ld      a,(de)

call_func:
        call    $0000               ; Ici, le CALL à l'adresse $0000 sera modifié dynamiquement par
                                    ; la manipulation décrite ci-dessus. Lors de l'exécution de cette instruction,
                                    ; c'est donc bien la fonction spécifiée qui sera appelée.

Résultats

En situation réelle, il est très peu probable que j'utilise des fonctions identité ou division par 2. Les calculs seront faits sur place. Cependant, tester ces fonctions m'ont permis de développer mon petit framework de tests, assez minimaliste, et cela va m'être bien utile pour la suite, pour attaquer la division.

VG5000µ, SetPoint en ASM, vérifier la pile

2018-02-18T00:00:00+01:00

Il y a maintenant pas mal de temps, j'avais implémenté, en BASIC, une routine pour afficher un point à l'écran. Puis de là, une routine pour tracer une ligne, puis un cercle. Le constat était que c'était très lent. Le BASIC interprété est déjà plutôt lent de manière générale, et celui du VG5000µ n'est pas particulièrement rapide.

Il y a plusieurs raisons à cela, et ce sera peut-être le contenu d'articles futurs.

Mais en attendant, et après tous les efforts pour se confectionner un environnement de travail pour développer en assembleur, je repars sur l'implémentation du tracé d'un point à l'écran, et cette fois-ci, en assembleur.

L'avantage d'un programme écrit dans un langage de « haut niveau », comme le BASIC, est de simplifier bien des choses. Faire une division d'une variable A par 3 par exemple, peut s'écrire B = A/3. C'est simple, concis, lisible.

Traduire cela en assembleur n'est pas toujours simple. Diviser par un nombre quelconque n'est pas direct car le processeur Z80 n'a pas d'instruction de division. Le processeur possède des instructions pour additionner et soustraire, mais pas pour multiplier, ni de diviser.

Diviser par des nombres en particuliers est parfois simple, comme diviser par 2, qui consiste à décaler tous les bits d'un nombre binaire « vers la droite », tout comme diviser par 10 dans notre arithmétique courante consiste à décaler tous les chiffres vers la droite (ou supprimer l'unité, si vous préférez).

Pour 30 par exemple, en décimal, une vision par 10 donne 3. En binaire, le même nombre s'écrit 00011110 (sur 8 bits) et sa division par 2 donne 00001111, c'est-à-dire 15 en décimal. Diviser (ou multiplier) par des multiples de la base dans laquelle on représente les nombres est simple.

Cependant, dans le calcul du pixel à afficher, j'avais une division par 3. Et là... c'est plus compliqué.

La première étape, puisque je pars de zéro est d'implémenter une division. Puisque le calcul n'a besoin que de diviser par 2 et par 3, et que la division par 2 est simple, je vais me contenter d'une division par 3.

Mais STOP. Si vous suivez ce blog, vous avez peut-être vu que j'aime essayer de transposer des techniques modernes sur d'anciennes machines. C'est de la rétro-programmation anachronique, mais qui peut convenir au fait que, de toute façon, programmer ce genre de machines depuis un ordinateur actuel est anachronique.

Une technique moderne de développement (qui a ses détracteurs) est de guider sa programmation à travers des tests qui peuvent, à chaque instant, indiquer si une erreur apparaît. La méthode est globalement de : 1/ écrire un test... qui échoue 2/ écrire le minimum pour faire passer ce test 3/ améliorer (sans ajouter de nouvelle fonctionnalité).

Le point 3/ en particulier, permet de tester des choses en étant certain que ce que l'on a programmé ne « casse » pas. Suite à une optimisation un peu trop cavalière par exemple. Je ne suis pas un spécialiste de l'écriture de programmes en assembleur Z80, et un outil qui me permet de vérifier que mon changement ne casse pas tout m'intéresse.

Puisque je vais implémenter une fonction, mon environnement de test prendra en entrée une suite de nombres, y appliquera la fonction puis, testera que les résultats sont ceux que j'attends. J'affiche ensuite le résultat de la comparaison.

Techniquement, un tel système de tests devrait lui-même être testé... mais à si bas niveau, c'est aller un peu trop loin pour ce que je veux faire.

Le premier test

La première chose dont je veux m'assurer, c'est que la pile à la sortie de mon traitement soit dans le même état qu'au début. En effet, si ce n'est pas le cas, il va se passer des choses probablement à classer dans le domaine du « mal ». Dans le meilleur des cas une erreur bizarre, dans le pire (et souvent), un reboot de la machine.

Aparté: je crois n'avoir jamais parlé de la pile dans un article précédent. Très rapidement, c'est un endroit en mémoire où l'on peut stocker des informations sous forme de pile (imaginez une pile d'assiettes). La dernière donnée mise sur le pile est aussi la première que l'on lira par la suite. Cette pile est entre autre la moyen lors de l'appelle d'une routine d'en revenir. À l'appel, l'adresse du code appelant est mis sur la pile. Pour retrouver cette adresse, il faut donc que l'état de la pile soit le même en entrée et en sortie de fonction.

Voilà la première partie de la vérification de l'état de la pile.

        ld      hl,0        ; Il n'est pas possible sur Z80 de prendre le pointeur de pile pour le mettre dans un registre
        add     hl,sp       ; l'astuce est donc d'ajouter à 0 la valeur du pointeur de pile, en deux étapes.
        push    hl          ; Et je pousse la valeur du pointeur de pile dans la pile

Il y a à présent en haut de la pile une valeur arbitraire suivi de l'adresse de la pile en début de fonction.

Voici ensuite la seconde partie de la vérification de l'état de la pile. C'est un peu plus long car il y a la vérification ainsi que l'affichage du résultat.

        pop     hl                  ; Récupération de la valeur depuis la pile
        or      a,a                 ; Reset de la retenue
        sbc     hl,sp               ; Soustraction de cette valeur avec le pointeur de pile
        jr      nz,print_stk_fail   ; Si le résultat n'est pas zéro, c'est qu'on n'a pas trouvé la bonne valeur dans la pile
                                    ; Dans ce cas, saut à print_stk_fail

                                    ; Si tout ce passe bien, c'est à dire que la pile n'a pas été corrompue et qu'elle
                                    ; est au même « niveau » qu'au début, alors...
        ld      hl,stack_ok         ; on charge dans HL le message de succès
        call    $36aa               ; et on l'affiche

        ; [...]                     ; On verra plus tard ce qui est ici.

        ret

print_stk_fail:                     ; On arrive ici en cas d'échec
        ld      hl,stack_fail       ; On charge dans HL le message d’échec
        call    $36aa               ; et on l'affiche

                                    ; Mais on ne peut pas sortir comme ça de la fonction. Puisque la pile n'est pas dans
                                    ; le même état qu'au début, l'instruction `RET` ne va pas trouver l'adresse ramenant
                                    ; au programme appelant, et cela ne va rien amener de bon (un reboot très souvent)
endless_loop:
        halt                        ; Alors on arrête tout... ou presque. L'instruction HALT va arrêter le système jusqu'à
                                    ; la prochaine interruption, qui est, sur VG5000µ, l'interruption d'affichage.
        jr      endless_loop        ; Puis à la fin de l'affichage, ou boucle à l'infinie.
                                    ; Cela permet de voir le message d'erreur.

stack_ok:
    defm "Stack Pass!\0"

stack_fail:
    defm "Stack Fail!\0"

Les instructions utilisées

Lire de l'assembleur peut être un peu déroutant au premier abord. Les explications fonctionnelles sont disponibles en commentaire dans le code ci-dessous, voici à présent les instructions utilisées dans l'ordre de leur apparition :

ld : abréviation de load, c'est-à-dire charge. La valeur à droite de la virgule est chargée dans le registre à gauche. Par exemple, après ld hl,0, le registre HL contiendra la valeur 0,
add : la valeur de droite (ou le contenu du registre à droite) de la virgule est additionné (add) dans le registre à gauche. Arès add hl,sp, le contenu de HL sera augmenté de la valeur de SP,
push : pousse la valeur contenu dans le registre sur la pile, après push hl, le contenu de HL est en haut de la pile, HL n'est pas modifié,
pop : est le contraire de push. La valeur en haut de la pile est chargée dans le registre en paramètre, puis la pile est positionné sur l'élément au-dessous. Après pop hl, HL contient le contenu qui était en haut de la pile,
or : permet d'effectuer une opération ou. Ici, cependant, cette instruction est utilisée uniquement pour mettre le drapeau de retenue à zéro, à cause de l'instruction suivante,
sbc : soustraction avec retenue, la valeur du registre de droite est soustraite de la valeur du registre de gauche. Il n'est pas possible sur Z80 de faire une soustraction sans retenue entre deux registres 16 bits. De là vient la nécessité d'effacer la retenue, au cas où, avec le or précédent. Le résultat est chargé dans le registre de gauche.
jr : saut relatif, un branchement, c'est-à-dire une modification d'ordre d'exécution, va être effectué au label indiqué. Dans le code ci-dessus, nz à gauche de la virgule indique que le saut sera conditionné par le résultat du calcul précédent si celui-ci n'était pas nul (not zero). Après jr nz,print_stk_fail, le processeur continuera son exécution à l'emplacement indiqué par print_stk_fail si le résultat n'est pas 0. Dans le cas contraire, le branchement n'a pas lieu et l'exécution continue à l'instruction suivante,
call : est un appel de sous-routine. L'emplacement de l'instruction suivante est mise sur la pile (équivalent d'un push) puis un branchement est fait au label indiqué,
ret : est le pendant de call, la valeur en haut de la pile est prise pour prochaine instruction grâce à l'équivalent d'un pop. L'exécution continue donc là d'où avait été appelée la routine,
halt : arrête l'exécution du processeur. Lorsqu'une interruption matérielle est reçue, le processeur se remet en route.
defm : ce n'est pas une instruction du processeur mais une directive pour l'assembleur. Une zone mémoire est réservée et initialisée avec la chaîne de caractères qui suit.

Garder le contexte

Cette routine de vérification de la pile modifie quelques registres. Pour laisser les choses dans l'était où elles étaient lorsque ce code sera appelé, il est de bon ton de sauvegarder l'état des registres et de les restituer à la fin. Cela peut se faire par une série de push et de pop. Ce qui donne au final :

        ; Vérification de pile
        org     $7000

        defc    print_str = $36aa

        ; Sauve le contexte
        push    hl
        push    bc
        push    af
        push    de

        ; Enregistre la pile
        ld      hl,$0
        add     hl,sp
        push    hl
        ;

        ; Opérations futures...

        ; Vérification de la pile
        pop     hl
        or      a,a
        sbc     hl,sp
        jr      nz,print_stk_fail

        ; Message en cas de succès
        ld      hl,stack_ok
        call    print_str

        ; Restitution du contexte
        pop de
        pop af
        pop bc
        pop hl

        ret

print_stk_fail:
        ld      hl,stack_fail
        call    print_str
loop:
        halt
        jr      loop

stack_ok:
    defm "Stack Pass!\0"

stack_fail:
    defm "Stack Fail!\0"

Résultat

Pour le moment, pas grand chose, tout se passe bien et un message est affiché indiquant que... la pile est ok.

Automatisation : utilisation de Sublime Text 3

2018-02-12T00:00:00+01:00

Dans les articles précédents sur l'automatisation au niveau des outils de développement, j'avais vu comment injecter un programme dans MAME en émulation VG5000µ d'abord grâce au debuggeur manuellement, puis avec un script LUA grâce aux possibilité d'extensions de MAME.

Ce n'est toujours pas suffisant pour moi. Comme je l'ai déjà écrit dans ces autres articles, je ne veux pas faire ce qu'une automatisation peut faire bien plus facilement, et sans se tromper. Lancer l'assembleur en ligne de commande, puis lancer MAME avec les bons paramètres, cela n'est pas bien compliqué avec un shell moderne (comme fish).

Un des principaux problèmes que j'y vois, outre que ce sont des opérations manuelles, c'est que ce sont des opérations non documentées. Si je fais une pause dans un projet et que j'y reviens deux mois après (ça arrive bien souvent, surtout pour du hobby), il y a de bonnes chances que je ne me souvienne plus des opérations exactes à faire. J'ai pu prendre des notes, laisser des instructions, écrire un article même. Mais quoi de mieux comme instructions que de laisser des outils qui fonctionneront et seront une source de documentation si besoin ?

Un premier script assez simple serait de regrouper l'assemblage et le lancement dans un même script. Ou pourquoi pas dans un Makefile.

J'ai choisi d'ajouter les outils à un environnement Sublime Text 3, qui est l'un des deux éditeurs de texte que j'utilise le plus souvent.

De la couleur

Et puisque j'en étais à créer un petit environnement confortable pour mettre au point des programmes en assembleurs pour Z80, j'ai fait un petit détour par la colorisation syntaxique. N'ayant pas trouvé de colorisation adéquat à de l'assembleur tel qu'attendu par z80asm, j'ai écrit une description simpliste que vous trouverez dans le package en fin d'article.

Il ne gère pas tous les cas, et je pense l'améliorer en fonction des besoins.

Au passage, Sublime Text 3 a un système de tests pour la colorisation syntaxique qui est extrêmement pratique pour mettre au point le fichier. Le fichier de test est disponible dans le paquetage au côté des autres, pour référence.

Un système de build

Deuxième étape, la plus importante, celle qui permet de construire un code objet à partir d'un code source en assembleur. La mise en place de la colorisation syntaxique n'a pas amené que des couleurs à l'affichage. Elle a aussi permis de déclarer l'existence d'un format spécifique, que j'ai appelé z80asm.

Lorsque l'éditeur de texte ouvrira un fichier .asm, il l'associera par défaut à ce format (sauf si vous avez d'autres associations pour .asm, auquel cas cela sera un choix possible).

Pour créer un nouveau système de build avec Sublime Text 3, il suffit d'aller dans Tools -> Build System -> New Build System. Un nouveau fichier de description, en JSON, permettra d'indiquer à l'éditeur les actions qu'il devra effectuer lors de la construction du fichier.

Pour une construction simple, qui appel l'assembleur z80asm se trouvant dans vos chemin de recherche d'exécutables, cela peut donner ceci :

{
    "selector": "source.asm.z80",
    "cmd": ["z80asm", "-b", "-v", "$file"],
    "file_patterns": ["*.asm"],
    "file_regex": "^Error at file '([^']+)' line (\\d+): ()(.+)"
}

selector: indique que ce type de construction est valable pour le type de fichier associé au format source.asm.z80.
cmd: indique la commande à exécuter. $file indiquant le fichier actif au moment du lancement de la construction.
file_patterns: indique le type de fichier valable pour ce type de construction aussi, au cas où le format de selector n'aurait pas été appliqué
file_regex: est une expression régulière identifiant les erreurs de construction, et permettant à l'éditeur de texte d'indiquer ces erreurs directement dans le fichier édité.

Avec ceci, un Ctrl-B (sous Linux et Windows) transforme votre fichier .asm en fichier du même nom .bin.

Lancer MAME après le build

Je voulais aller un peu plus loin et avoir la possibilité de lancer MAME depuis Sublime Text si l'assemblage était un succès. Pour cela, il m'a fallu écrire un script python un peu plus complexe qui lance l'assemblage de la même manière que ce qui est indiqué au paragraphe précédent, et en cas de succès, lance MAME avec les bons paramètres.

Il aurait été aussi tout à fait possible, et probablement plus simple, d'appeler un fichier script shell (ou batch). Mais j'avais depuis quelques temps envie de comprendre comment écrire un plugin de build pour Sublime Text, j'ai donc fait un détour.

Je ne rentrerai pas dans le détail du fonctionnement du plugin de build que vous pourrez trouver dans le paquetage à la fin de l'article.

Le système est améliorable. Pour le moment, l'adresse de démarrage du code objet est fixé par le script vgboot.lua. Il faudra donc changer cette adresse dans le script à l'endroit de l'injection du code et au moment du CALL si votre code objet est situé à une autre adresse mémoire.

Dans le fichier README.md, vous trouverez les instructions pour créer le système de build correspondant. Je le reprends ici pour l'expliquer :

{
    "selector": "source.asm.z80",
    "cmd": ["z80asm", "-b", "-v", "$file"],
    "file_patterns": ["*.asm"],
    "file_regex": "^Error at file '([^']+)' line (\\d+): ()(.+)",

    "variants": [
        {
            "target": "z80_asm",
            "name": "run",
            "mame_path": "mame",
            "script": "vgboot.lua"
        }
    ]
}

Outre le début, qui est identique à la version du paragraphe précédent, une section variants a fait son apparition. Cette section indique des versions alternatives de construction. Le paramètre target indique quel est le plugin à invoquer. Les autres paramètres sont passés tel quel au plugin.

Les variantes hérites aussi des paramètres principaux, mais mon plugin se contente de les ignorer pour tout gérer seul.

Pour sélectionner une variante dans Sublime Text 3, le raccourci est Ctrl-Shift-B (sous Linux et Windows).

Le paquetage

Les sources du paquetages sont disponibles sur Github mais aussi sous forme de paquetage Sublime Text 3 (qui est en fait un fichier zip) directement ici (à la version lors de la publication de l'article).

Le résultat

À présent, je peux écrire de l'assembleur dans mon éditeur de texte et, par un seul raccourci, lancer l'assemblage, avoir un retour d'erreur annoté directement dans le code source, et en cas de réussite, le programme lancé directement dans l'émulateur.

On pourrait aller encore plus loin, avec le script MAME qui ouvrirait un canal de communication afin d'injecter le code sans relancer l'émulateur... Mais je vais m'arrêter ici et revenir sur le sujet qui a entraîné tout cela.

Scripter MAME pour explorer la machine

2018-01-18T00:00:00+01:00

Puisque je suis actuellement dans l'utilisation de LUA pour scripter MAME, faisons un petit détour pour explorer quelques possibilités.

Les fonctions accessibles aux scripts LUA sont assez nombreuses. Je n'en connais pas de documentation complète si ce n'est dans les sources du programme lui-même à cet endroit : mame/src/frontend/mame/luaengine.cpp. Des groupes de commentaires indiquent les fonctions et leur usage. Reste à utiliser la console pour expérimenter un peu la façon de les appeler.

L'une des possibilités intéressantes est de pouvoir agir sur l'affichage de l'émulateur. Cela peut être assez pratique pour suivre certaines valeurs en mémoire, pour afficher des informations sur le comportement de la machine, voire d'ajouter des fonctionnalités interactives à l'émulateur facilement.

Affichage à l'écran

La première chose à faire pour afficher quelque chose à l'écran est de récupérer un objet permettant de le manipuler. Pour cela, en passant par l'objet manager, on récupère la machine, puis un écran qui dans notre cas se nomme :screen.

Grâce à cet objet, il est ensuite possible d'afficher du texte, de tracer des lignes et des boites. C'est limité, mais déjà pas mal.

Ce qui suit est un exemple d'utilisation dans lequel je vais chercher directement en mémoire les coordonnées X et Y du curseur du VG5000µ, qui sont situées aux emplacement mémoire fixes $4805 et $4806. Par un objet donnant accès à la mémoire et l'utilisation des fonctions read_u8 (comme lecture d'un entier non signé sur 8 bits), je récupère les valeurs et je les affiche.

Simple et efficace. Je peux à présent, si le script est dans un fichier nommé vgdisplay.lua, lancer la commande suivant pour suivre les évolutions des coordonnées du curseur.

mame64 vg5k -ramsize 48k -nomax -window -autoboot_delay 0 -autoboot_script vgdisplay.lua

Le script

-- Script for MAME that launches the vg5k emulator
-- and continuously displays the position of the cursor

-- Get the only screen of the VG-5000µ
local screen = manager:machine().screens[":screen"]

-- Get access to the memory
local cpu = manager:machine().devices[":maincpu"]
local memory = cpu.spaces["program"]

function draw_hud()
    local cursor_x = memory:read_u8(0x4805)
    local cursor_y = memory:read_u8(0x4806)
    screen:draw_text(300, 40, "X: " .. cursor_x, 0xffff0000);
    screen:draw_text(300, 50, "Y: " .. cursor_y, 0xffff0000);
end

emu.register_frame_done(draw_hud)

Le résultat

Injecter un programme dans un émulateur VG5000µ, partie II

2018-01-10T00:00:00+01:00

La fois dernière était consacrée au lancement d'un programme sur VG5000µ avec l'émulateur MAME de manière à injecter un programme binaire directement en mémoire puis à l'appeler. Tout cela automatiquement. Pour rappel, l'idée derrière cela est d'éviter les erreurs de manipulations qui arrivent de temps en temps.

La première option utilisée dans l'article précédent était d'utiliser un script pour le debuggeur d'une part, et la capacité de MAME à entrer au clavier de la machine émulée une suite de frappes de touches.

Cette méthode fonctionne mais a ses limites : il faut régler le délai avant la frappe de touches de manière empirique, et le script est linéaire. Dans cet article, je vais utiliser une autre possibilité de MAME pour résoudre ces deux écueils.

La console

Commençons par une première manipulation.

mame64 vg5k -ramsize 48k -nomax -window -debug -debugger none -console

Dans le shell depuis lequel vous avez entré cette commande s'affiche un bandeau et une invite [MAME]>. Vous avez à présent accès à une console qui comprend le LUA. C'est bien entendu le paramètre -console qui a permis cela.

Le couple -debug -debugger none est plus surprenant. Il indique que le debuggeur est activé, mais sans interface graphique. Le debuggeur est donc utilisable depuis la console, et c'est parfait. Au passage, vous remarquerez que, en l'absence d'interface graphique pour le debuggeur, l'émulateur ne s'est pas mis en pause.

Depuis la console, vous pouvez essayer ceci :

m = manager:machine()
md = m:debugger()
print(md)

Vous devez voir quelque chose comme sol.debugger_manager*: 0xf9de9a8 qui indique que md contient bien un debuggeur (l'adresse sera différente). Si vous obtenez nil, c'est que le debuggeur n'est pas actif.

L'object md permet de s'adresser au debuggueur.

Par exemple :

md:command("help")

Et l'aide du debuggeur s'affiche. Nous communiquons bien avec le debuggeur. C'est pratique.

Script LUA

Mais si une console est pratique pour essayer des choses, ce n'est pas ce que je recherche au final. Ce que je recherche à faire est toujours automatiser le démarrage d'un programme pour sa mise au point.

Et MAME a la commande qu'il me faut : -autoboot_script. Cette commande, suivie par un nom de fichier, va exécuter un script écrit en LUA qui aura accès au fonctionnement de l'émulateur.

La commande pourra ressembler à quelque chose comme ça :

mame64 vg5k -ramsize 48k -nomax -window -debug -debugger none -autoboot_delay 0 -autoboot_script vgboot.lua

-autoboot_delay 0 indique que le script doit être lancé dès le démarrage de l'émulation de la machine. La première chose (ou presque) à faire dans le script si vous voulez contrôler la machine cible dès le début est alors un emu.pause() que vous pourrez balancer avec un emu.unpause() lorsque votre script sera prêt.

Le script que j'utilise est trop long pour s'afficher sur cette page. Vous pouvez le trouver ici.

Des choses intéressantes à savoir :

manager:machine() renvoie l'objet contrôlant machine émulée,
manager:machine():debugger() renvoie l'objet de contrôle du debuggeur,
manager:machine():debugger().consolelog est le log du debuggeur, pratique pour vérifier les retours de commandes,
manager:machine().devices[":maincpu"] renvoie l'objet contrôlant le CPU principal de la machine (le Z80 pour le VG5000µ),
manager:machine().devices[":maincpu"]:debug() renvoie l'objet de commande du debuggeur sur ce CPU (qui offre des facilités sur les commandes du debuggeur pour ce processeur en particulier).

Sur l'objet renvoyé par debug() sur le CPU, par exemple, on peut appeler bpset() pour placer un point d'arrêt. Sur l'objet renvoyé par debugger(), on peut envoyer tous les commandes que l'on entrerait dans l'interface graphique avec command().

Ainsi ...:debugger():command("go") a le même effet, sur cette machine, que ...:debug():go().

L'objet emu qui permet de faire pause() et unpause() permet aussi de simuler les appuis sur les touches du clavier émulé. Par exemple emu.keypost('CALL &"7000"\n').

C'est plus complexe !

Oui, cette méthode est plus complexe, plus longue à écrire. Elle permet aussi un meilleur contrôle et des choses que ne permettent pas un script de debuggeur simple. À vous de choisir !

Injecter un programme dans un émulateur VG5000µ

2018-01-03T00:00:00+01:00

Reprenons sur la programmation en assembleur sur VG5000µ depuis un ordinateur actuel. Car s'il est possible et tout à fait légitime, par hobby, de programmer directement sur la machine, à l'ancienne, pour « retro programmer » comme il y a du « retro gaming » en éprouvant les sensations originelles, ce n'est pas mon but ici.

Mon but, c'est de pouvoir programmer depuis un éditeur de texte simple, mais pas trop, et de pouvoir mettre au point avec certaines facilités comme un retour d'erreur d'assemblage et l'accès à un debuggeur. Et tout ceci avec une chaîne qui minimise les manipulations répétitives.

Minimiser les manipulations répétitives permet de rester concentré au maximum sur ce que je fais. Je n'ai pas envie, à chaque lancement, de taper des commandes particulières ou de faire quelques clics souris, toujours les mêmes, avec un risque de me tromper et de chasser un bug que je crois être là alors que je me suis juste trompé dans une manipulation.

Il y a de nombreuses manière d'automatiser une chaîne de construction de programme. Certains choix sont contraints par les outils que l'on utilise. D'autres sont des choix par préférences.

Après avoir fait mon travail de reflexion, lorsque je passe à la partie d'entrée au clavier, les données sont les suivantes :

j'entre le code source dans un éditeur,
j'effectue une action qui produit un fichier binaire,
ce fichier binaire doit se lancer dans un émulateur et/ou produire un fichier pour chargement sur machine réelle,
s'il y a des erreurs, les afficher,
s'il n'y a pas d'erreurs l'émulateur se lance automatiquement et lance à son tour le programme.

Cette dernière opération est mon point de départ et le sujet de cet article. Vous aurez compris au passage, et suite à l'article précédent, que j'utiliserai un émulateur pour la mise au point, avant de passer sur machine réelle pour confirmation du fonctionnement.

Choix de l'émulateur

Au niveau VG5000µ, au moment de l'écriture, il n'y a pas beaucoup de choix : soit DCVG5K, soit MAME. Les deux possèdent un debuggeur et le moyen d'injecter un binaire en mémoire.

Je vois en MAME deux avantages pour moi : la possibilité de scripter le debuggeur et le lancement en natif sous Linux, qui est derrière le système d'exploitation que j'utilise (Ubuntu). DCVG5K a l'avantage de la légèreté dû au fait qu'il est dédié à une seule machine, ainsi que de la simplicité d'utilisation.

Pour savoir comment utiliser MAME, c'est très simple, il suffit de taper mame -showusage en ligne de commande... Ooops... 462 lignes d'explication de paramètres... Et ce n'est qu'un résumé.

MAME est un gros morceau et j'espère qu'avec les renseignements de cet article, je vous aurait débrousaillé le terrain.

Lancement de l'émulation

Avant toute chose : tout ce que j'explique est du lancement en ligne de commande. Il est possible de faire la même chose à travers des fichiers de configuration ou des raccourcis Windows avec paramètres mais le but final est d'inclure ça à un script de lancement. La ligne de commande est aussi la manière la plus simple de jouer avec les paramètres (pour peu qu'on utilise un shell moderne).

Pour lancer l'émulation du VG5000µ, c'est tout simplement :

mame64 vg5k

Note : l'exécutable s'appelle mame64 pour quoi car je compile la version depuis les sources. Suivant les distributions de MAME, il peut avoir un autre nom.

Note : Si MAME vous annonce qu'il vous manque une ROM, revenez à mon article précédent, dumpez votre ROM, placez-là dans le répertoire attendu par MAME et c'est reparti.

Le lancement de l'émulateur dans cette configuration lance la machine après un bandeau la présentant et, à l'heure actuelle, un bandeau rouge indiquant que l'émulation ne fonctionne pas. En effet, l'émulation n'est pas considérée comme terminée ; mais en ce qui nous concerne, cela sera suffisant.

J'ai évoqué un debuggeur. Il est accessible sous plusieurs formes et je vais laisser celle par défaut :

mame64 vg5k -ramsize 48k -nomax -window -debug

J'ai ajouté au passage quelques options supplémentaires :

-ramsize 48k indique que je veux l'extension RAM maximale disponible sur le VG5000µ (l'autre option est 32k, et par défaut, la machine aura ses 16k)
-nomax indique que je ne veux pas maximiser la fenêtre
-window indique que je veux lancer l'émulateur dans une fenêtre et non en plein écran
-debug, bien entendu, lance le debugger

En mode debugger par défaut, l'émulation ne se lance pas tout de suite. Elle est immédiatement mise en pause. Sur l'image suivante, vous pouvez voir que le PC est à $0000, sur la première instruction qui sera exécutée par le processeur de la machine jp $1000.

Ce debugger accepte des raccourcis clavier mais peut aussi accepter des commandes. Le debugger peut aussi prendre ses commandes depuis un fichier texte grace à la commande source.

Je vous invite à entrer le texte suivant dans un fichier debug.txt.

go $2adf
load hello.bin,$7000
go

Note : go $2adf indique de lancer l'émulation avec un point d'arrêt temporaire à l'adresse $2adf, qui est une addresse qui, lorsqu'elle est atteinte, garanti que le VG5000µ a terminé son initialisation.

Puis d'avoir un fichier binaire au nom de hello.bin de mettre ces deux fichiers dans le répertoire de travail de MAME.

Et enfin, depuis le debuggeur, taper source debug.txt

Le debuggeur devrait afficher :

>go $2adf
Stopped at temporary breakpoint 2ADF on CPU ':maincpu'
>load hello.bin,$7000
Data loaded successfully to memory : 0x7000 to 0x7018
>go

Suivant votre fichier, l'addresse 0x7018 peut varier. Dans mon cas, le fichier provient du résultat de l'assembleur d'un article précédent.

Dans le debuggeur, vous pouvez ouvrir une fenêtre de visualisation de mémoire pour vérifier que le fichier binaire a été injecté. Et si votre fichier est le même que le mien, vous pouvez entrer CALL &"7000" dans la machine émulée pour voir apparaître Bonjour! à l'écran.

C'est déjà bien, non ?

Automatique on a dit !

C'est bien... mais taper source à chaque lancement, c'est long, on peut se tromper et cela serait mieux si cela pouvait être automatique.

Et c'est tout à fait possible :

mame64 vg5k -ramsize 48k -window -nomax -debug -debugscript debug.txt

-debugscript, comme son nom l'indique, fourni un nom de script pour le debugger qui sera exécuté au démarrage. Juste après le lancement de l'émulateur, le fichier binaire est donc injecté sans manipulation.

D'accord, mais il faut encore taper la commande CALL &"7000" pour lancer le programme, et avec la disposition d'un clavier qui change entre la machine émulée et la machine hôte, personnellement, je trouve cela fastidieux (surtout pour la touche ", qui est une touche morte dans ma configuration par défaut).

Pas de problème :

mame64 vg5k -ramsize 48k -window -nomax -debug -debugscript debug.txt -autoboot_command 'CALL &"7000"\n' -autoboot_delay 2

-autoboot_command indique la chaîne à passer à l'émulateur comme si les touches étaient appuyées,
-autoboot_delay pose un délai de 2 secondes avant de lancer les commandes, ce qui laisse le temps au script de s'exécuter.

À vrai dire, le délai de 2 secondes est la valeur par défaut, mais l'idée était de montrer la commande, pour pouvoir ajuster le délai.

Là, ça commence à être pas mal.

Mais...

Mais il y a deux choses encore qui me chiffonnent. Tout d'abord, la fenêtre du debuggeur se place au-dessus de ma fenêtre d'émulation, et je dois systématiquement la bouger pour voir le résultat. Il y a bien la possibilité d'utiliser la commande -debugger none, mais alors le script n'est plus exécuté.

Il y a la possibilité d'utiliser un debuggeur qui utilise la bibliothèque imgui et qui s'affiche dans la fenêtre d'émulation. Je vous suggère alors de passer -nomax en -max. Possibilité aussi pour le debugger par défaut (mais imgui est semi-transparent, le debugger par défaut opaque).

mame64 vg5k -ramsize 48k -window -max -debug -debugscript debug.txt -autoboot_command 'CALL &"7000"\n' -autoboot_delay 2 -debugger imgui -video bgfx

Cela donne déjà de quoi s'amuser et automatiser la chaîne de développement. Il y a cependant moyen d'aller encore plus loin avec MAME. Ça sera pour la prochaine fois.

Travailler sur émulateur et dump de la ROM VG5000µ

2018-01-01T00:00:00+01:00

Précédemment, j'ai commencé à parler d'une chaîne d'assemblage pour développer un programme depuis un ordinateur actuel vers une machine ancienne, le VG5000µ qui est l'ordinateur qui nous suit depuis le début de ces articles.

Un des avantages d'utiliser une machine de développement différente de la machine cible est de ne pas souffrir des erreurs, plantages et reboot provoquées par des erreurs. Imaginez, développer sur la machine que l'on programme elle-même, à une époque où le système d'exploitation ne protège rien du tout : une erreur, un reboot et si vous n'avez pas sauvé, il faut recommencer. Et si vous avez sauvé, les temps de chargements et de sauvegardes sont assez long, surtout sur une machine qui n'a pour mémoire externe qu'un magnétophone à cassettes !

Bref, développer sur une machine annexe et envoyer sur la machine cible, c'est plus simple, cela permet de profiter d'outils modernes mais... ça reste lent dans la plupart des cas. En tout cas sur une machine comme le VG5000µ qui n'a pas eu de développement spécifique qui pourrait injecter du code depuis une autre machine (pour le moment tout du moins, car c'est possible et j'ai cru comprendre qu'une carte était à l'étude).

Viens la solution de l'émulation. Un émulateur est un logiciel qui va reproduire le fonctionnement de la machine cible. Étant énormément plus lente que la machine hôte, la machine cible pourra être émulée de manière tout à fait satisfaisante. Un émulateur pourra aussi facilement et rapidement charger un programme depuis la machine hôte pour la mise au point, réduisant la fréquence d'essai sur machine véritable.

Mais pour utiliser un émulateur, dans la majorité des cas, il faut fournir la ROM, c'est-à-dire le programme résident de la machine. Ce n'est pas nécessaire pour DCVG5K, l'émulateur développé par Daniel Coulom. Par contre, c'est nécessaire pour l'utilisation de MAME (plus exactement sa sous-partie MESS, qui émule les ordinateurs). De manière générale, vous êtes supposés avoir une copie de votre propre version de la ROM. Passons sur la partie un peu ridicule de cette restriction puisque le fichier que vous allez obtenir sera en tout point identique à celui obtenu par extraction depuis une autre machine...

Toujours est-il qu'il est très simple de copier (dumper) le contenu de la ROM d'une machine de ce type, puisqu'elle est visible et complètement adressable par l'utilisateur.

La méthode

Le VG5000µ doit être branché, bien entendu, et relié à une carte d'acquisition audio. Cela peut être tout simplement l'entrée son de votre ordinateur, certains utilisent des enregistreurs séparés.

L'idée est donc de sauver le contenu de la ROM, tel quel, dans un fichier. Rien de plus simple :

CSAVEM"ROM",0,16384

CSAVEM est la commande pour sauver un fichier depuis la Mémoire. Le nom du fichier est entre guillemets. 0 est l'adresse de départ et 16384 la taille en octets de la plage à sauvegarder. La ROM faisant 16 kio, la sauvegarde contiendra l'intégralité de la ROM.

Avant d'appuyer sur la touche ENTRÉE du VG5000µ, il faudra démarrer l'enregistrement sur l'ordinateur. J'utilise Audacity pour cela. Un logiciel libre de manipulation audio.

Assurez-vous au niveau du niveau d'entrée que le signal sature, cela sera plus facile pour le décodage. N'oublions pas qu'on est-ici dans un codage de signal numérique, pas dans de l'écoutable, ce qui est important, c'est que les signaux soient distinguables.

L'opération est assez longue, environ 2 minutes 30.

Une fois le signal enregistré, il faut l'exporter en format WAV puis le décoder. Comment décoder un signal en sortie de VG5000µ sera l'objet d'un futur article ou je décrirai le programme que j'utilise (et que je publierai sur GitHub). En attendant, l'outil DCToolBox de Daniel Coulom fonctionne bien, et se lance tout à fait avec Wine sous Ubuntu si vous n'êtes pas sous Windows.

Avec mon outil, le contenu binaire intéressant est extrait simplement.

Avec DCToolBox, il vous faudra transformer le WAV en format K7 et en extraire les informations. Le format K7 est extrêmement simple, il contient l'ensemble des données encodées dans le signal numérique produit par la machine. Tout d'abord les 32 octets d'en-tête, qui ne nous intéressent pas ici, puis 10 octets d'amorce du contenu sauvé, puis le contenu lui-même. La taille, nous la connaissons, est de 16384 octets.

Il faut donc aller chercher les 16384 octets à partir du 42ième, ce qui s'écrit très simplement dans un shell Unix :

tail -c+43 dump.k7 | head -c 16384 > dump.rom

dump.k7 étant le nom du fichier au format K7 et dump.rom le fichier résultat.

Si vous n'avez pas accès à un shell Unix... je suis preneur d'une méthode simple pour l'ajouter à l'article.

Et voilà !

Vous avez à présent une extraction de la ROM d'une machine VG5000µ, utilisable par les émulateurs la nécessitant.

Joyeuses fêtes en haute résolution

2017-12-30T00:00:00+01:00

Puisque la fin de l'année approche et que les fêtes dites de fin d'années ainsi que le nouvel an sont d'actualités, j'ai ressorti mon convertisseur d'image vers le VG5000µ publié ici et décrit ici pour une image « haute résolution » sur la machine.

L'astuce pour que la compression passe bien a été de positionner le maximum de motifs identiques sur une grille. Pour les dates et l'adresse du site, j'ai ajouté dans le programme BASIC à la main l'affichage en texte.

91 J$="22001177--22001188"
92 CURSORX15:CURSORY17:TX6,3:PRINTJ$
93 CURSORX15:CURSORY18:TX6,3:PRINTJ$
95 CURSORX23:CURSORY23:TX6,0:PRINT"TRICERAPROG.FR"

On y voit que pour écrire en double hauteur, il faut doubler l'affichage sur la ligne suivante. Et pour écrire en largeur, il faut doubler les lettres à afficher. Le tout en précisant 3 en second paramètre de l'instruction TX.

Le dithering qu'effectue la conversion malheureusement n'a pas été des plus heureux sur l'un des e, ce qui fait que la palette aurait pu être plus petite qu'elle ne l'est.

Voici l'image tramée :

Ainsi que la palette obtenue :

Avant de passer au résultat, un fichier zip est disponible contenant le programme en format .k7 ainsi qu'en .wav.

Petit détail : sur un émulateur, l'écran reste noir pendant la construction de l'image, puis celle-ci apparaît lorsque dans la deuxième partie du programme, les caractères étendus sont construits.

Par contre, sur une machine réelle, la mémoire du processeur graphique n'étant pas effacée au démarrage, on commence par voir s'afficher des bandes verticales mêlées à un peu de bruit, puis le message apparaît lorsque les caractères étendus sont construits.

Dans les deux cas, après un redémarrage à chaud (le programme BASIC n'est pas effacé de la mémoire), l'affichage se fait progressivement, car les caractères étendus sont déjà construits.

Triceraprog

Comparaisons 8 bits en Z80

Table des matières

Comparaisons non signées (8 bits)

A = B

A ≠ B

A < B et A ≥ B

A ≤ B et A > B

Comparaisons signées (8 bits)

A > B ou A ≤ B (signé)

A < B ou A ≥ B (signé)

Comparaisons signées simplifiées (8 bits)

A > B ou A ≤ B (signé, pas d'overflow)

A < B ou A ≥ B (signé, pas d'overflow)

Les drapeaux

À propos de S et V :

Instructions et drapeaux

z80dezasm, désassembler et commenter le Z80

L'origine

Mars 2026

z80dezasm

Adressage 6502, un récapitulatif

Tableau Récapitulatif

($nn,X) vs ($nn),Y

Références

Forth sur 6502, épisode 11

ACCEPT, enfin !

Gestion du clavier complet

Transferts PPU <-> RAM

Retour à l'édition de ligne logique

ACCEPT !

Amélioration du framework de test

Interprète... interprète !

Deux livres pour le développement sur Famicom

Making Games for the NES

Langage machine 6502 et 6510

Forth sur 6502, épisode 10

Un curseur et des branches

Entrer du texte

Et les tests ?

La suite !

Forth sur 6502, épisode 9

Froid, abandon, quitte...

Lire le clavier

Accès au clavier

Scan dans le Forth

Ce qu'il reste à faire

On peut écrire !

Forth sur 6502, épisode 8

Afficher des caractères

Presque EMIT

Des variables... pour de vrai ?

EMIT... pour de vrai aussi

Moving Forth, épisode 6

La suite

Forth sur 6502, épisode 7

En route pour l'affichage

Afficher du texte à l'écran

Les variables

Pas si vite !

Retour à la pile des paramètres

Le mot de test en Forth

Conclusion

Forth sur 6502, épisode 6

Des mots complets

Implémentation

Moving Forth, épisode 5

Conclusion et prochain épisode

Forth sur 6502, épisode 5

La boucle, pour de vrai !

Moving Forth, épisode 4

Prochain épisode

Forth sur 6502, épisode 4

NEXT

Implémentation

La boucle complète

DOCOL et ;S

Pseudo-code pour les deux mots

Et ça fonctionne

Moving Forth, article 3

`($nn,X)` vs `($nn),Y`