Les décisions
Deux choix expliquent la forme de l’émulateur. Les voici avec les options écartées.
ADR-01 — lier firmware/common/
Quatre options : réécrire l’API en C (écartée : divergence garantie) ; compiler firmware/common/ tel quel avec une couche hôte propre (retenue) ; vendoriser une copie dans le dépôt (écartée : duplication et dérive) ; co-simuler le RP2040 (retenue en plus, comme second backend). Le chemin du firmware est un paramètre du Makefile (NEO_FIRMWARE) et sa version est épinglée dans le manifeste des captures.
ADR-02 — sauvegarder l’état entre deux bornes de lien
Le problème : l’état du firmware lié est réparti dans des centaines de variables statiques, qu’on s’interdit de modifier pour les rendre sérialisables. Options écartées : sérialiser variable par variable (impossible sans toucher aux sources) ; regrouper les variables dans une section nommée avec #pragma clang section (ignoré par WebAssembly, absent de GCC) ; copier toute la mémoire linéaire WebAssembly (emporte la libc, SDL, le tas, la pile : non restaurable).
La solution retenue : deux objets minuscules (fwstate_begin.c et fwstate_end.c) liés juste avant et juste après les objets du firmware. Comme l’éditeur de liens place .data et .bss dans l’ordre des objets, toutes les variables du firmware tiennent entre les deux bornes : on copie cet intervalle, sans toucher à ses sources. Chaque construction le vérifie sur la carte de liens. L’image contient un en-tête (version, révision), le 65C02, la partie hôte champ par champ, et les deux blocs du firmware ; elle ne se relit qu’avec le même binaire.