Journal Un lecteur vidéo pour regarder Big Buck Bunny sur un Macintosh IIcx de 1989

Sommaire

• Introduction
• Mais pourquoi faire ça ?
• Le Développement
  • Retro68 et Mini vMac
  • Format de la vidéo et du son
  • Lecture
  • Faire tourner le programme sur un vrai Mac
• L’expérience

Introduction

On n’aime pas forcement beaucoup Apple ici. Mais j’espère que vous me pardonnerez vu qu’il s’agit de développement, de bidouillage, d’informatique rétro et que je vais évoquer pas mal de logiciels libres.
Il s’agit ici de mon expérience de développement d’un lecteur vidéo basique qui tourne sur un Macintosh IIcx de 1989 sous Système 7. Beaucoup de logiciels libres ont été utilisés pour parvenir au but : Retro68, Mini vMac, python, OpenCV, ffmpeg…

Vous pouvez visualiser la démonstration du résultats sur Youtube ou en téléchargement direct.
Le code du lecteur est disponible sur GitHub sous licence MIT.

Mais pourquoi faire ça ?

Je me suis récemment pris d’une passion un peu bizarre. Je collectionne et répare les vieux Macintosh des années 80. Je ne suis pourtant pas un adepte d’Apple. Je n’ai jamais eu de Mac moderne et j’utilise uniquement Linux depuis plus de 10 ans. Mais ma nouvelle passion doit être sans doute liée à mes premiers émois avec l’informatique, lorsque mon père ramenait de son travail l’une de ces machines.
Bref, on m’a récemment très gentiment donné un Macintosh IIcx de 1989 qui traînait dans une cave. C’était une machine plutôt haut de gamme à base de CPU Motorola 68000, comme tous les Macs de cette époque. Une de ces particularités est que l’unité centrale était accompagnée d’un CRT monochrome en mode portrait.
La machine ne fonctionnait pas lorsque je l’ai reçue : l’alimentation était instable. Mais après avoir passé la carte mère au lave vaisselle (oui, ça se fait très bien) et avoir changé les condensateurs de la carte mère et de la carte graphique, c’est tombé en marche ! Il est courant pour ces machines que le liquide des condensateurs électrolytiques vieillissants montés en surface fuit. Ces derniers ne fonctionnent alors plus et ça peut créer des court-circuits et de la corrosion sur les pistes du circuit imprimé.

Une fois réparée, l’envie m’est venu de tenter de développer pour cette plateforme. Comme démo, en souvenir de mon travail autour de VLC, j’ai pensé à afficher de la vidéo. C’était un défi car cette machine de 30 ans n’est pas vraiment prévue pour ça. L’écran est monochrome et les ressources de calcul sont limitées.

Le Développement

Retro68 et Mini vMac

La formidable toolchain Retro68 m’a permis de développer le lecteur en C sur Linux. Elle contient un cross-compilateur basé sur GCC et des scripts CMake qui génèrent automagiquement des images de disque pour l’émulateur libre Mini vMac et des exécutables facilement transférables sur un vrai Mac.
Retro68 ne contient pas pour des raisons légales les bibliothèques systèmes mais on peut facilement les ajouter. On peut aussi trouver de la documentation en ligne pour les API systèmes dans des volumes PDF « Inside Macintosh » archivés à différents endroits sur le Web.

Format de la vidéo et du son

Comme la puissance de la machine est limitée, j’ai voulu éviter d’utiliser des algorithmes de compression vidéo et audio. Les données sont lus directement décompressés depuis un fichier au format spécifique. Le lecteur va en fait ne faire que des copies de mémoire au bon moment.

Une limitation, le fait que l’écran soit monochrome, se retrouve être ici un avantage. On peut stocker la valeur d’un pixel sur un bit (blanc ou noir). Ainsi, si l’on joue la vidéo dans la résolution 320x240, on a besoin de 9.4 ko pour stocker chaque image. Si l’on affiche 10 images par seconde, on arrive à une taille de 5.5 Mo pour une minute. Ce sont des ordres de grandeurs acceptables pour le court-métrage que je voulais jouer et le moyen de stockage (sur lequel je reviendrai) dont je disposais sur le Mac réel. ffmpeg m’a donc servi à convertir le film à la résolution et à la fréquence d’affichage dont j’avais besoin.
Pour passer le court-métrage et ses nombreuses couleurs en noir et blanc, j’ai décidé de faire un rendu des contours grâce au détecteur de Canny d’OpenCV. Une amélioration pourrait être de combiner les contours avec différents motifs noir et blanc pour simuler différents niveaux de gris. C’est une technique souvent utilisée sur cette plateforme.

