Linux/4004 : démarrer Linux sur un Intel 4004 sans objectif commercial

 (dmitry.gr)
1 points par GN⁺ 2024-09-21 | 2 commentaires | Partager sur WhatsApp
  • Debian Linux démarre sur une vraie carte utilisant uniquement le Intel 4004 4 bits de 1971 comme CPU, illustrant les limites des anciens microprocesseurs et un cas extrême d’empilement logiciel
  • Linux ne s’exécute pas directement sur le 4004 : il démarre sur un émulateur MIPS R3000/DECstation 2100 écrit en assembleur 4004, tandis qu’une partie du disque et de la console est simplifiée via des hypercalls et des pilotes paravirtualisés
  • La limite de 4 Ko de ROM, les opérations 4 bits, l’absence d’opérations logiques, la pile d’appels peu profonde et l’adressage atypique de la RAM 4002 ont imposé des contournements comme le banking de ROM, les tables de correspondance, les status nibbles et une RAM virtuelle basée sur de la PSRAM
  • Après optimisation, le temps estimé de démarrage de Linux sur un vrai 4004 à 740 KHz est de 4,76 jours ; la carte réalisée est overclockée à 790 KHz, avec un MIPS virtuel fonctionnant à environ 74,73 Hz
  • Le résultat a été conçu comme une carte d’art rétro à accrocher au mur, avec un VFD 40x2, 32 LED de PC, une carte SD, de la PSRAM SPI et un UART ; les sources et images disque sont publiées sous condition d’usage non commercial

Démarrer Debian Linux sur un vrai 4004

  • Linux/4004 est un projet qui démarre Debian Linux sur une vraie carte utilisant l’Intel 4004 de 1971 comme unique CPU
  • Le 4004 est présenté comme le premier microprocesseur produit commercialement au monde, et le projet utilise une vraie puce Intel 4004 des années 1970
  • La vidéo de démonstration a été accélérée à vitesse variable selon les sections pour réduire l’ennui, mais l’horloge et le calendrier affichés à l’écran sont exacts
  • Une vidéo de type original, lue à vitesse constante, est également fournie séparément

Pourquoi le 4004 ?

  • En 2012, l’exécution de Linux sur un microcontrôleur AVR 8 bits avait établi un record de « Linux exécuté sur la configuration la plus minimale », puis le projet plus pratique LinuxCard a aussi été mené
  • En 2023, une tentative de battre ce record sur base AVR et un projet de démarrage de Linux sur un MOS 6510 ont fait émerger l’objectif d’un CPU encore plus rudimentaire
  • Pour remonter plus loin que les candidats Intel 8080 et 8008, le Intel 4004 de 1971 a été choisi
  • Le 4004 étant une puce 4 bits, il permet de fixer clairement une référence plus basse que celle des CPU 8 bits

Contraintes de l’Intel 4004

  • Le 4004 fonctionne par unités de 4 bits, et la plupart des instructions font 1 octet et s’exécutent en 8 cycles d’horloge
    • Certaines instructions de 2 octets nécessitent 16 cycles
    • FIN est une exception : c’est une instruction de 1 octet, mais elle prend 16 cycles
  • Le jeu d’instructions ne comporte pas d’opérations logiques comme AND, OR, XOR et repose essentiellement sur ADD et SUB
  • Le carry flag se comporte de façon particulière : comme un borrow en entrée de SUB, puis comme un not borrow après SUB, ce qui a été confirmé sur le matériel réel
  • Les registres internes sont au nombre de 16 et font 4 bits, le PC fait 12 bits, et la return stack matérielle a 4 niveaux
    • Comme l’entrée actuellement au sommet de la pile est utilisée comme PC, l’imbrication réelle des fonctions est limitée à 3 niveaux
  • Il n’y a pas d’interruptions ; le mécanisme le plus proche du traitement d’événements externes consiste à sonder la broche TEST dans les branchements conditionnels

