Site logo

Triceraprog
La programmation depuis le Crétacé

  • 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


  • VG5000µ, le commentaire de la ROM ()

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

    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)

    Platine principale

    La platine K7/Son

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

    Platine K7/Son

    Note

    Le schéma a été mis à jour dans un nouvel article.


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

Tous les tags

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

Les derniers articles

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

Atom Feed

Réseaux