Le premier confinement a été pour moi et pour beaucoup d'autres l'occasion de prendre un peu de recul et de voir sous un jour nouveau mon propre parcours informatique, commencé adolescent par la découverte du basic et de l'assembleur dans les années 80, puis du C et de Caml à l'X.

J'ai ainsi réalisé à quel point, en 40 ans, les systèmes avaient gagné en complexité et en opacité alors même que le gain pour l'utilisateur n'est pas toujours évident : démarrage de plusieurs secondes, mises à jour interminables, obsolescence assez rapide des machines, interface utilisateur pas spécialement réactive.

Même l'opensource n'y échappe pas : un serveur linux "neuf" contient d'emblée environ 200 processus, et donc autant de surface d'attaque, alors qu'on n'a encore rien fait avec.

Pour le développeur, c'est aussi une régression : l'enfer des dépendances, l'empilement des boîtes noires, l'instabilité des frameworks dans le temps, le labyrinthe des forums de "support", souvent périmés et contradictoires.

Cette complexité et cette opacité sont des obstacles majeurs dès lors qu'on aborde les sujets de cybersécurité, de souveraineté, et de sobriété énergétique ou matérielle. La vérité oblige à reconnaître que les systèmes sont hors de contrôle.

Si on veut adresser correctement ces trois sujets, on doit retrouver la compréhension des calculs réellement effectués par la machine. Le principe du "Less is more" a été appliqué avec succès il y a 35 ans dans le hardware pour passer du Cisc au Risc. Il est temps de l'appliquer au software.

La solution que je propose a déjà une histoire. En 1995, à la sortie de l'X, j'ai eu l'occasion de concevoir une machine virtuelle et un langage de programmation associé (de type langage fonctionnel) pour créer des mondes virtuels (Scol). Cette machine virtuelle avait pour but d'abstraire et de sécuriser l'exécution du code sur le client.

En 2006, une version très améliorée Metal a été intégrée dans le Nabaztag : la machine virtuelle y sert également d'OS et de Bios.

En 2014, une version encore améliorée Metal V2 est utilisée comme coeur de la version téléchargeable de 3D Slash.

En 2020, je suis reparti de zéro avec cette fois l'objectif de diffuser cette technologie, sous le nom "Minimacy" :

• opensource puisque la promesse est de maîtriser tout le fonctionnement de la machine
• une combinaison unique Machine Virtuelle + langage de haut-niveau
• un Bios et un ensemble réduit de librairies essentielles, écrits dans ce langage
• une machine virtuelle qui fonctionne sur Windows, Linux, RaspberryPi, MacOs, iOS, Android et bientôt directement sur le hardware.

En appliquant le principe « Less is more », Minimacy ramène la complexité des systèmes informatiques à la mesure d’un cerveau humain, libère la créativité et ouvre la porte vers des solutions inédites aux problèmes de sécurité, de sobriété et de souveraineté. Ce faisant Minimacy fait de l’informatique une chose humaine.

Pour participer à cette aventure, commencez ici : https://minimacy.net/

Fin 2005 je suis contacté par une petite société qui fournit du matériel d'initation technique aux écoles. Elle est a la recherche d'un connaisseur du processeur motorola 6809, et a entendu parler de mon émulateur To7 qui s'appuie lui aussi sur le 6809.

Il est alors décidé de réaliser une carte électronique à base de 6809, avec un Bios en rom, une liaison série vers un PC, et sur ce PC une application qui sert d'IDE

L'IDE permet la saisie du code source asm 6809, la compilation vers du langage machine, un debugger avec points d'arrêt et exécution pas-à-pas. L'IDE intègre aussi un émulateur de la carte (basé sur le code source de mon émulateur To7), ainsi qu'une liaison série vers la carte pour transférer le programme en langage machine et en contrôler l'exécution.

Je pense que la plupart des passionnés d'informatique ont un jour rêvé de construire leur propre ordinateur à partir de zéro : c'est précisemment ce qui m'est proposé !!!

Le plus difficile est bien sûr de réaliser la Rom de l'ordinateur. Celle-ci doit être capable de :

• initialiser le système, les interruptions, la liaison série avec le PC
• proposer des fonctions simples : affichage hexadécimal à 6 chiffres, lecture du clavier
• communiquer avec le PC pour recevoir des programmes et les exécuter
• fournir des fonctionnalités de debug : pause/relance, exécution pas-à-pas, dump de la mémoire, affichage des valeurs des registres.

C'est l'IDE que je développe en premier avec son simulateur intégré, car c'est avec lui que je vais écrire la ROM. Pour la tester sur la vraie carte j'utilise un simulateur de ROM, ELNEC SIMEPROM-01B, qui ressemble à ceci.

Libsic Studio est une création très personnelle qui regroupe plusieurs thématiques qui me sont chères.

Il s'agit d'un travail sur l'énergie créatrice, cette force vitale qui est le propre de l’Homme, qui nous révèle aux autres et à nous-mêmes et nous permet de nous accomplir.

Ensemble avec Libsic Studio nous pouvons poser la première pierre d’un monde numérique plus humain, basé sur la créativité, la curiosité et la bienveillance.

Libsic Studio se présente sous la forme d’un double numérique de la Terre, social et programmable. Il repose sur une vaste image satellite de notre planète, décomposée en petites cellules carrées (Cells en anglais) d’environ 1 mètre de côté.

Vous pouvez explorer ou redéfinir l’apparence et le comportement de chacune de ces cellules, que ce soit avec les briques élémentaires disponibles ou à l’aide de Libsic, un langage de programmation dérivé du Basic.

LIST, RUN, EDIT, PRINT, FOR ... NEXT, LOAD, POKE, ...!

Chaque cellule peut être vue comme l'écran de 64x64 pixels d'un petit ordinateur. Cet ordinateur fait tourner un programme que vous pouvez modifier à votre guise. Ce programme peut réagir à différents événements, par exemple lorsque vous cliquez dessus ou lorsque votre avatar le traverse.

En guise d'exemple, le programme LIBSIC suivant affiche un quadrillage de lignes rouges:

Dans ce monde vous n’êtes pas seuls, vous partagez votre énergie créatrice avec les autres utilisateurs. Inspirés du slow web, les mécanismes sociaux de Libsic Studio n’encouragent ni l’affrontement ni les provocations, mais redonnent de la valeur aux contributions des individus.

Il s'agit donc aussi d'un travail sur la Liberté : Liberté de création, Liberté d'expression.

Ce projet réunit plusieurs complications techniques :