Structure mémoire et I/O

  • Le 4004 ne traite pas directement les instructions mémoire elles-mêmes : des puces reliées au bus comme les 4001/4002/4289/4265/4308 les décodent et les exécutent
  • Le 4001 est une puce ROM avec 256 octets de mask ROM et un port I/O 4 bits ; le contenu de la ROM et la configuration du port I/O sont fixés à la fabrication
  • Le 4002 est une puce RAM avec 320 bits de DRAM, un circuit de refresh et un port output-only 4 bits
    • Un bank de RAM peut être constitué de quatre 4002
    • Chaque bank de RAM contient 256 nibbles directement adressables, ainsi que 64 status nibbles accessibles séparément
  • Le 4289 est un contrôleur ROM combinant les fonctions des 4008 et 4009, ce qui permet de connecter relativement facilement le 4004 à de l’EEPROM/EPROM 5 V
  • L’accès mémoire nécessite une procédure en plusieurs étapes : sélection du bank, chargement de l’adresse dans une paire de registres, envoi de l’adresse sur le bus avec SRC, puis exécution de RDM/WRM
    • Les status nibbles se sont révélés utiles pour accéder rapidement aux données fréquemment utilisées et ont contribué à augmenter d’environ 30 % la vitesse de l’émulateur MIPS

Préparation de la carte de développement et de l’émulateur

  • La carte de développement utilisée pour la validation initiale se compose d’un clock generator 4201, d’un CPU 4004, d’une RAM 4002-1, d’un contrôleur ROM 4289 et d’un ATMEGA48 faisant office de ROM
  • L’alimentation part de 5 V, puis le pôle positif d’un convertisseur boost isolé 5 V vers 10 V est relié à la masse afin de produire une alimentation -10 V fournie aux puces MCS-04
  • Le premier programme 4004 était un code faisant clignoter une LED connectée à l’output pin 0 du 4002, et il a fonctionné après augmentation de la limitation de courant
  • Avant de fabriquer la carte réelle, un émulateur 4004 nommé u4004 a été écrit
    • Il émule non seulement le cœur 4004, mais aussi une carte SD virtuelle, un UART SPI, un VFD, l’agencement des 4002 et même les LED de PC
    • Il servait à valider en amont l’état des broches SPI et le fonctionnement des périphériques, difficiles à déboguer sur le matériel réel

Émuler MIPS au lieu d’exécuter Linux directement

  • Linux ne peut pas s’exécuter directement sur le 4004
    • Il n’existe pas de compilateur C ciblant le 4004, et il a été jugé difficile de porter directement le noyau Linux en raison des contraintes de l’architecture
    • L’imbrication des appels, les espaces d’adressage ROM/RAM et les limites du calcul 4 bits empêchent l’exécution directe
  • À la place, un émulateur MIPS R3000 a été écrit sur le 4004, et Linux pour DECstation 2100 démarre par-dessus
  • MIPS a été choisi car il était plus facile à émuler dans l’espace de code du 4004 que les autres candidats
    • ARM comporte de nombreux shift operands arbitraires
    • RISC-V a été jugé lent à cause de son mode d’adressage
    • x86 pourrait dépasser 4 Ko rien que pour le décodage des instructions
    • PPC est trop complexe
  • L’objectif initial était de faire tenir tout l’émulateur dans les 4 Ko de ROM que le 4004 peut adresser de base

Contournements dans l’implémentation de l’émulateur MIPS

  • Le seul décodage des instructions MIPS consomme déjà beaucoup d’espace ROM
    • La dispatch table des 64 opcodes de premier niveau nécessite 128 octets
    • En incluant les sous-tables supplémentaires, le décodage principal nécessitait 359 octets
  • Les 32 registres 32 bits du MIPS représentent 1024 bits, soit 256 nibbles du point de vue du 4004, et occupent un bank de RAM
  • Le TLB MIPS compte normalement 64 entries, mais Linux n’exigeant pas exactement 64 entrées, il a été réduit à 16 entries
    • Le nombre d’entrées du TLB a été conçu pour pouvoir aussi être configuré à 4, 8, 12 ou 16
  • Comme le 4004 n’a pas d’opérations logiques, AND/OR/XOR/NOR sont implémentées avec des additions, du carry, des shifts et des boucles
    • Plus tard, une fois l’espace ROM augmenté, elles ont été optimisées avec une table de correspondance de 256 entries
  • Les shifts devaient eux aussi être implémentés uniquement avec l’instruction de rotation du 4004 passant par le carry 1 bit, puis ont été améliorés par copie au niveau nibble et jusqu’à 3 bit shifts
  • Le traitement du registre $zero du MIPS exploite le comportement circular return stack du 4004 pour économiser de l’espace ROM
    • Lorsque la destination est $zero, le code ne fait pas de return et passe au traitement de l’instruction suivante, ce qui économise 3 octets et 3 cycles par callsite

