Site logo

Triceraprog
La programmation depuis le Crétacé

  • Un peu d'Atari ST ()

    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 peu d'assembleur, je me suis dit que c'était l'occasion de la redécouvrir. Par la programmation bien entendu.

    Le ton de Zisquier est direct, il va à l'essentiel, progressivement. Il y a des tests à la fin des leçons qui apportent un petit côté ludique. C'est fun et j'aime bien. Et petit à petit, me voici actuellement avec un sprite qui se déplace à l'écran au-dessus d'un décors.

    Le code est un peu moche, j'y vais un peu à tâtons et je ne sais pas toujours quels sont les meilleurs façon d'utiliser les instructions 68000. Mais il y a un Discord associé avec des personnes qui sont aidantes sur le sujet.

    Le sprite est en CC-BY 3.0 par « Withthelove », trouvé sur OpenGameArt.org.

    Le tileset est en CC0 par « Kenney », c'est Tiny Town remanié au niveau de la palette de couleurs et du layout pour correspondre à l'Atari ST et à mon besoin.

    Sprite et Tilemap sur Atari ST


  • Le Forth sur Hector HRX ()

    Avec la nouvelle session de Retro Programmers United for Obscure Systems, il est temps de découvrir la ligne des Hector HR. Que ce soit l'Hector 2HR, le 2HR+, le HRX et probablement le MX.

    Pour en savoir plus sur ces ordinateurs, il existe une page dédiée à ces machines.

    Après avoir cherché un peu dans les resources Hector, je me suis dirigé pour ma contribution à cette session vers le « Hector HRX » et son Forth. En effet, le HRX est un de ces rares ordinateurs 8 bits qui venait avec un Forth en ROM, au lieu du plus classique BASIC.

    Il existe un livre sur le Forth pour Hector HRX, « la pratique du Forth avec Hector », qui est plutôt agréable à lire afin de découvrir la machine à travers ce langage, et pourquoi pas, découvrir le Forth au passage.

    L'ennui avec le livre, c'est qu'il présente les mots en contexte, mais qu'il n'y a pas de référence regroupement les mots par catégorie, ou par usage. Il faut donc se souvenir du passage où le mot est présenté, et le retrouver parmi la prose pédaogique.

    Je n'étais pas non plus certain que tous les mots soient présentés par le livre (après en avoir fait la liste, il en manque bien quelques uns, mais c'est en fait très complet).

    Pour moi, il manquait donc une référence, et c'est ce que je me suis appliqué à faire. Cette référence n'est pas un apprentissage du Forth, la lecture du livre ou d'une autre ressource est nécessaire. Par contre, elle présente une liste catégorisée des mots ainsi que les grands principes du Forth et son implémentation sur Hector HRX.

    Éspérant donc que cette référence pourra vous être utile comme elle l'est pour moi, je l'ai publiée à cette adresse.


  • J'MSX 24 et un micro jeu ()

    Le salon

    Les 23 et 23 mai 2024 ont eu lieu à Paris deux journées autour du MSX. La rencontre se passait à ISART, une école de jeux vidéo, et était co-organisée par l'association MO5 et le MSX Village.

    Deux journées vraiment sympas avec quelques conférences, dont certaines faites par le concepteur du MSX en personne, Kazuhiko Nishi, qui avait fait le déplacement. Son but est de présenter ses projets de MSX0 et MSX3, sur lesquels je ne m'étendrai pas ici.

    Conférence de Kazuhiko Nishi

    Pour moi, cela a été l'occasion de rencontrer des gens passionnés par le MSX. N'étant moi-même pas très connaisseur de la machine, en tout cas pas autant qu'eux, j'ai pu apprendre plein de choses. Outre une exposition autour des jeux Konami, avec plein de MSX jouables en libre service, il y avait une petite exposition d'illustrations faites dans des modes de rendus MSX, ainsi qu'une présentation de diverses extensions modernes et françaises pour les machines du standard.

    La game jam

    Pendant le week-end, une game jam a été proposées aux étudiants de l'école qui nous accueillait. Quelques étudiants se sont prêtés au jeu. Le but était bien évidemment de créer un jeu pour MSX, fonctionnel sur une machine réelle, et donc de comprendre ses contraintes. L'organisateur les avait briefé auparavant, pour ne pas partir de zéro le jour J.

    Le thème ? « l'amour éternel ». Il y avait de bonnes idées autour du thème, mais je ne sais pas si les jeux ont été terminés.

    De mon côté, j'étais titillé par l'idée de participer. Mais je ne voulais pas non plus y passer le week-end. J'ai donc fait rapidement un petit truc le dimanche matin, probablement en 2 ou 3 heures tout en déambulant dans le salon. Le résultat n'est pas tout à fait un jeu : on ne peut pas gagner. Mais on peut perdre, et c'est déjà ça. On pourrait ajouter au jeu un score à maximiser...

    Capture d'écran de mon micro jeu

    Dans ce jeu, il faut attraper des logos MSX qui apparaissent sur le terrain. Lorsqu'on en attrape un, cela laisse sur place un petit visage souriant, propageant ainsi l'amour éternel du MSX. Ces visages gênent les déplacements, et il devient donc de plus en plus difficile d'attraper les logos. Le jeu est en mode 1 et est jouable sur un MSX1. J'ai bien entendu utilisé la librairie MSXgl que nous utilisons aussi pour le projet Room 5 pendant les lives twitch de l'association MO5. Jeu qui d'ailleurs était jouable sur place et sur vrai matériel.

    Bref, deux journées qui font plaisir.

    Room 5 en présentation à la J'MSX 24


  • Récréation 3D, Matra Alice ()

    Suite à des discussions semi-sérieuses sur la possibilité de transporter un Matra Alice pour l'utiliser à la plage, je me suis amusé à imaginer (et à modéliser) une extension « batterie + écran » pour le Matra Alice.

    Ce n'est qu'une vue d'artiste, aucune étude de faisabilité n'a été faite. Mécaniquement, je n'ai aucune idée de si ça tiendrait, je ne sais pas si ça serait pratique... c'est pour le fun !

    Dans cette hypothétique extension qui se clipserait à l'arrière de la machine, on peut imaginer des batteries pour fournir les 5V nécessaires (si on laisse tomber le port série), des connecteurs pour amener le signal vidéo à un écran plat. Et pourquoi pas une extension RAM ?

    Un concept de Matra Alice portable

    On m'a signalé que la chaîne YouTube « The Taylor and Amy Show » avait adapté un écran plat à un TRS-80 MC-10, si vous voulez voir ça, c'est par ici.


  • Tuiles des plus très-curieuses ()

    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 même taille de mémoire vidéo associée, 8k.

    Autant dire que niveau graphique, j'étais en terrain connu.

    Niveau processeur par contre, c'est une découverte. Le 6803 est un microcontrôleur 8 bits, de la famille des 6800. Mais je ne connaissais pas vraiment. En tout cas, je n'en avais aucune pratique. Il a de la RAM embarquée sur la page 0. Il a aussi un chronomètre (timer), normalement utilisée pour les communications (séries et cassette).

    Le développement

    Avant de parler du jeu, un mot sur le développement. Comme je venais de recevoir l'extension « Multiports » , je voulais que le jeu puisse être sur cartouche. Autre avantage, pas de temps de chargement si l'émulateur gère bien cette extension.

    Vous le savez si vous avez lu d'autres articles sur ce blog, j'aime bien avoir une chaîne de développement avec le maximum d'automatismes, pour me concentrer sur le développement du jeu et faire le moins d'opérations manuelles possibles.

    Mon choix habituel va vers MAME. Et MAME a un support pour l'Alice... mais pas pour l'extension. Mon premier développement a donc été d'ajouter à MAME le support de l'extension, en tout cas le support cartouche et l'ajout de RAM. Le changement a été accepté, mais j'ai quelques modifications qui m'ont été demandées et que je dois toujours terminer.

    Utilisant mes scripts d'automatisation habituels, j'avais en tout cas de quoi lancer l'émulateur automatiquement après une compilation.

    Cependant pour compiler... il faut un compilateur. Il n'y a pas beaucoup de choix pour le 6803 pour un compilateur C, et légèrement plus, mais pas trop, pour un assembleur. Dans un premier temps, j'ai fais quelques tests avec un premier assembleur... mais avec le jeu que je voulais faire, je me suis dit que j'y gagnerais en productivité avec un compilateur C.

    Après quelques recherches et essais, j'ai choisi CC6303. Le message « The assembler and linker should be reasonably reliable and complete. » m'a fait un peu peur, mais j'ai quand même tenté. J'ai fais des tests, et ça semblait générer du code correct.

    Sur toute la durée du développement, j'ai eu deux fois des problèmes de génération de code. Je ne les ai pas analysés plus que ça, car c'était (bien entendu) vers la fin.

    J'ai contribué à une paire de modifications au passage. Au moins, la game jam aura permis modestement d'améliorer les outils de développement pour cette machine.

    Le jeu

    Comme d'habitude, je suis parti sur une idée bien trop ambitieuse, et avec le premiers mois consacré à la découverte de la machine et aux modifications de MAME, j'ai dû revoir mes plans. En fait, même avec la totalité du temps, je n'aurais pas pu faire ce que je voulais...

    Je suis donc parti sur une idée de jeu que je voulais aussi faire : un Match-3. C'est un type de jeu auquel je joue beaucoup. C'est aussi un type de jeu qui a beaucoup de variations : est-ce que les tuiles tombent, est-ce qu'elles montent, est-ce qu'elles sont renouvelées, quel scoring, quels bonus, des challenges, etc.

    Pour démarrer, j'ai fait un prototype avec un terrain de 10 par 10, toujours rempli de tuiles. Lorsque 3 tuiles identiques ou plus sont alignées, elles disparaissent. Les tuiles du dessus tombent, et des nouvelles tuiles apparaissent en haut. Les tuiles étaient représentées par des chiffres. Le but pour moi était de 1/ trouver l'algorithme de recherche des tuiles alignées, 2/ vérifier que la machine était assez puissante pour ce type de jeu.

    Prototype du jeu

    Une fois le prototype fonctionnel, j'ai commencé à ajouter des graphismes. J'ai utilisé Pixelorama pour dessiner les tuiles, avec un thème « Alice au Pays des Merveilles ». Comme je l'ai fait auparavant, j'exporte manuellement les images en PNG (j'aimerais bien un export automatique, mais cela ne semble pas possible pour le moment, ou alors je n'ai pas trouvé). Ces imagines PNG sont ensuite converties en données dans un format que je peux inclure dans le code.

    De temps en temps, je lançais un test sur la machine réelle. C'est ainsi que je me suis aperçu que mon extension a un problème avec son extension RAM. Comme je n'avais pas le temps de m'en occupé, j'ai coupé la RAM supplémentaire (c'est une option de l'extension). Le jeu n'a pas besoin de beaucoup de mémoire, le code et les données graphiques étant présents dans la ROM.

    Les tuiles

    Une fois le jeu fonctionnel, je voulais ajouter un principe de challenges pour avoir une sorte de mode « histoire ». Je voulais aussi ajouter un mode « infini », mais je n'aurai pas assez de place pour ça. Je voulais aussi ajouter un petit personnage qui réagit aux actions du joueur.

    Dessiner un personnage avec les contraintes de couleur et mes (bas) talents de dessinateur a été un peu compliqué, mais je suis assez content du résultat.

    INSÉRER IMAGE AVEC LE PERSONNAGE Le personnage animé

    Problème : la place sur la cartouche. Une cartouche d'extension Multiports a une taille totale de 64k. En mode cartouche, cette taille est divisée en 8 banques de 8k. Cela signifie qu'à un moment donné, il n'y a que 8ko accessible. Le Multiports a un système simpliste de changement de banque : il suffit d'écrire sur une plage de donnée précise le numéro de la banque voulue. C'est suffisant, mais sans support du compilateur, c'est un peu acrobatique.

    Je n'avais pas le temps de pousser un système d'appels de code entre les banques, j'ai donc séparé le jeu en deux grandes parties. Dans la première partie, et donc la première banque, je mets tout ce qui est graphiques. C'est une astuce sur les jeux cassettes que je reprends ici : un premier programme se charge et redéfini les caractères. Ensuite, il lance le jeu.

    La première banque contient aussi l'écran de titre.

    Le cœur du jeu est dans la deuxième banque. Pour passer d'une banque à l'autre, j'ai un petit bout de code que je place en RAM pour faire le changement. Chaque programme est compilé comme un logiciel indépendant.

    Mais... et le titre ?

    Le titre est une référence à la traduction française de « Alice's Adventures in Wonderland » qui est trouvable sur le projet Gutenberg. Le chapitre deux commence par ce passage : « “De plus très-curieux en plus très-curieux!” s’écria Alice ».

    Dans mon jeu, Alice se retrouve dans un monde étrange avec des tuiles à aligner. On ne peut pas dire que ça va très loin d'un point de vue histoire et justification... mais ça suffira.

    Oh, et j'ai aussi dessiné une jaquette pour la cartouche et la manuel. À base de dessin sur tablette et de beaucoup de temps de retouche avec The Gimp, puis de composition avec Blender pour ajouter les tuiles.

    Quelques liens

    Conclusion

    Le jeu est disponible sur itch.io. J'ai rapidement ajouté une version cassette, car tout le monde n'a pas un Multiports (pas encore disponible sur la page, elle sera dans la version 1.1 que j'ajouterai bientôt).

    Tuiles des plus très-curieuses


« (précédent) Page 2 / 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), Peertube (1), Photo (2), Programmation (3), Python (1), ROM (15), RPUfOS (5), Salon (1), SC-3000 (1), Schéma (5), Synthèse (14), Tortue (1), Triceraprog (1), VG5000 (62), VIC-20 (1), Vidéo (1), Z80 (20), z88dk (1)

Les derniers articles

Instance Peertube pour Triceraprog
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

Atom Feed

Réseaux