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 …

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 …

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 …

À 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 …

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 …

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 …

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 …

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 …

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 …

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 …

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 …

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à …

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 …

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 …

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 …

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 …

Le premier billet de ce site, que je veux consacrer principalement à la programmation et son histoire, commence, c'est le paradoxe, par de la soudure.

De discussion en discussion sur le forum System.cfg, l'idée de créer un lecteur de SD Card pour le VG5000 est apparue. Initialement, j'avais plus dans l'idée de m'occuper de la partie programmation. Cependant, à moins de vouloir utiliser de la sauvegarde sur cassette comme à l'époque, il est nécessaire d'avoir de quoi communiquer des informations depuis un ordinateur plus moderne.

La méthode est simple, en théorie, on branche un cordon entre la prise cassette du VG5000µ et les prises son du PC. Et c'est ainsi que commence l'aventure : je n'ai pas ce cable à disposition. Un petit coup d'oeil au brochage me montre qu'il me faut une prise DIN 8 broches. J'ai des prises DIN 8 broches sous la main... mais celles pour Commodore …