Banking de ROM et amélioration des performances

  • 4 Ko de ROM ne suffisaient pas à inclure le code gérant la carte SD, la PSRAM, le VFD, l’UART, etc. ; une ROM de 8 Ko divisée en deux banks a donc été utilisée
  • Le changement de bank ROM est contrôlé par une output pin du 4002, avec des veneers placés pour les call/return entre banks
  • L’augmentation de l’espace ROM a rendu possibles des optimisations de performances
    • AND/OR/XOR sont chacune implémentées par une table de correspondance de 256 entries
    • L’utilisation d’une table de correspondance de multiplication de nibbles rend la multiplication 8 fois plus rapide que l’ancienne implémentation bit par bit
  • La table de correspondance des opérations logiques exploite le fait que, lorsque l’instruction JIN du 4004 se trouve à la fin d’une page ROM, elle saute par rapport à la page suivante
  • La table de multiplication est implémentée en combinant la lecture de données byte dans la ROM avec FIN et l’évitement du traitement de l’entry 0

Configuration matérielle finale

  • La carte finale a été conçue comme une carte artistique principalement traversante, avec une esthétique des années 1970
    • Elle comprend de larges pistes à angle droit, aucune via, des trous pour fixation murale et un afficheur VFD
  • Les principaux composants sont les suivants
    • CPU 4004 ou 4040
    • générateur d’horloge 4201
    • puces RAM 4002
    • contrôleur ROM 4289
    • EEPROM
    • 1 à 2 SPI PSRAM
    • emplacement pour carte SD
    • UART SPI SC16IS741A
    • VFD 40x2
    • 32 LED d’affichage du PC
  • La SPI PSRAM sert de RAM MIPS virtuelle
    • La première PSRAM doit avoir au moins 4 Mo, car le noyau doit y être chargé de manière contiguë
    • La deuxième PSRAM peut rester vide ou être montée avec une taille arbitraire d’au moins 128 Ko
  • Le VFD utilisé est un Futaba M402SD10FJ, et il a été indiqué que le Noritake CU40025-UW6J était compatible
  • L’UART a été choisi sous la forme du composant CMS SC16IS741A, en raison des contraintes de contrôle de flux du MAX3100, candidat UART SPI en traversant

Alimentation et translation de niveau

  • Les composants MCS-04 utilisent des tensions atypiques de la famille -15 V et une logique inversée
    • Au niveau système, il est plus simple de raisonner avec une alimentation -10 V et +5 V
  • La carte reçoit du +5 V via un connecteur USB-C en bord de carte, et génère également du +3,3 V et du -10 V
  • Le régulateur abaisseur +3,3 V est basé sur un LM2574
  • L’alimentation -10 V utilisait un MAX764 dans la première révision, mais celui-ci ne fournissant pas assez de courant, elle a été remplacée par une configuration avec MAX774, FET externe, grosse diode et grosse inductance
    • Au final, elle fournit plus de 700 mA à -10 V, avec une ondulation inférieure à 200 mV
  • La translation de niveau des sorties du 4002 vers le domaine 3,3 V a été difficile, et a été résolue par une combinaison de pulldown 10 kΩ, résistance 2,7 kΩ, clamp TVS et diviseur résistif

