Triceraprog
La programmation depuis le Crétacé

  • Récréation 3D, Pascaline ()

    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.

    une Pascaline


  • VG5000µ, Schémas de principe mis à jour en v1.4 ()

    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 à novueau.

    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)

    Platine principale


    La platine K7/Son

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

    Platine K7/Son


  • Programmer sur Nintendo Switch en BASIC ()

    « 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.

    Le mode direct de Smile Basic 4

    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.

    Commandes de dessin avec Smile Basic 4

    Et pour créer ces sprites, ou n'importe quel dessin, un logiciel de pixel art est disponible sur F10.

    Editeur graphique Smile Basic 4

    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.

    L'aide en ligne Smile Basic 4

    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.

    Un petit programme


  • Automatisation : utilisation de Visual Studio Code ()

    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 ()

    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.

    Affichage des résultats de tests dans MAME


Page 1 / 16 (suivant) »