Bonjour à tous,
une incantation céleste a été prononcée, je sors de mon trépas pour m'exprimer
En préambule, je m'occupe du dev de Goldorak sur TO8, en assembleur 6809.
Voilà, la partie où je me vante est terminée, je vais pouvoir vous raconter mon cheminement personnel pour en arriver là.
Tout petit déjà, ... nan allez je vous épargne ça.
Début 2021, en trainant mes clics souris sur le forum logicielsmoto (forum dédié + dev/partage qu'ici je trouve, pour MO et TO, j'entends) je tombe sur un certain Bentoc qui met en avant un "machin" écrit en Java qui l'aide à faire des sprites (compilés) en ASM 6809.
A l'époque je commence à me ré-intéresser à l'ASM, j'ai lu la doc technique TO8 plusieurs fois, je me replonge dans mes bouquins de 6809. J'essaye d'engranger le plus d'info partout. En 2019 j'ai fait l'acquisition du SDDrive de Daniel, puis de l'extension mémoire TO8. Je l'évoque, car ce sont des outils nécessaires pour mon dev aujourd'hui, tout comme son émulateur DCMOTO et son interface de debugging. Sans oublier la T2 de FoolDuplex, évidemment.
Je vous fais grâces de mes étapes de "remontée" en compétence ASM 6809. Une grande partie a terminé sous forme d'article dédié sur mon blog (un peu de pub :
https://www.fxjavadevblog.fr/retro-programming )
Comme j'échange pas mal avec Bentoc notamment sur le BM16, le double buffering, la gestion des IRQ, les pratiques ASM : je me lance et je lui propose de participer à son "framework" composé d'un builder réalisé en Java et d'un ensemble de routines 6809 (Engine) très évolués, qui met en oeuvre de nombreux design pattern qu'on pense réservés à la programmation orientée objets. Comme je fais du Java depuis fin 1996, Java ne me pose pas de problème et donc je propose des améliorations, on modifie pas mal de choses (usage de maven, picocli, java 11) et on entame même une version 2 du builder (non opérationnelle à ce jour). Ce builder nous permet de construire rapidement des images disquettes, de cartouches T2, etc. en se préoccupant finalement qui doit être codé en plus. Il apporte des routines d'affichages de sprites compilés (dont la pré-compilation depuis des PNG est réalisée en Java) de double buffering, de musique, de son, aussi bien vers le CNA que vers les nouvelles cartes son YM et SN.
Quand je code Goldorak, je suis donc sous mon Linux :
- avec Visual Studio Code + plugin ASM 6809
- avec Java et Maven pour compiler le builder
- avec Java et le Builder pour transformer mes assets PNG en qqch d'exploitable par les routines ASM
- avec LWASM qui est un compilateur "cross-plateform" pour 6800 / 6809 / 6309, invoqué par le Builder
- avec l'émulateur en ligne 6809.uk pour vérifier des mini-algorithmes de manière unitaire.
- avec notre émulateur Fork de Theodore (lui-même fork de DCMOTO mais il y a très longtemps, dans une galaxie lointaine, très lointaine)
- DCMOTO sous Wine pour profiter du debugger
Avec tout ça j'obtiens en une ligne de commande, un .FD, un .SD, un .ROM issu de la compilation de Goldorak, que je m'empresse de mettre sur une jolie carte SD pour tester sur machine réelle.
A tout cela s'additionne avec le fait que je ne suis pas pressé par le temps, contrairement aux devs de l'époque, je préfère avancer doucement mais sûrement appliquer les bons algorithmes, les bonnes structures de données, les bonnes astuces, les bonnes optimisations de code.
Je ne pourrai pas faire tout ça sans toute la documentation mise à disposition, le site de Prehisto, de Pulkomandy, et les connaissances de mes potes du groupe "wide-dot". Parce que oui, rapidement, Benoît (bentoc) et moi avons demandé à Adnz de nous rejoindre, fort de son expérience sur Pacman 2022 mais aussi de ses talents de graphiste et musicien.
A cela s'est ajoutée l'arrivée dans le groupe "wide-dot" de personnes vraiment, vraiment, vraiment exceptionnelles : Sam et Yoann. Outre leurs compétences, ce sont aussi des gars adorables toujours prêt à aider / dépatouiller / optimiser (même sur les starfields à 1 étoile
). On se prend pas la tête et on se marre vraiment bien.
Perso, je code pour moi. C'est à dire que Goldorak, c'est pour MOI : pour le challenge, pour m'amuser, mais aussi à la base pour m'accaparer entièrement le framework de Benoit et la prog 6809. Ce que j'entends par là, ce n'est ni pour me faire mousser sur les forums ni pour sortir une version que tout le monde attend avant septembre ...
A titre professionnel je suis adepte du mouvement "Craftsmanship" que je m'applique quotidiennement :
- Qualité++
- Evolutivité au centre de la conception
- Application systématique des bonnes pratiques connues
- “Comprenabilité”
- Expertise (sandbox, kata)
- Exploration
- Capitalisation, Templating, Patterns
- Transmission
- Remise en cause
Et pourquoi tout ça c'est universel ? Car :
En ASM j'utilise :
- Nommages explicites
- Macros (== inline C) versus Routines (== fonction C)
- Optimisations mémoire : 512 Ko max, 16 Ko simultanés
- Optimisations cycles (TFR U,X devient LEAX ,U)
- Auto-modifications des OP codes
- Manipulations bas niveau / Algorithmes “optimisés”
C'est "pareil" en Java, par exemple :
- Nommages explicites
- JVM Usage Statistics Dynamic Inlining
- Optimisations de la mémoire et CPU : serverless !
- Moins de CPU / Mémoire = Moins d’infrastructure = Moins €€€
- Auto-modifications de code (Java : weaving, bytecode, introspection)
- Manipulations haut niveau / Algorithmes “optimisés”
- Structures de données optimisées (Map, Tree, LinkedList, etc.)
Pour résumer, c'est grâce aux compétences de dingues du groupe Wide-dot et notamment de Bentoc, que j'ai pu en arriver là. Aujourd'hui je commence à peine à me sentir à l'aise en dev ASM 6809. Je ne connais pas par cœur les 59 instructions du proc, mais ça commence à venir. Je suis souvent le nez dans la doc officielle Motorola/Hitachi et Thomson TO8. Mais j'ai quand même une certaine expérience professionnelle en C, C++, Java et sur en algorithmie / structures de données. Les reproduire en ASM est d'ailleurs souvent assez ardu et ça doit toujours faire l'objet de compromis CPU/MEMORY.
Merci de m'avoir lu, j'ai des PSHS qui m'attendent. Bisous à tous.
PS1: je vais remettre 1 pièce dans le flipper, mais je trouve que le 6809 est + 16 bits que 8 bits ...
Parce que je vous lis partout à dire "8 bits" mais la majorité de ce que je lui fais faire est sur 16 bits !
PS2: merci de ne pas troller le sujet avec "Java c'est bien / c'est pas bien", c'est pas le sujet et ces conversations de comptoirs m'exaspèrent.