Outils de débogage et défaut réel

  • Comme le 4004 n’a pas de fonction de débogage intégrée, le bus MCS-04 a été capturé longuement avec Saleae Logic
  • Un décodeur de bus MCS-04 a été écrit pour analyser l’état du bus, l’adresse ROM, la valeur lue en ROM, le désassemblage et les valeurs de lecture/écriture RAM/I/O
    • Il a ensuite été contribué à Saleae et inclus dans le logiciel Saleae standard
  • Sur la carte en révision 1.1, les caractères en sortie étaient rarement corrompus
    • Par exemple, i apparaissait comme h, ou C comme B, avec le bit de poids faible qui disparaissait
  • L’analyse a montré que, pendant le memcpy() du kernel, le bit du bas d’un nibble donné tombait parfois de 1 à 0 dans la puce 4002 où était stocké le $t1 émulé
  • Après remplacement de ce 4002, l’affichage texte est redevenu normal

Chemin de démarrage

  • Le firmware commence par sonder le nombre de puces mémoire dans la troisième banque RAM afin de déterminer le nombre d’entrées TLB
  • Il initialise ensuite le VFD, l’UART et la carte SD
    • En cas d’échec d’initialisation de la carte SD, il affiche "Failed to init SD card. Halting here and now!"
    • Cette chaîne est l’unique chaîne de tout le firmware
  • Le firmware ne contient pas de ROM virtuelle : il charge le premier secteur de la carte SD à l’adresse RAM 0x80000000, puis saute dessus
  • Le loader de 446 octets du premier secteur cherche dans la table de partitions une partition de type 0xBB, la lit à 0x80001000, puis saute dessus
  • Le deuxième loader fait environ 14 Ko et est écrit en C
    • Il monte la partition active en FAT12/16/32
    • Il analyse vmlinux comme ELF, le charge en RAM et saute vers son point d’entrée
    • Il transmet le type de machine, une valeur magique, le mapping de la RAM et une table de callbacks pour l’affichage early console

Accès disque et carte SD

  • L’accès disque utilise le même pilote disque paravirtualisé PVD que le projet LinuxCard
  • Au lieu d’émuler en assembleur 4004 une puce SII SCSI et un disque SCSI, des hypercalls de lecture/écriture de secteurs fonctionnent comme du DMA du point de vue du MIPS virtuel
  • La RAM totale de la carte Linux/4004 est de 440 octets en incluant les nibbles de statut, ou 352 octets sans eux
    • L’état des registres MIPS et la TLB occupent chacun une grande part, ce qui ne laisse pas de place pour un buffer de secteur SD de 512 octets
  • Les données de secteur SD ne sont pas placées en RAM 4004 : elles sont lues directement vers la PSRAM, ou écrites depuis la PSRAM vers la SD, via les bus SPI séparés de la carte SD et de la PSRAM
  • Lire ou écrire un secteur SD prend un peu plus d’une seconde
  • Les exigences de timing de l’initialisation ACMD41 de la spécification SD ne pouvaient pas être respectées avec un SPI bit-bang, mais les cartes SD testées s’initialisaient quand même à 5 kHz et avec des intervalles d’au moins 200 ms

