Triceraprog
La programmation depuis le Crétacé

  • Scripter MAME pour explorer la machine ()

    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

    Affichage en surimpression dans MAME


  • Injecter un programme dans un émulateur VG5000µ, partie II ()

    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 !

    La console LUA dans MAME


  • Injecter un programme dans un émulateur VG5000µ ()

    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.

    Debugger par défaut (Qt) sur MAME

    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.

    Debugger utilisant ImGUI sur MAME


  • Travailler sur émulateur et dump de la ROM VG5000µ ()

    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.

    Signal audio d'un enregistrement sur K7

    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.

    Sauver la ROM sur K7


  • Joyeuses fêtes en haute résolution ()

    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 :

    L'image tramées

    Ainsi que la palette obtenue :

    La palette

    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.

    Le résultat


Page 1 / 8 (suivant) »