Vincent Rivière

Mais qui ne connait pas Vincent Rivière ? peu de mains se lèvent, oui Vincent est un super héros des temps modernes qui a su concocter des merveilles comme...à l’arrache... l’évolution d’Emutos, du Firebee, des tutos youtube, réparer un réveil etc.

Veillez, svp et sous vos applaudissements, accueillir Mr VINCEEEEEEENT!!!

-Bien le bonjour Vincent, alors comme les autres que j’ai interviewé , peux-tu te presenter ? d’ou viens-tu ? Que fais-tu de beau dans la vie ? Et raconte-nous ton parcourt informatique et surtout la découverte du monde Atari

Bonjour, Emmanuel. Je m'appelle Vincent Rivière. On me connaît généralement pour mes travaux sur GCC, EmuTOS, ou plus récemment pour ma chaîne YouTube "Vretrocomputing". Mon pseudo est "BlankVector", pour l'instant je l'utilise seulement sur les forums. J'ai grandi dans le sud de la France, et j'habite à Paris depuis plus de 20 ans. Je suis développeur dans le service informatique d'une université. Je fais principalement de la programmation en Java et SQL. Mais auparavant, j'ai eu la chance de travailler pour plusieurs sociétés dans des domaines très variés, ce qui m'a permis d'acquérir une solide expérience dans le développement en général. Et d'être à l'aise dans la plupart des domaines relatifs à l'informatique.

J'ai découvert l'informatique à l'école primaire, au début des années 80. Tout d'abord, avec le ZX81. C'était un ordinateur minuscule qu'on branchait sur une télé en noir et blanc via la prise d'antenne. Il permettait de programmer en BASIC (donc en anglais), avec son petit clavier à membrane. Personne n'y comprenait grand chose, mais ça me fascinait. Puis toujours à l'école, on a eu un Thomson TO7-70. Il permettait bien sûr de programmer en BASIC, mais aussi : en LOGO. Et là, ça a été le déclic. Car le LOGO était un langage en français, donc plus facile d'accès que le BASIC. Et en plus, il s'est révélé être un très bon langage procédural. Ce LOGO était fourni avec deux très bons manuels qui permettaient d'assimiler progressivement le langage. C'est ainsi que j'ai appris les notions de variables, d'instructions et de procédures. De plus, le LOGO permettait de faire bouger une "tortue" qui traçait des traits sur l'écran. On faisait ainsi de la programmation graphique, très simplement. Franchement, c'était très pédagogique. Depuis cette époque, je n'ai eu qu'un seul objectif : avoir un ordinateur à la maison pour pouvoir continuer à programmer. Hélas, à l'époque c'était hors de prix, complètement inaccessible pour moi. Plus tard, j'ai fini par apprendre le BASIC. Je me souviens qu'on avait des MO5 au collège, avec un "nanoréseau" qui utilisait un PC comme serveur pour sauvegarder les programmes sur une disquette 5"1/4. C'est dingue, c'était vraiment une autre époque. Plus tard, on m'a prêté un Alice 32 pendant les grandes vacances. Encore un très bon ordinateur, avec lequel j'ai pu me perfectionner en BASIC. Et finalement, c'est au lycée que mes amis m'ont fait découvrir l'Atari ST. La claque. Un ordinateur à la fois puissant et polyvalent. Pour programmer, bien sûr. Mais aussi pour jouer. Faire du dessin. Et surtout : de la musique, que ce soit du soundchip ou des modules avec des sons digitalisés. Quelque temps plus tard, en 1992, mon rêve s'est enfin réalisé : j'ai pu m'offrir un Atari 520 STe. Et je me suis mis en tête de le connaître à fond. D'abord, j'ai programmé avec l'Omikron BASIC qui était fourni avec le STe. Puis en assembleur 68000 grâce à ST Magazine et un ami très motivé. Et enfin, en C. J'ai longtemps travaillé exclusivement avec des disquettes. Tardivement, j'ai pu acheter un disque dur d'occasion (merci 3614 RTEL2). Ca m'a permis de travailler plus confortablement. Et même de découvrir MiNT. A la même époque, je travaillais sur UNIX à l'école. Ca m'a permis de faire le parallèle entre les deux systèmes. Et surtout, ça m'a appris à programmer proprement en langage C : je compilais mes programmes aussi bien sur UNIX que sur Atari. Et comme je connaissais déjà bien l'assembleur 68000, en j'ai pu comprendre beaucoup de subtilités du langage C en désassemblant les programmes produits. J'ai continué comme ça le plus longtemps possible. Et finalement, en 1997, le ST est devenu trop lent pour mes besoins. Alors j'ai laissé tomber, et je suis passé sur PC. On va dire que j'ai eu 10 ans d'absence sur Atari. Puis j'y suis revenu.