J'espère que vous prendrez beaucoup de plaisir à découvrir LibertyCells et à vous l'approprier !

On a tous déjà remarqué l'aspect très particulier du point lumineux que forme un rayon laser projeté sur un mur. Il y a une sorte de grain qu'on ne trouve nulle part ailleurs. Et pourtant cette technologie est peu exploitée : cela se limite aux pointeurs pour conférencier, et aux effets visuel des nightclubs.

Il y a évidemment des raisons pour cela, la principale étant qu'on ne sait pas dévier un rayon laser autrement que par un miroir. Dans un écran cathodique vectoriel (oscilloscopes, console Vectrex) on utilise un champ électrique pour dévier un rayon d'électrons, et on sait modifier ce champ de manière instantanée. Avec un rayon laser, on utilise deux miroirs pivotants placés dans des galvanomètres. Le mouvement des miroirs est donc relativement lent et gêné par des questions d'inertie. De fait, on ne peut transmettre que quelques milliers de positions par seconde, et encore à condition que les positions successives restent proches.

Malgré ces contraintes, et en utilisant une carte Lumax, j'ai pu développer un Asteroid laser pour la Cité des Sciences. La qualité de la vidéo ci-après est assez mauvaise, car l'effet stroboscopique combiné de la caméra et du projecteur laser fait qu'il est difficile d'avoir une image stable.

Cet été, un de mes neveux avait un livre rempli de grilles de Takuzu (autrement connu sous le nom de Binairo), qui est une variante du sudoku avec uniquement des 0 et des 1 et des règles un peu différentes. Il doit y avoir exactement cinq 0 et cinq 1 sur chaque ligne et chaque colonne, et on ne peut avoir trois chiffres identiques côte à côte.

Comme récréation estivale, je me suis dit qu'il serait amusant de faire un programme qui résoud automatiquement les grilles contenues dans le livre. Le programme utilise la caméra pour analyser la grille, puis il calcule la solution, et remplit la grille directement sur l'image de la caméra, en temps réel!

Ceci donne un aperçu de ce qu'on pourra obtenir avec un casque de réalité augmentée comme le futur Hololens de Microsoft.

L'impression 3D change radicalement notre rapport à la matière. Bien plus qu'une simple révolution de certains procédés industriels, elle donne enfin à chaque individu un pouvoir sur la matière : pensez à un objet et vous l'obtenez. Toutefois pour que cette révolution soit possible, il fallait un outil de conception 3D utilisable par tous, ce qui n'était pas le cas. Essayez d'ouvrir Solidworks ou même Blender et vous comprendrez la difficulté.

Par ailleurs, chacun d'entre nous n'est pas un créatif accompli. Les formules habituelles du style "vous n'êtes limité que par votre imagination" nous rappellent justement que notre imagination est très limitée. Alors que l'essentiel des modèles 3D disponibles sur internet sont des bibelots, conçus par d'autres et sans grand intérêt, les gens normaux ont des besoins plus simples, notamment dans le domaine de la réparation ou du remplacement. L'outil grand public, pour être utile, doit donc pouvoir créer des formes aux dimensions très précises car ces formes doivent se combiner avec des objets existants.

En observant les enfants jouer à Minecraft, j'ai pensé qu'il y avait là une piste à creuser : une primitive très simple -ajouter ou retirer un cube- qui n'est pas aussi fastidieuse qu'il y paraît, quand on voit ce que les enfants réalisent en une vingtaine de minutes. Toutefois le modèle de Minecraft est trop simple, il ne permet pas de faire des pièces suffisamment précises. Une imprimante 3D grand-public peut typiquement imprimer des objets de 10x10x10 cm, avec une précision de 0.1 mm, ce qui représente 1 milliard de cubes!

En introduisant plusieurs tailles de cube avec un agencement particulier entre les cubes de différentes tailles, on obtient un outil intuitif, qui permet de réaliser toutes sortes d'objets.

Le résultat de ce travail s'appelle "3D Slash"

Il s'agit :

• d'une application web avec backup et partages : www.3dslash.net
• d'une application téléchargeable, réalisée avec la technologie metal, ce qui la rend disponible pour Windows, MacOs, Linux, iOS et Android. Disponible aussi sur le site www.3dslash.net
• d'un format de fichiers "*.3dslash" qui permet l'encodage de vos objets sous une forme optimisée

Cette invention a obtenu la médaille d'or du Concours Lépine International Paris 2014.

Rendez-vous sur le site www.3dslash.net !

Après le succès rencontré par le Nabaztag, la société Violet développe un nouvelle version, plus puissante, avec la même équipe : Philippe Debadier pour l'électronique, et moi-même pour l'embarqué et le coeur du serveur.

Peu de choses le distinguent visuellement de son aîné : un nombril cache l'apparition d'un micro qui lui permet d'écouter et d'enregistrer du son. Il enferme aussi sous son nez un capteur RFID. Cependant, la puissance s'améliore avec un ARM à 6Mips, 128Ko de ROM pour le programme et 1Mo de RAM. Pour gagner en coût de fabrication, il n'y a pas de mémoire flash, et la carte wifi est de type SoftMac : contrairement au Nabaztag, le Nabaztag-tag doit donc implémenter dans son firmware l'intégralité du protocole wifi (connexion, encodage des trames, ...), la carte SoftMac traitant surtout la partie radio et le cryptage.

Le logiciel embarqué est écrit en C. Il gère les différents périphériques. Il gère également la carte wifi, via un driver écrit par un étudiant génial, Sébastien Bourdeauducq que j'ai découvert un peu par hasard sur le net dans les pages du projet opensource Prism54. Bien qu'il soit alors en maths spé, en train de préparer puis de passer les concours, il réalisa le driver parfait.

Une nouvelle fois, il a semblé naturel d'intégrer une machine virtuelle pour traiter le comportement fonctionnel de l'objet. D'abord tenté d'intégrer une VM java, il fallut partir sur une solution mieux maîtrisée en termes de délai, et j'intégrai donc en quelques semaines une version simplifiée de la VM Métal que j'avais développée début 2003.

Cette machine virtuelle utilise un langage de type "langage fonctionnel" statiquement typé, offrant une grande souplesse dans la création des calculs, et disposant d'un garbage collector. De fait, la couche réseau (arp, ip, udp, tcp, dns client, dhcp client et serveur, http client et serveur) est implémentée dans ce langage.

