Aller au contenu
Eliott65wiki
Sommaire

L'émulateur et les bancs

Quand la carte n’était plus disponible, le projet a continué sur le PC : le même noyau, compilé pour l’ordinateur de bureau, autour d’une 6502 simulée. Puis, pièce par pièce, le matériel de la carte lui-même.

Dans cette page

Le principe : le vrai noyau, pas une imitation

Un émulateur ordinaire réécrit le comportement d’une machine. Celui d’Eliott65 fait autre chose : il compile pour le PC les sources du noyau, inchangées, et ne remplace que la « plate-forme » (quelques centaines de lignes) : ce qui, sur la carte, touche au matériel.

La 6502 simulée est le cœur 65C02 de Phosphoneo, un autre émulateur du même auteur, recopié tel quel. Il a deux qualités décisives :

  • il produit un accès au bus par cycle, exactement comme la vraie 6502 vue par le bus PIO + DMA ;
  • il passe la batterie de tests SingleStepTests : 50 800 cas, 254 instructions, 100 %.

Premier essai : le programme de démarrage s’affiche comme sur la carte, et 4,1 secondes de la machine sont simulées en 0,24 seconde. Avec une clé virtuelle, le shell démarre seul et fait tourner trois processus avec préemption.

Les bancs : le matériel de la carte, simulé

Restait ce que le premier émulateur ne couvrait pas : la PIO, la DMA, la vidéo, l’USB. Trois bancs l’ont ajouté.

Le bus

Un interpréteur PIO exécute le vrai programme du bus, avec un modèle de la DMA et des trois tampons, et les temps de la 6502 mesurés sur la carte. Confronté aux huit réglages mesurés sur la carte, le modèle donne les mêmes réussites et les mêmes échecs, pour les mêmes causes, et des vitesses à moins de 1 % près.

La vidéo

Le vrai pilote DVI tourne sur le PC, avec un modèle de sa DMA et de sa PIO, et un écran simulé décode le signal produit. Résultat : un signal conforme au 640 × 480, et 0 pixel différent de l’image attendue sur la mire, l’écran de démarrage et le shell. Un seul bit inversé exprès est bien détecté.

Un obstacle instructif : sur un PC 64 bits, la liste de lignes du pilote (des pointeurs) faisait 8 octets par entrée, alors que la DMA du RP2040 lit des mots de 32 bits. Plutôt que de « tricher » avec le pilote, l’émulateur est compilé en 32 bits.

L’USB

Le vrai pilote USB tourne dans un modèle du contrôleur USB du RP2040, face à des appareils simulés d’après le journal de la carte : hub, clavier et souris lents, clé rapide adossée à une image disque. Le shell est chargé depuis la clé USB simulée et piloté au clavier USB simulé.

Ce banc a trouvé un vrai défaut : une seule erreur de lecture pendant le chargement du shell l’empêchait de démarrer. Il permet aussi de brancher, déplacer et arracher des appareils à chaud, y compris en pleine écriture.

Conforme à la carte ?

Quand la carte est revenue, un outil a joué les mêmes scénarios des deux côtés :

  1. un programme de calcul (additions et soustractions binaires et décimales avec leurs drapeaux, comparaisons, décalages) : 28 416 octets de résultats identiques, octet pour octet ;
  2. les écrans du shell : 30 lignes sur 30 identiques ;
  3. le journal du pilote USB : 19 lignes sur 19 identiques.

Le temps, lui, a été réglé sur la mesure de la carte (7,20 MHz), pas prédit : le projet le dit ainsi. Le modèle du bus, qui ignore la concurrence de la vidéo, donnait 2,9 % de trop. À 270 MHz, il a été recalé sur la nouvelle mesure (7,716 MHz, écart nul), puis réglé sur une vitesse prédite (7,494 MHz) après la correction du bus. La carte a ensuite mesuré 7,707 MHz : l’émulateur tourne désormais à cette vitesse (v0.59.1). Le même modèle a servi d’outil d’enquête : voir Le bus.

La fenêtre

Un second exécutable ouvre une fenêtre (SDL2) : l’écran en direct, et le vrai clavier du PC, converti en rapports USB et passé par le clavier USB virtuel. Il tourne en temps réel : 3,12 s pour 3 s simulées.

Les captures d’écran de ce wiki viennent de cet émulateur.

Le débogueur (v0.56)

L’émulateur sait aussi regarder un programme 6502 tourner. Ces outils ne s’activent que si on les demande : sans eux, rien ne change ni ne ralentit.

  • Les symboles de l’assembleur 64tass, produits avec chaque programme : les adresses s’affichent par leur nom (JSR $10BB ; e65_quitter).
  • Une trace de chaque instruction (cycle, processus, adresse, instruction, registres), entre deux bornes.
  • Des points d’arrêt, sur une adresse ou un symbole, éventuellement pour un seul processus.
  • Une surveillance : arrêt dès qu’un octet de la mémoire change.
  • Une console : pas à pas, continuer, registres, mémoire, désassemblage, symboles ; elle se pilote aussi par un script.

Le désassembleur est celui du cœur 65C02 de Phosphoneo.

Ce que l’émulateur ne prétend pas faire

  • Il ne modélise pas la concurrence entre la vidéo et le bus sur la DMA, ni la dispersion des temps d’une puce à l’autre.
  • L’USB simulé est 3 à 4 fois plus rapide que la vraie clé : les attentes de la clé et de sa flash ne sont pas modélisées, et le projet ne sait pas quelle part revient à chacune.

Sources dans le dépôt : docs/journal/12-emulateur.md, docs/adr/ADR-0020-emulateur-hote.md, docs/adr/ADR-0021-modele-du-bus.md, docs/adr/ADR-0022-banc-video-dvi.md, docs/adr/ADR-0023-banc-usb.md, docs/adr/ADR-0024-fenetre-sdl.md.