L'idée : le contrôleur de bus est le noyau
Sur la Neo6502kbd, le RP2040 sert chaque cycle de la 6502. Eliott65 pousse cette situation jusqu’au bout : puisque le RP2040 est déjà là, c’est lui qui sera le système.
Dans cette page
Deux exigences au départ
Le projet est né de deux demandes, posées dès l’étude de faisabilité du 13 octobre 2026 :
- préserver la mémoire de la 6502, et proposer quelque chose de neuf ;
- partir d’une page blanche : ne pas reprendre Morpheus, le firmware fourni avec la Neo6502 (écrit par Paul Robson).
L’étude a comparé trois voies : un système 6502 au-dessus de Morpheus, une variante de Morpheus, ou un firmware entièrement neuf. La troisième a été retenue. Le dépôt de Morpheus a servi de documentation sur les temps du matériel et de point de comparaison, sans qu’aucune ligne en soit reprise. Le choix a son prix, assumé : aucun programme écrit pour Morpheus ne tourne tel quel sur Eliott65.
Le projet est allé plus loin que prévu dans ce sens : les pilotes HDMI et USB sont eux aussi écrits pour Eliott65, sans les bibliothèques PicoDVI ni TinyUSB. Seul le pico-sdk de Raspberry Pi est utilisé.
L’idée centrale : un noyau « hors bande »
Sur un ordinateur classique, le système d’exploitation tourne sur le processeur, et occupe une partie de sa mémoire. Sur la Neo6502kbd, il existe un deuxième processeur, plus puissant, qui voit passer chaque accès mémoire de la 6502 : le RP2040.
Eliott65 y installe donc tout le système. La 6502 n’exécute que les programmes de l’utilisateur. On dit que le noyau est hors bande : il tourne à côté du processeur qu’il sert, pas dedans.
Cinq idées qui en découlent
L’étude listait cinq innovations. Voici ce que chacune est devenue.
1. Un système qui ne prend que 8 octets ✅
Deux octets de porte d’appel ($FFF8–$FFF9) et les six octets de vecteurs que la 6502 exige
($FFFA–$FFFF). Rien d’autre : pas de ROM, pas de variables système, pas de tampon d’écran imposé.
Le noyau ROM de Morpheus, à titre de comparaison, occupe 1 024 octets en $FC00.
2. Des appels système sans boîte aux lettres ✅
Le programme passe au noyau l’adresse d’un bloc de paramètres rangé dans sa propre mémoire, là où il veut. Il n’y a donc aucune zone réservée aux échanges. Voir Les appels système.
3. Un démarrage « évanescent » ✅
Pour lancer un programme, le RP2040 le dépose directement dans la mémoire de la 6502, maintient le RESET, puis le relâche. Aucun chargeur ne reste en mémoire : le programme démarre dans une machine où il est seul.
4. Une MMU dans le contrôleur de bus ❌ (puis ✅ autrement)
L’idée la plus audacieuse : puisque le RP2040 décode chaque adresse, il pourrait la traduire, et offrir à la 6502 une vraie gestion de mémoire par pages (protection, partage, mémoire virtuelle).
Le critère fixé d’avance était une perte de vitesse d’au plus 20 %. La mesure a donné −34 % (4,73 MHz au lieu de 7,20). Décision : no-go, la variante reste en option expérimentale. Le multitâche a été obtenu autrement, en échangeant les pages au moment de changer de programme plutôt qu’à chaque accès. Voir Plusieurs programmes à la fois.
5. L’hibernation instantanée ✅
Toute la mémoire de la 6502 vivant dans le RP2040, l’état complet de la machine peut être écrit dans un fichier, puis rechargé. Voir L’hibernation.