Triceraprog

Travailler sur émulateur et dump de la ROM VG5000µ (2018-01-01)
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-30)
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.
Les différents VG5000µ (2017-12-14)

Depuis le début de la création de ce site, la majorité des articles a été consacré à du développement sur VG5000µ. Les programmes sont testés sur du matériel réel, même si je les mets au points sur un ordinateur moderne. Les captures d'écrans sont aussi faites sur un vrai VG5000µ, en sortie sur un moniteur récent grâce à un adaptateur Peritel vers HDMI.

Le VG5000µ a cette particularité d'exister sous différentes marques : Philipps, Schneider et Radiola. Plus de détails peuvent se trouver sur des sites plus détaillés dans l'histoire de cette machine, comme je l'indiquais dans un billet en début d'année.

En attendant la suite des articles sur les outils pour programmer cette machine en assembleur, voici une petite photo de famille.
Des outils pour programmer en assembleur sur VG5000µ (2017-11-16)
La dernière fois, j'avais évoqué le logiciel d'assemblage, ou assembleur comme étant le programme permettant de passer d'un programme sous sa forme source, c'est-à-dire écrite sous forme lisible par un humain, dans une forme binaire, qui sera plus exactement nommée forme objet. C'est cette forme qui pourra être exécutée par la machine.

Pour programmer, quel que soit la forme que revêt cette programmation, on a besoin d'outils. Les outils primaires peuvent être une table de référence, des manuels, un stylo, des feuilles et beaucoup de patience. Rapidement, le besoin d'outils pour effectuer les tâches automatiques et répétitives qui forment la transformation d'un programme source en programme objet se fait sentir. Et quoi de mieux pour traier des tâches automatiques et répétitives de transformation qu'un... ordinateur.

Le problème de la poule et de l'œuf n'est pas le sujet ici. Le principal est qu'à l'heure de l'écriture de cet article, il y a des outils utilisables sur un ordinateur actuel pour travailler plus facilement sur les ordinateurs plus anciens qui m'intéressent ici.

Pour le processeur Z80, il y a le choix. Mais comme du travail a déjà été fourni pour le VG5000µ, autant s'en servir. Et c'est vers la suite d'outils z88dk que je vais me tourner. Cette suite contient bien plus qu'un assembleur Z80 et j'en ferai un petit tour par la suite. Mais pour le moment, ce qui m'intéresse, c'est l'assembleur.

Outil de listing

Pour voir en quoi un assembleur peut nous aider, commençons par un test simple. Tout d'abord, j'écris le programme de l'article précédent dans un fichier hello.asm. Pour rappel, ce programme affichait Bonjour ! à l'écran avec les commandes suivantes :
```
    ORG $7000         ; Spécification de l'adresse mémoire d'implentation

    PUSH AF           ; Sauvegarde des registres sur la pile
    PUSH BC
    PUSH DE
    PUSH HL

                      ; Le cœur du programme :
    LD HL, chaine     ; Chargement de l'adresse du texte dans le registre HL
    CALL $36AA        ; Puis appel de la routine d'affichage de chaîne de caractères.

    POP HL            ; Restauration des registres depuis la pile
    POP DE
    POP BC
    POP AF

    RET               ; Retour au programme appelant
chaine:
    DEFB "Bonjour !", 0
```
Dans un terminal, j'exécute la commande suivante : z80asm -l hello.asm et j'obtiens très rapidement un nouveau fichier, hello.lis avec le contenu suivant :
```
1     0000                      ORG $7000
2     0000              
3     0000  F5                  PUSH AF
4     0001  C5                  PUSH BC
5     0002  D5                  PUSH DE
6     0003  E5                  PUSH HL
7     0004              
8     0004  21 0F 00            LD HL, chaine
9     0007  CD AA 36            CALL $36AA
10    000A              
11    000A  E1                  POP HL
12    000B  D1                  POP DE
13    000C  C1                  POP BC
14    000D  F1                  POP AF
15    000E              
16    000E  C9                  RET
17    000F                  chaine:
18    000F  42 6F 6E 6A 6F 75 72 20 21 00 
                                DEFB "Bonjour !", 0
19    0019
```
Ce fichier listing est constitué en première colonne d'un numéro de ligne, en seconde colonne d'une adresse mémoire relative au début du fichier, dans la colonne suivante de valeurs hexadécimales correspondant au résultat de l'assemblage, autrement dit au langage machine, puis enfin vient le contenu du programme source.