Vitesse d’exécution et résultats d’optimisation

  • Après émulation de la vraie carte SD et de la SPI PSRAM, l’estimation initiale du temps de démarrage était de 8,9 jours avec un 4004 à 740 kHz
  • Les principaux résultats d’optimisation sont les suivants
    • opérations logiques et table de correspondance de multiplication : 8,4 jours
    • déroulage des boucles d’envoi/réception de nibbles PSRAM : 7,25 jours
    • copie mémoire spécialisée et déroulage de boucles : 6,63 jours
    • suppression de la zone de stockage de l’instruction courante et suivi de liveness : 6,50 jours
    • amélioration des shifts : 6,19 jours
    • déroulage de la boucle d’envoi d’adresse PSRAM : 6,01 jours
    • réduction de la configuration du kernel Linux, console factice 1x1 et utilisation d’un tiny init : 5,33 jours
    • suppression de la prise en charge des block devices de 2 To et plus, et désactivation de la fonctionnalité ext4 huge_files : 4,81 jours
    • fast path dédié à l’instruction fetch : 4,76 jours
  • Un démarrage en 4,76 jours correspond à une machine MIPS d’environ 70 Hz avec un 4004 à 740 kHz
  • La carte fabriquée utilise le 4201 en mode divide-by-7 et un quartz de 5,5296 MHz, ce qui l’overclocke à 790 kHz
  • Le mix d’instructions 4004 de la carte Linux/4004 est de 8,8 % d’instructions à 16 cycles et 91,2 % d’instructions à 8 cycles, pour une vitesse effective de 90 640 instructions/s
  • L’interruption de timer virtuelle est à 16 Hz, et une IRQ est envoyée toutes les 65 536 instructions virtuelles, si bien que le CPU virtuel se voit comme cadencé à 1,05 MHz
    • Le vrai guest MIPS émulé atteint environ 70 Hz à 740 kHz, et environ 74,73 Hz à 790 kHz
    • Le temps est dilaté d’un facteur 14 030, de sorte qu’une seconde virtuelle correspond à environ 3 h 54 min dans le monde réel

Configuration de Linux et expérience d’utilisation

  • Le kernel Linux a été réduit à environ 2,5 Mo en supprimant les sous-systèmes, filesystems, TCP/IP et autres options inutiles
  • Utiliser seulement init=/bin/sh laisse le système sans session, $PATH, /proc, /sys, etc. ; un tiny init, /sbin/uMIPSinit, a donc été écrit
    • Il monte /proc et /sys
    • Il configure le hostname et $PATH
    • Il relance sh chaque fois qu’il se termine
  • Avec seulement 4,5 Mo de RAM, par exemple une puce de 4 Mo + une puce de 512 Ko, il est possible de démarrer jusqu’au prompt du shell sans swap
  • En activant le swap, il est possible de compiler les sources du kernel sur l’appareil lui-même
    • La compilation des sources du kernel devrait prendre plusieurs années
    • Grâce au journal ext4, le plan est de pouvoir récupérer le filesystem après une coupure d’alimentation au redémarrage, puis de reprendre la compilation

Objectif en tant que carte artistique

  • Ce projet a dès le départ eu en partie un objectif artistique
  • La carte a été conçue pour pouvoir être accrochée au mur, avec un VFD, un layout PCB rétro et des LED PC
  • Un programme inclus dessine l’ensemble de Mandelbrot en mode texte sur le VFD et le port série
    • La version en floating point /root/mandelbrot nécessite que Linux émule les opérations en virgule flottante, si bien qu’il lui faut environ 30 jours pour dessiner une image de 13 lignes x 40 colonnes
    • La version integer-only /root/mandelbrot_nofp se termine en moins de 9 heures

Coût des composants et reproductibilité

  • Comme l’un des objectifs importants était de permettre à d’autres de reproduire le projet, le 4265, difficile à trouver, a été évité
  • Le 4201 a été choisi parce qu’il est plus simple qu’un circuit d’horloge de remplacement, et le 4289 parce qu’il est plus facile à trouver que la combinaison 4008+4009
  • La carte a été conçue pour pouvoir accueillir aussi un 4040 à la place du 4004 ; les fonctions supplémentaires du 4040 ne sont pas utilisées, ce qui préserve la compatibilité avec le 4004
  • Pour le TLB, on peut monter seulement 1, 2, 3 ou 4 puces 4002, pour l’utiliser comme TLB de respectivement 4, 8, 12 ou 16 entrées
    • Avec moins d’entrées TLB, les performances diminuent
    • Cette bank gère aussi les 16 bits hauts des LED d’affichage du PC ; si elle n’est que partiellement peuplée, certaines LED ne fonctionneront pas
  • Les composants des années 1970 sont chers
    • Le 4004 coûte environ 250 $
    • Le 4040 coûte environ 60 $
    • Le 4201 coûte environ 50 $
    • Le 4002-1 coûte environ 7 $
    • Le 4002-2 coûte environ 25 $
    • Le 4289 coûte environ 70 $
  • Les composants modernes sont relativement bon marché ; le VFD SPI peut être difficile à trouver, mais un exemplaire a été obtenu sur eBay pour 15 $
  • Une configuration sans VFD, avec une interaction uniquement via le port série, est également prise en charge