Au démarrage, le lapin possède un premier bytecode (appelé bytecode de boot), qui prend en charge la connexion au wifi. Une fois connecté, le lapin télécharge le bytecode nominal ; c'est ce bytecode qui détermine le fonctionnement du lapin. Ce fonctionnement est donc très libre, même si la société Violet ne l'a pas fait beaucoup évoluer par la suite. Le lapin est notamment capable de communiquer directement avec tout serveur, sans passer par le serveur "principal".

Le bytecode est généré par un compilateur, qui est lui-même intégré à un simulateur.

En 1996, alors que le développement du Deuxième Monde touche non sans mal à sa fin, la nécessité d'un "middleware" dédié aux mondes virtuels apparait de manière évidente pour pouvoir exploiter plus avant le filon. Nous lançons donc un projet de R&D en ce sens qui aboutira à la création de la technologie Scol, au sein de la filiale Cryonetworks.

La première présentation aura lieu début 1998, autour d'un univers baptisé Cryopolis, designé par Laurent Doubre.

La technologie comprend deux aspects très différents :

• une machine virtuelle dédiée à l'application d'applications réseau multimédia, reposant sur le langage Scol, et fonctionnant aussi bien côté serveur que côté client. Sous l'influence de mes stages au MIT et à l'Inria (voir plus bas), le langage Scol ressemble aux langages fonctionnels comme Id ou Caml, avec une syntaxe simplifiée à destination des développeurs traditionnels.
• une recherche autour des questions de distribution : chaque fonctionnalité est encapsulée dans un module qui regroupe à la fois un code serveur et un code client. Cette manière de découper l'application "verticalement" ouvre la voie à un outil d'intégration graphique (le SCS) dans lequel les modules de fonctionnalités sont connectés graphiquement par un utilisateur ignorant tout des questions pourtant délicates de distribution. Cette recherche aboutit au concept "user-flow", qui fera l'objet d'un papier au GT-RV99 de Laval.

Même la Fnac s'y est mis, en 2000, bien avant le buzz "second life" :

Cryopolis en 2000, une communauté avec 1.000 DAU, tous en liaison modem :

Cryonics, l'outil simplifié de création de monde virtuel. L'hébergement est local, sur le PC de l'utilisateur (qu'il ne faut donc pas éteindre); Scol, pionnier du P2P ?

Une présentation de Cryonetworks en 2000, qui est alors une société côtée de 180 personnes ; la vidéo montre les jeux online (Venise et Mankind) et Cryopolis :

Après la disparition du groupe Cryo, en 2002, j'ai récupéré les droits de la technologie Scol, et l'ai passée en opensource.

En 1995, la nouvelle société de Philippe Ulrich, Cryo Interactive, me demande de l'aider à réaliser un projet révolutionnaire, à l'intersection de deux sujets alors dans l'air du temps, la 3d et les réseaux. Il s'agit d'un des tous premiers mondes virtuels, le Deuxième Monde, qui reproduit un Paris virtuel dans lequel les utilisateurs se rencontrent au travers d'avatars.

J'interviendrai en tant que CTO et en réalisant moi-même deux des éléments de ce "jeu" : le moteur 3d et le serveur.

Le moteur 3d temps réel, à une époque où les cartes 3d n'existent pas encore, doit être capable de gérer des scènes étendues, contenant un nombre élevé de polygones, contrairement aux jeux de l'époque (cf. Descent ou Quake) qui gèrent un espace clos. Ecrit en assembleur, selon l'algorithme du scanline, il utilise une technique originale de gestion du mapping des textures : en effet, le mapping des textures nécessite théoriquement deux divisions par pixel, ce qui est trop coûteux en 1995 pour du temps réel. L'astuce consiste à passer en logarithme (via des tables de conversion) et à remplacer alors ces divisions par des soustractions.

Une première version sortira en 1997, suivi rapidement d'une V2.

Le serveur fonctionne sous Unix, et peut gérer quelques centaines de participants simultanés. En 1995, internet n'est pas encore un réseau grand public, et le jeu est alors initialement prévu pour fonctionner sur un réseau télématique dédié ; mais avant la fin du développement, les modems et les FAI se répandent, et le jeu utilisera finalement bien le réseau internet.

On peut revoir aujourd'hui les scènes 3D de l'époque grace à un prototype de monde virtuel s'appuyant sur la technologie Scol, et réalisé à la même époque.

Début 2014, j'ai remis un serveur en route, ce qui permet de se reconnecter au Deuxième Monde, avec un ordinateur Windows, Mac ou Linux, en s'appuyant sur VirtualBox. On procède comme ceci :

• télécharger et installer VirtualBox : https://www.virtualbox.org/wiki/Downloads
• télécharger le fichier "application virtuelle" 2M : http://dev.ambermind.com/2m/2M-virtualbox.ova
• lancer VirtualBox
• dans le menu Fichier, choisir "importer une application virtuelle", et sélectionner le fichier 2M-virtualbox.ova que l'on vient de télécharger
• démarrer la machine virtuelle "Windows 98 SE - 2eMonde" (windows 98 se lance)
• sur l'écran "saisie du mot de passe réseau", laisser vide et cliquer sur OK ou Annuler
• double-cliquer sur le "Raccourci 2monde.exe"
• il vous faut un compte pour vous connecter : envoyez-moi un mail à lui-meme@sylvain-huet.com, en me précisant le login que vous souhaitez
• je vous retourne le password asap

qques trucs :

• lorsqu'on utilise VirtualBox, on ne sait pas toujours comment sortir de la machine virtuelle : sur PC, c'est la touche Ctrl droite qui permet de reprendre la main, alors que sur Mac c'est la touche Cmd gauche
• pour quitter l'application, il vaut mieux quitter proprement windows 98. Menu Démarrer, choisir arrêter. L'écran se fige alors sur l'image "Fermeture de Windows". Il faut alors fermer la fenêtre Virtual Box, et choisir "éteindre la machine".

Le langage Metal développé en 2003 s'est avéré très utile dans mon activité, que ce soit indirectement comme aide au prototypage ou à la mise au point de technologies, ou comme partie intégrante de la technologie (cf. Nabaztag-tag). Toutefois, quelques limitations sont apparues, notamment par le choix du C++, qui limitait de manière importante la portabilité. En 2003, le PC windows était hégémonique à l'exception des serveurs Linux; en 2012, il faut nécessairement compter aussi avec les Mac, les iPhones, les iPads et Android.

J'ai donc entrepris de mettre à jour cette technologie, en conservant la compatibilité ascendante, et en redéveloppant complètement avec le langage C, qui est le seul point commun entre ces différentes plateformes.

