picoZ80

Le picoZ80 poursuit le concept du tranZPUter, en remplaçant un Z80 physique dans un ordinateur hôte ou industriel par un processeur plus rapide, davantage de mémoire, des périphériques virtuels, une connectivité réseau (WiFi, BT), un chargement rapide d'applications depuis une carte SD et une gestion par WiFi. Il s'agit d'un circuit imprimé sur mesure conçu pour s'insérer directement dans le support CPU DIP-40 du Z80 de tout ordinateur historique à base de Z80. Plutôt qu'un processeur Z80 discret, la carte embarque un microcontrôleur RP2350B — un dispositif double cœur Cortex-M33 à 150 MHz pouvant fonctionner jusqu'à 300 MHz — dont les machines à états d'entrées/sorties programmables (PIO) prennent le contrôle total et cycle-exact des bus d'adresses, de données et de contrôle du Z80. Le picoZ80 n'est pas un simple adaptateur d'émulation. Chaque transaction bus est gérée en temps réel par les moteurs PIO du RP2350, offrant au système hôte exactement le même timing bus qu'un véritable Z80. Parallèlement, le second cœur du RP2350 et son abondante SRAM interne, combinés à 8 Mo de PSRAM externe et 16 Mo de Flash, permettent de superposer une gamme quasi illimitée de capacités à l'interface Z80 brute — incluant l'exécution accélérée, la mémoire virtualisée, la pagination ROM, les lecteurs de disques virtuels et l'émulation complète de personnalités machine. Un co-processeur ESP32 fournit la connectivité WiFi et Bluetooth, le stockage de masse sur carte SD et une interface de gestion accessible par navigateur. Toute la configuration est pilotée par un unique fichier config.json lisible par l'humain, stocké sur la carte SD, ce qui signifie qu'aucune recompilation n'est nécessaire pour reconfigurer la carte mémoire, les images ROM ou la sélection des pilotes. Le picoZ80 a été démontré en fonctionnement dans plusieurs machines Sharp MZ. Un ensemble de personnalités est en cours de développement pour ces machines, et à terme pour d'autres systèmes Z80, afin de fournir des fonctionnalités très attendues telles que la RAM/ROM paginée, l'émulation de lecteur de disquettes, l'émulation de QuickDisk, le ROM Filing System, le TranZPUter Filing System, tous capables de fonctionner simultanément. La configuration est entièrement pilotée par JSON ; l'ajout du support d'un nouvel hôte Z80 se résume à l'édition d'un fichier de configuration et, lorsqu'un nouveau comportement d'E/S est nécessaire, à l'ajout d'un petit pilote C dans la base de code.

• Remplacement direct du Z80
  - s'installe dans n'importe quel support DIP-40 de Z80. L'hôte voit un timing bus Z80 normal en permanence.
• Interface Bus PIO cycle-exact
  - trois machines à états PIO du RP2350 gèrent simultanément les signaux d'adresse, de données et de contrôle à la pleine vitesse du bus Z80.
• Grand espace mémoire
  - 8 Mo de PSRAM organisés en 64 banques × 64 Ko, offrant un total de 4 Mo d'espace d'adressage paginé accessible par contexte CPU.
• Pagination ROM/RAM
  - les blocs mémoire sont configurables avec une granularité de 512 octets et peuvent être mappés en ROM, RAM, mémoire physique de l'hôte ou gestionnaires de fonctions virtuelles.
• Cadre de périphériques virtuels
  - tout bloc mémoire de 512 octets ou plage de ports d'E/S peut être adossé à une fonction C, permettant des périphériques entièrement virtualisés.
• Personnalités Machine
  - le firmware Z80 peut être configuré via un fichier JSON pour fonctionner dans n'importe quel hôte Z80. Des personnalités sont disponibles pour plusieurs machines Sharp MZ (MZ-80K, MZ-700, MZ-800, MZ-80A, MZ-80B, MZ-2000, MZ-2200, MZ-2500, MZ-1500), l'Amstrad PCW-9512 et le Tatung Einstein TC-01, plus une personnalité vanilla OpenZ80 pour les expérimentateurs qui intègrent le picoZ80 dans une carte de leur propre conception ou dans une machine sans pilote dédié. Des variantes de compilation ciblées (BaseZ80, SharpZ80, AmstradZ80, TatungZ80, OpenZ80) permettent un firmware spécifique à chaque machine pour réduire la taille du binaire.
• Émulation de disquette et QuickDisk
  - contrôleur de disquettes compatible WD1773 et émulation du lecteur Sharp QuickDisk, utilisant des images DSK/RAW/D88 sur la carte SD.
• WiFi et gestion web
  - l'ESP32 embarqué fournit une interface web Bootstrap de sept pages pour la configuration, la gestion de fichiers, les mises à jour firmware OTA et la sélection de personnalité.
• Shell de débogage ICE
  - un débogueur ICE de 49 commandes accessible via USB CDC série fournit des points d'arrêt (8 simultanés), l'exécution pas à pas, la trace d'exécution, l'inspection des registres Z80, la lecture/écriture mémoire et E/S, un désassembleur et assembleur Z80 intégrés, l'imagerie disque, les diagnostics bus et la surveillance de l'état du système.
• Double partition firmware
  - deux emplacements firmware indépendants de 5 Mo permettent des mises à jour OTA sécurisées ; la partition active est sélectionnée depuis l'interface web ou le bootloader.
• Mise à jour firmware USB
  - le bootloader expose un pont USB pour le flashage du firmware sans nécessiter de débogueur matériel.

X (Twitter) project preview — picoZ80 in action

Le circuit imprimé du picoZ80 (révision 2.5) est une carte compacte multicouche conçue pour tenir dans l'empreinte physique du boîtier DIP-40 du Z80 et dans l'espace disponible à l'intérieur des boîtiers typiques d'ordinateurs rétro. Toute la logique fonctionne en 3,3 V ; les considérations de translation de niveau et de courant d'attaque pour le bus 5 V de l'hôte sont traitées dans la conception du schéma. La carte intègre cinq sous-systèmes sur un seul PCB : le processeur RP2350B, l'interface bus Z80, le co-processeur ESP32, l'alimentation et un hub USB.

• RP2350B (Cortex-M33 double cœur)
  - processeur principal, fonctionnant jusqu'à 300 MHz. Exécute la boucle chaude d'émulation Z80 sur le Core 1 et gère les E/S fichier, l'USB et le relais ESP32 sur le Core 0. 512 Ko de SRAM interne. La variante RP2350B (par opposition au RP2350A) fournit les 48 broches GPIO nécessaires pour le bus Z80 complet.
• 16 Mo SPI Flash
  - stocke le bootloader, deux emplacements firmware applicatifs, deux emplacements de configuration et une partition de configuration générale. L'agencement adressable total s'étend de 0x10000000 à 0x11000000.
• 8 Mo PSRAM (SPI)
  - RAM pseudo-statique externe fournissant 64 banques × 64 Ko d'espace d'adressage paginé pour le CPU émulé. Connectée au RP2350 via un périphérique SPI dédié.
• Co-processeur ESP32
  - fournit le WiFi (802.11 b/g/n, modes AP et client), le Bluetooth, le lecteur de carte SD et le serveur web. Communique avec le RP2350 via un protocole IPC binaire sur FSPI à 50 MHz (avec vérification d'intégrité CRC32, canaux DMA pré-alloués et transferts de secteurs en rafale jusqu'à 16 secteurs par transaction) et un UART à 460,8 kbaud pour les commandes de contrôle.
• Emplacement carte SD
  - FAT32, géré par l'ESP32. Stocke le config.json, les images ROM, les images disque (DSK, QuickDisk, RAM disk) et les arborescences du système de fichiers TZFS/RFS.
• Hub USB
  - hub USB embarqué pour la connectivité hôte et le pont de mise à jour firmware.
• Alimentation 3,3 V
  - convertisseur buck efficace alimenté par le 5 V présent sur la broche VCC du support Z80.

Le matériel du picoZ80 est conçu sous KiCad. La révision actuelle est la v2.5. Les fichiers de schéma et de routage du PCB sont disponibles dans le dépôt du projet sous kicad/PICOZ80/. Le schéma est divisé en cinq feuilles :

Toutes les affectations GPIO du RP2350B, le découplage, l'oscillateur à quartz 12 MHz, les connexions Flash 16 Mo et PSRAM 8 Mo. Le boîtier QFN-80 du RP2350B est choisi spécifiquement pour ses 48 GPIO — le bus Z80 complet (16 adresses + 8 données + 12 signaux de contrôle) plus les signaux SPI/UART de l'ESP32 et les signaux USB consomment pratiquement chaque broche disponible.

Module ESP32-S3-PICO-1, interface carte SD (SPI), antenne intégrée, connecteur de débogage et lignes de communication inter-processeurs (bus FSPI à 50 MHz, UART à 460,8 kbaud). Les signaux de la carte SD et les signaux SPI/UART inter-processeurs sont clairement séparés sur cette feuille.

Les connexions du support DIP 40 broches et le réseau de résistances de l'interface bus. Les lignes d'adresse A0–A15, les lignes de données D0–D7 et tous les signaux de contrôle du Z80 (MREQ, IORQ, RD, WR, M1, RFSH, BUSREQ, BUSACK, HALT, INT, NMI, WAIT, CLK, RESET) sont routés via des résistances série vers des broches GPIO dédiées du RP2350, surveillées par les machines à états PIO.

Convertisseur buck synchrone TLV62590BV 5 V vers 3,3 V avec condensateurs de filtrage en entrée/sortie. Le convertisseur doit alimenter la charge combinée du RP2350B à 300 MHz, de la PSRAM 8 Mo, de l'ESP32 et du hub USB à partir de l'unique broche VCC 5 V du support DIP-40 du Z80.

Contrôleur hub USB CH334F avec connecteur Mini-B, quartz 12 MHz et ports en aval routés vers le RP2350 (pour le pont de mise à jour firmware) et l'ESP32 (pour l'accès USB direct sur les révisions de carte plus récentes).

Le PCB a été conçu aussi petit que possible pour accueillir tous les circuits nécessaires et tenir dans les limites d'un support DIP-40. Les composants les plus petits pouvant être assemblés manuellement ont été utilisés, c'est-à-dire des composants passifs 0402/0603 et un espacement de 0,5 mm entre les broches des CI, afin de réduire la taille globale, et un empilage 6 couches a été sélectionné pour accueillir tous les composants nécessaires. Les conceptions initiales, v2.0 et v2.1, ont été assemblées manuellement avec application ponctuelle de soudure, placement manuel des composants et une station de reprise à air chaud. La version 2.2 a été assemblée manuellement avec un pochoir et un four de refusion. Les versions v2.3a et v2.5 ont été assemblées en fabrication.

Cliquez ici pour afficher un diagramme interactif de placement des composants du PCB et la nomenclature (Bill of Materials).

Les deux cœurs Cortex-M33 du RP2350B ont des responsabilités complètement séparées, communiquant via une file de messages inter-cœurs (queue_t). Le Core 0 gère toutes les tâches non temps réel : pont USB et CDC série, coordination des mises à jour firmware, E/S fichier (relayées vers l'ESP32 via UART), dispatch des commandes ESP32 (changements d'images disquette/QuickDisk, rechargement de configuration, requêtes de version), gestion des partitions et supervision du watchdog. Un timer watchdog matériel surveille la séquence de démarrage et la boucle principale, avec un suivi de la progression du démarrage via les registres scratch du RP2350 qui survivent aux réinitialisations watchdog. Des gestionnaires de fautes complets capturent l'état des registres et les informations de diagnostic en PSRAM, permettant une analyse post-réinitialisation des fautes matérielles, fautes bus et fautes d'utilisation. Un journal PSRAM persistant (plogf) capture les messages critiques du démarrage avant que l'USB ne soit disponible, complétant le système de sortie de débogage standard debugf. Le Core 1 exécute exclusivement la boucle chaude d'émulation CPU. Il dessert les FIFO PIO pour traiter les transactions bus Z80, résout chaque adresse selon la carte mémoire, et soit transmet la transaction au matériel physique de l'hôte (type PHYSICAL), la dessert depuis la PSRAM (types RAM/ROM), soit appelle une fonction de gestionnaire de périphérique virtuel (type FUNC). La latence sur ce chemin est minimisée en gardant la boucle interne en SRAM et en utilisant la SRAM de 512 Ko du RP2350 comme table de consultation rapide pour les pointeurs de blocs mémoire.

L'interface bus Z80 est implémentée entièrement en assembleur PIO du RP2350 (z80.pio). Le RP2350 fournit trois blocs PIO (PIO 0, PIO 1, PIO 2), chacun avec quatre machines à états. Le firmware Z80 utilise les trois blocs PIO :

• PIO 0 — Bus d'adresses et de données (GPIO 0–23)
  - gère le bus d'adresses 16 bits (A0–A15, GPIO 0–15) et le bus de données bidirectionnel 8 bits (D0–D7, GPIO 16–23). Les machines à états exécutent les programmes z80_addr et z80_data simultanément, poussant les mots d'adresse et pilotant ou échantillonnant les octets de données en synchronisme.