Processus de production de la vidéo

  • La scène de démarrage réelle a été transformée en vidéo à partir de photos prises pendant environ 9 jours
  • Prendre une photo 1920x1080 toutes les 2 secondes génère environ 1,76 Go par heure ; 9 jours de prise de vue représentent environ 379 Go et près de 388 000 fichiers
  • Les appareils Android ont rencontré des problèmes de blocage ou de surchauffe pendant les longues prises de vue ; l’iPhone SE3 était stable pour la capture elle-même, mais posait des problèmes d’espace de stockage et de transfert des photos
  • Finalement, un iPhone 12 Pro Max de 512 Go a été utilisé pour filmer toute la séquence en continu ; il a ensuite été monté sous Linux avec ifuse, puis environ 400 000 fichiers ont été copiés avec cp -Rvf en plus de 10 heures
  • La vidéo finale a été produite avec des commandes ffmpeg, et les passages ennuyeux ont été traités avec une accélération variable
    • La vitesse de lecture varie de 5 FPS, soit 10x le temps réel, à 960 FPS, soit 1920x le temps réel
    • Une version séparée non montée est en capture à 0,5 FPS et lecture à 60 FPS, soit une vitesse de 120x le temps réel

Documents publiés et licence

  • L’image disque pour carte SD est fournie en téléchargement séparé
  • Le téléchargement principal comprend les éléments suivants
    • L’analyseur de bus MCS-04 pour le logiciel Saleae
    • Le code source de l’émulateur DECstation 2100 i4004
    • Le code source du MBR MIPS et du bootloader de second niveau
    • La configuration du kernel et les informations de version
    • Le code source de l’émulateur u4004 pour la carte Linux/4004
  • La licence est gratuite pour un usage non commercial ; tout usage commercial nécessite une licence séparée
  • Pour toute utilisation, l’auteur original doit être crédité dans les formes source et binaire

À lire aussi

2 commentaires

 
y15un 2024-09-21

L’auteur du billet original, c’est bien ce type qui a récemment été escorté hors de scène à la Defcon à cause d’une histoire liée aux badges. Je ne prendrai le parti de personne, mais il faut reconnaître qu’il a un niveau vraiment impressionnant.
 