La syntaxe s'est légèrement enrichie : la définition des constantes est plus souple. La construction "for ... do" s'est enrichie. On peut interrompre une fonction ou une boucle par un 'return' ou un 'break'.

Les autres nouveautés sont :

• compatibilité Windows, Linux 32 ou 64 bits, macOs, iOs, Android
• possibilité d'obtenir le bytecode d'un programme, et de le lancer sans le code source correspondant, simplification du packaging d'une application
• couche OpenGLES
• support multi-touch et accéléromètre
• support utf8 et Json
• support client mysql pour les versions Desktop

Le travail de packaging est encore en cours, mais on peut juger du multi-plateforme sur le cas de 3D Slash:

Pacman est une référence incontournable, l'archétype du jeu vidéo, même si je n'ai jamais vraiment aimé la version arcade ; je préfère un labyrinthe plus complexe, avec des parties un peu plus longues, un peu comme sur VCS2600.

En 1991 j'ai développé une version un peu aboutie sur Atari ST, en monochrome ; je l'ai ensuite déclinée sur plusieurs environnements, en conservant à chaque fois le gameplay et les labyrinthes. On pourra télécharger ci-dessous toutes les versions.

La première version, en 1991 sur Atari ST monochrome, en assembleur 68000:

Toujours sur ST et en assembleur 68000, en 1992, mais en couleur:

En 1992, version Powerboook intégrée en 'cheatmode' dans le Projet info, un mix d'assembleur 68000 et de langage C.

En 1993, version unix X11 en langage C:

En 2003, version en langage Métal:

En 2012, version unix en mode texte (librairie ncurses) en langage C:

Dernière en date, renommée Dad-Man, version iPad, Android, windows, mac, linux en Metal V2, sous openGL

Début 2004, lorsque commence le projet Nabaztag, j'entreprends de me mettre à niveau en électronique embarquée en réalisant un prototype d'un tapis de danse pour lecteur dvd de salon, un peu à la manière de "Dance dance revolution".

Le principe est de brancher un tapis sur n'importe quel lecteur DVD de salon, et de fournir des DVD contenant les différents clips avec les indications des pas de danse.

Problème : il n'y a pas d'entrée-sortie standard sur ces lecteurs. La solution retenue consiste à utiliser le seul connecteur qu'on trouve partout, à savoir le connecteur RCA video (prise jaune). Cette prise est uniquement une sortie vidéo. Pour générer de l'interactivité, il faut donc trouver des solutions de contournement (un peu comme les anciennes pages Teletel, qui donnaient l'impression d'un échange avec un "serveur minitel" distant).

Le principe est le suivant : les écrans du DVD intègrent des planches graphiques qui ressemblent à des mosaiques noir et blanc et encodent une information. Le boitier reçoit le signal vidéo, reconnait ces planches, et arrive à en extraire le code. Ce code contient par exemple la liste des pas de danse que le joueur doit effectuer.

Le boitier gère alors lui-même la partie (en émettant des sons pour indiquer si le pas est correct ou non), et présente le score sur son afficheur.

Je réaliserai un prototype complet, en wrapping, à base d'un micro-contrôleur 8 bits Microchip (similaire à celui du Nabaztag). Cliquer sur les photos pour agrandir.

Le projet comporte également un utilitaire pour saisir les pas et générer la vidéo avec le défilement des flèches, le tout développé en langage Métal

ainsi qu'un DVD de test, contenant deux clips, et une gestion de configuration.