• PIO 1 — Signaux de contrôle, exécution de cycle et rafraîchissement DRAM (GPIO 16–47)
  - exécute les programmes de contrôle bus principaux sur la plage GPIO supérieure : la machine à états de cycle (z80_cycle) orchestre tous les cycles bus Z80 incluant la génération intégrée du rafraîchissement DRAM, la demande/acquittement de bus (z80_busrq), la détection NMI (z80_nmi), la synchronisation d'horloge (z80_clk_sync) et la gestion de l'acquittement d'interruption (z80_int_ack).
• PIO 2 — Timing hôte, réinitialisation et états d'attente
  - gère les interactions critiques en temps entre le RP2350 et le bus Z80 hôte qui doivent rester correctes même lorsque le Core 1 dessert la mémoire interne. Quatre machines à états dédiées fonctionnent dans le PIO 2 :
  • Détection RESET (z80_reset) — surveille la ligne RESET de l'hôte et signale le Core 1 afin que l'état d'émulation puisse être réinitialisé proprement à chaque réinitialisation matérielle.
  • Générateur d'états d'attente (z80_wait) — insère des états d'attente T-cycle configurables (contrôlés par le paramètre JSON tcycwait) en assertant /WAIT sur le bus hôte, étirant les cycles bus individuels pour correspondre aux exigences de timing des périphériques lents ou de la ROM/RAM paginée.
  • Synchronisation T1 (z80_sync) — détecte le front montant de T1 à chaque cycle bus (le moment où le Z80 place une adresse valide sur le bus) et signale le Core 1 via IRQ. Cette synchronisation est essentielle pour les applications qui dépendent de l'horloge hôte pour un timing précis — incluant les boucles de temporisation logicielles et les E/S sensibles au temps comme le contrôle du moteur de cassette et le bit-banging série — garantissant que les opérations mémoire internes du RP2350 n'introduisent pas de dérive de timing perceptible.

L'ensemble complet des programmes PIO dans z80.pio, groupés par bloc PIO :

Les machines à états communiquent via des drapeaux IRQ PIO plutôt que par scrutation, ce qui élimine la latence inter-machines : IRQ 0 signale le début adresse/cycle, IRQ 1 signale la phase données, IRQ 2 indique la détection T1, IRQ 3 signale un événement RESET, IRQ 4 signale NMI et IRQ 6 signale un BUSRQ actif. Parce que les programmes PIO s'exécutent indépendamment des cœurs Cortex-M33, l'interface bus continue de répondre de manière déterministe même lorsque le Core 1 est occupé par des accès PSRAM ou des appels de périphériques virtuels.