C'est donc un mélange de code source et d'une représentation lisible du code objet. Pratique pour suivre le résultat de la compilation simplement. Mais pas pratique pour essayer de lancer le programme sur la machine cible. Ce format est fait pour être lisible par un humain.

Création d'un binaire

Pour être adapté à la machine, par exemple en utilisant le programme de chargement en BASIC utilisé précédemment, j'ai besoin d'une forme qui ne contient que les octets indiqués dans le listing, sans tous les commentaires. J'ai besoin d'une seconde chose : que le programme soit logé à l'adresse mémoire que j'ai indiqué avec ORG $7000.

En effet, le listing ci-dessus a été produit avec des adresses commençant à l'adresse mémoire 0. Sur un VG5000µ, comme dans tous les ordinateurs à base de Z80, c'est un emplacement de ROM, une zone dans laquelle je ne pourrai pas écrire ce programme. J'avais donc indiqué une autre zone mémoire précise pour implenter le programme.

Appartée : à cause des instructions que j'ai utilisé, c´est une indication obligatoire. L'instruction LD HL, chaine est une instruction qui prend une adresse de manière absolue. La chaîne de caractère doit donc se trouver à un endroit connu et absolu en mémoire. Mon programme n'est pas relogeable. Si je n'avais utilisé que des instructions adressant la mémoire de manière relative, c'est-à-dire toujours sous forme d'une distance à partir de l'instruction courante, alors le programme aurait été relogeable, et l'adresse d'implentation n'aurait pas été importante. Faire des programmes relogeables sur Z80 n'est pas si simple, et même si z80asm peut aider cela sort du cadre de l'article.

Voyons ce que produit cette autre commande : z80asm -b hello.asm. Cette fois, c'est une fichier hello.bin que j'obtiens. Et si j'essaie de l'ouvrir comme un fichier texte, je n'obtiens rien de franchement lisible, à part la chaîne de caractères Bonjour ! à la fin.

Cependant, la taille du fichierest de 25 octets et c'est exactement le nombre de données hexadécimales indiqué dans le listing obtenu plus tôt. C'est aussi le nombre d'octets dans le chargeur en BASIC utilisé à l'article précédent.

Si je regarde le contenu de ce fichier avec un outil qui permet d'afficher le contenu de fichier sous forme hexadécimale, j'obtiens bien la même chose.
```
00000000  f5 c5 d5 e5 21 0f 70 cd  aa 36 e1 d1 c1 f1 c9 42  |....!.p..6.....B|
00000010  6f 6e 6a 6f 75 72 20 21  00                       |onjour !.|
```
Une utilisation possible est alors de transférer le contenu de ce fichier sous forme de DATA dans un chargeur en BASIC et voilà.

Par exemple, avec un petit script écrit en Python 3, cela pourrait donner ça :
```
basic = """10 S=&"7000"
20 READ A$
30 IF A$="FIN" THEN END
40 A$="&"+CHR$(34)+A$+CHR$(34):A=VAL(A$)
50 POKE S,A
60 S=S+1
70 GOTO 20
300 DATA {0}
400 DATA FIN"""

with open('hello.bin', 'rb') as f:
    content = f.read()

data = [hex(d)[2:].upper() for d in content]
data = ",".join(data)

print(basic.format(data))
```
C'est un script assez limité, sans protection au niveau de la taille du programme, ce qui pourrait générer un trop grand nombre de DATA, mais cela peut être utile pour, par exemple... écrire des articles avec des petits bouts de programmes à copier/coller dans un émulateur facilement.