En ce qui concerne le son, il est simplement reéchantillonné à une fréquence de 11KHz en 8 bit mono. Cette opération est aussi réalisée avec ffmpeg. Cela signifie que le son est stocké sur des entiers de 8 bits avec 11000 valeurs par seconde, ce qui représente 645 ko par minute. C’est tout à fait compatible avec mes contraintes de stockage souples.

Pour faire la détection de contours avec OpenCV et multiplexer dans un seul fichier les données vidéos et sonores, j’ai codé un script Python 3.

Lecture

Un point critique dans un lecteur multimédia, et je pense que les développeurs de VLC ne me contrediront pas, est la fiabilité de l’horloge. Il faut afficher au bon moment la bonne image et synchroniser les échantillons sonores avec les images.
Ici, c’était bien sûr beaucoup plus simple car je maîtrisais entièrement les données d’entrée. Pour faciliter la tâche le Mac nous permet d’activer une interruption système (VBL) qui a une fréquence de 60Hz. Cette dernière est normalement prévue pour commiter dans un temps limité les changements à l’écran juste avant l’affichage et ainsi éviter les rafraîchissements partiels. Pour ma part, comme je dois rafraîchir une bonne partie de l’écran, ce temps n’est pas suffisant mais cette interruption me permet de cadencer de manière temporellement stable l’avancement de la vidéo.

Des API systèmes sont exposées pour créer des interfaces graphiques, dessiner sur l’écran et jouer du son. Les interfaces graphiques sont mêmes définies dans des fichiers de ressources.
Un fait que je trouve intéressant et que lorsque l’on tente de dessiner, on se rend bien compte que les temps changent. Un exécutable client peut ainsi dessiner sans limitation partout sur l’écran ; environnement de bureau et autres logiciels. Personnellement, moi qui suis adepte de la méthodologie que je nomme "YOLO programming", je suis assez fan. De la même manière, l’OS est très laxiste au niveau des débordements de tampon et nous laisse aisément écrire un peu où on veut. Revers de la médaille, lorsqu’on a fait trop de caca et que le programme crash, un seul choix nous est laissé : redémarrer… Au revoir toutes les tâches en cours et données non sauvegardées !

L’API sonore est basée sur une queue de commandes à exécuter qui permet d’empiler les paquets d’échantillons sonores. On doit leur ajouter un en-tête spécifique qui décrit le format du paquet. Cette API a tendance à contenir des bugs sur les vieux systèmes. Et des limitations matérielles ou logicielles font qu’il n’est pas possible par exemple d’enchaîner sans coupure les paquets d’échantillons sonores sur les Macintosh Plus et SE. Cela rend le son très haché sur ces machines.

Faire tourner le programme sur un vrai Mac

J’ai développé le logiciel avec l’aide de l’émulateur Mini vMac. Mais l’objectif final était bien sûr que ça fonctionne sur le vrai Mac. Pour transférer le programme, je me suis procuré un adaptateur SD2SCSI qui permet au Mac dont les disques durs sont à norme SCSI de lire des cartes SD formatées en HFS. Pour ne pas avoir de soucis, il est conseillé de ne pas dépasser 2Go comme taille de partition. C’est déjà énorme en comparaison de la taille standard du disque dur intégré à cette machine (80 Mo) et ça laisse suffisamment de place pour stocker les données de la vidéo. Linux permet sans problème de lire et d’écrire les partitions au format HFS.

L’expérience

L’expérience de développement sur cette plateforme était assez amusante et obtenir le résultat escompté fût gratifiant. Cependant, même si le programme représente peu de ligne de code au final, il m’a fallu beaucoup de temps pour arriver au bout.

Lorsque l’on débute aujourd’hui sur cette plateforme, les seules ressources sont quasiment les volumes "Inside Macintosh" d’Apple. Ils sont vraiment très complets. J’admire l’effort qu’ils ont fait pour les rédiger. Cependant de mon point de vue, ils sont aussi très verbeux. J’aurais parfois envie qu’ils aillent plus rapidement droit au but. Naviguer dans ces PDFs de 300, 400, 500 pages sans aucun lien est pénible.

Comme on peut l’imaginer, le "Stack Overflow based programming" (pour le site de questions réponses) qui est une composante du "YOLO programming" que j’affectionne s’applique mal ici. Le fainéant que je suis se retrouve obligé de RTFM ! Hormi des scans de vieux livres ou revues pour développeur, il y a peu d’exemples de code. De plus, certains exemples, notamment pour l’API sonore, peuvent ne pas fonctionner pour le système ciblé avec ses limitations et bugs. Certaines API ont vu leur vie être prolongée jusqu’au premières versions de Mac OS X !
Le dépôt de Retro68 contient aussi quelques programmes d’exemple.

Voilà pour mon premier journal ! J’espère que ce petit retour d’expérience vous aura intéressé.