En 2001, j'ai l'occasion de m'essayer au développement de jeux pour téléphone mobile. A cette époque c'est vraiment le tout début ; le standard java pour applications graphiques mobiles (j2me midp2.0) n'existe pas encore : la seule technologie existante est la technologie Exen (de la société française In-Fusio). Elle s'appuie sur le langage Java et ajoute des librairies graphiques. Les écrans des téléphones sont alors purement monochromes (c'est-à-dire sans nuance de gris), et le jeune graphiste aura du mal au début à comprendre cette contrainte, mais s'en sortira plutôt bien.

Je choisis de faire un petit jeu de tennis, car cela semble adapté au contexte graphique et à la puissance disponible. La position de la balle et de son ombre sont calculées en 3d, et l'IA de l'adversaire nécessite quelques tatonnements.

La plateforme Exen repose sur le langage java, mais ne bénéficie pas de la souplesse de sa gestion mémoire. Il faut configurer le programme en découpant la mémoire en zones allouables (par exemple 16 blocs de 8 octets, ...).

Le jeu sera commercialisé par In-Fusio.

En 1986, le formidable magazine Jeux&Stratégies propose un casse-tête à partir du matériel de jeu d'Othello. Il s'agit en gros de retourner tous les pions du plateau par une succession de coups qu'il faut déterminer (règle complète ci-dessous). Un abonnement gratuit est en jeu. Le temps de mettre au point le programme sur mon TO7, un autre lecteur a trouvé la solution à la main. Mais le magazine réitère le challenge sur trois variantes, et cette fois mon programme est prêt.

Sur un TO7, il faut 20 minutes de calcul pour trouver la solution du premier problème.

Avec un peu plus de métier (j'avais 14 ans en 1986), une nouvelle version écrite en 2012 descend à 15 secondes pour le premier problème. Pour suivre l'évolution du programme sans le ralentir, celui-ci fonctionne directement dans la mémoire écran, qui contrairement aux machines d'aujourd'hui fait partie de la mémoire principale. On voit donc des pixels qui s'agitent tant que la solution n'a pas été trouvée.

Le langage Scol que j'avais développé chez Cryo présentait à l'usage de nombreuses lacunes qu'il était difficile de corriger dans un cadre de "compatibilité ascendante". Aussi, après la liquidation du groupe, j'ai eu un peu de temps et j'ai pu repartir sur une base plus simple en intégrant notamment le Garbage collector incrémental, les types faibles, les types paramétriques, une unification de types nettement plus efficace dans le compilateur, syntaxe plus légère, ...

De fil en aiguille, ce projet initialement conçu pour "se libérer l'esprit" est devenu progressivement utile lorsque j'ai lancé mon activité de conseil. D'abord simple outil de prototypage ou d'aide à la création de logiciels, il s'est avéré très utile, et une version simplifiée a même été intégrée dans le Nabaztag-tag en 2006.

Pour concaténer deux listes quelconque, on définira la fonction conc comme ceci :

La machine virtuelle est pourvue de librairies graphiques, réseau, audio, ainsi que openGL.

La machine virtuelle existe sur Windows, Linux et MacOS.

En déambulant un peu au hasard avec Philippe Ulrich dans les allées du CES 2007 à Las Vegas, nous découvrons Koo Hyoung Lee sur son stand (Neurosky), en train de faire une démonstration d'un casque capable de lire les pensées. Nous travaillons alors sur un projet de musique interactive, et il nous semble évident que cette interface cérébrale revet un grand potentiel pour ce projet : la musique pourrait ainsi s'adapter automatiquement à l'état émotionnel de l'auditeur, voire l'influencer.

Contact pris avec la société Neurosky, je mènerai diverses expériences, qui aboutiront à la réalisation d'un prototype fonctionnel (casque + logiciel de musique pilotée par les ondes cérébrales) présenté au Midem 2008. Ces casques ont la particularité d'embarquer à la fois la technologie Brainwaves et des écouteurs audio, car par un heureux hasard, dixit Philippe, "les oreilles sont proches du cerveau, et ce n'est sans doute pas un hasard". J'ai confié le design des casques à l'agence Inprocess (qui a designé Nabaztag et la lampe Dal). Ces casques obtiendront un prix de l'innovation marketing en 2008.

La technologie de Neurosky est intégrée dans un petit module électronique bluetooth ; elle utilise trois capteurs : deux sont au niveau des oreilles et prennent la tension de référence, le troisième capteur se situe sur le front et extrait le signal cérébral.

Une interview de la BBC :

En 2006, dans le cadre des mes recherches sur la musique interactive, je cherche à modéliser un système qui évolue de façon aléatoire, mais en respectant des contraintes pré-établies et des contraintes dynamiques, qui sont parfois contradictoires. C'est en fait un modèle théorique pour les oeuvres interactives : l'oeuvre évolue aléatoirement, dans les limites fixées par l'auteur, et en fonction des actions de l'utilisateur.

J'aboutis à un modèle qui s'avère être un calcul "Turing complet", et qui repose sur les notions d'états et d'observables. Le système calcule des probabilités pour chaque état, et effectue un tirage aléatoire pour sélectionner l'état observé (cf. réduction quantique). Les probablités sont déterminées par les contraintes pré-établies, sous formes de relations de contributions de probabilités. Comme il s'agit de "mixer des états", et que c'est un calcul, je l'appellerai "mix-calcul".

En 2003, j'assiste totalement par hasard à une performance de Michel Risse, "Instrument|Monument" dans la vieille gare de Longueville, lors des journées du patrimoine :

Cette vidéo montre les concepts, mais ne rend malheureusement pas du tout l'impression sonore du spectacle, qui était intense et prenante. Dans le jeu des musiciens/danseurs/acrobates, je perçois une dimension interactive (qui n'est peut-être qu'une impression), où la musique est le simple produit des interactions impromptues entre ces musiciens. Il semble y avoir trop d'aléas dans la durée des acrobaties pour que la musique soit prévisible, et pourtant tout s'accorde. La fin arrive comme un cheveu sur la soupe, frustrante : la musique aurait pu continuer indéfiniment, dans un renouvellement permanent.

Ce sont les bases de ce que j'entends par "musique interactive" : une musique qui se génère en fonction d'événements externes, et dont la durée se décide également de manière interactive. Cette interactivité n'empêche pas l'artiste de définir un cadre, des sons, une ligne mélodique, ... Tout ceci crée pour l'auditeur une expérience engageante et ludique.

On trouvera ci-dessous un prototype très simple de génération automatique et infinie de musique, réalisée par mixage dynamique de samples. L'interaction est alors réduite au minimum, l'auditeur pouvant juste arrêter la musique lorsqu'il le souhaite. Le mixage se fait sur le poste client, le serveur se contentant de fournir les samples comme un simple serveur http.

Après quelques expérimentations en 2004-2005, le sujet intéressera Philippe Ulrich, mon complice de toujours, et nous créerons ensemble (avec Gilles Babinet) la société Mxp4 (aka. Musinaut) qui explorera ce sujet pendant deux ans avant de prendre une orientation sans rapport. Nous ferons diverses expérimentations autour de musiques connues, avec une interaction de l'auditeur pour choisir le style et la durée. Nous testerons également le pilotage de la musique par des capteurs de mouvement, des accéléromètres, et par les ondes cérébrales.

Techniquement, cette recherche aboutira à la création du format mxp4, qui permet de définir une musique interactive reposant sur un mixage dynamique de samples, le choix des samples étant le résultat de règles fournies par l'artiste et d'interactions externes. Le player mxp4 existera sous différentes formes : streaming avec player Flash, offline sur windows, mac, linux, windowsCE, symbian, iPhone.

La vidéo ci-dessus montre la version iPhone sur un cover du titre Oxygène4 (Jean-Michel Jarre). L'interaction consiste à choisir des styles d'interprétation, chacun générant une musique infinie et différente à chaque écoute. Le bouton "lock" permet de stationner sur un style, alors qu'en mode normal, le style changera automatiquement au bout d'un certain temps. Bien qu'imprévisible, la musique est accompagnée de commentaires contextuels, sur l'instrumentation, le morceau original, ...

Au-delà de l'aspect technique, ce travail de recherche montrera la difficulté de donner du sens musical à cette interactivité ; si je bouge, la musique change : oui, mais comment pour que cela ait du sens ? C'est cette capacité à mettre en scène une interactivité musicale intéressante qui ouvre la porte à un nouvel espace de création musicale. Qui sont ces nouveaux artistes ? Le projet montrera que, de même qu'un bon photographe ne fera pas un bon cinéaste (pourtant on parle toujours de pellicule), de même un musicien traditionnel ne fera pas forcément un musicien interactif...

La première barrière est mentale et tient à l'exhaustivité de l'écoute. Autant un auteur de jeu vidéo revendique facilement la paternité de son jeu, alors qu'il n'a pas vu, et ne peut pas voir toutes les parties possibles, autant un musicien du début du 21e siècle veut pouvoir tout entendre avant de mettre son nom dessus.

La seconde barrière se trouve justement dans l'aptitude à créer un espace musical interactif qui ait du sens, et cette aptitude n'a pas de rapport avec les qualités d'un musicien ou d'un compositeur traditionnels. A contrario, un minimum de connaissance musicale semble indispensable.

En juillet 2011, le nouveau propriétaire du Nabaztag, Mindscape, dépose le bilan et annonce l'arrêt des serveurs Nabaztag. Il reste encore quelques milliers de lapins en vie, et il y a quelque chose de frustrant de voir que cet objet n'a pas connu l'exploitation qu'il méritait. Il présente globalement une ergonomie de répondeur téléphonique : il reçoit des messages, les lit, et comme il ne sait pas si quelqu'un les a écoutés, se met à clignoter. Lorsqu'on arrive chez soi et que le lapin clignote, on sait qu'un message est arrivé et on peut le relire en appuyant sur le bouton. Le choix des messages à recevoir se fait sur un site web, via des réglages complexes.

Pourtant ce lapin a été conçu pour avoir une véritable autonomie, et il dispose d'une puissance assez importante.

Ayant un peu de temps à ce moment là, je décidai de mettre en place un serveur alternatif, qui explorerait une toute autre voie. Ce sera "Nabizdead", néologisme issu d'un mélange de Nabaztag et Webisdead, en référence à une soirée à laquelle j'avais assisté début 2003.

Ce service propose une approche radicalement différente : il n'est pas nécessaire d'aller sur le site web, tout peut se faire depuis le lapin, en utilisant le bouton et les oreilles.

Le service fonctionne comme un twitter vocal : le lapin pioche dans des flux de messages courts, et les lit à voix haute. Il invite à noter les flux (en levant ou en baissant les oreilles à la fin du message) ce qui influencera le choix des messages suivants. De même il propose régulièrement de s'inscrire à de nouveaux flux. Les tags RFID peuvent être associés à un flux.

Le micro est en fait ouvert en permanence, et c'est la détection d'un bruit qui déclenche la lecture d'un nouveau message par le lapin.

Par ailleurs, le lapin donne l'heure, et retient ses heures de coucher et de réveil ; on le couche en baissant ses deux oreilles.

En allant sur le site, on peut créer soi-même des flux et poster des messages. On visualise alors l'audience de ces messages et les notations des lapins auditeurs. Une API permet de poster automatiquement des messages sur ces flux.

Le service a rencontré un petit succès, tant sur le nombre de lapins inscrits (plus de 3000 début janvier 2012), que sur le nombre de flux créés par les internautes (plus de 150, dont la plupart générant automatiquement des messages via l'api, pour donner la météo, les titres des journaux, les résultats sportifs)

La liquidation rapide de Mindscape, et son rachat également rapide par Aldebaran, qui a rouvert les serveurs officiels, réduit la nécessité de serveurs alternatifs, mais l'expérience reste intéressante.

Techniquement, le service ouvre de nouvelles perspectives : l'hébergement jugé trop lourd par Mindscape est ici remplacé par un serveur mutualisé à 60 euros l'année, qui pourrait accueillir sans problème les quelques 10.000 lapins encore en service. Le lapin gère lui-même son TTS (synthèse vocale), en appelant de manière autonome des services TTS sur internet. Pour cela il a suffi de modifier le bytecode nominal.

Ergonomiquement, le service offre une vision communautaire, où selon le principe éprouvé de Twitter, tout le monde génère très facilement du contenu. L'interaction se fait directement avec le lapin en exploitant ses quelques entrées-sorties de manière très intuitive. Enfin le lapin possède une voix unique : il n'y a plus de "schizophonie".

Fin 2005, je rencontre Fabien Vial et Pierre Varrod, qui lancent un projet de guide touristique sur pda/gps, à destination des grands hôtels parisiens. Il s'agit d'une carte interactive, tactile, avec beaucoup de contenu (culture, shopping, restaurants, ...) en 4 langues, sur un PDA équipé d'un GPS.

Plus forcément très original en 2012 à l'heure de l'iPhone, mais on est fin 2005, et le produit sera prêt en juin 2006.

Je réalise la totalité du soft, en C++ sur WindowsCE, sur un terminal cible Fujitsu N520.

J'ai découvert l'existence de 'Chocolate fix' en cherchant un cadeau pour une personne qui aime le chocolat. C'est un casse-tête édité par la société Thinkfun. Il s'agit de placer 9 "chocolats" sur une grille 3x3 en respectant une série de contraintes, qui forment un "problème". Chaque contrainte définit la position relative de chocolats, de couleurs ou de formes ; en effet les 9 chocolats sont le produits de trois couleurs (chocolat au lait, chocolat noir, fraise) et de trois formes (carré, rond, triangle). Un petit livre réunit une quarantaine de problèmes.

Le jeu est très amusant, mais on arrive vite à bout des problèmes proposés, et ceux-ci sont plutôt trop simples.

L'idée récréative est donc de parvenir à générer automatiquement des problèmes, et notamment des problèmes difficiles. Quel algorithme ? quelle complexité ? Il faut que le jeu de contraintes soit minimal, c'est-à-dire qu'il autorise une et une seule solution. J'ai trouvé une technique qui permet de générer trois niveaux différents, selon le type de contrainte produite. Sur un processeur Intel core i7-2620M à 2,7GHz, utilisé en mono-thread, la génération des problèmes prend entre 1 et 6 secondes selon la difficulté.

L'interface ci-dessous permet de visualiser ces problèmes et leur solution. Saurez-vous les résoudre ? Mais surtout, comment feriez vous le programme qui les génère ?

En 2004, la société Violet renonce à commercialiser la lampe DAL et se lance dans un projet d'objet communicant grand public. Après avoir hésité entre une fleur et une peluche, le projet s'arrête sur un lapin stylisé en plastique blanc. Il faudra un peu plus d'un an entre le début du projet et sa commercialisation en juin 2005.

L'électronique est réalisée par Philippe Debadier, ingénieur à l'école Sudria, sur la base d'un microcontrôleur 8 bits Microchip. Je m'occupe pour ma part du logiciel embarqué et de la partie serveur. Le système dispose de 3,5Ko de RAM et 48Ko de ROM pour stocker le programme, et 1Mo de flash utilisée comme mémoire de masse pour stocker la configuration et les données reçues du serveur ; on est donc face à une puissance comparable aux ordinateurs 8 bits du début des années 80, avec une RAM particulièrement faible.

Le logiciel embarqué est écrit en C. Il gère les différents périphériques ainsi que la carte wifi, au format pcmcia. La carte Wifi est de type 'Hardmac', ce qui signifie que l'essentiel du protocole wifi est traité dans la carte elle-même, notamment les mécanisme de connexion, le cryptage, l'encodage des trames réseaux. La RAM ne permettant pas le stockage complet des trames réseaux, celles-ci sont extraites (ou transmises) octet par octet de la carte pcmcia. Malgré tout, le firmware intègre une couche réseau relativement complète : arp, ip, udp, tcp, dns client, dhcp client et serveur, http client et serveur. En effet, comme pour la lampe DAL, la configuration se fait en mode wifi adhoc au travers d'un petit serveur http intégré ; ce mode s'active lorsqu'on appuie sur le bouton du lapin en le branchant.

Le firmware intègre également une machine virtuelle rudimentaire, qui lui permet de recevoir des bytecodes du serveur ; ceci permet d'une part de sécuriser le bon fonctionnement de l'objet, et d'autre part de faire évoluer le comportement interne de l'objet après le début de sa commercialisation. En effet, au début du développement du produit, nous n'avions pas les idées très claires sur les services qui seraient proposés.

Cette machine virtuelle utilise un langage de type assembleur 8 bits, auquel sont apportés quelques conforts rencontrés sur le processeur 16 bits motorola 68000 (Macintosh, atari ST, amiga) : il y a notamment 16 registres. Certaines fonctions de ce processeur permettent de piloter les leds, les moteurs, les capteurs optiques et le circuit audio. Le nom de code de ce langage est VASM.

Une fois connecté au wifi, le lapin télécharge un premier bytecode, puis régulièrement, interroge le serveur en http, et reçoit éventuellement un nouveau bytecode, qui remplacera le précédent

Le code source du logiciel embarqué n'a à ce jour pas été diffusé par ses nouveaux propriétaires, c'est pourquoi on ne le trouvera pas encore ici.

Le bytecode est généré par un serveur java qui s'appuie sur des templates de sources VASM, qui sont paramétrés à la volée, puis assemblés vers le bytecode.

En 2003, je suis mis en relation avec Olivier Mével, qui s'apprête à créer la société Violet sur le thème des objets pervasifs et de l'intelligence ambiante. Je vais l'aider pendant 3 ans, comme co-fondateur et CTO externe, en prenant en charge l'ensemble des sujets logiciels ; c'est le côté amusant de ce genre de startup : pendant plus d'un an, il faudra tout faire. Violet internalisera ensuite progressivement les aspects web et serveurs, mais touchera peu aux aspects embarqués.

Le premier objet est la Lampe DAL. Pourquoi une lampe ? parce que "la lumière, c'est la vie" me confiera le designer. Cette lampe sera développée en moins de 4 mois. En son coeur se trouve une électronique basée sur Linux. Elle communique avec un serveur Java. Pour garantir l'intégrité du fonctionnement, le logiciel embarqué prend la forme d'une machine virtuelle, qui télécharge des applis du serveur, et les fait fonctionner simultanément dans la lampe. Le langage utilisé est un langage Xml spécifique, qui permet de faire des calculs simples et d'accéder aux périphériques : 9 leds RGB et des capteurs de toucher.

L'objet est connecté à des sources de données (météo, mail, bourse, ...) qu'il reçoit du serveur ; les programmes s'appuient sur ces sources pour générer des animations lumineuses.

L'objet est connecté par wifi. La configuration se fait en mode wifi adhoc (avec un commutateur sous la lampe pour choisir le mode adhoc) au travers d'un petit serveur http intégré.

Le serveur permet de configurer ses services, mais aussi d'uploader ses propres programmes.

La lampe DAL sera présentée en 2003 à Beaubourg, au salon Batimat, puis à Apple Expo.

Une vidéo de Pierre Dandumont :

A l'occasion du salon Imagina 97, Philippe Ulrich et moi élaborons un papier prospectif sur les mutations que la numérisation va provoquer.

Il y est question d'information, de copie, d'ubiquité ; on pourra même y voir une introduction imagée au lambda calcul. La fin du papier annonce un projet encore en gestation, l'expérience Magma qui donnera naissance à la technologie Scol.

Le Menta, fusion de l'information et de son traitement, doué de mobilité et d'ubiquité, reste encore un sujet de prospection.

En 1996, j'ai l'occasion d'effectuer mon stage de DEA à l'Inria, dans l'équipe PARA de Jean-Jacques Lévy, sur le sujet "Sécurité et processus mobiles". C'est l'occasion de découvrir le pi-calcul (un calcul théorique comme le lambda-calcul, dédié à la distribution), et le join-calcul, développé par l'équipe PARA et qui permet une mobilité des processus (en cours de fonctionnement). Le stage aborde les questions de cryptographie et de droit d'accès dans ce contexte théorique très particulier.

En 1994, j'ai l'occasion de passer quelques mois au MIT, dans le laboratoire Computation Structures Group du professeur Arvind. Cette équipe a mis au point Monsoon, un ordinateur Dataflow, en partenariat électronique avec Motorola. Le Dataflow est un modèle de programmation parallèle particulièrement efficace : "Imagine a computer program that can run on thousands of processors with no modifications and even greater performance. Scalability and programmability would be virtually unlimited".

Mon travail a consisté à ajouter de l'interactivité à cette machine qui en était totalement dépourvue. En ajoutant une interface X11, il a été possible d'explorer de nouvelles fonctionnalités, comme la parallélisation d'une feuille excel, mais aussi ce qui fut sans doute le premier et le dernier casse-brique parallèle de l'Histoire.

La machine se programmait dans un langage fonctionnel, appelé "Id", très élégant, très efficace, et parfaitement adapté au parallélisme.

En 1994, à une époque où les cartes 3d n'existent pas, je cherche des techniques pour optimiser le calcul d'objet en 3d. J'imagine une technique de précalcul de l'ordre d'affichage des polygones, qui débouche sur une étude théorique qui me semble intéressante.

Quand un objet est convexe le tri des polygones est simple : on affiche d'abord les polygones dont on voit la face intérieure, puis les polygones dont on voit la face extérieure.

Quand un plan sépare un objet en deux, on affiche d'abord les polygones qui ne sont pas du même côté de ce plan que l'observateur, puis les polygones qui sont du même côté du plan que l'observateur

Fort de ces ceux observations, on démontre qu'on peut toujours décomposer un objet comme une arborescence de ces deux cas, et que de manière inattendue, des objets apparemment complexes se réduisent à une succession du premier cas (par exemple un escalier).

Sur la lancée du programme Reverse, en 1987, j'imagine une technique de résolution de coup très simple, qui s'avérera différente et meilleure que le minimax. J'en ferai une première implémentation sur Atari ST en 1990, mais ce n'est qu'en 1994 que j'aurai le bagage mathématique pour analyser cette solution.

Dans ce type de problème, on utilise une fonction d'évaluation qui attribue un score à une position de jeu. Pour une recherche à 5 demi-coups par exemple, on cherche le coup qui garantit la meilleure valeur de la fonction d'évaluation 5 demi-coups plus tard, quels que soient les coups de l'adversaire. La technique de résolution classique s'appelle Minimax et s'accompagne d'une variante optimisée appelée "alpha-bêta".

Dans la méthode ici décrite, on procède par dichotomie : on choisit une valeur de la fonction d'évaluation, par exemple V, et on se demande s'il existe un coup qui permet de garantir cette valeur. Pour n demi-coups, on joue le premier demi-coup au hasard, puis le second demi-coup au hasard, jusqu'au n-ième demi-coup. On regarde alors la position obtenue. Si son score est supérieur à la valeur V, on modifie le dernier coup de l'adversaire ; si on les a tous essayés, on remonte de deux demi-coups et on modifie donc l'avant dernier coup de l'adversaire. Puis on rejoue la partie au hasard jusqu'au n-ième demi-coup. Si le score est inférieur à la valeur V, on modifie le dernier coup du joueur, etc. En remontant de deux demi-coups pour modifier un coup de l'adversaire, il arrive finalement qu'on revienne avant la position actuelle. Cela signifie que la valeur V est garantie, et que le premier demi-coup du joueur actuellement tenté est le bon. Si c'est en modifiant un coup du joueur qu'on revient avant la position actuelle, cela signifie que le valeur V ne peut être garantie. En appliquant une dichotomie sur les valeurs V, on détermine précisément le meilleur coup possible et la meilleure valeur V garantie.

Tout ceci est expliqué en détail dans le papier ci-dessous.

A l'arrivée à l'X en 1992, nous sommes contraints d'acquérir un portable apple (powerbook 145), sur lequel nous devons réaliser un projet informatique sur un sujet éventuellement libre. Intéressé par les problématiques de Système d'exploitation, de multi-tâche préemptif, et par l'évolution des interfaces graphiques, je réalise un tel système sur Mac. A l'époque, les systèmes courants (Mac, Windows 3.1) n'étaient pas préemptifs, ce qui signifie que seule la fenêtre qui avait le focus travaillait réellement ; les autres étaient gelées. De même, les applications devaient rendre elles-même la main au système lorsqu'elles avaient fini chaque traitement, sans quoi le système lui-même était gelé. Dans un système préemptif, le système reprend la main d'office, avant de la redonner plus tard.

Ce projet reconstruit from scratch (juste en récupérant l'adresse de la mémoire vidéo) un environnement graphique monochrome avec fenêtre et souris, au-dessus d'un gestionnaire de processus (avec scheduler et multi-threading).

Plusieurs démonstrations sont intégrées : un calcul de l'ensemble de Mandelbrot (qui démontre visuellement que plusieurs fenêtres travaillent simultanément), un othello, un moniteur de processus et de mémoire, quelques démonstrations de concurrence (le classique "parking", avec une seule entrée, une seule sortie, et plusieurs voitures), ... et un cheatmode, accessible sur quintuple click.

Les copies d'écrans ci-après ont été réalisées sur l'émulateur Mess en mode Mac SE/30 (car il faut un 68030 avec un écran monochrome). L'écran du Powerbook 145 était sensiblement plus large, et un peu plus haut (640x400 au lieu de 512x384), ce qui explique que certaines images sont tronquées.

Début 1994, je découvre les "émulateurs", ces programmes qui transforment les ordinateurs du moment en ordinateurs des années 80. Apple ][, Commodore 64, Zx Spectrum, la plupart des machines sont déjà traitées. Toutes ? non car l'ordinateur français de référence, le To7, résiste, et n'a pas encore suscité de vocation, sans doute car inconnu hors de France. Je m'attèle à la tâche et fais ainsi revivre ma première machine. C'est aussi ma première machine virtuelle ; je ne sais pas encore qu'il y en aura beaucoup d'autres.

La première version est réalisée sur Unix/X11 (Linux, mais pas seulement). Il faudra attendre 1995 pour une version Ms-Dos, environ 2000 pour une version Windows puis PocketPC.

Un compagnon indispensable de tout émulateur est l'outil de récupération des logiciels ; en l'occurrence, l'outil qui récupère les logiciels stockés sur cassettes audio. On numérise une cassette (par exemple au format 44.100Hz, 8 bits, mono), puis un programme s'efforce de repérer les sons qui correspondent à des 1, et ceux qui correspondent aux 0. A partir de là, en connaissant le format d'encodage des données du To7, on reconstitue l'information complète. C'est en théorie assez simple, mais les bandes ne sont pas toujours bien conservées, et l'outil va alors se tromper sur certains bits. Comment retrouver lesquels ? La meilleure technique que j'ai trouvée consiste à développer deux outils de récupération utilisant deux techniques distinctes (par exemple l'un sur l'analyse fréquentielle, l'autre sur l'analyse temporelle) : en cas d'erreur à un endroit de la bande, les deux techniques donnent généralement deux résultats différents pour cette partie de la bande, ce qui permet de localiser très précisément l'erreur.

Une version particulière de l'émulateur a été développée pour la Bibliothèque Nationale de France, dans le cadre de son activité de conservation du patrimoine logiciel, et notamment du fonds très volumineux des logiciels éducatifs du plan Informatique Pour Tous. Ce fonds est ainsi accessible aux chercheurs désireux de consulter ce glorieux patrimoine.

En 1988, Ere Informatique me demande de porter un de ses jeux à succès, Macadam Bumper (de Rémi Herbulot) sur les ordinateurs Thomson du moment. Disposant de très peu de documentation sur l'original, c'est ici une adaptation très libre. Il s'agit d'un flipper constructible.

C'est un mélange de Basic et d'assembleur 6809, avec très peu de Basic ; il est assez difficile d'extraire le code source en basic, autrement qu'en le chargeant sur un émulateur. Il était distribué sous forme de disquette 3 pouces 1/2

Ce premier programme est réalisé en 1986, à l'age de 14 ans, et repéré par Philippe Ulrich, qui est alors directeur de la création de Ere Informatique, un éditeur français qui s'appuie sur un réseau d'auteurs indépendants. Il est publié sous le label 'Gasoline Software'.

Ce programme est écrit pour les ordinateurs Thomson (To7, Mo5), dont j'ai plus tard écrit des émulateurs. C'est un mélange de Basic et d'assembleur 6809. Il était distribué sous forme de cassette audio.