Cependant, cela reste très manuel et ce n'est pas très satisfaisant. Nous verrons donc dans l'article suivant comment aller plus loin en utilisant les outils à disposition et se faciliter la vie.
Cross Chase, un défi multiplateforme (2017-09-29)

Des jeux vidéo récents sur des vieilles machines, il en sort régulièrement. Ainsi que des portages de jeux d'une de ces machines vers une autre de la même époque, qui n'avait pas eu sa version. Ou bien encore des versions améliorées.

CROSS-CHASE est un jeu développé par Fabrizio Caruso dont l'idée est un peu différente. Le défi est de développer un jeu vidéo sur l'ensemble des machines 8 bits. Le défi n'est pas terminé mais déjà bien avancé : Jupiter ACE, Apple II, Aquarius, Oric Atmos, C64, CPC, VIC20, VG5000µ,...

L'enjeu est donc de trouver un gameplay assez simple qui pourra être supporté par toutes ses machines, et programmer de manière à minimiser l'effort de portage sur chacun de ces hardwares.

Le joueur contrôle un personnage qui doit fuir des cercles en s'en débarassant par collision sur des X. C'est fun et rapide, jouable, dans l'esprit de l'époque. Il y a même plusieurs niveaux sur les version complètes.

En effet, il y a des limites à la portabilité entre ces machines du fait principalement de leurs capacités mémoire. Le jeu est donc séparé en une version complète nécessitant plus de mémoire qu'une version minimale, consommant elle un maximum de 16 ko.

J'ai pu essayer sur du vrai matériel les version VG5000µ et Commodore 64. La version Commodore 64 dispose de caractères redéfinis, ce qui ajoute une touche sympathique. Elle n'est cependant jouable qu'au joystick, ce que j'ai trouvé assez dommage, car cela manque de la précision que l'on peut avoir au clavier. La version VG5000µ ne se joue elle qu'au clavier, mais la disposition des touches de cette machine ne rend pas le contrôle du jeu optimal.

N'empêche, je me suis bien amusé.

Et la technique ?

Ce site parlant programmation, voyons quels sont les outils utilisés par CROSS-CHASE.

Tout d'abord, la grande partie du jeu est programmée en C, compilé avec CC64 pour les ordinateurs utilisant un CPU 6502 et Z88DK pour les ordinateurs utilisant un CPU Z80 (je ne fais là que paraphraser le contenu du README). Le choix du C permet un code objet compact, proche de la machine tout en restant portable. Le code ne sera pas optimal pour chaque machine, mais pour un portage sur autant de plateformes différentes, le choix est judicieux. On se rapproche ici des méthodes modernes de jeux développés sur plusieurs plateformes.

Dans le code VG5000µ, l'appel de l'affichage de caractère est néanmoins en assembleur, ainsi que le code pour faire disparaître le curseur. Le reste profite du support des compilateurs et de leurs bibliothèques.

Le reste de la stratégie de portage consiste à un mélange de fichiers spécifiques compilés uniquement pour les bonnes cibles et l'utilisation de #define/#ifdef. Le choix entre jeu minimal et complet est aussi fait par utilisation de #define/#ifdef.

Niveau compilation, depuis quelques jours un Makefile est apparu et à remplacé la multitudes des fichiers batch de compilation spécialisés par plateforme (qui ont été déplacées au chaud dans un répertoire batches). C'est bien plus pratique à lire.

Cerise sur le gâteau : les sources sont disponibles, ce qui donne un bon exercice de lecture.

Je vous conseille d'aller voir ce projet et de jouer au jeu sur la machine de votre choix. Il devrait bien y avoir une version pour votre machine préférée !