Au début des années 2000, j'étais à fond sur le langage C++. Je me suis mis en tête de programmer en C++ pour Game Boy Advance, depuis Windows. Mais à cette époque, il y avait peu d'outils. Le compilateur le plus flexible, c'était bien sûr GCC. Mais comme je ne connaissais ni GCC, ni la Game Boy Advance, je me suis dit que le plus simple c'était de commencer à me faire la main avec GCC pour la machine que je connaissais le mieux : l'Atari ST. C'est ainsi que je me suis investi dans les m68k-atari-mint cross-tools. Je voulais utiliser mon environnement de développement habituel (PC sous Windows) pour produire des programmes Atari, les tester avec les émulateurs, et enfin les utiliser sur le vrai hardware. Et c'est là que je suis tombé sur les travaux de Patrice Mandin. Patrice a fait un travail remarquable : il a pris les anciens patchs de la distribution SpareMiNT (qui utilisait GCC 2.95) et les a portés sur GCC 3. Et surtout, il a tout documenté sur son site web (*). C'est ce qui m'a mis le pied à l'étrier. J'ai donc entrepris de compiler GCC sous Windows, en utilisant Cygwin (un environnement de type UNIX), pour produire des programmes Atari. Et là, l'horreur. J'y ai littéralement passé des années, pour plusieurs raisons. Tout d'abord, GCC est avant tout conçu pour Linux. En choisissant de le compiler pour Cygwin, j'ai cumulé les difficultés. Par exemple, la compilation est beaucoup plus longue, et les sources de GCC sont énormes. Ensuite, d'une version à l'autre, le code de GCC change plus ou moins. J'ai voulu appliquer les patchs de Patrice sur les versions de GCC 3 plus récentes. Et là aussi, ça a encore compliqué les choses. Le temps que j'arrive à résoudre les problèmes un par un, GCC était déjà passé en version 4. Et ça avait encore plus changé. Alors j'ai décidé de mettre un grand coup, pour que tout le travail que j'avais déjà effectué ne soit pas vain. Je me suis acharné comme jamais. Je suis tombé sur des bugs des binutils et de GCC. J'ai fait des rapports de bugs auprès des équipes du GNU, j'ai dû attendre que quelqu'un les résolve, parfois j'ai dû les corriger moi-même. Je précise que j'ai fait tout ça seul dans mon coin, souvent à la limite du désespoir. Et finalement, en 2007, j'ai fini par obtenir un GCC 4 qui produisait du code correct pour Atari. Même en C++. Alors j'ai décidé de créer un site web pour publier ces travaux (Vincent Rivière's m68k-atari-mint cross-tools **). Puis j'ai fait une annonce sur le newsgroup fr.comp.sys.atari.

(*) http://patrice.mandin.pagesperso-orange.fr/en/howto-cross33.html
(**) http://vincent.riviere.free.fr/soft/m68k-atari-mint/

Et là, ça a été un tournant. J'ai eu mes premiers contacts avec les autres ataristes. Mon travail a été très favorablement accueilli. Et je dois tout particulièrement remercier une personne : Olivier Landemarre. Car comme moi, Olivier s'était lui aussi frotté à GCC 4. En fait, nous avions tous les deux travaillé dessus, sans le savoir. Olivier m'a suggéré de parler de mon travail sur la MiNT Mailing List. J'avoue que j'ai été surpris, car j'étais persuadé que plus personne n'utilisait MiNT depuis bien longtemps. Les ataristes de fr.comp.sys.atari m'ont aussi fait découvrir ARAnyM (machine virtuelle à base de 68040) dont je n'avais jamais entendu parler. J'ai halluciné de voir un environnement graphique complet de type MiNT fonctionner avec ARAnyM, surtout aussi rapidement. Donc j'ai suivi les conseils d'Olivier, et j'ai rejoint la MiNT Mailing List (en anglais). Et là, j'ai découvert qu'il y avait toute une communauté qui existait encore autour de ce système. J'ai appris que le noyau MiNT avait été renommé FreeMiNT et qu'il était désormais maintenu par la communauté. Tout comme la MiNTLib (librairie standard C) et les autres outils. A l'époque, c'était la distribution SpareMiNT qui avait le vent en poupe, avec ses paquets RPM de type Red Hat, construits avec GCC 2.95. J'ai appris que c'était sur cela que Patrice Mandin s'était basé pour ses patchs GCC, bien avant moi. La communauté FreeMiNT s'est montrée très intéressée pour utiliser GCC 4. Je dois avouer que ça a donné une nouvelle impulsion pour mettre à jour les paquets qui étaient vieillissants. C'est à cette époque que j'ai lié connaissance, par écrit, avec Frank Naumann, Alan Hourihane et Miro Kropáček, pour ne citer qu'eux. Tout à coup, mon travail a eu une portée internationale. Tous ensemble, nous avons amélioré GCC 4 ainsi que FreeMiNT. Et finalement, je ne suis jamais retourné à la Game Boy Advance.

-tu as participé au développement du firebee avec plusieurs personnes en Europe, est-ce qu’il a eu le succès escompter par les développeurs ? Est-il toujours d’actu ?

En effet, le projet ACP (Atari Coldfire Project) été un autre tournant. C'est lui qui a permis l'apparition du FireBee (ou de la FireBee, c'est comme on veut). Fin 2008, j'ai été contacté par Mathias Wittau. Il m'a annoncé qu'il était en train de monter une équipe pour produire un nouvel ordinateur à base de processeur ColdFire, et m'a demandé si je souhaitais en faire partie. J'ai accepté. Pour ceux qui ne connaissent pas (ce qui était mon cas à l'époque), les processeurs ColdFire sont les successeurs des 680x0. Enfin, pas tout à fait : ce sont un peu comme des cousins. Ils ont une architecture similaire, mais simplifiée : ils ne supportent qu'un sous-ensemble des instructions du 68000. Et comme ils sont de conception plus récente, ils peuvent plus facilement monter en fréquence. Par exemple, le FireBee est équipé d'un ColdFire 5474 (coeur V4e) à 264 MHz. On voit qu'en termes de fréquence, on est à des années-lumière du ST. Et ça reste largement au dessus des CT60, même overclockées. C'est ce qui a motivé le choix du ColdFire V4e pour le FireBee: un processeur très similaire au 68000, mais à une fréquence beaucoup plus élevée. De plus, le FireBee embarque un puissant FPGA. Ce type de composant est programmable, et permet de simuler des circuits électroniques, même très compliqués. C'est donc l'idéal pour simuler tous les circuits du Falcon et permettre ainsi une compatibilité au niveau des registres hardware (du moins, en théorie).

En pratique, j'ai passé 4 ans à travailler d'arrache-pied sur le FireBee, en y passant tout mon temps libre. Le projet ACP m'a permis de côtoyer beaucoup d'ataristes, dont plusieurs pointures. A commencer par Fredi Aswchwanden, qui a conçu et réalisé le hardware du FireBee, ainsi que la couche logicielle de bas niveau (BaS). Fredi est bien connu dans la milieu Atari, car c'est lui a créé les ordinateurs Medusa T40 et Hades (compatibles Atari) au milieu des années 90. Ca vous donne une idée de son niveau. Une autre personne bien connue est Didier Méquignon, qui a notamment créé Aniplayer (lecteur multimédia) mais surtout le TOS modifié des cartes CT60. Didier a adapté son TOS pour ColdFire sous le nom de FireTOS. Ca reste aujourd'hui le système d'exploitation principal du FireBee. Didier a dû faire face à de nombreux problèmes techniques pour réussir à faire fonctionner le TOS sur ColdFire, qui est par nature un processeur incompatible. Il a dû recourir à des astuces incroyables. C'est un véritable tour de force. Et en plus, il a apporté des améliorations comme le support des claviers/souris USB, un driver IDE/CompactFlash, et des modes vidéo étendus sur 32 bits pour les écrans modernes. Franchement, on peut dire que Fredi et Didier sont des génies. Et je pèse mes mots.

En pratique, Didier a réussi à adapter son FireTOS pour le FireBee relativement facilement. Mais il y a une raison à cela. C'est parce qu'auparavant, il s'était déjà fait la main sur d'autres machines à base de ColdFire : les cartes d'évaluation. Et là, ça dépasse l'entendement. Didier a réussi à faire fonctionner le TOS sur ces cartes d'évaluation qui n'ont rien à voir avec les machines Atari, pas même le processeur. C'est une histoire incroyable, qu'il a raconté au jour le jour sur son site web, en marge du projet CTPCI (*). A cette époque, Olivier Landemarre (encore lui !) travaillait avec Didier, notamment pour ajouter le support ColdFire dans GCC 4 et pour rendre FreeMiNT compatible ColdFire. C'est fou car à la même époque, je travaillais moi aussi sur GCC 4, et nous ne nous connaissions pas encore.

(*) https://didierm.pagesperso-orange.fr/ct60/ctpci.htm

Mais revenons au projet ACP, début 2009. Nous avions en projet cette machine, le FireBee. Mais elle n'existait pas encore, et il fallait avancer d'une manière ou d'une autre. De mon côté, je me suis dit que FireBee aurait besoin d'un système d'exploitation 100% ColdFire. Et pour cela, j'ai naturellement pensé à EmuTOS : un système libre, écrit principalement en langage C, et compatible avec le TOS d'Atari. Je ne connaissais pas beaucoup EmuTOS, car je l'avais découvert peu de temps auparavant, en même temps qu'ARAnyM. Je me suis donc attelé à 2 tâches : activer le support ColdFire dans les m68k-atari-mint cross-tools (ce qu'Olivier avait déjà expérimenté), et compiler EmuTOS pour ColdFire. En pratique, cette dernière tâche s'est révélée beaucoup plus difficile qu'il n'y parait, et cela pour plusieurs raisons. EmuTOS est écrit majoritairement en C, mais il y a tout de même un certain nombre de sources en assembleur. Ces derniers doivent impérativement être revus et adaptés manuellement pour ColdFire. Donc ce travail s'est révélé ardu. D'abord, je connaissais à peine EmuTOS. Ensuite, je ne connaissais pas le ColdFire. Et enfin, le FireBee n'existait pas encore. De plus, il n'existait aucun émulateur de ColdFire V4e. Une nouvelle fois, c'est Olivier Landemarre qui m'a sauvé la mise. Il m'a tout simplement envoyé sa carte d'évaluation ColdFire M5484LITE, celle sur laquelle il avait travaillé avec Didier. Ca m'a permis de tester les routines assembleur d'EmuTOS sur ColdFire, une à une. Mais il restait un gros problème : EmuTOS était un système d'exploitation pour Atari ST et Falcon. Alors qu'il n'y avait évidemment aucun matériel Atari sur la carte d'évaluation : aucune carte graphique (du moins en standard), pas de lecteur de disquettes, pas de soundchip, seulement deux ports série et un port Ethernet. Donc je me suis lancé dans un autre chantier titanesque : EmuTOS pour matériel non-Atari. Concrètement, ça consiste à parcourir les sources d'EmuTOS, et à désactiver toutes les parties du code qui font appel au matériel Atari. Ainsi, je me suis retrouvé avec une version d'EmuTOS 100% ColdFire, et qui n'avait besoin d'aucun matériel Atari. Il a ensuite suffi que j'ajoute quelques routines, notamment la redirection des entrées/sorties console vers le port série de la carte, et je me suis retrouvé avec un EmuTOS qui fonctionnait parfaitement en mode texte dans un terminal. Ca m'a permis de corriger les derniers bugs. Et c'est comme ça qu'est né EmuTOS pour ColdFire. Ensuite, en réactivant le code spécifique pour les machines Atari, tout en conservant la compilation pour ColdFire, j'ai obtenu une version d'EmuTOS qui était censée être compatible avec le futur FireBee. Je vous passe les détails, car en pratique le chemin a été semé d'embûches. Mais ça s'est passé à peu près comme ça. Finalement, les premiers prototypes du FireBee sont arrivés, et on a pu utiliser cette version d'EmuTOS pour débugger le hardware. On peut retrouver toute cette histoire sur le site web du projet ACP (*).

(*) http://acp.atari.org/news_fr.html

Mais tout compte fait, après cette phase initiale, EmuTOS a été peu utilisé sur FireBee. Cela pour plusieurs raisons. EmuTOS pour ColdFire fonctionnait parfaitement sur le FireBee, et c'est toujours le cas aujourd'hui. Mais j'ai souhaité qu'EmuTOS pour ColdFire s'exécute 100% en mode ColdFire, à vitesse optimale et sans aucune émulation. En conséquence, EmuTOS pour FireBee ne permet pas de faire fonctionner les programmes 68000. Bien sûr, sur ST/TT/Falcon avec un processeur 68000 ou 68030, EmuTOS permet d'exécuter les vieux programmes Atari, exactement comme le TOS. Mais EmuTOS pour FireBee ne permet d'exécuter que des programmes recompilés pour ColdFire (pour peu qu'ils soient écrits en C et que les sources soient disponibles). Il ne permet donc pas d'exécuter les vieux programmes Atari qui nécessitent un 68000. Donc ça limite très fortement les possibilités. J'ai par la suite adapté FreeMiNT pour ColdFire (en continuant le travail d'Olivier Landemarre et Didier Méquignon), et recompilé de nombreux programmes de type UNIX pour MiNT en m'inspirant des paquets de SpareMiNT. Même si ça marche à merveille, et très vélocement, ça ne remplace pas tous les vieux programmes qui font l'âme de nos machines Atari. De son côté, Didier a inclus dès le début une émulation 68060 dans son FireTOS. Même si elle est imparfaite, ça marche étonnamment bien. De plus, FireTOS gère les claviers USB et les résolutions étendues en 32 bits, alors qu'EmuTOS nécessite un clavier Atari et ne gère que les résolutions du Falcon. Donc pour les utilisateurs, le choix est vite fait : FireTOS offre beaucoup plus de possibilités qu'EmuTOS. Même si c'est au prix d'une grande complexité en interne. Alors qu'EmuTOS est beaucoup plus simple, et facilement modifiable.

Finalement, j'ai quitté le projet ACP fin 2012. Ca commençait un peu à tourner en rond. Je ne sais pas trop ce que c'est devenu depuis. Il y a occasionnellement des annonces sur le site officiel firebee.org (*). Jusqu'ici, 200 FireBee ont été produits, en 2 séries. Je trouve que c'est assez énorme, pour une machine aussi atypique et relativement chère. Peut-être que si suffisamment de personnes se montrent intéressées, il pourrait y avoir une 3ème série. L'avenir nous le dira.

(*) http://firebee.org/

Pour conclure sur ce sujet, je suis un peu déçu du FireBee. C'est vraiment une bonne machine qui offre d'innombrables possibilités, surtout avec son FPGA reprogrammable et ses nombreux ports d'entrée/sortie. Mais ses atouts sont aussi ses faiblesses. A commencer par le processeur ColdFire. Car quoi qu'on en dise, le ColdFire reste incompatible avec le 68000. Donc soit on fait un choix radical comme EmuTOS, en supportant les programmes ColdFire de manière optimale mais en laissant tomber la compatibilité 68000. Soit on fait un compromis comme FireTOS en proposant une émulation 68060 imparfaite (mais correcte dans 95 % des cas) avec une vitesse confortable. Un autre problème du FireBee, c'est son FPGA qui nous promet un hardware compatible Falcon. Sauf qu'en pratique, cette implémentation est loin d'être parfaite. Bien sûr, le FPGA est reprogrammable, donc tous les problèmes pourraient théoriquement être corrigés. Mais un FPGA se programme en langage VHDL, ce qui demande des compétences très spécifiques et peu répandues. Donc concrètement, ça ne bouge pas beaucoup de ce côté là. Je tiens tout de même à terminer sur une note positive. Le couple FireBee/FireTOS fonctionne étonnamment bien pour faire fonctionner les programmes GEM. Avec FreeMiNT et les modes vidéo étendus, c'est clairement l'environnement de type Atari le plus moderne.

 

-Emutos est aussi ton système d’exploitation favori que tu as créé. Que peut-il faire de « plus» que notre bon vieux TOS ?

Ah non, je rectifie tout de suite. Ce n'est pas moi qui ai créé EmuTOS ! C'est Martin Döring qui a initié le projet en 2001. Il a commencé à partir des antiques sources du GEM de Digital Research pour PC qui ont été libérés quelque temps auparavant par la société Lineo. Cela inclut notamment les sources du BDOS (GEMDOS) et du GEM. En fait, ce sont les mêmes sources qui ont servi de base à Atari pour créer le TOS. Mais Atari n'a jamais libéré ses sources. Donc Martin est parti des sources de Digital Research, et il a comblé les trous pour produire EmuTOS et le rendre compatible TOS. Bref, il a refait le même travail qu'Atari. Concrètement, il a dû réécrire tout le BIOS/XBIOS, mais aussi corriger de nombreux détails. Mais Martin n'a pas travaillé seul. Rapidement, il a été rejoint par Laurent Vogel, puis par Thomas Huth (l'auteur de Hatari). En 2007, j'ai eu mes premiers contacts avec l'équipe d'EmuTOS, à propos de la compilation avec GCC 4. Et en 2009, j'ai fourni les patchs pour ajouter le support du processeur ColdFire, en vue du FireBee. Ca a été un gros travail. Pour les sources C, il a suffi de changer une option de compilation. En revanche, j'ai dû manuellement patcher tous les sources assembleur. Et finalement, en 2010 Thomas m'a proposé de devenir responsable du projet EmuTOS. Ca a été la consécration ! Car après toutes ces années à étudier le fonctionnement du TOS, j'ai pu exploiter ces connaissances sur un projet concret : un système d'exploitation compatible TOS. Je souligne au passage un des nombreux avantages des projets libres : ils peuvent facilement changer de responsable. Mes principales contributions ont été EmuTOS pour ColdFire, dont je viens de parler. Mais aussi EmuTOS pour Amiga ! Car après m'être donné tant de mal pour le FireBee, porter EmuTOS sur Amiga a presque été une formalité. Evidemment, cette version a de sévères limitations. Mais comme l'Amiga a un vrai 68000, ça marche quand même à merveille. Concrètement, si un programme fait seulement des appels au TOS (sans accès direct au hardware Atari) et supporte le mode monochrome, alors il a toutes les chances de fonctionner sans aucune modification sur Amiga. Donc EmuTOS pour Amiga est plus compatible avec les vieux programmes Atari qu'EmuTOS pour FireBee ! Pour revenir à mes contributions sur EmuTOS, j'ai aussi corrigé d'innombrables bugs. Au fil des années, EmuTOS est devenu très fiable. Les sources sont arrivés à une certaine maturité, de nos jours on n'a presque plus de surprises. J'ai également écrit la première version du driver IDE intégré à EmuTOS, ce qui a permis d'exploiter les cartes CompactFlash du FireBee (ce que FireTOS faisait déjà). Et j'ai aussi automatisé la production automatique des snapshots avec Travis CI, à l'image de ce qui avait déjà été fait par l'équipe FreeMiNT. C'est intéressant, car ça permet à n'importe quel utilisateur de tester les développements en cours sans devoir recompiler manuellement les sources. Et surtout, sans aucun effort de la part des développeurs. Finalement, en 2015 je me suis lassé, et j'ai passé la main à Roger Burrows, qui à ce jour est toujours le responsable d'EmuTOS. Roger a fait un travail exemplaire, notamment en fiabilisant le driver FAT16 d'EmuTOS pour n'importe quelle taille de partition jusqu'à 2 Go. Il a également écrit un incroyable décompilateur de ressources GEM (erd) pour faciliter leur intégration dans EmuTOS. Et il a aussi réécrit le driver IDE pour qu'il soit plus fiable. Plus récemment, il a amélioré le bureau d'EmuTOS pour qu'il dispose des mêmes fonctions que celui du TOS 2/3. Vraiment, je tire mon chapeau à Roger, pour son travail, ses compétences, sa gentillesse et sa modestie. Et l'histoire continue, car de nouveaux développeurs continuent à se joindre au projet.

Ceci étant dit, je n'élude pas la question ! Qu'est-ce qu'EmuTOS peut faire de plus que le TOS d'Atari ? Avant tout, EmuTOS est un projet libre. Cela signifie que n'importe qui peut l'utiliser, l'étudier, le modifier, et le redistribuer à sa guise, dans le respect de sa licence GPL. Donc si on veut changer quelque chose, il suffit de récupérer les sources, de faire la modif, et de recompiler. Ou de demander à quelqu'un de le faire. Au niveau des fonctionnalités, ce qui est le plus appréciable c'est son support intégré pour les disques durs ACSI/SCSI/IDE, et même des cartes SD sur le FireBee. Pas besoin de driver supplémentaire. De plus, il reconnait les tables de partitions Atari et PC. Donc on peut par exemple formater une carte CompactFlash sur PC, et l'utiliser sur Atari avec EmuTOS. C'est pratique pour échanger des données. Seule limite : EmuTOS supporte uniquement les partitions FAT16. Il ne supporte pas la FAT32 (mais ça marche si on ajoute FreeMiNT par dessus). EmuTOS supporte aussi tout type de CPU, du 68000 au 68060 et même le ColdFire V4e. Donc il est idéal pour tester des cartes accélératrices. Il supporte tous les modèles d'Atari : ST/TT/Falcon. Il détecte aussi les extensions de mémoire et les exploite automatiquement. Bref, EmuTOS peut potentiellement utiliser toutes les extensions matérielles. Si le support n'existe pas déjà dans son BIOS, on peut facilement ajouter un nouveau driver. Au niveau pratique, EmuTOS est fourni sous plusieurs formes : ROM, PRG, disquette, cartouche... Et en 12 langues différentes ! Donc on peut facilement le tester, que ce soit sur un émulateur ou du vrai hardware. Je l'ai dit plus haut, EmuTOS fonctionne déjà sur Amiga, et permet de lancer des logiciels Atari. Il pourrait en être de même avec n'importe quelle machine 68000 ou ColdFire qui a suffisamment de RAM, pour peu que quelqu'un écrive les drivers. Donc vous l'aurez compris, EmuTOS est un véritable couteau suisse qui permet d'obtenir un système compatible TOS dans n'importe quelle situation.

Un dernier mot sur la compatibilité. EmuTOS est très compatible avec le TOS d'Atari. C'est le cas sur ST et TT. Le support du Falcon n'est pas encore complet, mais ça progresse. Toutefois, EmuTOS n'est compatible qu'avec les programmes propres qui respectent le système d'exploitation. Or à l'époque du ST, tous les programmes n'étaient pas propres, loin de là. Certains programmes écrasaient des zones de mémoire en supposant qu'elles étaient inutilisées. D'autres exploitaient des comportements du système qui n'étaient ni voulus, ni documentés. D'autres encore étaient tout simplement buggés. La politique d'EmuTOS est claire : aucun effort ne sera fait pour ces programmes. Lorsque l'équipe en découvre, ils sont simplement consignés dans le fichier doc/incompatible.txt. De toute façon, de tels programmes ne supportent généralement pas le passage au TOS 2.06, par exemple. Donc ça ne marche pas mieux avec EmuTOS, qui est encore plus différent en interne. Donc en pratique, je ne vous recommande pas de remplacer la ROM de votre ST/STe par EmuTOS. Si votre machine vous donne satisfaction, gardez votre ROM d'origine. Tout changement de ROM implique quelques problèmes de compatibilité, surtout avec certains vieux jeux. En revanche, gardez à l'esprit qu'EmuTOS existe : il pourra parfois vous rendre service. Souvenez-vous, il est fourni sous plusieurs formes, notamment comme PRG facile à utiliser sur n'importe quel Atari. EmuTOS est aussi un très bon choix pour les émulateurs. Par exemple avec Hatari, il supporte n'importe quelle combinaison de matériels (CPU, machine, mémoire...). Et pour une configuration avancée de type ARAnyM/FreeMiNT, EmuTOS est tout simplement le meilleur choix, car tous ces projets coopèrent ensemble.

-as-tu d’autres projets pour notre marque favorite?

Des projets sur l'Atari lui-même, non, pas vraiment. J'ai passé le relais sur EmuTOS, et GCC est entre de bonnes mains avec l'équipe FreeMiNT. Par ailleurs, je suis admiratif de voir tout ce qui continue à sortir sur Atari au fil des années. Les extensions matérielles modernes, telles que le HxC Floppy Emulator (émulateur de disquettes) et l'UltraSatan (émulateur de disque dur) permettent de simuler des disques Atari à partir de cartes SD. On aurait rêvé de tout ça à notre époque. Ces projets exploitent la technologie moderne au service des anciennes machines. Il y a aussi Exxos et son équipe qui ont bien avancé sur leur projet de remake de carte mère STf. Franchement, c'est génial. Côté logiciel, en ce moment je suis très impressionné par le framework Atari Game Tools développé par DML. Il permet de créer facilement des prototypes de jeux en exploitant au maximum le STe. Et en plus il a utilisé mes cross-tools! C'est exactement ce que j'aurais rêvé de faire quand j'ai commencé à m'intéresser à GCC. Finalement, je suis parti sur d'autres voies en contribuant à FreeMiNT et à EmuTOS. On ne peut pas tout faire. Mais un jour ou l'autre, j'aimerais bien produire des démos. J'ai quelques notions de base dans ce domaine, mais je n'ai jamais vraiment pratiqué. En fait, je m'intéresse plus aux outils qu'aux produits finis.

Mais mon plus grand projet, c'est de partager tout ce que j'ai appris sur ma chaîne Vretrocomputing. Après tout ce temps passé à travailler sur l'Atari ST, j'ai envie de transmettre ce savoir. Je ne sais pas tout, loin de là ! Mais à force de travailler sur les projets, avec différentes équipes, j'ai acquis une bonne vision d'ensemble. Et maintenant, j'ai envie d'expliquer tout ça, avec mes mots. Aujourd'hui, YouTube est la plate-forme idéale pour ça. Ca peut paraître incroyable, mais pendant des années je suis passé à côté de YouTube. Bien sûr, je tombais occasionnellement sur des vidéos populaires ou humoristiques, mais ça s'arrêtait là. Puis des amis m'ont dit qu'il existait des chaînes de grande qualité, animées par des passionnés. Alors j'ai creusé un peu, et je suis tombé sur des pépites. L'une des chaînes qui m'a le plus marqué, c'est ScienceEtonnante. David y expose des sujets très compliqués, mais avec une pédagogie hors pair. Non seulement ce type-là est un génie, mais en plus il sait expliquer les choses de manière simple et progressive pour que tout le monde comprenne. Et en plus, en français. Dans un autre style, Defakator fait lui aussi preuve d'une grande pédagogie. Et voici une autre chaîne qui m'a complètement bluffé : GameHut (en anglais), et surtout sa série Coding Secrets, qui depuis lors est devenue une chaîne à part entière. Jon (le programmeur de Leander, entre autres) y explique les astuces de demomaker qu'il avait utilisées quand il travaillait sur Mega Drive. Et il n'hésite pas à montrer des routines en assembleur 68000 pour illustrer ses propos. Ca passionne le public ! Clairement, quand découvert tout ça, je me suis dit : c'est ce que je veux faire. Moi aussi, j'ai des choses à montrer, et à expliquer. Sur Atari ST, bien sûr, mais pas seulement. Je n'ai pas envie de me limiter.

-tu es un touche-àtout d’après tes vidéos youtube, que ce soit l’installation de freemint sur aranym ou la réparation d’un réveil , quelle est la video la plus difficile à réaliser ? Des anecdotes ? Peut t-on connaître les prochains sujets de tes vidéos ? Quel a été la vidéo la plus compliquée a réaliser ?

En effet, il y a un peu de tout sur Vretrocomputing, c'est le principe. Bien sûr il y a beaucoup de sujets sur l'Atari ST, puisque c'est la plate-forme que je connais le mieux. Mais je parle parfois d'autres machines, et je n'hésite pas à faire des hors-sujet quand ça me chante. L'important, c'est avant tout de me faire plaisir, en parlant de ce qui m'intéresse. Et les abonnés me connaissent : ils savent que quand je publie quelque chose qu'ils ne connaissent pas, il y a de grandes chances que ça les intéresse aussi. Pour revenir à l'Atari ST, je me suis aperçu qu'il y a plusieurs communautés assez différentes. D'un côté il y a ceux qui aiment les émulateurs, et de l'autre ceux qui ne jurent que par le vrai hardware. Ensuite il y a ceux sont passionnés par le ST, et d'autres par le Falcon et les cartes accélératrices. Enfin il y a ceux qui utilisent leur Atari pour jouer, et d'autres pour les utilitaires. Et par ailleurs, il y a la communauté FreeMiNT qui est un peu à part. Il y a aussi la barrière de la langue : certaines personnes participent aux forums français, mais pas aux forums internationaux parce qu'ils sont en anglais. De mon côté, j'ai la chance de connaître un peu tout ça. Donc j'ai décidé de parler de tous ces sujets. Pas forcément en profondeur, ce n'est pas le but. Mais pour que les différentes communautés découvrent autre chose que ce qu'elles connaissent déjà. L'exemple le plus criant, c'est justement la vidéo "FreeMiNT sur ARAnyM". Je suis sûr que beaucoup d'ataristes n'avaient jamais rien vu de tel. Et pourtant, comme je le montre, c'est à la portée de tout le monde en quelques clics. En fait, c'est ce genre de vidéos que j'avais envie de montrer dès le début. Mais certains nouveaux venus n'auraient pas compris si j'avais commencé par ce type de configuration avancée. C'est pour ça que j'ai commencé par parler de sujets plus basiques, comme les disquettes, les manettes... Pour pouvoir glisser progressivement sur des solutions plus novatrices, comme le Gotek par exemple (ça viendra). C'est difficile de vanter les mérites d'un CosmosEx pour quelqu'un qui ne connait pas l'Atari ST. Autre thème qui me tient particulièrement à coeur : la programmation en assembleur. Je n'ai nullement l'intention de faire un cours complet d'assembleur 68000. D'autres ont déjà fait ça très bien. En revanche, je compte montrer quelques routines pratiques pour faire des choses intéressantes, dans des contextes bien particuliers. C'était notamment le cas dans ma vidéo "Afficher une image". Je sais très bien que ceux qui ne sont pas familiers avec la programmation ne comprendront pas toutes les subtilités. Mais s'ils sont attentifs, ils pourront comprendre le principe général. C'est ce qui m'intéresse. Et peut-être que ça pourra produire un déclic chez ceux butaient sur un point qu'ils n'avaient jamais compris. En expliquant tout pas à pas, lentement mais sûrement, on finit par arriver à faire comprendre des concepts pas forcément évidents. Et pas toujours bien documentés.

Concernant la production des vidéos : ça me prend un temps fou ! Pour l'instant, je filme avec mon smartphone. Mais je songe à m'équiper mieux que ça. J'ai changé de micro l'an dernier. Avant, je passais un temps fou a nettoyer le son avec Audacity. Maintenant, j'ai un son de qualité, sans trop d'efforts. Après le son, j'améliorerai l'image. Mais une chose après l'autre. Au début, j'utilisais un logiciel de montage qui était vraiment peu performant. Donc en pratique, je me contentais de mettre des séquences bout à bout, c'était vraiment du bricolage. Maintenant, je suis beaucoup plus à l'aise, j'arrive à faire à peu près ce que je veux en termes de montage. Je fais très attention à conserver un bon rythme. C'était un conseil qu'avait donné le Joueur de Grenier à propos de ses vidéos, ça m'a paru important. Et justement, j'ai mis longtemps à trouver le bon rythme. Dans mes premières vidéos tuto, j'ai choisi de parler lentement, pour que tout le monde puisse suivre facilement. Mais du coup, c'était un peu mou. Alors j'ai fini par accélérer un peu. Je suis assez content des dernières vidéos, je pense que j'ai trouvé un bon rythme. Mais en réalité, ce rythme est totalement artificiel. Je recale toutes les phrases au dixième de seconde près, ça me prend énormément de temps. Même si maintenant, j'y arrive assez facilement. En revanche, là où j'ai toujours énormément de mal, c'est pour dire les textes face caméra. Il m'arrive régulièrement de faire plus de 100 prises pour une seule phrase ! C'est vraiment abusé, je me demande comment font les YouTubers professionnels qui font des vidéos au kilomètre. Heureusement, pour la voix off, c'est plus facile. Même si j'y passe quand même beaucoup de temps.

Mais reprenons depuis le début. Pour chaque vidéo, je commence par écrire le scénario, ça me prend déjà du temps. Ensuite, je fais un enregistrement audio en lisant le texte, sans effort particulier. Ca me permet d'avoir une idée du rythme global. Puis pour chaque partie du texte, j'imagine la meilleure illustration possible. Ca peut être une copie d'écran, une image, ou le plus souvent un schéma fait à partir de rien. J'utilise généralement Steem pour les copies d'écran Atari. Ensuite, il faut l'agrémenter avec des flèches, parfois, des animations... Ca aussi, ça me prend beaucoup de temps. Mais si ça peut aider à la compréhension, ça vaut le coup. Puis j'enregistre la version définitive de la voix off, phrase par phrase. C'est souvent l'occasion de faire les dernières corrections du texte, pour que ça sonne mieux. Et enfin, dernière étape, je tourne les petites séquences d'introduction et de conclusion. Ce ne serait pas strictement nécessaire, mais je trouve que ça rend les vidéos plus vivantes. Dans les vidéos pratiques, je dois aussi filmer les manipulations. Mais comme je suis mal équipé, et peu expérimenté, c'est souvent compliqué. Donc je fais du mieux que je peux, même si c'est parfois un peu limite question qualité. Mais à partir du moment où on voit l'essentiel, je me dis que ça fait quand même l'affaire. Mais clairement, j'ai de la marge pour m'améliorer dans ce domaine. Autre tâche ultra-chronophage : les sous-titres ! Je m'astreins à fournir des sous-titres de qualité, notamment pour les abonnés anglophones. Entre la transcription, la traduction, et surtout le recalage des phrases, c'est vraiment très long et très pénible. Comme tout ça me prend un temps incalculable, je ne peux pas sortir autant de vidéos que je le voudrais. Donc de temps en temps, je me permets de faire des vidéos "à l'arrache", comme par exemple l'installation des cross-tools. Ce sont des vidéos partiellement improvisées : j'ai une trame générale, mais pas de texte précis. Je fais quelques quelques prises, en faisant attention à ne pas trop bafouiller, et en général ça suffit. Ensuite, ça me demande très peu de montage. Et vu l'aspect improvisé, je ne fournis pas de sous-titres. Ca me permet de varier les formats, pour ne pas toujours rester enfermé dans la rigidité des tutos. Et comme je l'ai dit, je ne m'interdis aucun sujet, pour peu que ça ait un rapport avec l'informatique ou l'électronique. Concernant le réveil, cette panne était vraiment un souci car il me réveillait le week-end ! Il fallait vraiment faire quelque chose. J'en ai profité pour filmer l'opération. Et un exercice de soudure, ça peut aussi servir dans un ordinateur. On l'a vu ensuite avec le remplacement de la ROM de mon STe par une EEPROM.

Les vidéos les plus difficiles à réaliser, je dirais que ce sont les dernières grosses vidéos, sur lesquelles il y a eu beaucoup de montage. Notamment la vidéo sur les émulateurs, à laquelle j'ai apporté beaucoup de soin. Je l'ai voulue la plus générale possible, pour toucher un large public. Idem pour la vidéo de Steem, que j'ai longuement peaufinée, entre le scénario que j'ai souhaité le plus complet possible, et tous le exemples que j'ai dû chercher et capturer. Les tutos assembleur me demandent aussi beaucoup de travail, entre les captures d'écran, les surlignages et les illustrations. Mais franchement, même si ça me prend du temps, je suis content de ces tutos de programmation. C'est exactement le type de vidéos que j'aimerais regarder. Pour l'instant, ça reste basique. Mais ça va rapidement évoluer sur des sujets plus intéressants, comme les animations, l'accès direct au hardware, la gestion du son...

Quelques anecdotes ? Eh bien, je fais particulièrement attention à ce qui est dans le cadre. Tout semble en ordre, mais c'est parce qu'à chaque fois je pousse le bazar sur les côtés ! Et même dans mon dos. Quand je me filme, je fixe mon smartphone... sur mon séchoir à linge ! Ca fait longtemps que je compte investir dans un trépied, mais je ne suis pas persuadé que ce soit plus pratique. Mais j'y viendrai sûrement. Et pour tout dire, je n'utilise quasiment jamais mon STe. Ni mon PC portable, d'ailleurs. Je ne les démarre que pour faire figuration sur les vidéos. En pratique, je préfère mon PC de bureau et les émulateurs.

Quant aux sujets de prochaines vidéos, j'ai une liste longue comme bras ! En vrac :
- La suite des tutos assembleur. Petit à petit, on va faire des programmes qui ressemblent à des démos. Ca tombe bien, car même si je connais quelques techniques, je n'ai jamais fait de démo moi-même. C'est l'occasion d'avancer tous ensemble sur ce sujet passionnant.
- Quelques vidéos sur le hardware (même si je n'en ai pas beaucoup, et si je préfère les émulateurs). Je compte parler du Gotek et de l'UltraSatan, qui sont des périphériques remarquables. Et vous le savez, j'adore mélanger les machines et les périphériques.
- Continuer à présenter les émulateurs en détail, notamment Steem SSE, Hatari et ARAnyM.
- Parler de tout ce qui touche à EmuTOS : son utilisation, ses sources, sa compilation. Idem avec FreeMiNT et fVDI.
- Traiter les environnements de développement et les outils de compilation.
- Faire de la musique ! Entre le soundchip, les modules et le MIDI, il y a de quoi faire.
- Montrer le FireBee, qui reste une machine remarquable mais mal connue.
- Montrer la carte d'évaluation ColdFire et EmuTOS qui fonctionne dans un terminal. Plus exotique que ça, y a pas.
- Montrer quelques logiciels Atari qui m'avaient marqué à l'époque, et qui restent dignes d'intérêt.
- Ressortir des vieux trucs que j'avais bricolés il y a bien longtemps : que ce soit du matériel ou des bouts de programmes. Il y a des idées à creuser, des trucs qu'on n'a jamais vus sur ST.
- Faire quelques bidouilles sur d'autres machines, histoire de ne pas se limiter à l'Atari ST.
- Et bien sûr, plein de surprises que je garde en réserve ! Car j'ai bien l'intention de continuer à étonner mes abonnés.

Bref, j'ai des idées plein la tête. Il me restera à trouver du temps pour tout ça. Mais je suis ultra-motivé. Donc d'une manière ou d'une autre, ça se fera petit à petit.

-Je t’ai vu dans une vidéo ou tu  présentais l’Atari st free operating système en 2018 à foss north en suède, qu’est-ce donc cette convention ? Est ce que ton sujet sur l’atari st a suscité des réactions chez certains dans le public ?

Ah, foss-north 2018 (*) ! C'est une histoire assez incroyable. En 2017, j'ai créé un PPA sur Launchpad (**). Il s'agit de la plate-forme collaborative d'Ubuntu. Les PPA sont des dépôts personnels pour héberger des paquets Ubuntu. Il suffit d'uploader un paquet source, puis le PPA se charge de construire les paquets binaires, et de les héberger. C'est très pratique. Je m'en suis servi pour distribuer les m68k-atari-mint cross-tools pour Ubuntu. Auparavant, j'avais mon propre dépôt, il fallait que je construise les paquets moi-même et que je les héberge. Avec le système des PPA, c'est le serveur Launchpad qui s'occupe de tout. Bref, tout ça pour dire qu'en 2017 l'adresse des cross-tools pour Ubuntu a changé. En cherchant l'ancienne adresse sur le web, je suis tombé sur le projet TOSEMU d'un certain Johan Thelin sur GitHub. Je lui ai donc écrit pour lui suggérer de faire pointer son projet sur la nouvelle adresse. Il m'a remercié en me disant qu'il venait d'effectuer la mise à jour. Et que par ailleurs, il organisait annuellement les conférences foss-north à Göteborg en Suède. Il m'a dit qu'il serait heureux de m'y voir pour parler de mon travail sur les cross-tools. L'édition 2017 étant passée, ça pourrait se faire pour l'année suivante. N'étant pas un grand voyageur, ni un grand orateur, j'ai simplement répondu "peut-être". Mais ça m'a boosté, et l'idée a fait son chemin. J'ai acheté un ordinateur portable (celui qu'on voit dans les vidéos). Puis j'ai ouvert ma chaîne Vretrocomputing. Finalement, en 2018, Johan m'a relancé pour participer à foss-north. Et j'ai accepté. Ca a bousculé mes habitudes, c'est sûr. J'avais carte blanche pour le contenu. J'ai donc décidé de voir large en choisissant le sujet "Atari ST Free Operating Systems". L'idée était de présenter mes projets, bien sûr : cross-tools, EmuTOS, FreeMiNT, FireBee... Mais aussi de faire un état des lieux des autres projets matériels et logiciels sur les plates-formes Atari. Car mine de rien, beaucoup de projets ont fleuri au fil des années, pas forcément connus de tous. J'ai souhaité inclure un maximum de projets relatifs à EmuTOS/FreeMiNT. Et finalement, j'ai obtenu un diaporama de 157 pages à présenter en 45 minutes ! La taille n'était pas un problème, car j'avais l'intention de passer rapidement sur chaque sujet. Les personnes intéressées pouvant revoir la présentation en ligne, et approfondir les sujets qui les intéressent avec les liens fournis. En pratique, j'ai passé tout mon temps a créer le diaporama, et j'ai complètement négligé l'entrainement à l'oral en anglais ! Je me revois encore en train répéter ma présentation à l'aéroport et à l'hôtel. Finalement, ça s'est super bien passé, devant une cinquantaine de personnes. J'ai eu de très bons retours, et tout le monde a été adorable. Un souvenir inoubliable. J'ai adoré la Suède.

Le public était composé de nerds, donc ils connaissaient forcément l'Atari ST, au moins de nom. Mais je pense que quasiment personne ne connaissait FreeMiNT. Donc quand on se représente l'Atari ST comme un petit bureau vert avec un système monotâche, ça surprend de le voir faire fonctionner en multitâche les mêmes logiciels que sous Linux (par exemple le shell bash). Combiné à des émulateurs améliorés (ARAnyM) ou des machines accélérées (Falcon+CT60, FireBee), ça donne un résultat tout à fait utilisable. EmuTOS et FreeMiNT pour Amiga ont aussi fait leur petit effet, surtout combinés à une carte Vampire. Voir une telle configuration capable d'exécuter des logiciels Atari non modifiés est assez étonnant. Les projets hardware (Suska, FireBee, MiST, MiSTer...) ont aussi étonné. Bref, le public a vu que non seulement les communautés Atari étaient encore bien vivantes, mais qu'en plus les logiciels récents conçus pour Linux leur étaient accessibles. Malgré les années, les successeurs de l'Atari ST sont toujours dans la course.

Encore quelques mots sur foss-north. Johan Thelin organise ces conférences annuellement, en anglais. En 2018 il y avait 2 salles en parallèle, sur 2 jours, la principale étant un grand amphithéâtre. C'est donc un événement important. Il y avait plus de 25 intervenants, qui ont présenté des sujets très variés mais toujours intéressants en rapport avec l'informatique et les logiciels libres. Côté public, il y avait aussi beaucoup de monde. Certaines personnes étaient venues de loin, y compris d'autres pays européens. J'y ai même rencontré des ataristes avec qui je correspondais déjà, comme Johan Klockars (fVDI) et Peter Persson (***). C'était inespéré. Vraiment, Johan Thelin organise ces conférences d'une main de maître. Les présentations sont enregistrées, et disponibles sur YouTube (****), n'hésitez pas à y jeter un coup d'oeil. Voire même à aller sur place à Göteborg si vous en avez l'opportunité !

(*) https://foss-north.se/2018/speakers-and-talks.html#vriviere
(**) https://launchpad.net/~vriviere/+archive/ubuntu/ppa
(***) https://www.facebook.com/Vretrocomputing/photos/a.1809820502372302/1809844999036519/
(****) https://www.youtube.com/c/fossnorth

-Merci beaucoup pour ses longues réponses à tu une dernière chose à ajouter ? (si il me dit non là je tomberai sur le c..)

D'abord merci à toi Emmanuel pour cette interview ! Et en effet, je me suis lâché. Mais c'est parce que tu as posé les bonnes questions.

Alors pour finir, je souhaite rendre hommage à ceux qui ont compté pour moi dans mon parcours sur Atari. Pour n'en citer que quelques-uns :
- Mes amis du lycée, les KCBM, qui m'ont fait découvrir l'Atari ST et toute la richesse de son environnement.
- Les membres du 3614 RTEL2 avec qui j'ai pu échanger, à une époque où les communications n'étaient pas ce qu'elles sont aujourd'hui.
- Les auteurs des émulateurs Atari, qui nous simplifient tellement la vie au quotidien.
- Olivier Landemarre, qui m'a aiguillé vers la MiNT Mailing List et qui m'a envoyé sa carte d'évaluation ColdFire. Par deux fois, il m'a ouvert les portes d'un nouveau monde.
- Les membres de la MiNT Mailing List, avec qui nous avons fait progresser GCC et FreeMiNT.
- Les membres du projet ACP, grâce à qui j'ai appris énormément de choses lors de la mise au point du FireBee.
- Les membres des la liste EmuTOS, et tout particulièrement Roger Burrows qui a repris le projet après moi en 2015.
- Les Removers et Brume, qui m'ont permis de faire connaissance avec les ataristes parisiens (mais pas que).
- Johan Thelin, pour m'avoir permis de m'exprimer à foss-north 2018, et m'avoir fait découvrir la Suède.
- Les rédacteurs en chef qui m'ont permis d'écrire des articles sur l'Atari ST dans leurs magazines.
- Et surtout, tous les abonnés à ma chaîne Vretrocomputing qui me soutiennent et qui m'encouragent.

Il y en aurait beaucoup d'autres, mais je vais en rester là pour aujourd'hui.

Alors à très bientôt pour de nouvelles aventures ! Je vous réserve encore plein de surprises sur Vretrocomputing.

Vincent Rivière