Les accès mémoire sont résolus à travers trois niveaux de latence croissante : Niveau 1 — SRAM du RP2350 (512 Ko, zéro état d'attente)
Un tableau de 128 entrées de valeurs membankPtr 32 bits, une par bloc de 512 octets de l'espace d'adressage Z80 complet de 64 Ko, donne au Core 1 une recherche de type bloc en O(1) pour chaque transaction bus. Ce tableau est la table de dispatch interne : chaque entrée encode le type de bloc et, pour les blocs adossés à la PSRAM, le décalage PSRAM. Niveau 2 — PSRAM externe (8 Mo, SPI)
La PSRAM contient 64 banques de 64 Ko d'images RAM ou ROM, plus un tableau de pointeurs memPtr de 64 Ko, un tableau de pointeurs de fonctions memioPtr de 64 Ko et un tableau de pointeurs de fonctions E/S ioPtr de 64 Ko. La latence d'accès PSRAM est déterministe et gérée via le périphérique SPI du RP2350 avec DMA. Niveau 3 — Flash SPI 16 Mo
Le firmware, les images ROM et le config.json minifié sont stockés en Flash. Les images ROM sont copiées de la Flash vers la PSRAM au démarrage et sont ensuite servies depuis la PSRAM en fonctionnement. La Flash n'est pas accédée pendant les transactions bus Z80 normales. Les blocs mémoire sont configurés avec une granularité de 512 octets. Les types de blocs disponibles sont :

La Flash de 16 Mo est partitionnée comme suit :

Chaque emplacement de configuration peut contenir jusqu'à 64 images ROM et une configuration JSON minifiée de 64 Ko. Le slot actif est enregistré dans la table de partitions et peut être changé depuis l'interface web ou en maintenant le bouton approprié pendant le démarrage.

La personnalité active est sélectionnée via la page Personality de l'interface web ou en éditant le fichier config.json.

Le firmware prend en charge un système de compilation ciblée qui produit des binaires spécifiques à chaque machine : pZ80-BaseZ80 inclut tous les pilotes (Sharp + Amstrad + Tatung), pZ80-SharpZ80 inclut uniquement les pilotes Sharp MZ, pZ80-AmstradZ80 inclut uniquement les pilotes Amstrad PCW, pZ80-TatungZ80 inclut uniquement les pilotes Tatung Einstein, et pZ80-OpenZ80 est la personnalité vanilla/expérimentateur qui n'expose que les cartes d'interface indépendantes de la machine (voir OpenZ80 — Personnalité Expérimentateur ci-dessous). Chaque cible est contrôlée par des définitions à la compilation (INCLUDE_SHARP_DRIVERS, INCLUDE_AMSTRAD_DRIVERS, INCLUDE_TATUNG_DRIVERS, INCLUDE_OPEN_DRIVERS). Les pilotes de périphériques suivants sont disponibles : Série Sharp MZ Lorsque compilé avec INCLUDE_SHARP_DRIVERS, les pilotes de périphériques Sharp suivants sont compilés et peuvent être liés à n'importe quelle personnalité matérielle virtuelle via la configuration JSON :

• MZ700.c — Ensemble de périphériques Sharp MZ-700
  - gère la commutation de banques caractéristique du MZ-700, la vidéo et les E/S clavier au niveau périphérique.
• MZ80K.c — Ensemble de périphériques Sharp MZ-80K
  - émulation du MZ-80K original de Sharp (1978), modelée sur le pilote MZ-80A. Fournit la ROM moniteur SP-1002 (0x0000–0x0FFF), 2 Ko de VRAM (0xD000–0xD7FF), le PPI 8255, le PIT 8253 et le scanner clavier LS367 (0xE000–0xE7FF), ainsi que la région de la ROM de boot disquette native MZ-80FD/MZ-80FIO (0xF000–0xF3FF). Implémente l'échange mémoire MEMSW/MEMSWR (relocalise le moniteur SP-1002 entre 0x0000 et 0xC000) afin que CP/M puisse fonctionner. Prend en charge le fonctionnement physique (remplacement direct dans un vrai MZ-80K) et virtuel (basé sur la PSRAM) ; CP/M nécessite le mode virtuel (ou le chemin de re-mappage mémoire propre au pilote) car le MZ-80K original ne dispose d'aucun matériel d'échange mémoire. Le MZ-80K peut lier l'ensemble complet des cartes d'interface du MZ-80A en plus de son propre contrôleur de disquettes natif. Deux chemins disquette distincts sont pris en charge : (1) l'interface native MZ80FIO (contrôleur Toshiba T3444M) — l'interface disque MZ-80FD originale — qui démarre et lit tous les disques MZ-80K, y compris les jeux, applications, BASIC et CP/M ; et (2) la carte MZ80AFI (le FDC à base de WD du MZ-80A), utilisée par CP/M — elle peut démarrer le CP/M du MZ-80K et lire les disques CP/M MZ-80K originaux depuis CP/M (montés comme lecteurs C:/D:). Utilisez MZ80FIO pour l'usage général des disques MZ-80K et MZ80AFI lors de l'exécution de CP/M. Sous-interfaces : RFS, MZ80FIO (disquette native T3444M), MZ80AFI, MZ-1E14, MZ-1E19, MZ-1R12, MZ-1R18, MZ-1R37, PIO-3034.
• MZ80A.c — Ensemble de périphériques Sharp MZ-80A
  - émulation complète de la machine MZ-80A incluant la ROM moniteur SA-1510, 2 Ko de VRAM, Intel 8253 PIT (Timer à intervalles programmable avec les six modes de compteur), Intel 8255 PPI (Interface périphérique programmable), scanner clavier LS367 et le mécanisme d'échange mémoire MEMSW/MEMSWR pour le support CP/M (échange la ROM moniteur à 0x0000 avec la RAM à 0xC000). Prend en charge le fonctionnement physique (matériel réel) et virtuel (basé sur la PSRAM), incluant le mode mixte où le pilote fonctionne virtuellement mais un contrôleur de disquettes physique est utilisé. Sous-interfaces : RFS, MZ80AFI, MZ-1E14, MZ-1E19, MZ-1R12, MZ-1R18.
• MZ2000.c — Ensemble de périphériques Sharp MZ-2000
  - émulation complète de la machine MZ-2000 avec commutation de mode mémoire boot/normal (BST/NST), superposition de VRAM caractères et graphiques avec sélection de banque, Intel 8253 PIT (4 MHz), Intel 8255 PPI (contrôle cassette et mode mémoire), Z80 PIO (clavier et pagination VRAM), et FDC MB8866. Prend en charge le mode physique (remplacement direct du Z80 dans un vrai MZ-2000 avec détection automatique du mode boot/normal) et le mode virtuel (émulation complète basée sur la PSRAM avec miroir de la ROM IPL). Sous-interfaces : RFS, MZ80AFI, MZ-1E14, MZ-1E19, MZ-1R12, MZ-1R18.
• MZ2200.c — Ensemble de périphériques Sharp MZ-2200
  - émulation machine MZ-2200 basée sur l'architecture MZ-2000 avec 8253 PIT, 8255 PPI, Z80 PIO, MB8866 FDC et CRT couleur. Prend en charge la commutation de mode mémoire BST/NST avec superposition VRAM. Sous-interfaces : RFS, MZ-8BFI/E0054PA, MZ-1E14, MZ-1E19, MZ-1R12, MZ-1R18.
• MZ80B.c — Ensemble de périphériques Sharp MZ-80B
  - émulation machine MZ-80B avec ROM IPL 2 Ko, commutation de mode BST/NST, affichage monochrome avec double pages VRAM graphique, 8253 PIT (31,25 kHz), 8255 PPI, Z80 PIO et sélection de page graphique. Les 10 interfaces de cartes d'extension sont prises en charge. Sous-interfaces : MZ-8BFI/E0054PA, MZ-1E14, MZ-1E19, MZ-1R12, MZ-1R18, MZ-1R23, MZ-1R37, PIO-3034, Celestite, MZ-1E30.
• MZ2500.c — Ensemble de périphériques Sharp MZ-2500 (SuperMZ)
  - émulation machine MZ-2500 avec MMU 8 pages (64 blocs mémoire), modes de compatibilité (MZ-2000, MZ-80B, natif), son OPN YM2203 FM+PSG, contrôleur graphique G-CRTC, FDC MB8876, palette graphique 16 entrées, contrôleur d'interruptions, RTC, ports joystick. Le mode virtuel prend en charge les logiciels pilotés par interruptions via des gestionnaires fetchByte et RETI personnalisés qui exécutent des cycles bus M1 physiques (nécessaires pour les horloges internes cadencées par M1 du gate array), le format de disque natif D88 avec auto-détection sparse/contiguë, et la suppression d'interruption unique pendant l'initialisation. Sous-interfaces : MZ-8BFI/E0054PA, MZ-1E14, MZ-1E19, MZ-1R12, MZ-1R18, MZ-1R23, MZ-1R37, PIO-3034, Celestite, MZ-1E30.
• MZ1500.c — Ensemble de périphériques Sharp MZ-1500
  - sur-ensemble du MZ-700 avec lecteur Quick Disk intégré, Programmable Character Generator (PCG), son stéréo PSG (SN76489AN), interface imprimante Z80 PIO, 8253 PIT et sélection de mode MZ-700/MZ-1500 par interrupteurs DIP. Sous-interfaces : RFS, MZ-1E05, MZ-1E14, MZ-1E19, MZ-1R12, MZ-1R18, MZ-1R23, MZ-1R37, PIO-3034, Celestite.
• MZ800.c — Ensemble de périphériques Sharp MZ-800
  - pilote double mode qui fonctionne en mode de compatibilité MZ-700 ou en mode natif MZ-800, basculant à la volée via le registre Display-Mode du GDG (Graphics Display Generator) (port 0xCE). Le mode natif ajoute des graphismes 320×200 / 640×200 avec une palette de 4 ou 16 couleurs (plans VRAM à 0x8000–0xBFFF), le son PSG SN76489 (port 0xF2), les ports de pagination mémoire 0xE0–0xE6, le FDC WD1773 et le QuickDisk ; le mode MZ-700 fournit les 8255/8253 mappés en mémoire et la VRAM texte pour exécuter les logiciels MZ-700 et CP/M. Mode virtuel ; rejoue un RETI physique sur le bus réel afin que la chaîne d'interruptions (daisy-chain) du Z80-PIO (IM2) continue de fonctionner depuis la PSRAM. Sous-interfaces : RFS, MZ80FIO, MZ80AFI, MZ-1E05, MZ-1E14, MZ-1E19, MZ-1E30, MZ-1R12, MZ-1R18, MZ-1R23, MZ-1R37, MZ-8BFI, PIO-3034, Celestite, MZ-8BIO3, MZ-1E24.
• WD1773.c — Contrôleur de disquettes
  - émule un FDC WD1773 prenant en charge les images disque 80 pistes, 2 têtes, 8 secteurs par piste aux formats DSK, RAW et D88 stockés sur la carte SD. Les registres WD1773 sont mappés comme blocs d'E/S de type FUNC.
• T3444M.c — Contrôleur de disquettes Toshiba T3444M/T3444A (MZ-80K)
  - émule le FDC Toshiba T3444M/T3444A utilisé par l'unité disquette MZ-80FD du Sharp MZ-80K. Lit les images CPC extended DSK avec la géométrie native du MZ-80K (35 pistes, 2 têtes, 16 secteurs/piste, secteurs FM de 128 octets), avec jusqu'à quatre images de lecteur simultanées. Un analyseur DSK dédié parcourt les signatures Track-Info sur le disque car la table de taille de piste du CPC-DSK du MZ-80K n'est pas fiable. Utilisé par l'interface MZ80FIO — en tant que contrôleur original/natif du MZ-80K, il démarre et lit tous les types de disques MZ-80K, pas seulement CP/M.
• MZ80FIO.c — Interface disquette MZ-80FD / MZ-80FIO (MZ-80K)
  - émule l'interface Sharp MZ-80FD/MZ-80FIO — l'interface disque originale du MZ-80K — en utilisant le contrôleur Toshiba T3444M. Fournit la ROM de boot FDIF à 0xF000–0xF3FF ainsi que les ports de registres et de commandes du T3444M à 0xF8–0xFB. Démarre et lit tous les disques MZ-80K (jeux, applications, BASIC et CP/M), prend en charge jusqu'à quatre lecteurs et les changements de disque en cours d'exécution depuis l'interface web. Pour exécuter CP/M, le contrôleur MZ80AFI du MZ-80A peut être utilisé à la place — une seule interface disquette est active à la fois, et si les deux sont configurées, MZ80FIO a la priorité.
• QDDrive.c — Lecteur QuickDisk
  - émule le lecteur miniature QuickDisk à accès séquentiel de Sharp en utilisant des fichiers image QD sur la carte SD. Le pilote fournit une émulation complète du Z80 SIO/2 (Canal A pour les données de piste spirale, Canal B pour le contrôle moteur/état), avec détection d'octet de synchronisation en phase de recherche, contrôle moteur via RTS et opérations fichier asynchrones inter-cœurs pour l'accès à la carte SD.
• RFS.c — ROM Filing System
  - implémente la pagination RFS et l'interface de système de fichiers, permettant le chargement de fichiers programme MZF depuis la carte SD. La personnalité RFS inclut CP/M v2.23 (48 Ko), l'interpréteur BASIC SA-1510 personnalisé et Microsoft BASIC v4.7, tous améliorés avec un accès lecture/écriture à la carte SD afin que les programmes et données puissent être chargés et sauvegardés directement depuis la carte SD sans matériel cassette ou disquette.
• TZFS.c — TranZPUter Filing System
  - un moniteur bas niveau multi-banques et système de fichiers fonctionnel, modelé sur le TZFS du tranZPUter SW et son processeur d'E/S virtuel K64F, et proposé comme interface sélectionnable sur la personnalité MZ-700 (enregistré aux côtés de RFS dans MZ700.c, et en pratique mutuellement exclusif avec lui). Il enrichit le MONITOR 1Z-013A original avec l'accès à la carte SD, la commutation de banques ROM, un assembleur / désassembleur et des outils, et il démarre CP/M sous le moniteur. Les modes mémoire de la machine sont commutés en écrivant des modes tranZPUter (TZMM_ORIG/BOOT/TZFS/TZFS2/TZFS3/TZFS4/CPM/CPM2/COMPAT) sur le port d'E/S 0x60, ce qui repositionne les pointeurs de banque ; le Z80 demande les services de système de fichiers et de CP/M avec OUT (0x68), ce qui met en file une requête de service vers le Core 0 (listage de répertoire, chargement de fichier et les services de lecteur CP/M). Comme le picoZ80 n'a pas d'accès SD direct, les secteurs CP/M de 512 octets sont lus et écrits via l'ESP32 sur des fichiers image complets, les chemins d'image par lecteur étant repris des entrées JSON d'interface param[].file (modèle de repli CPM/SDC16M/RAW/CPMDSK<nn>.RAW). La ROM TZFS est roms/tzfs.bin sur la carte SD, assemblée à partir du TZFS/asm/tzfs.asm du projet compagnon TZFS. Elle est livrée dans config_MZ-700_MZ-700.json avec "enable": 0 — présente mais désactivée par défaut — et est activée dans le JSON ou depuis la page Configuration de l'interface web.
• MZ-1E05.c — Unité d'interface disquette
  - émule l'unité de contrôleur de disquettes Sharp MZ-1E05, qui est basée sur le FDC WD1773.
• MZ8BFI.c — Interface disquette MZ-8BFI / E0054PA (MZ-2000)
  - émule l'interface disquette du MZ-2000 en utilisant le FDC compatible MB8866/WD1773. Contrairement au MZ-1E05, le MZ-8BFI n'a pas de ROM pilote embarquée — le code FDC réside dans la ROM IPL du MZ-2000. Prend en charge le format d'image disque D88. 40 cylindres, 2 têtes, 16 secteurs/piste, secteurs de 256 octets.
• MZ-1E14.c — Contrôleur QuickDisk avec ROM BIOS (MZ-700 / MZ-800)
  - émule le contrôleur QuickDisk MZ-1E14, qui inclut une ROM BIOS embarquée pour les machines MZ-700 et MZ-800.
• MZ-1E19.c — Contrôleur QuickDisk sans ROM BIOS (MZ-800 / MZ-2000 / MZ-2200 / MZ-2500)
  - émule le contrôleur QuickDisk MZ-1E19, qui n'a pas de ROM BIOS embarquée et cible les machines MZ-800, MZ-2000, MZ-2200 et MZ-2500.
• MZ-1R12.c — Carte RAM sauvegardée par batterie de 32 Ko
  - émule l'extension RAM sauvegardée par batterie Sharp MZ-1R12 de 32 Ko. Au lieu d'utiliser une vraie batterie, l'image RAM est persistée et restaurée depuis la carte SD. Cette carte est couramment utilisée pour stocker une application afin qu'elle soit instantanément disponible au démarrage, évitant les longs temps de chargement par cassette.
• MZ-1R18.c — Carte RAM 64 Ko
  - émule l'extension RAM Sharp MZ-1R18 de 64 Ko, typiquement utilisée comme disque RAMFILE pour le stockage de programmes ou pour fournir de la mémoire supplémentaire pour les applications personnalisées nécessitant plus que l'espace d'adressage standard.
• MZ-1R23.c — ROM Kanji MZ-1R23 / ROM Dictionnaire MZ-1R24
  - émule la ROM Kanji de 128 Ko (motifs JIS 16×16) et les cartes optionnelles de ROM Dictionnaire de 256 Ko. Fichiers ROM chargés depuis la carte SD. Ports E/S B8h–B9h avec lecture auto-incrémentée.
• MZ-1R37.c — EMM (Extended Memory Manager) MZ-1R37 640 Ko
  - émule une carte mémoire étendue de 640 Ko avec un espace d'adressage 20 bits et un verrouillage d'adresse de port E/S.
• PIO-3034.c — EMM IO DATA PIO-3034 320 Ko
  - émule une carte mémoire étendue de 320 Ko avec un compteur d'adresses 19 bits et un port de données auto-incrémenté.
• Celestite.c — Carte composite LAN / Mémoire Celestite
  - émule un contrôleur Ethernet Wiznet W5100 (fichier de registres), un contrôleur d'interruptions, un stockage persistant UFM, une RAM CMOS intégrée MZ-1R12 de 32 Ko (extensible à 64 Ko), et un EMM optionnel MZ-1R37 de 640 Ko. Ports E/S 60h–6Fh. L'adresse du serveur de fichiers netfs.py est configurable via le paramètre JSON ip (p. ex. "192.168.1.210:6800"). L'implémentation Phase 2 fournit un véritable réseau TCP/IP via le pont ESP32 — les commandes socket W5100 (OPEN, CONNECT, LISTEN, SEND, RECV, CLOSE) sont transmises à l'ESP32 qui effectue les opérations socket BSD réelles, permettant à la carte Celestite de communiquer avec des services réseau tels que le serveur de fichiers netfs.py.
• SASI.c + MZ1E30.c — Interface disque dur SASI MZ-1E30
  - émule le contrôleur de disque dur SASI Sharp MZ-1E30 pour MZ-2500/MZ-80B. Prend en charge jusqu'à 4 cibles disque (~21,4 Mo chacune, blocs de 256 octets), ROM IPL de 32 Ko et E/S secteur à la demande depuis les images disque sur carte SD. Commandes SASI : TEST_UNIT_READY, REQUEST_SENSE, READ(6), WRITE(6), SEEK(6), INQUIRY. Ports E/S 0xA4–0xA5 (bus SASI), 0xA8–0xA9 (accès ROM).
• MZ8BIO3.c / MZ1E24.c — Cartes d'interface série RS-232C
  - cartes série à double canal bâties sur un Zilog Z80 SIO émulé. Ports 0xB0–0xB3 (base configurable) : canal A à 0xB0/0xB1, canal B à 0xB2/0xB3. Le canal A est ponté vers le port série USB CDC 2 et le canal B vers le port série USB CDC 3, de sorte qu'un terminal, un modem ou un programme de transfert de fichiers sur le PC hôte communique avec les logiciels série Sharp. La MZ-8BIO3 utilise le câblage de connecteur « BI », la MZ-1E24 le câblage Sharp « ST » ; sinon identiques. Pas de ROM. Disponibles sur les personnalités MZ-700, MZ-800, MZ-80B et MZ-1500.
• Z80SIO.c — Émulation Zilog Z80 SIO/2
  - Z80 SIO fidèle au niveau des registres (WR0–WR7, RR0–RR2, interruptions vectorisées Z80 mode 2 avec une chaîne (daisy-chain) in-service à 4 niveaux), utilisé par les cartes MZ-8BIO3 et MZ-1E24. Utilise des tampons circulaires (ring buffers) sans verrou à producteur unique/consommateur unique pour transférer les octets entre l'émulation Z80 (core 1) et le service USB CDC (core 0).

Série Amstrad PCW Lorsque compilé avec INCLUDE_AMSTRAD_DRIVERS, les pilotes de périphériques Amstrad suivants sont compilés :

• PCW9512.c + uPD765.c — Ensemble de périphériques Amstrad PCW-9512
  - émulation complète de l'Amstrad PCW-9512 avec gate array (ASIC), FDC NEC uPD765 (format CPC DSK), 512 Ko de RAM avec pagination 4 banques de 16 Ko, contrôleur d'imprimante à marguerite 8041, émulation de séquence d'amorçage et imagerie de disque physique. Modes virtuel et physique pris en charge.

Série Tatung Einstein Lorsque compilé avec INCLUDE_TATUNG_DRIVERS, les pilotes de périphériques Tatung suivants sont compilés :

• EinsteinTC01.c + EinsteinFDC.c + WD1770.c — Ensemble de périphériques Tatung Einstein TC-01
  - émulation complète du Tatung Einstein TC-01 avec Z80A @ 4 MHz, 64 Ko de RAM + 8 Ko de ROM commutable (X-TAL MOS), basculement ROM/RAM via le port 0x24 (tout accès bascule ; les écritures vont toujours en RAM), FDC WD1770 avec support de disque virtuel (40 pistes, 1 tête, 10 secteurs, 512 octets — disques de 200 Ko), VDP TMS9129 (processeur d'affichage vidéo) avec application de timing inter-accès (~2 us d'écart), PSG AY-3-8910 (son 3 canaux) aux ports 0x02-0x03, CTC Z80 (4 canaux) aux ports 0x28-0x2B, Z80 PIO aux ports 0x30-0x33, interface clavier au port 0x20, et imagerie de disque physique (lecture d'une disquette physique vers DSK, écriture d'un DSK vers une disquette physique). Modes virtuel et physique pris en charge. Sous-interface : EinsteinFDC (2 lecteurs, support des formats DSK/D88).

OpenZ80 — Personnalité Expérimentateur Lorsqu'il est compilé avec INCLUDE_OPEN_DRIVERS (la cible OpenZ80), le firmware fournit une personnalité Z80 délibérément « vanilla » (src/drivers/Other/Open.c) qui ne comporte aucun matériel spécifique à une machine. Son intérêt principal est qu'elle vous permet d'ajouter des cartes d'interface virtuelles empruntées à d'autres machines Sharp, Amstrad et Tatung sur un ordinateur Z80 sur mesure ou autrement non pris en charge — afin que vous puissiez écrire de nouveaux logiciels pour ces cartes, ou adapter des logiciels existants pour qu'ils fonctionnent sur votre propre machine. Elle est destinée à deux types d'expérimentateurs :

• Vous concevez votre propre carte Z80 — insérez le picoZ80 dans le support 40 broches et laissez-le agir comme un Z80 ordinaire. En mode physique, l'ensemble de l'espace d'adressage et d'E/S 64K est transmis directement à votre carte, et toute carte d'interface indépendante de la machine que vous activez est superposée à ses ports d'E/S. En mode virtuel, OpenZ80 présente une RAM 64K plate, dans laquelle vous pouvez charger séquentiellement à partir de 0x0000 une ou plusieurs de vos propres images ROM, ce qui vous permet de démarrer une carte qui n'a ni mémoire ni ROM propre.
• Vous disposez d'un ordinateur Z80 sans pilote picoZ80 dédié — partez d'OpenZ80 et de l'un des pilotes de machine existants comme base, puis modifiez-le pour votre machine (voir ci-dessous).

OpenZ80 n'expose que les cartes d'interface qui ne nécessitent aucun support spécifique à une personnalité, et chacune d'elles peut voir son port d'E/S de base relocalisé pour s'adapter à votre carte (voir Ports d'E/S d'interface relocalisables) : les cartes mémoire / fichier-RAM / Kanji MZ-1R12, MZ-1R18, MZ-1R23 et MZ-1R37, l'EMM parallèle PIO-3034, les cartes série RS-232C MZ-8BIO3 / MZ-1E24 (Z80 SIO), l'interface disquette WD1773 MZ-1E05, et la carte LAN ESP32 Celestite. Compilez-la avec build_tzpuPico.sh open. Construire à partir d'un pilote ou d'un BIOS existant Pour adapter le picoZ80 à une nouvelle machine, prenez l'un des pilotes fournis comme point de départ et modifiez-le. Les pilotes de personnalité se trouvent sous src/drivers/ — les machines Sharp dans src/drivers/Sharp/ (p. ex. MZ700.c, MZ80A.c, MZ80K.c, MZ2000.c), l'Amstrad PCW dans src/drivers/Amstrad/PCW9512.c, le Tatung Einstein dans src/drivers/Tatung/EinsteinTC01.c, et la personnalité vanilla dans src/drivers/Other/Open.c. Choisissez la machine la plus proche de la vôtre et modifiez sa carte mémoire, ses gestionnaires d'E/S et sa disposition de ROM. Les ROM de moniteur, d'IPL, de BIOS CP/M et d'amorçage disquette correspondantes sont fournies sous forme de code source assembleur Z80 commenté dans les projets compagnons RFS et TZFS, dans leurs répertoires asm/, afin que vous puissiez les recompiler ou les corriger pour votre machine :

• ROM de moniteur — RFS/asm/sp1002.asm (MZ-80K SP-1002), RFS/asm/sa1510.asm (MZ-80A SA-1510), RFS/asm/1z-013a.asm et TZFS/asm/1z-013a.asm (MZ-700), RFS/asm/mz800_iocs.asm (MZ-800 IOCS).
• Chargeurs d'amorçage (IPL) — TZFS/asm/mz2000_ipl.asm (MZ-2000), TZFS/asm/mz80b_ipl.asm (MZ-80B), RFS/asm/ipl.asm.
• BIOS CP/M — RFS/asm/cbios.asm et RFS/asm/cpm22-bios.asm (également TZFS/asm/cbios.asm / cbiosII.asm).
• ROM d'amorçage disquette / QuickDisk — RFS/asm/mz80afi.asm (MZ-80A FDC), TZFS/asm/mz80kfdif.asm (MZ-80K FDIF), RFS/asm/mz-1e05.asm, RFS/asm/mz-1e14.asm (QD), RFS/asm/sfd700.asm.
• ROM de système de fichiers — la ROM RFS elle-même (RFS/asm/rfs.asm, en banques) et la ROM TZFS (TZFS/asm/tzfs.asm, en banques) peuvent servir de base à un système de fichiers en ROM personnalisé.

Consultez le Guide du Développeur pour un exemple pas à pas d'écriture ou d'adaptation d'un pilote. Des personnalités Sharp MZ supplémentaires et le support d'autres machines Z80 seront ajoutés en temps voulu. Plusieurs personnalités peuvent coexister dans la configuration JSON, chacune associée à une banque PSRAM différente. Changer de personnalité modifie la carte mémoire active et les images ROM chargées sans redémarrer l'hôte.

Le projet picoZ80 inclut un serveur de fichiers réseau basé sur Python (tools/NetFileServer/netfs.py) qui s'exécute sur un PC Windows ou Linux et sert des fichiers programme MZF au périphérique BASIC NETx: du Sharp MZ via le réseau. Lorsque le picoZ80 est équipé d'une carte Celestite (ou du pilote virtuel Celestite), les programmes BASIC s'exécutant sur le MZ peuvent charger, sauvegarder et lister les fichiers du système de fichiers du PC en utilisant les commandes BASIC standard avec le préfixe de périphérique NETx:.

python3 netfs.py [--port 6800] [--dir ./mzf_files] [--dir2 path] ... [--dir7 path]

Le serveur prend en charge les unités 1 à 7 (NET1: à NET7:), chacune mappée vers un répertoire distinct sur le PC. Commandes prises en charge : DIR (liste du répertoire), READ (chargement de données de fichier), WRITE (sauvegarde de fichier), INFO (métadonnées de fichier), DELETE et CLOSE. Le serveur est multi-thread, gère l'analyse et la création d'en-têtes MZF, et inclut un délai d'expiration de connexion de 30 secondes pour la récupération après plantage.

La manière la plus simple de compiler le firmware du picoZ80 est de télécharger et d'exécuter le script de configuration automatisé adapté à votre plateforme. Il installe toutes les dépendances, clone les dépôts, configure les chemins et crée des scripts de compilation prêts à l'emploi — aucune configuration manuelle n'est nécessaire.

Téléchargez et exécutez le script de configuration depuis n'importe quel répertoire. Il vous demandera un emplacement d'installation (par défaut : ~/pico).

curl -O https://git.eaw.app/eaw/pico/raw/branch/master/setup_picoZ80.sh
chmod +x setup_picoZ80.sh
./setup_picoZ80.sh

Le script effectue les opérations suivantes :

• Détecte votre OS (Debian/Ubuntu, Fedora/RHEL, Arch/Manjaro, macOS) et installe les paquets requis — CMake, compilateur croisé ARM, Git, Python, Perl, rsync.
• Clone le dépôt picoZ80, le Pico SDK (branche develop), Pico Examples et Pico Extras avec tous les sous-modules.
• Configure les scripts de compilation avec les chemins corrects et installe l'en-tête de carte picoZ80 dans le SDK.
• Configure optionnellement Docker et récupère l'image espressif/idf:release-v5.4 pour les compilations du firmware ESP32.
• Crée ~/picoZ80_env.sh — un fichier d'environnement à sourcer lors des prochaines sessions. Il définit tous les chemins requis et fournit la fonction d'assistance idf54 pour des compilations ESP32 transparentes via Docker (préféré) ou une installation native d'ESP-IDF (solution de repli).

Après la configuration, sourcez l'environnement et compilez :

# Add to your ~/.bashrc or ~/.zshrc for automatic loading:
source ~/picoZ80_env.sh

# Build all RP2350 targets
build_tzpuPico.sh

# Build a specific target family
build_tzpuPico.sh sharp              # Sharp MZ targets only
build_tzpuPico.sh amstrad            # Amstrad PCW targets only
build_tzpuPico.sh tatung             # Tatung Einstein targets only
build_tzpuPico.sh open               # OpenZ80 experimenter persona only

# Build with debug symbols
build_tzpuPico.sh DEBUG

# Build everything including ESP32 firmware
build_tzpuPico.sh ALL

# Build ESP32 firmware only
build_esp32

Téléchargez setup_picoZ80_windows.ps1 et exécutez-le depuis une invite PowerShell Administrateur :

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
.\setup_picoZ80_windows.ps1

Le script Windows effectue les mêmes étapes adaptées à l'écosystème Windows :

• Installe les outils requis via winget — Git, CMake, Ninja, Python, Perl et la chaîne d'outils ARM GNU. Fournit des URL de téléchargement manuel pour tout outil ne pouvant pas être installé automatiquement.
• Clone tous les dépôts et configure les chemins.
• Crée build_tzpuPico.bat et picoZ80_env.bat pré-configurés pour votre emplacement d'installation.
• Offre trois options pour les compilations ESP32 : Docker Desktop, l'installateur hors-ligne Espressif ESP-IDF (~1,5 Go), ou ignorer.

Après la configuration, ouvrez une nouvelle invite de commandes :

picoZ80_env.bat
build_tzpuPico.bat                   REM build all RP2350 targets
build_tzpuPico.bat sharp             REM build Sharp targets only
build_tzpuPico.bat ALL               REM build RP2350 + ESP32
build_tzpuPico.bat esp32             REM build ESP32 firmware only

Note : n'exécutez pas build_tzpuPico.bat depuis une invite PowerShell/CMD ESP-IDF — la chaîne d'outils ESP-IDF remplace cmake et ne peut pas compiler les outils hôte du RP2350. Le fichier batch détecte ce cas et quitte avec une erreur explicite. L'activation d'ESP-IDF est gérée automatiquement par l'étape de compilation ESP32.

Le système de compilation produit des binaires firmware spécifiques à chaque machine pour réduire la taille du firmware lorsque seul un sous-ensemble de pilotes est nécessaire :

Chaque modèle cible a son propre répertoire sous src/model/ avec un CMakeLists.txt dédié, un point d'entrée et des scripts d'édition de liens. Utilisez la cible BaseZ80 pour une compatibilité maximale ou sélectionnez une cible spécifique à une machine pour un binaire plus petit qui s'insère plus confortablement dans la partition firmware de 5 Mo. Le répertoire fw/uf2/ contient les images UF2 du Bootloader (pour le flashage initial par stockage de masse USB) ; le répertoire fw/bin/ contient les images binaires (.bin) de partition applicative pour les mises à jour OTA. Les partitions applicatives sont placées à des adresses Flash non standard que le format UF2 ne peut pas exprimer, c'est pourquoi le binaire pur est utilisé pour tous les transferts OTA. Chaque cible est compilée en variantes standard et DBGSH — la variante DBGSH active le shell de débogage ICE complet sur le canal 1 USB CDC.

Si vous préférez configurer l'environnement manuellement plutôt que d'utiliser les scripts de configuration automatisés, les étapes sont :

1. Installez les prérequis : CMake 3.20+, arm-none-eabi-gcc (compilateur croisé ARM), Git, Python 3, Perl, et optionnellement Docker ou une installation native d'ESP-IDF v5.4 pour les compilations ESP32.
2. Clonez le dépôt principal : git clone https://git.eaw.app/eaw/pico.git <root>
3. Clonez le Pico SDK : git clone https://github.com/raspberrypi/pico-sdk.git --branch develop et exécutez git submodule update --init à l'intérieur.
4. Clonez Pico Extras : git clone https://github.com/raspberrypi/pico-extras.git et exécutez git submodule update --init à l'intérieur.
5. Éditez la variable PICO_PATH en haut de build_tzpuPico.sh pour qu'elle pointe vers votre répertoire racine.
6. Exécutez ./build_tzpuPico.sh pour compiler le firmware RP2350, ou ./build_tzpuPico.sh ALL pour inclure le firmware ESP32.

Consultez la section Guide du Développeur — Configuration de l'Environnement de Développement pour tous les détails sur les procédures automatisée et manuelle.

Il n'y a pas de bouton physique BOOTSEL ou Reset sur la carte picoZ80. Les deux signaux sont exposés sur le connecteur de débogage 6 broches :

Pour entrer dans le mode de stockage de masse du bootloader RP2350, utilisez un cavalier ou une sonde sur le connecteur de débogage :

1. Maintenez la Pin 6 (BOOTSEL) à l'état bas.
2. Appliquez l'alimentation, ou forcez la Pin 3 (Reset RP2350) à l'état bas puis relâchez-la — le RP2350 commence à démarrer.
3. Relâchez BOOTSEL rapidement après la mise sous tension ou la réinitialisation. La maintenir à l'état bas au-delà du moment initial de démarrage empêche le RP2350 d'accéder à la FlashRAM.
4. Connectez le port USB du picoZ80 à un PC — le RP2350 s'énumère comme un périphérique de stockage de masse USB.
5. Copiez Bootloader_<version>.uf2 sur le lecteur monté. Le RP2350 auto-flashe le bootloader et redémarre.

Toutes les mises à jour firmware RP2350 suivantes peuvent être effectuées via la page web OTA sans toucher au connecteur de débogage.

L'ESP32 est flashé en utilisant esptool via un environnement virtuel Python. Sur les révisions de carte plus récentes, l'ESP32 apparaît comme son propre périphérique USB ; sur les cartes originales avec un seul port USB, il n'était accessible que via le RP2350 agissant comme pont USB-UART. Dans les deux cas, la Pin 4 (Reset ESP32) sur le connecteur de débogage est utilisée pour maintenir l'ESP32 en réinitialisation pendant la séquence de démarrage du RP2350 si nécessaire. Configurez l'environnement esptool une seule fois :

python3 -m venv ./venv/
source ./venv/bin/activate
cd $HOME/esptool

Puis flashez les quatre composants firmware ESP32 en une seule commande, en ajustant PORT pour correspondre au nœud de périphérique assigné par votre OS et BINPATH au répertoire contenant les binaires compilés :

PORT=/dev/tty.usbmodem141403   # adjust to your system
BINPATH=/path/to/build/output

python3 ./esptool.py \
  -p ${PORT} -b 115200 \
  --before default_reset --after hard_reset \
  --chip esp32s3 \
  write_flash \
  --flash_mode dio --flash_size 4MB --flash_freq 80m \
  0x0     ${BINPATH}/bootloader.bin \
  0x8000  ${BINPATH}/partition-table.bin \
  0x9000  ${BINPATH}/ota_data_initial.bin \
  0x10000 ${BINPATH}/sd_card.bin

Toutes les mises à jour firmware ESP32 suivantes peuvent être effectuées via la page web OTA (ota-esp32.htm) sans nécessiter esptool. Note sur la révision de carte : Les cartes picoZ80 originales (v2.0 à v2.2) ont un seul port USB connecté au RP2350. Sur ces cartes, l'ESP32 doit être programmé via le RP2350 agissant comme pont USB-UART. Les révisions de carte plus récentes ajoutent un second port USB connecté directement à l'ESP32, permettant à esptool de l'adresser indépendamment.

• OTA RP2350
  - naviguez vers http://<device-ip>/ota-rp2350.htm, sélectionnez le fichier .bin versionné depuis fw/bin/ et téléversez. Les partitions applicatives se trouvent à des adresses Flash non standard, le binaire pur (pas UF2) est donc requis. Le bootloader vérifie la somme de contrôle de l'image avant d'activer la nouvelle partition.
• OTA ESP32
  - naviguez vers http://<device-ip>/ota-esp32.htm et téléversez le binaire firmware ESP32. L'ESP32 redémarre automatiquement avec le nouveau firmware. La même page accepte également une archive FilePack versionnée qui met à jour le système de fichiers web de l'ESP32 sur la carte SD — voir Téléversement FilePack ci-dessous.

Formatez la carte SD en FAT32. Placez config.json dans le répertoire racine. Créez des sous-répertoires pour les images ROM, les images disque et les arborescences du système de fichiers tels que référencés dans votre configuration. Une fois la carte en fonctionnement, la carte SD peut également être gérée entièrement via la page web File Manager.

Le picoZ80 prend en charge le débogage complet au niveau source des deux cœurs RP2350 et du co-processeur ESP32. Le RP2350 est débogué via SWD en utilisant une sonde CMSIS-DAP, avec OpenOCD fournissant un serveur GDB à deux cibles (un port par cœur). L'ESP32-S3 est débogué via son interface USB-JTAG intégrée en utilisant le GDB de la chaîne d'outils Xtensa.

Connexion matérielle
Connectez une sonde ARM DAPLink / CMSIS-DAP (p. ex. Raspberry Pi Debug Probe, Black Magic Probe ou tout adaptateur compatible CMSIS-DAP) au connecteur de débogage 6 broches de la carte picoZ80. Seules trois connexions sont nécessaires :

Broche du connecteur de débogage	Signal	Fonction SWD
Pin 1	SWCLK	Serial Wire Clock
Pin 2	SWDIO	Serial Wire Data
Pin 5	GND	Référence de masse

Démarrage d'OpenOCD
OpenOCD expose deux ports serveur GDB — le port 3333 pour le Core 0 et le port 3334 pour le Core 1. Le picoZ80 nécessite une petite modification du script de cible OpenOCD RP2350 standard pour activer le débogage SMP véritable avec des ports GDB séparés par cœur. Copiez le script standard et décommentez la ligne target smp :

sudo cp /usr/local/share/openocd/scripts/target/rp2350.cfg \
        /usr/local/share/openocd/scripts/target/rp2350_tzpu.cfg

Puis éditez rp2350_tzpu.cfg — trouvez la ligne target smp à l'intérieur du bloc if {[string compare $_USE_CORE SMP] == 0} et supprimez le # initial :

# Before (rp2350.cfg):
    #target smp $_TARGETNAME_0 $_TARGETNAME_1

# After (rp2350_tzpu.cfg):
    target smp $_TARGETNAME_0 $_TARGETNAME_1

Ce seul changement active le mode SMP pour qu'OpenOCD enregistre le Core 0 sur le port GDB 3333 et le Core 1 sur le port 3334, permettant à chaque cœur d'être attaché et exécuté pas à pas indépendamment. Lancez OpenOCD depuis la racine du projet avant de démarrer GDB :

openocd -f interface/cmsis-dap.cfg -f target/rp2350_tzpu.cfg -c "adapter speed 5000"

Initialisation globale de GDB (~/.gdbinit)
GDB nécessite une permission explicite pour charger automatiquement les fichiers .gdbinit par répertoire. Ajoutez ce qui suit à ~/.gdbinit, en ajustant les chemins pour correspondre à l'emplacement de votre projet (montré ici relatif à la racine du projet — utilisez des chemins absolus dans ~/.gdbinit si vous exécutez GDB depuis des répertoires variés) :

set history save on
set history filename ~/.gdb_history
set history size 65536
add-auto-load-safe-path build/bin/model/BaseZ80/.gdbinit:build/bin/model/Bootloader/.gdbinit

Copiez le fichier .gdbinit approprié par cœur dans le répertoire de compilation du Bootloader, puis lancez gdb-multiarch. Le fichier .gdbinit.bootloader.3333 se connecte au Core 0 (port 3333) et journalise la sortie dans gdb_core0.txt ; .gdbinit.bootloader.3334 se connecte au Core 1 (port 3334) avec journalisation dans gdb_core1.txt. Ouvrez deux terminaux pour déboguer les deux cœurs simultanément :

# Terminal 1 — Core 0
cd build/bin/model/Bootloader
cp ../../../../.gdbinit.bootloader.3333 .gdbinit
gdb-multiarch Bootloader.elf

# Terminal 2 — Core 1
cd build/bin/model/Bootloader
cp ../../../../.gdbinit.bootloader.3334 .gdbinit
gdb-multiarch Bootloader.elf

Les fichiers .gdbinit du firmware principal (.gdbinit.3333 et .gdbinit.3334) définissent une commande personnalisée xac <address> <count> qui affiche la mémoire en sortie combinée hex et ASCII, se connectent au port GDB respectif et poursuivent l'exécution. Ceci est utile pour inspecter le contenu des banques PSRAM et l'état des périphériques mappés en mémoire sans arrêter la boucle d'émulation :

# Terminal 1 — Core 0
cd build/bin/model/BaseZ80
cp ../../../../.gdbinit.3333 .gdbinit
gdb-multiarch BaseZ80_0x10020000.elf

# Terminal 2 — Core 1
cd build/bin/model/BaseZ80
cp ../../../../.gdbinit.3334 .gdbinit
gdb-multiarch BaseZ80_0x10020000.elf

# Memory dump example (in GDB prompt):
(gdb) xac 0x20000000 64

Le co-processeur ESP32-S3 dispose d'une interface USB-JTAG intégrée — aucune sonde de débogage externe n'est nécessaire. Connectez un câble USB d'un PC hôte directement au port USB ESP32 de la carte picoZ80. Démarrez OpenOCD en utilisant la configuration JTAG intégrée de l'ESP32-S3 :

openocd -f board/esp32s3-builtin.cfg

Puis lancez le GDB Xtensa en pointant vers l'ELF du firmware ESP32 (situé à esp32/build/main.elf relatif à la racine du projet) et attachez-vous au serveur GDB d'OpenOCD :

xtensa-esp32s3-elf-gdb esp32/build/main.elf
(gdb) target extended-remote :3333

Assurez-vous que l'ELF a été compilé à partir de la même révision source que le firmware flashé sur l'appareil afin que les symboles et les adresses correspondent correctement.

Tout le comportement du picoZ80 est contrôlé par le fichier config.json sur la carte SD. Le RP2350 lit ce fichier au démarrage via l'ESP32, le minifie et stocke le résultat en Flash. Si aucune carte SD n'est présente, la configuration précédemment stockée est utilisée. La configuration peut être éditée directement dans le navigateur via la page Config Editor. La structure de niveau supérieur est :

{
  "esp32": {
    "core": {
      "device": "Z80",
      "mode":   0
    },
    "wifi": {
      "override":  1,
      "wifimode":  "client",
      "ssid":      "MyNetwork",
      "password":  "MyPassword",
      "ip":        "192.168.1.192",
      "netmask":   "255.255.255.0",
      "gateway":   "192.168.1.1",
      "dhcp":      0,
      "webfs":     "webfs",
      "persist":   0
    }
  },
  "rp2350": {
    "core": {
      "cpufreq":   300000000,
      "psramfreq": 133000000,
      "voltage":   1.10
    },
    "z80": [
      {
        "memory":  [ ... ],
        "io":      [ ... ],
        "drivers": [ ... ]
      }
    ]
  }
}

L'objet de niveau supérieur esp32 configure le co-processeur ESP32. Il contient deux sous-objets : core et wifi.

L'objet wifi fournit un mécanisme pour injecter les identifiants WiFi et les paramètres réseau depuis config.json, remplaçant ce qui est stocké en NVS. Ceci est utile pour le provisionnement initial ou pour déployer une configuration réseau fiable sans utiliser le WiFi Manager web. Définissez override à 0 pour ignorer entièrement le fichier de configuration et s'appuyer sur les paramètres NVS précédemment persistés.

Le tableau memory définit la carte mémoire Z80. Chaque entrée couvre une région contiguë de l'espace d'adressage Z80 de 64 Ko, arrondie aux limites de blocs de 512 octets.

"memory": [
  {
    "enable":   1,
    "addr":     "0x0000",
    "size":     "0x1000",
    "type":     "ROM",
    "bank":     0,
    "tcycwait": 0,
    "tcycsync": 0,
    "task":     "",
    "file":     "/TZFS/tzfs.rom",
    "fileofs":  0
  },
  {
    "enable":   1,
    "addr":     "0x1000",
    "size":     "0xCFFF",
    "type":     "RAM",
    "bank":     0,
    "tcycwait": 0,
    "tcycsync": 0,
    "task":     "",
    "file":     "",
    "fileofs":  0
  },
  {
    "enable":   1,
    "addr":     "0xD000",
    "size":     "0x1000",
    "type":     "PHYSICAL_VRAM",
    "bank":     0,
    "tcycwait": 2,
    "tcycsync": 0,
    "task":     "",
    "file":     "",
    "fileofs":  0
  }
]

Le tableau io mappe les plages de ports d'E/S Z80 vers des gestionnaires. Les cycles d'E/S sont distingués des cycles mémoire par le signal Z80 IORQ, que la machine à états PIO de contrôle surveille.

"io": [
  {
    "enable": 1,
    "addr":   "0xE0",
    "size":   "0x08",
    "type":   "FUNC",
    "func":   "mz700_io"
  },
  {
    "enable": 1,
    "addr":   "0x00",
    "size":   "0xE0",
    "type":   "PHYSICAL"
  }
]

Le tableau drivers lie des instances de pilotes nommées au contexte Z80. Chaque pilote possède une ou plusieurs interfaces (listées sous la clé "if"), chacune pouvant charger des images ROM, remapper des plages d'adresses, remapper des plages de ports d'E/S et recevoir des fichiers de paramètres.

Afin que les cartes d'interface indépendantes de la machine puissent être utilisées sur des cartes personnalisées / d'expérimentation (voir OpenZ80), plusieurs cartes peuvent voir leur port d'E/S de base relocalisé. Une carte relocalisable lit son adresse de base depuis le dstaddr de son entrée iomap (avec srcaddr réglé sur le port authentique de la carte), et revient à son port d'origine lorsqu'aucune entrée iomap n'est présente. La façon la plus simple de le régler est le champ Base I/O Port de la page Configuration GUI, qui écrit l'entrée iomap correcte pour vous. Les cartes relocalisables et leurs bases par défaut sont :

"drivers": [
  {
    "enable": 1,
    "name":   "MZ700",
    "type":   "PHYSICAL",
    "if": [
      {
        "enable": 1,
        "name":   "main",
        "type":   "PHYSICAL",
        "rom": [
          {
            "enable":   1,
            "file":     "/MZ700/mz700.rom",
            "loadaddr": [
              {
                "enable":   1,
                "position": 0,
                "addr":     "0x0000",
                "bank":     0,
                "size":     "0x1000",
                "tcycwait": 0,
                "tcycsync": 0
              }
            ]
          }
        ],
        "addrmap": [
          {
            "enable":  1,
            "srcaddr": "0x0000",
            "size":    "0x1000",
            "dstaddr": "0x0000"
          }
        ],
        "iomap": [
          {
            "enable":  1,
            "srcaddr": "0xE0",
            "size":    "0x08",
            "dstaddr": "0xE0",
            "16bit":   0
          }
        ],
        "param": [
          {
            "enable": 1,
            "file":   "/config/mz700.cfg"
          }
        ]
      }
    ]
  },
  {
    "enable": 1,
    "name":   "MZ-1E05",
    "type":   "PHYSICAL",
    "if": [
      {
        "enable": 1,
        "name":   "fdc0",
        "type":   "PHYSICAL",
        "rom":    [],
        "addrmap": [],
        "iomap": [
          {
            "enable":  1,
            "srcaddr": "0xD8",
            "size":    "0x04",
            "dstaddr": "0xD8",
            "16bit":   0
          }
        ],
        "param": [
          {
            "enable": 1,
            "file":   "/DSK/MZ700/disk0.dsk"
          }
        ]
      }
    ]
  }
]

Voici une configuration minimale qui démarre un MZ-700 avec ROM, 48 Ko de RAM, VRAM hôte et le contrôleur de disquettes WD1773 :

{
  "rp2350": {
    "core": {
      "cpufreq":   300000000,
      "psramfreq": 133000000,
      "voltage":   1.10
    },
    "z80": [
      {
        "memory": [
          { "enable":1, "addr":"0x0000", "size":"0x1000", "type":"ROM",
            "bank":0, "tcycwait":0, "tcycsync":0, "task":"",
            "file":"/MZ700/mz700.rom", "fileofs":0 },
          { "enable":1, "addr":"0x1000", "size":"0xCFFF", "type":"RAM",
            "bank":0, "tcycwait":0, "tcycsync":0, "task":"", "file":"", "fileofs":0 },
          { "enable":1, "addr":"0xD000", "size":"0x1000", "type":"PHYSICAL_VRAM",
            "bank":0, "tcycwait":2, "tcycsync":0, "task":"", "file":"", "fileofs":0 },
          { "enable":1, "addr":"0xE000", "size":"0x2000", "type":"PHYSICAL",
            "bank":0, "tcycwait":0, "tcycsync":0, "task":"", "file":"", "fileofs":0 }
        ],
        "io": [
          { "enable":1, "addr":"0xE0", "size":"0x08", "type":"FUNC", "func":"mz700_io" },
          { "enable":1, "addr":"0xD8", "size":"0x04", "type":"FUNC", "func":"wd1773_io" }
        ],
        "drivers": [
          {
            "enable":1, "name":"MZ700", "type":"PHYSICAL",
            "if": [{ "enable":1, "name":"main", "type":"PHYSICAL",
                     "rom":[], "addrmap":[], "iomap":[], "param":[] }]
          },
          {
            "enable":1, "name":"MZ-1E05", "type":"PHYSICAL",
            "if": [{ "enable":1, "name":"fdc0", "type":"PHYSICAL",
                     "rom":[], "addrmap":[], "iomap":[],
                     "param":[{ "enable":1, "file":"/DSK/MZ700/disk0.dsk" }] }]
          }
        ]
      }
    ]
  }
}

Le picoZ80 inclut un shell de débogage ICE (In-Circuit Emulator) interactif intégré via le second canal série USB CDC. Connectez un émulateur de terminal (115200 baud, 8N1) au port série de débogage — il apparaît comme le second port COM/ttyACM lorsque le picoZ80 est connecté via USB. L'invite du shell est dbg> . Le firmware est disponible en deux variantes : une compilation standard sans le shell de débogage, et une compilation DBGSH qui inclut le débogueur ICE complet. La variante DBGSH est identifiée par le suffixe _DBGSH dans le nom de fichier du firmware.

Le shell de débogage fournit 49 commandes pour l'inspection et le contrôle en temps réel de l'émulation CPU Z80 :

Points d'arrêt — jusqu'à 8 points d'arrêt peuvent être actifs simultanément. Lorsqu'un point d'arrêt est atteint, le CPU est automatiquement maintenu et l'adresse atteinte est affichée. Utilisez go pour continuer ou step pour exécuter pas à pas depuis le point d'arrêt. Trace d'exécution — lorsqu'activée, le PC, l'opcode et le registre de drapeaux de chaque instruction exécutée sont enregistrés dans un tampon circulaire de 512 entrées. Utilisez trace dump pour inspecter l'historique d'exécution récent avec un désassemblage complet. Modes d'accès mémoire — dm p lit la mémoire via le bus Z80 physique (déclenchant les réponses du matériel réel), dm f lit en utilisant des cycles fetch (M1), dm v lit directement depuis la PSRAM virtuelle (aucune activité bus), et dm r lit l'espace d'adressage propre du RP2350 (Flash, SRAM, périphériques).

Le picoZ80 prend en charge trois modes réseau, sélectionnables à la compilation via des fichiers sdkconfig pré-construits de l'ESP32. Chaque mode détermine comment l'interface web et les pages de configuration sont accessibles.

USB NCM (Network Control Model) présente un adaptateur Ethernet virtuel via le port USB OTG de l'ESP32. Lorsque le picoZ80 est connecté à un ordinateur hôte via USB, l'hôte voit une interface réseau standard. Un serveur DHCP intégré au picoZ80 attribue automatiquement une adresse IP à l'hôte — aucune configuration manuelle n'est nécessaire. L'interface web est alors accessible à l'adresse http://192.168.7.1. Le mode NCM uniquement est le mode par défaut recommandé pour les cartes livrées sans certification WiFi. Il fournit la fonctionnalité complète de l'interface web (configuration, mises à jour firmware, gestion de fichiers, sélection de personnalité) sans aucune émission de fréquence radio. Le réseau d'adaptation d'antenne WiFi n'a pas besoin d'être monté sur le PCB. Le mode WiFi + NCM active les deux interfaces simultanément. Le serveur HTTP se lie à toutes les interfaces, donc les pages web sont accessibles depuis le WiFi ou la connexion réseau USB. Le WiFi se connecte de manière asynchrone, donc l'interface USB NCM est disponible immédiatement à la mise sous tension. Pour changer de mode, copiez le fichier sdkconfig.mode_* approprié vers sdkconfig dans le répertoire de compilation ESP32, recompilez et flashez le firmware ESP32.

Important : La carte picoZ80 n'a pas été soumise pour la certification d'émetteur intentionnel FCC (États-Unis) ou RED (UE). Telle que livrée, la carte doit avoir les composants d'adaptation d'antenne WiFi non montés et le firmware ESP32 compilé avec la configuration NCM uniquement (sdkconfig.mode_ncm_only). Dans cette configuration, aucune énergie radiofréquence n'est émise et la carte ne relève pas des réglementations sur les émetteurs intentionnels. Les utilisateurs finaux qui souhaitent utiliser le WiFi peuvent monter le réseau d'adaptation d'antenne sur le PCB, compiler le firmware ESP32 avec sdkconfig.mode_wifi_only ou sdkconfig.mode_wifi_and_ncm, et exploiter la carte sous l'exemption amateur/expérimentale applicable dans leur juridiction. Toute partie souhaitant vendre la carte commercialement avec le WiFi activé doit d'abord obtenir la certification FCC et/ou RED pour l'assemblage complet.

Le co-processeur ESP32 héberge une interface de gestion web construite avec Bootstrap 4. Connectez-vous au réseau WiFi du picoZ80 (ou configurez le mode client pour rejoindre votre réseau existant) et naviguez vers http://<device-ip>/ — par défaut http://192.168.4.1/ en mode Point d'Accès. En mode NCM, l'interface web est accessible à http://192.168.7.1 via la connexion réseau USB. Voir Réseau ci-dessus pour les détails des modes. Au premier démarrage en mode WiFi, la carte démarre en mode AP. Utilisez la page WiFi Manager pour configurer le mode client et attribuer une adresse IP fixe sur votre réseau. Toutes les pages partagent une barre de navigation commune à gauche offrant un accès en un clic à Status, Config Editor, Config GUI, File Manager, Settings (Firmware ESP32 / RP2350, WiFi Manager) et Persona. En mode NCM uniquement, la page WiFi Manager n'est pas présente et la barre de navigation affiche le même ensemble de pages moins WiFi Manager.

La page d'accueil affiche l'état en direct de la carte à travers trois panneaux :

• Configuration WiFi / Configuration Réseau
  - en modes WiFi, ce panneau affiche le SSID actuel, l'adresse IP attribuée, le masque de sous-réseau et la passerelle. En mode NCM uniquement, ce panneau est intitulé Configuration Réseau et affiche l'état du réseau USB NCM (adresse IP, masque de sous-réseau) à la place — il n'y a pas d'information SSID ou liée au WiFi. Le nom de la carte (tzpuPico) et la chaîne de copyright sont servis comme variables de modèle par le serveur web ESP32.
• Informations de Version
  - table de partitions ESP32 montrant tous les slots OTA avec le type, le sous-type, l'adresse Flash, la taille, la version du firmware, l'horodatage de compilation et quel slot est actuellement en cours d'exécution. Cela facilite la confirmation du firmware actif après une mise à jour OTA.
• Partitions RP2350
  - la table de partitions Flash du RP2350 avec le numéro de partition, l'adresse, la taille, la somme de contrôle, le drapeau actif/en cours d'exécution, la licence, l'auteur, la description, la version, la date de compilation et le copyright — donnant un instantané complet de l'état du firmware RP2350 aux côtés des informations ESP32.

Deux menus déroulants dans la barre de navigation en haut à droite sont disponibles sur chaque page :

• Menu Actions
  - Change Floppy Disk 1 / 2 — sélectionner un nouveau fichier image DSK depuis la carte SD et le monter dans le slot 1 ou 2 du contrôleur de disquettes virtuel WD1773 sans redémarrer. Le nom du fichier image disque actuellement chargé est affiché à côté de chaque entrée (ou "none" si aucune image n'est chargée).
  - Change QD Disk — échanger le fichier image QuickDisk actif à la volée. Le nom du fichier image QD actuellement chargé est affiché à côté de l'entrée.
  - Reload RP2350 Config — envoyer une commande de rechargement au RP2350 via l'UART ESP32–RP2350 ; le RP2350 re-analyse le config.json et ré-applique la carte mémoire et la configuration des pilotes sans un cycle complet de mise hors/sous tension.
• Menu Reboot
  - ESP32 — redémarrage logiciel du co-processeur ESP32 (redémarre le serveur web et la pile WiFi, le RP2350 n'est pas affecté).
  - RP2350B — réinitialiser le processeur RP2350 (ré-exécute le bootloader et recharge le slot firmware actif, le CPU hôte est mis en pause pendant la réinitialisation).
  - Host — asserter la ligne de réinitialisation de l'ordinateur hôte, redémarrant l'ordinateur historique dans le support Z80 sans affecter la carte picoZ80 elle-même.
  - IPL Reset — effectuer une réinitialisation IPL (Initial Program Load) en basculant le bit 3 du Port C du PPI 8255, ramenant la machine en mode boot (BST). Disponible sur les personnalités MZ-80B, MZ-2000, MZ-2200 et MZ-2500 — équivalent à appuyer sur le bouton IPL du matériel original.
  - RP2350 UF2 Boot — forcer le RP2350 en mode boot USB ROM UF2 via le bootloader personnalisé. L'ESP32 réinitialise le RP2350 avec la broche BOOT maintenue, puis envoie un identifiant magique via UART qui cause le bootloader à appeler reset_usb_boot(). Le RP2350 se présente comme un périphérique de stockage de masse USB pour le flashage par glisser-déposer UF2. C'est la méthode de récupération principale lorsque l'application principale est défaillante (p. ex. mauvais paramètres d'horloge/tension) — le bootloader personnalisé fonctionne avec des paramètres sécurisés par défaut et reste réactif.
  - RP2350 UF2 Boot (App) — demander à l'application RP2350 en cours d'exécution d'entrer en mode boot USB UF2 via une commande SPI. C'est une solution de repli pour les situations où le bootloader lui-même doit être remplacé — l'application en cours appelle directement reset_usb_boot(). Ne fonctionne que lorsque l'application est en cours d'exécution et réactive aux commandes SPI.

La page Éditeur de Configuration donne un contrôle complet d'édition sur le fichier de configuration JSON. Modifiez la configuration en utilisant l'éditeur WYSIWYG, sauvegardez selon les besoins et cliquez sur Apply pour retraiter la configuration. La carte SD conserve des sauvegardes numérotées automatiques de chaque configuration enregistrée (config.json;1, config.json;2, ... le numéro le plus élevé étant le plus récent), il est donc toujours possible de revenir à une configuration fonctionnelle précédente. Les configurations éditées sont sauvegardées sur la carte SD ; cliquer sur Apply ou une action de menu « Reload » envoie alors une commande de rechargement au RP2350 via l'UART ESP32–RP2350, provoquant le RP2350 à re-analyser et ré-appliquer la nouvelle configuration et provoquant l'ESP32 à analyser et recharger sa configuration.

La page Configuration GUI fournit un éditeur graphique basé sur des formulaires pour la configuration du picoZ80, complétant l'Éditeur de Configuration JSON brut. Au lieu d'éditer le JSON directement, tous les paramètres sont présentés sous forme de champs de saisie étiquetés, de menus déroulants et de tableaux éditables. Les modifications sont sauvegardées dans config.json sur la carte SD (le fichier existant est automatiquement sauvegardé avant l'enregistrement). Pour l'édition avancée, l'Éditeur de Configuration reste disponible pour la manipulation directe du JSON. La page est organisée en quatre onglets : RP2350 Global — paramètres globaux du cœur qui s'appliquent aux deux partitions firmware sauf remplacement au niveau partition :

• Core Voltage — tension du cœur RP2350 en volts (p. ex. 1,10 V).
• CPU Frequency (MHz) — fréquence d'horloge du RP2350. La plage valide est affichée à côté du champ.
• PSRAM Frequency (MHz) — fréquence d'horloge SPI de la PSRAM. Des valeurs plus élevées améliorent la vitesse d'émulation mais peuvent réduire la stabilité sur certaines cartes.

Partition 1 / Partition 2 — configuration par partition. Chaque onglet de partition a la même disposition :

• Core Settings — remplacements spécifiques à la partition pour Core Voltage, CPU Frequency et PSRAM Frequency. Si définis, ceux-ci prennent le pas sur les valeurs globales pour cette partition.
• Memory Regions — un tableau éditable définissant la carte mémoire Z80. Chaque ligne spécifie un bloc mémoire avec : Address hex, Size, Type (ROM, RAM, PHYSICAL ou FUNC), T-States (états d'attente), Bank (numéro de banque PSRAM), Track (drapeau de synchronisation T-cycle), File (nom de fichier image ROM sur la carte SD), File Offset et une case Load. Les lignes peuvent être ajoutées ou supprimées avec les boutons Add Memory Region et supprimer.
• I/O Regions — un tableau éditable définissant la carte des ports d'E/S Z80. Chaque ligne spécifie : Address, Size, Type et Function (le gestionnaire du pilote). Ajoutez ou supprimez des lignes selon les besoins.
• Drivers — liste les pilotes de périphériques actifs (p. ex. MZ80AFI, RFS, MZ-1E30, Celestite) avec des bascules activation/désactivation. Le bouton Add Driver présente un menu déroulant des pilotes valides pour le firmware en cours d'exécution — la page lit la chaîne de personnalité du firmware et n'offre que les pilotes de cette série (Sharp, Amstrad, Tatung ou Open). Chaque pilote liste ses System ROMs (images ROM au niveau du pilote qui écrasent les ROM de l'hôte) et ses Interfaces ; contrôleurs de disquettes, QuickDisk, cartes RAM/ROM, disque dur SASI, cartes série RS-232C et interfaces LAN peuvent être ajoutés, et les fichiers ROM, images disque et paramètres de chaque interface configurés directement.
  • Base I/O Port — pour les cartes d'interface relocalisables (MZ-1R12, MZ-1R18, MZ-1R23, MZ-1R37, PIO-3034, MZ-8BIO3, MZ-1E24, MZ-1E05, Celestite), un unique champ hexadécimal Base I/O Port est affiché, pré-rempli avec la base authentique de la carte. Modifiez-le pour déplacer les ports de la carte sur une carte personnalisée (voir Ports d'E/S d'interface relocalisables) ; le GUI écrit automatiquement l'entrée iomap correspondante, et l'omet lorsque vous laissez la valeur par défaut.
  • Paramètre Port — les cartes série RS-232C (MZ-8BIO3 / MZ-1E24) acceptent également un paramètre numérique Port pour leur port d'E/S de base (par défaut 0xB0 ; canal A → USB CDC 2, canal B → USB CDC 3).

ESP32 — paramètres du co-processeur ESP32 :

• Core — type de périphérique ESP32 (p. ex. S3S).
• Network Interfaces — contrôles d'activation/désactivation pour le WiFi et le réseau USB NCM :
  • WiFi Enable — case à cocher pour activer ou désactiver le WiFi (nécessite un redémarrage ; ignoré si le WiFi n'est pas compilé dans le firmware).
  • NCM Enable — case à cocher pour activer ou désactiver le réseau USB NCM (nécessite un redémarrage).
  • NCM Retries — nombre maximum de cycles de tentative de connexion (0 = réessayer indéfiniment, 5–1000 = tentatives maximum).
  • NCM Retry Period — délai entre les tentatives en secondes (0 = backoff croissant de 1 s jusqu'à 60 s, 1–120 = intervalle fixe).
  • NCM IP Address — l'adresse IP de la passerelle USB NCM (par défaut : 192.168.7.1). Lors de la connexion de deux cartes picoZ80 au même hôte, chacune doit utiliser un sous-réseau différent (p. ex. 192.168.7.1 et 192.168.8.1). Les modifications prennent effet après redémarrage et sont persistées en NVS.
  • NCM Netmask — le masque de sous-réseau USB NCM (par défaut : 255.255.255.0). Les modifications prennent effet après redémarrage.
  • USB Product Name — la chaîne de produit USB signalée au système d'exploitation hôte. macOS utilise cela comme étiquette de l'interface réseau NCM. Chaque carte génère automatiquement un nom unique à partir de son adresse MAC (p. ex. « picoZ80-3C4E ») ; remplacez ici pour définir un nom personnalisé (p. ex. « picoZ80-MZ700 »). Laissez vide pour la génération automatique. Les modifications prennent effet après redémarrage.
• WiFi Configuration — SSID, mot de passe, adresse IP, masque de sous-réseau, mode WiFi (Point d'Accès ou Client), DHCP (Activé ou Désactivé), chemin du répertoire WebFS, période de scrutation et puissance TX. Ces paramètres reflètent la page WiFi Manager mais sont éditables ici dans le cadre de la configuration complète.

Cliquez sur Save Configuration pour écrire les modifications dans config.json sur la carte SD (la version précédente est sauvegardée automatiquement) et envoyer automatiquement une commande de rechargement au RP2350, appliquant la nouvelle configuration sans un cycle complet de mise hors/sous tension. Cliquez sur Reload pour relire le config.json actuel depuis la carte SD — utile si vous avez fait une erreur et souhaitez annuler vos modifications et repartir du dernier état sauvegardé.

Le Gestionnaire de Fichiers fournit un navigateur de fichiers complet basé sur le web pour la carte SD, offrant une disposition en liste de répertoires pour visualiser les fichiers sur la carte SD. Il est destiné à la maintenance générale de la carte SD : téléversement d'images ROM, d'images de disquettes (DSK), d'images QuickDisk (QD), d'images de disque RAM et de mises à jour du système de fichiers web sans avoir besoin de retirer la carte. Chaque entrée dispose de boutons d'action pour copier, supprimer, télécharger ou éditer les fichiers texte, et un bouton Select File en haut permet de transférer de nouveaux fichiers depuis le PC. La navigation par répertoire permet de descendre dans les sous-répertoires tels que roms/, dsk/, qd/ et ram/. Le téléversement de fichiers tar ou gzip entraînera automatiquement le décompactage et l'extraction du fichier tar ou gzip (ou tar.gz) dans le répertoire SD actuel. Plusieurs fichiers peuvent être sélectionnés en utilisant les cases à cocher dans la colonne la plus à gauche (ou la case « Select All » dans l'en-tête). Lorsqu'un ou plusieurs éléments sont sélectionnés, les boutons Download N Items et Delete Selected apparaissent dans l'en-tête du panneau. La fonction de téléchargement récupère chaque fichier séquentiellement avec une fenêtre modale de progression — les répertoires sont automatiquement téléchargés sous forme d'archives tar. Un bouton Backup SD télécharge l'intégralité du contenu de la carte SD sous forme d'une seule archive vers l'ordinateur local. Ces fonctionnalités sont particulièrement utiles lorsque le picoZ80 est installé à l'intérieur d'une machine hôte et que le retrait physique de la carte SD est peu pratique.

La page Persona configure la personnalité machine active indépendamment pour chacune des deux partitions firmware RP2350. Chaque partition dispose de sa propre colonne de boutons radio couvrant chaque type de machine Sharp MZ pris en charge :

• Basic CPU — émulation Z80 brute sans pilotes spécifiques à une machine ; utile pour le développement Z80 générique.
• MZ-80A et MZ-80B — série Sharp MZ-80 (ROM moniteur 1Z-013A, clavier MZ-80, carte mémoire standard).
• MZ-700 — Sharp MZ-700 avec VRAM commutée par banques, contrôleur clavier et pilotes optionnels disquette/QuickDisk.
• MZ-800 — Sharp MZ-800 avec modes vidéo étendus et support QuickDisk.
• MZ-1500 — Sharp MZ-1500 avec QuickDisk et disquette optionnelle.
• MZ-2000, MZ-2200, MZ-2500 — séries Sharp MZ ultérieures avec vidéo haute résolution et mémoire étendue.

Sélectionner une personnalité et cliquer sur Select Personae écrit le config.json pré-construit correspondant sur la carte SD (en sauvegardant d'abord le fichier actuel) et déclenche un rechargement de la configuration. Parce que chaque partition firmware peut contenir une personnalité différente, la carte peut basculer entre, par exemple, une personnalité MZ-700 sur la partition 1 et une personnalité MZ-80A sur la partition 2 sans aucune édition de la carte SD. La personnalité expérimentateur OpenZ80 (voir OpenZ80 — Personnalité Expérimentateur) est un build de firmware dédié plutôt qu'une option radio sur cette page : flashez le firmware OpenZ80 sur une partition via les pages de mise à jour du firmware, puis configurez ses cartes d'interface et leurs ports d'E/S de base sur la page Configuration GUI. Pour un Z80 simple dans le support, sans ressources ajoutées, sur une machine prise en charge, l'option Basic CPU ci-dessus reste disponible.

La page OTA de l'ESP32 rapporte l'inventaire logiciel complet de l'ESP32 avant d'accepter un téléversement de firmware :

• Panneau Modules
  - affiche la version de chaque composant logiciel ESP32 : l'application ESP32 principale, la bibliothèque NVS (stockage non volatile), la pile WiFi, le FilePack (empaqueteur de système de fichiers web) et le WebFS (système de fichiers web en Flash). Cela facilite la confirmation de la cohérence de tous les composants après une mise à jour.
• Panneau Partitions ESP32
  - affiche la table complète des partitions OTA de l'ESP32 (otadata, nvs, phy_init, ota_0, ota_1) avec les adresses, tailles, versions de firmware, horodatages de compilation et quel slot OTA est actuellement actif (marqué « Yes »).
• Panneau Téléversement Firmware ESP32
  - accepte le binaire ESP32 (.bin) produit par la compilation ESP-IDF. Après le téléversement, l'ESP32 redémarre avec le nouveau firmware et l'ancien slot est conservé comme solution de repli.
• Panneau Téléversement FilePack
  - téléverse une archive FilePack versionnée sur la carte SD. Un FilePack regroupe tous les assets web statiques de l'ESP32 (modèles HTML, CSS, JavaScript et fichiers annexes) dans une seule archive distribuable. Lors du téléversement, l'ESP32 décompresse l'archive dans le répertoire du système de fichiers web de la carte SD ; tout fichier remplacé est automatiquement renommé pour inclure son numéro de version précédent (p. ex. webfs devient webfs.2.80), préservant l'ancienne version pour un retour arrière. Cela correspond au versionnage de style VAX/VMS utilisé ailleurs sur la carte SD, où chaque révision successive d'un fichier éditable est préservée avec un suffixe numérique : config.json;1, config.json;2, etc. — garantissant qu'aucune édition n'est jamais silencieusement écrasée.

La page OTA du RP2350 gère les deux partitions firmware RP2350 :

• Panneau Partitions RP2350
  - liste les trois partitions : partition 0 (Bootloader), partition 1 (premier slot applicatif, p. ex. « Z80 CPU Emulator »), et partition 2 (second slot). Chaque ligne affiche l'adresse Flash, la taille, la somme de contrôle, le drapeau actif/en cours d'exécution, la licence, l'auteur, la description, la version et la date de compilation. La partition actuellement en cours d'exécution est marquée « Yes » dans la colonne Active.
• Panneau Téléversement Firmware RP2350
  - accepte un fichier firmware binaire pur .bin depuis fw/bin/. Le format UF2 n'est pas utilisé ici — les partitions applicatives se trouvent à des adresses Flash non standard que le UF2 ne peut pas exprimer, donc le transfert OTA utilise du binaire brut. Utilisez les boutons radio Partition 1 / Partition 2 pour sélectionner le slot cible. Deux cases à cocher supplémentaires sont disponibles : Clear App Config efface les images ROM et la partition de configuration JSON minifiée associée au slot cible (utile lors de la mise à niveau vers une version de firmware avec un schéma de configuration incompatible), et Clear Flash Header réinitialise l'en-tête de partition Flash aux valeurs d'usine, reconstruisant la table de partitions à partir de zéro tout en préservant la configuration du bootloader. Le téléversement est vérifié par somme de contrôle avant que la nouvelle partition ne soit activée.
• Panneau Partition Active RP2350
  - bascule indépendamment la partition active sans téléverser de nouveau firmware. Sélectionner une partition ici déclenche un redémarrage automatique dans le slot choisi — utile pour basculer entre deux variantes de firmware pré-chargées (p. ex. Z80 et une compilation de test) sans aucun transfert de fichier.

Note : La page WiFi Manager n'est disponible que lorsque le firmware ESP32 est compilé avec le WiFi activé (sdkconfig.mode_wifi_only ou sdkconfig.mode_wifi_and_ncm). En mode NCM uniquement, cette page n'est pas présente dans la navigation — la connectivité réseau est fournie automatiquement via USB NCM sans configuration utilisateur requise. Le WiFi Manager configure la façon dont le picoZ80 se connecte à un réseau sans fil. Le panneau supérieur affiche la configuration WiFi actuellement active (SSID, IP attribuée, masque de sous-réseau et passerelle). Le formulaire Configure WiFi en dessous expose tous les paramètres :

• Mode WiFi
  - Point d'Accès : le picoZ80 diffuse son propre SSID et vous vous y connectez directement (utile lors de la configuration initiale ou lorsqu'aucun réseau infrastructure n'est disponible). Client : le picoZ80 rejoint un réseau WiFi existant en tant que station.
• SSID et Mot de passe
  - le nom et la phrase de passe du réseau à rejoindre (mode client) ou à diffuser (mode AP).
• Mode DHCP
  - Activé : la carte demande une adresse au serveur DHCP du réseau. Désactivé : utiliser une IP statique, un masque de sous-réseau et une passerelle tels que saisis dans les champs ci-dessous. Une IP fixe est recommandée pour que l'adresse de l'interface web soit toujours prévisible.

Les paramètres sont sauvegardés dans la NVS (stockage non volatile) de l'ESP32 en cliquant sur Save et prennent effet au prochain redémarrage.

Les deux menus déroulants dans la barre de navigation en haut à droite sont disponibles sur chaque page de l'interface web, fournissant un accès rapide aux opérations en temps réel et aux fonctions de réinitialisation du système sans quitter la page actuelle. Le Menu Action (icône engrenage) fournit des opérations en temps réel qui prennent effet immédiatement sans redémarrage : échange d'images de disquettes ou QuickDisk à la volée, et déclenchement d'un rechargement de configuration en direct sur le RP2350. Les noms de fichiers des images disque actuellement chargées sont affichés à côté de chaque entrée pour que l'opérateur puisse voir d'un coup d'œil quelles images sont montées. Le Menu Reboot (icône rotation) fournit des options de réinitialisation ciblées pour chaque sous-système — ESP32, RP2350, ordinateur hôte et IPL — plus deux options de récupération UF2 pour reflasher le RP2350 via stockage de masse USB lorsque la carte est physiquement inaccessible à l'intérieur d'une machine hôte. Les deux entrées UF2 fournissent des chemins de récupération complémentaires : la voie bootloader fonctionne même lorsque l'application principale est défaillante, tandis que la voie applicative fonctionne même lorsque le bootloader doit être remplacé.

Le tableau ci-dessous contient tous les sites référencés dans la conception et la programmation du picoZ80.

Site	Langue	Description
RP2350 Datasheet	Anglais	Référence technique et fiche de données officielle du Raspberry Pi RP2350.
Pico SDK	Anglais	SDK C/C++ Raspberry Pi Pico — système de compilation et abstraction matérielle utilisés par le firmware picoZ80.
Z80 CPU User Manual	Anglais	Manuel utilisateur de la famille CPU Zilog Z80 — timing bus, jeu d'instructions et descriptions des signaux.
ESP-IDF	Anglais	Framework de développement IoT Espressif utilisé pour le firmware du co-processeur ESP32.
Sharp MZ Series	Anglais	Ressource communautaire pour le matériel, les logiciels et la documentation technique des ordinateurs Sharp MZ.

Le tableau ci-dessous contient toutes les fiches de données et manuels référencés dans la conception et la programmation du picoZ80.

Fiche de données	Langue	Description
RP2350	Anglais	Fiche de données du microcontrôleur Raspberry Pi RP2350.
ESP32-S3	Anglais	Fiche de données du SoC Espressif ESP32-S3 — co-processeur WiFi/BT de la carte picoZ80.
APS6404L PSRAM	Anglais	Fiche de données de la PSRAM SPI 8 Mo — la RAM étendue principale utilisée pour la pagination mémoire.
W25Q128 Flash	Anglais	Fiche de données de la Flash NOR SPI 16 Mo Winbond — stocke le firmware et les images ROM.
TLV62590	Anglais	Convertisseur buck synchrone Texas Instruments 5 V vers 3,3 V alimentant le picoZ80 depuis la broche VCC DIP-40 du Z80.
CH334F	Anglais	Contrôleur hub USB 2.0 4 ports CH334F — fournit la fonctionnalité hub USB pour les mises à jour firmware.

Les premières prévisualisations de développement du projet picoZ80 ont été partagées sur X (anciennement Twitter). Le post suivant montre la carte en fonctionnement pour la première fois : https://x.com/engineerswork1/status/1953171627065188841

Le picoZ80 installé dans un Sharp MZ-700, exécutant la personnalité ROM Filing System (RFS). La vidéo démontre les capacités de disque virtuel et de pagination mémoire de la carte.

Un court extrait montrant une carte Z80 CPU Tester testant le picoZ80. Le testeur vérifie que le picoZ80 est un véritable Z80, l'identifie comme un Z80 NMOS et exécute du code de test à 8 MHz pour confirmer le bon fonctionnement.

Le picoZ80 v2.5 installé dans un Sharp MZ-80A, chargeant un programme depuis une cassette physique. Le chargement par cassette est extrêmement sensible au timing — le Z80 doit effectuer du bit-banging sur le flux de données série provenant du matériel cassette en temps réel, sans aucune marge d'erreur de timing. Cette vidéo démontre que le picoZ80 gère le timing critique du CMT de manière identique à un vrai Z80.

Le picoZ80 v2.5 dans un Sharp MZ-80A, lisant depuis un vrai contrôleur de disquettes et un lecteur de disque physique. L'accès aux disquettes nécessite une interaction précise et critique en temps entre le Z80 et le matériel FDC WD1773 — le DRQ doit être desservi dans des fenêtres de timing strictes sous peine de perte de données. Cette vidéo démontre que le picoZ80 interagit avec du matériel critique en temps de la même manière qu'un véritable Z80.

Le picoZ80 v2.5a installé dans un Sharp MZ-2000, fonctionnant en mode entièrement physique — tous les accès ROM, RAM et VRAM passent par le matériel réel du MZ-2000. Le contrôleur de disquettes est virtualisé, le picoZ80 émulant le FDC MB8866 et servant les images disque depuis la carte SD tandis que le reste de la machine fonctionne sur son matériel d'origine.

Aucun usage commercial n'est autorisé sans l'accord écrit exprès de l'auteur. La conception matérielle du picoZ80 (schémas, routage PCB, fichiers KiCad), le firmware et tous les logiciels associés sont mis à disposition pour un usage personnel, éducatif et non commercial uniquement. Aucune partie de cette conception — incluant mais sans s'y limiter les dessins du PCB, la nomenclature, les binaires firmware, le code source ou la documentation — ne peut être utilisée, reproduite, fabriquée, vendue ou incorporée dans un produit ou service commercial sans l'accord écrit exprès de l'auteur (Philip D. Smart). Pour demander une licence commerciale ou discuter des usages autorisés, veuillez contacter l'auteur via le site eaw.app.

Le projet picoZ80 s'appuie sur le travail de plusieurs individus et projets open-source. Leurs contributions sont reconnues avec gratitude.

• Manuel Sainz de Baranda y Goñi
  Auteur de la bibliothèque d'émulateur CPU Z80 en langage C Z80 (github.com/redcode/Z80). Ce cœur d'émulateur Z80 de haute précision et cycle-exact est utilisé par le firmware picoZ80 lors de l'exécution d'instructions Z80 en interne sur le RP2350, fournissant un comportement de drapeaux précis et le support des opcodes non documentés. La bibliothèque est utilisée selon les termes de la GNU General Public License v3.
• Raspberry Pi Ltd
  Auteurs du Pico SDK et du matériel RP2350. L'assembleur PIO, le SDK C, l'intégration de la chaîne d'outils CMake et le silicium RP2350B rendent possible l'interface bus cycle-exact.
• Espressif Systems
  Auteurs du framework ESP-IDF et du matériel ESP32. Le co-processeur ESP32, la pile WiFi, la bibliothèque OTA et le framework de stockage NVS sous-tendent l'interface de gestion web.
• Philip Smart
  Conception matérielle (schémas KiCad et routage PCB), firmware PIO du RP2350, application web ESP32, système de configuration JSON, pilotes de personnalités machine Sharp MZ et toute la documentation du projet.
• Grok (xAI)
  Assistant IA qui a fourni une aide précieuse pendant le débogage des machines à états PIO — en particulier pour le diagnostic de cas limites de timing et de problèmes d'interaction bus cycle-exact dans les programmes PIO du RP2350.
• Claude (Anthropic)
  Assistant IA contribuant à ce projet dans plusieurs domaines : rédaction et structuration de la documentation du projet, analyse de l'interface FSPI/UART entre le RP2350 et l'ESP32 et recommandations d'amélioration du firmware, ainsi qu'une assistance continue au développement du firmware.

Le projet picoZ80 est composé de plusieurs composants, chacun couvert par sa propre licence :

Composant	Licence
Firmware RP2350 picoZ80 (PIO, sources C)	GNU General Public License v3
Firmware ESP32 picoZ80 et interface web	GNU General Public License v3
Bibliothèque d'émulateur CPU Z80 (Manuel Sainz de Baranda y Goñi)	GNU General Public License v3
Fichiers de conception matérielle KiCad (schémas, PCB, Gerbers)	Creative Commons BY-NC-SA 4.0
Documentation et guides utilisateur	Creative Commons BY-NC-SA 4.0
Raspberry Pi Pico SDK	BSD 3-Clause
Framework ESP-IDF	Apache License 2.0
Bootstrap 4 (interface web)	MIT License

En résumé : le firmware et les logiciels que vous compilez à partir du code source de ce projet sont open-source sous GPL v3 ; les conceptions matérielles et la documentation sont licenciées sous CC BY-NC-SA 4.0 (usage non commercial uniquement — licence commerciale disponible sur demande) ; les bibliothèques tierces conservent leurs propres licences telles que listées ci-dessus. Voir les fichiers LICENSE et NOTICE dans le dépôt pour les détails complets.

Copyright © 2019–2026 Philip Smart. Tous droits réservés. Conceptions Matérielles — CC BY-NC-SA 4.0
Toutes les conceptions matérielles (schémas KiCad, routages PCB, fichiers de fabrication Gerber, nomenclatures) sont licenciées sous la Licence Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International. Vous êtes libre de partager et d'adapter les conceptions pour des fins non commerciales uniquement, à condition de donner le crédit approprié et de distribuer toute modification sous la même licence. La fabrication ou la vente commerciale nécessite une licence séparée — veuillez contacter info@eaw.app. Firmware & Logiciels — GNU GPL v3
Le firmware et le code source logiciel sont des logiciels libres sous la GNU General Public License v3. Vous pouvez redistribuer et modifier le code selon les termes de la GPL v3. Toute modification distribuée doit également être licenciée sous GPL v3 avec le code source rendu disponible. Marque Déposée & Attribution
Les noms picoZ80, pico6502 et engineers@work sont des marques déposées de Philip Smart. Vous ne pouvez pas utiliser ces noms pour promouvoir des produits dérivés sans autorisation écrite. Vous ne pouvez pas supprimer ou modifier les avis de copyright, l'attribution d'auteur ou les crédits d'écran de démarrage/splash. Le re-branding de ce projet et sa présentation comme votre propre travail est expressément interdit. Voir le fichier NOTICE dans le dépôt pour les détails complets. Licence Commerciale
Si vous êtes un fabricant ou un distributeur intéressé par la production de cartes picoZ80 ou pico6502 pour la vente commerciale, veuillez contacter : info@eaw.app. L'usage personnel, éducatif et amateur/club est toujours autorisé sous les licences open-source ci-dessus. Les textes complets des licences sont inclus dans le dépôt sous LICENSE, LICENSE-HARDWARE.txt et LICENSE-SOFTWARE.txt.

Cet appareil intègre un module sans fil ESP32-S3-PICO-1 capable d'émettre dans la bande ISM 2,4 GHz, ce qui en fait un émetteur intentionnel au sens des réglementations radiofréquence mondiales (incluant FCC Part 15 Subpart C aux États-Unis et la Directive Équipements Radio 2014/53/UE dans l'Union Européenne) lorsque le WiFi est activé. NCM uniquement par défaut pour les cartes non certifiées
Parce que le picoZ80 en tant qu'assemblage fini n'a pas subi de certification FCC ou RED, les cartes doivent être livrées avec le réseau d'adaptation d'antenne WiFi non monté et le firmware ESP32 compilé avec la configuration NCM uniquement (sdkconfig.mode_ncm_only). Dans cette configuration, aucune énergie radiofréquence n'est émise et la carte n'est pas soumise aux réglementations sur les émetteurs intentionnels. L'interface web complète reste accessible par USB à http://192.168.7.1. Voir la section Réseau — Avis Réglementaire FCC / RED ci-dessus pour plus de détails. Bien que le module ESP32-S3-PICO-1 lui-même possède des certifications réglementaires préexistantes (FCC, CE et autres), ces certifications au niveau du module ne s'étendent pas automatiquement à un produit fini qui incorpore le module. L'exemption de module pré-certifié permet aux amateurs individuels de construire un nombre limité d'appareils pour un usage personnel, expérimental ou éducatif sans obtenir d'autorisation d'équipement séparée. Limitations Importantes

• Les appareils assemblés avec le WiFi activé ne doivent pas être vendus, proposés à la vente, offerts ou autrement distribués à des tiers à moins que le produit fini n'ait été indépendamment testé et n'ait reçu sa propre autorisation d'équipement (p. ex. FCC ID, marquage CE avec évaluation par un organisme notifié) dans la juridiction concernée.
• Les cartes expédiées ou distribuées à des tiers doivent utiliser la configuration firmware NCM uniquement avec le réseau d'adaptation d'antenne WiFi non monté.
• La construction de ce projet pour un usage personnel en quantités limitées avec le WiFi activé est généralement autorisée en vertu des dispositions d'usage amateur et expérimental (p. ex. FCC § 15.23), à condition que l'appareil ne cause pas de brouillage préjudiciable.
• Les exigences réglementaires varient selon les pays. Les constructeurs situés hors des États-Unis doivent consulter leur autorité nationale de radiofréquence pour les règles applicables.

Responsabilité du Constructeur
Il est de la seule responsabilité du constructeur de s'assurer que tout appareil construit à partir de ces conceptions est conforme à toutes les réglementations radiofréquence applicables dans sa juridiction. L'auteur fournit ces conceptions pour un usage personnel, éducatif et amateur et ne fait aucune déclaration qu'un appareil construit à partir de celles-ci satisfait les exigences réglementaires pour la distribution commerciale.