GN⁺ 2024-09-21
Avis de Hacker News

  • Waouh, je pensais que NetBSD moderne était lent sur un m68030 à 15 MHz, bus mémoire 16 bits, 10 Mo de RAM, mais là c’est vraiment délirant
    Ça montre bien qu’à la fin des années 80 et au début des années 90, quand les ordinateurs ont commencé à avoir du stockage permanent, un espace d’adressage ouvert et une MMU, on était en fait arrivé à l’informatique moderne
    Un Amiga 3000 ou un ordinateur i80486 peut exécuter les mêmes choses qu’un ordinateur moderne ; aujourd’hui on les exécute beaucoup plus vite, et on a aussi des choses comme des GPU qui n’existaient pas à l’époque, mais fonctionnellement il n’y a pas une grande différence
    J’aime bien la façon dont Dmitry montre à quel point on peut définir le mot fonctionnel de manière souple

    • Je ne sais pas si c’était aussi le cas aux États-Unis, mais en URSS dans les années 70 et 80, les échecs par correspondance étaient très populaires
      On s’envoyait vraiment les coups par courrier postal, et une partie pouvait durer des mois, voire des années
      Le temps que la réponse arrive, on pouvait avoir oublié sa stratégie initiale, ce qui ajoutait un autre niveau de difficulté aux échecs ; ce projet, c’est en fait du Linux par correspondance
      Le temps que la sortie d’une commande arrive, on peut avoir oublié pourquoi on l’avait lancée
    • 15 MHz m68030, bus mémoire 16 bits, 10 Mo de RAM : ce ne serait pas un Mac LC II, par hasard ? :)
      En réalité, ce n’était pas la fin des années 80 ou le début des années 90 : c’était déjà possible vers la fin des années 1960
      Porter Linux sur un IBM Model 67 [1] me semble possible, et comme GCC peut déjà cibler ce jeu d’instructions, ce serait peut-être même facile
      La MMU est suffisante, et la limite de 2 Mo maximum de mémoire à tores rapide serait serrée, mais ce serait dans la même catégorie que cette machine 68030, juste un peu plus lent
      La virtualisation complète et les frontières mémoire/E/S imposées par le matériel ont également été inventées très tôt, mais ces fonctionnalités ont mis du temps à descendre vers les mini-ordinateurs et les micro-ordinateurs, et encore bien plus longtemps avant d’être exploitées par les logiciels grand public
      [1] https://en.wikipedia.org/wiki/IBM_System/360_Model_67
    • C’est essentiellement le concept de complétude de Turing
      N’importe quel système Turing-complet peut exécuter n’importe quoi ; ce sera peut-être très lent, mais ça s’exécute
      Avec assez de temps, on pourrait aussi faire tourner ChatGPT sur un 4004
    • Le multicœur est une différence fonctionnelle assez importante
      C’est un peu comme attacher une voiture à une roue : ça ajoute trois roues de plus

  • Le badge participant de la Hackaday Supercon 2002 (https://hackaday.com/2022/10/12/the-2022-supercon-badge-is-a...) implémentait un CPU 4 bits virtuel et un panneau de contrôle permettant de saisir directement des instructions, de les exécuter et de les exécuter pas à pas
    Le panneau de contrôle avait un écran permettant de voir une page mémoire bit par bit, et c’était vraiment amusant d’y implémenter un shoot ’em up spatial
    Comparer l’architecture Voya4 au 4004 était aussi intéressant : il y avait des compromis similaires, mais Voya4 bénéficie de 50 ans d’expérience en matière de jeux d’instructions CPU
    Cela dit, l’approche de dimitygr ne fonctionnerait pas sur ce badge, car la mémoire et la RAM sont toutes deux intégrées au PIC24 qui implémente l’émulateur CPU
    À titre de référence, des CPU 4 bits sont encore fabriqués et utilisés. Beaucoup de télécommandes infrarouges produites en masse sont programmées avec des MCU 4 bits. La fiche technique est ici : https://www.emmicroelectronic.com/sites/default/files/produc...

    • C’est 2022

  • Quand on me demande si l’on peut faire tourner quelque chose sur une machine trop peu performante, je citais souvent l’exemple AVR ; maintenant j’ai un nouvel exemple à mettre en lien
    Vu la fréquence et la consommation, je me demande quelle quantité de RF ça émet, et si on peut le détecter et le décoder dans le waterfall d’un SDR
    Je suis encore en train de lire, mais à ce stade je vois le mot « soubroutine », qui semble être une faute de frappe

  • Waouh, ce projet n’a pas dû être bon marché. Merci aux collectionneurs sur eBay
    Et c’est probablement la seule situation où j’aurais choisi un LCD plutôt qu’un VFD
    Si on lance une compilation de plusieurs années, le VFD serait sans doute complètement ravagé par le burn-in à la fin

    • Personnellement, je trouve que c’est un projet qui mériterait un doctorat honoris causa
      Malheureusement, les universitaires ne semblent pas beaucoup lire HN

  • Waouh, impressionnant
    En regardant les bits hauts du PC, on voit ce qui est en cours d’exécution
    P.-S. : cela dit, c’est quand même plus rapide que de charger un noyau via une ISO virtuelle sur l’IPMI pourri d’un serveur à l’autre bout d’Internet ;D

    • Pendant le boot, en regardant les LED et en lançant nm sur vmlinux, on peut facilement faire la correspondance avec les fonctions du noyau
      Une fois arrivé dans l’espace utilisateur, on peut aussi distinguer le binaire principal — bien en dessous de 0x01000000 — des bibliothèques partagées, chargées à des adresses élevées autour de 0x77000000
    • Cette histoire de charger un noyau via une ISO virtuelle sur l’IPMI pourri d’un serveur à travers Internet me rappelle la fois où j’ai essayé de démarrer un serveur lame Dell M1000e avec une ISO hébergée en NFS sur un Raspberry Pi
      Le démarrage comme l’exécution étaient atrocement lents

  • C’était un article vraiment intéressant
    J’avais un peu lu sur le 4004, donc je savais que c’était une puce bizarre, mais le degré d’ésotérisme dépasse l’imagination
    Maintenant j’ai envie de voir ce qu’on pourrait faire comme CPU avec le même nombre de transistors
    Ce n’est pas tellement moins qu’un 6502, et en 8 bits ce serait beaucoup plus facile à programmer

    • Si on le fabrique avec des transistors, je porterai mon émulateur MIPS dessus :)

  • Le tournage de la vidéo a pris 9 jours, avec 4 heures par seconde d’émulation
    Et je me demande aussi pourquoi il utilise Windows 95

    • C’est Windows 2000
      Pour la vidéo, il me fallait un ordinateur portable avec un vrai port série, pas en USB
      Celui-ci correspondait aux critères et coûtait 20 dollars sur eBay
      Personnellement, je trouve que Windows 2000 est le plus beau des Windows, donc je l’ai installé pour la vidéo de démo
    • Désolé pour ce pinaillage, mais le portable dans la vidéo ressemble à Windows 2000

  • Vraiment impressionnant
    J’aimerais avoir assez progressé pour comprendre la majeure partie de ce projet, mais pour l’instant, avec mes compétences limitées en informatique, c’était trop difficile
    Le passage marquant que j’ai tout de même pu comprendre entièrement, c’est « Section 14.b & 14.c - Getting the data... »
    Il n’a fallu que 400 000 fichiers, environ 275 photos par jour pendant 4 ans
    Nous vivons vraiment une époque étrange : malgré l’abondance de puissance de traitement, de stockage et de réseau, les applis de synchronisation de médias qui semblent les plus utilisées se bloquent ou synchronisent lentement, AirDrop échoue, et il n’existe même pas de fonction UI « tout sélectionner » :)

    • Je me demande si Dmitry a envisagé des outils de synchronisation comme MobiusSync ou Syncthing pour copier en continu les photos vers le PC dès qu’il les prenait

  • Il faudrait quelque chose comme un prix Nobel pour ce genre de choses

    • Ce qui s’en rapprocherait le plus serait sans doute l’Ig Nobel Prize : https://en.wikipedia.org/wiki/Ig_Nobel_Prize
    • Dans le domaine de l’informatique, il existe l’équivalent, le Turing Award
      On pourrait y ajouter une catégorie récompensant les applications bizarres et singulières de l’informatique

  • Dans la section « Why MIPS? », il est dit que « certains sont forcément lents à cause de modes d’adressage médiocres (RISCV) » ; qu’est-ce qui cloche avec le mode d’adressage de RISC-V ?

    • En réalité, c’est davantage un problème de format d’instruction que de mode d’adressage
      Dans certaines instructions RISC-V, les bits des valeurs immédiates ne sont pas stockés de manière contiguë
      Dans les instructions MIPS, les bits des valeurs pour l’addition immédiate, le chargement de constantes, les branchements, etc., sont toujours stockés dans l’ordre
      Dans RISC-V, les bits sont parfois mélangés
      Par exemple, pour un branchement inconditionnel, les bits de l’offset de destination sont stockés dans l’ordre bit 19, bits 9-0, bit 10, bits 18-11
      En matériel, il suffit de connecter correctement les fils, donc le coût de réarrangement est quasiment nul ; en logiciel, en revanche, il faut beaucoup de manipulations de bits pour remettre tout cela en ordre
      Si RISC-V procède ainsi, c’est pour simplifier la conception matérielle
    • Si l’objectif n’est pas de l’émuler sur du matériel aux performances extrêmement faibles, ce ne sera sans doute pas vraiment un problème