picoZ80

Il picoZ80 continua il tema tranZPUter, sostituendo una CPU Z80 fisica in un computer host o industriale con una CPU piu' veloce, piu' memoria, dispositivi virtuali, connettivita' di rete (WiFi, BT), caricamento rapido delle applicazioni da scheda SD e gestione via WiFi. Si tratta di un PCB personalizzato progettato per inserirsi direttamente nel socket CPU Z80 DIP-40 di qualsiasi computer legacy basato su Z80. Anziche' utilizzare un processore Z80 discreto, la scheda ospita un microcontrollore RP2350B — un dispositivo dual-core Cortex-M33 a 150MHz capace di funzionare fino a 300MHz — le cui macchine a stati I/O programmabili (PIO) assumono il controllo completo e ciclo-accurato dei bus di indirizzo, dati e controllo dello Z80. Il picoZ80 non e' un semplice adattatore emulatore. Ogni transazione bus viene gestita in tempo reale dai motori PIO dell'RP2350, fornendo al sistema host esattamente la stessa temporizzazione bus che vedrebbe da uno Z80 reale. Allo stesso tempo, il secondo core dell'RP2350 e l'abbondante SRAM on-chip, combinati con 8MB di PSRAM esterna e 16MB di Flash, consentono una gamma praticamente illimitata di funzionalita' da sovrapporre all'interfaccia Z80 grezza — inclusa l'esecuzione accelerata, la memoria virtualizzata, il banking ROM, i drive disco virtuali e l'emulazione completa di personalita' macchina. Un co-processore ESP32 fornisce connettivita' WiFi e Bluetooth, archiviazione di massa su scheda SD e un'interfaccia di gestione via browser. Tutta la configurazione e' guidata da un singolo file config.json leggibile dall'uomo memorizzato sulla scheda SD, il che significa che non e' necessaria alcuna ricompilazione per riconfigurare la mappa di memoria della scheda, le immagini ROM o la selezione dei driver. Il picoZ80 e' stato dimostrato funzionante all'interno di molteplici macchine Sharp MZ. Un set di personalita' e' in fase di sviluppo per queste macchine, e in futuro anche per altri sistemi Z80, per fornire funzionalita' molto necessarie, come RAM/ROM banked, emulazione floppy disk, emulazione QuickDisk, ROM Filing System, TranZPUter Filing System, tutte in grado di funzionare simultaneamente. La configurazione e' interamente guidata da JSON; aggiungere il supporto per un nuovo host basato su Z80 e' una questione di modificare un file di configurazione e, dove e' richiesto un nuovo comportamento I/O, aggiungere un piccolo driver C nel codebase.

• Sostituzione diretta dello Z80
  - si installa in qualsiasi socket Z80 DIP-40. L'host vede la normale temporizzazione bus Z80 in ogni momento.
• Interfaccia bus PIO ciclo-accurata
  - tre macchine a stati PIO dell'RP2350 gestiscono simultaneamente i segnali di indirizzo, dati e controllo alla piena velocita' del bus Z80.
• Ampio spazio di memoria
  - 8MB di PSRAM organizzata in 64 banchi x 64KB, per un totale di 4MB di spazio di indirizzamento banked accessibile per contesto CPU.
• Banking ROM/RAM
  - i blocchi di memoria sono configurabili con granularita' di 512 byte e possono essere mappati come ROM, RAM, memoria host fisica o gestori di funzioni virtuali.
• Framework dispositivi virtuali
  - qualsiasi blocco di memoria da 512 byte o intervallo di porte I/O puo' essere supportato da una funzione C, abilitando periferiche completamente virtualizzate.
• Personalita' macchina
  - il firmware Z80 puo' essere configurato tramite un config JSON per funzionare all'interno di qualsiasi host Z80. Le personalita' sono disponibili per molteplici macchine Sharp MZ (MZ-80K, MZ-700, MZ-800, MZ-80A, MZ-80B, MZ-2000, MZ-2200, MZ-2500, MZ-1500), l'Amstrad PCW-9512 e il Tatung Einstein TC-01, piu' una personalita' vanilla OpenZ80 per gli sperimentatori che inseriscono il picoZ80 in una scheda di propria progettazione o in una macchina senza driver dedicato. Varianti di build mirate (BaseZ80, SharpZ80, AmstradZ80, TatungZ80, OpenZ80) consentono firmware specifico per macchina con dimensioni binarie ridotte.
• Emulazione Floppy e QuickDisk
  - controller floppy disk compatibile WD1773 ed emulazione drive Sharp QuickDisk, utilizzando immagini DSK/RAW/D88 sulla scheda SD.
• WiFi e gestione web
  - l'ESP32 integrato fornisce un'interfaccia web Bootstrap a sette pagine per configurazione, gestione file, aggiornamenti firmware OTA e selezione della personalita'.
• Shell di debug ICE
  - un debugger ICE a 49 comandi accessibile via USB CDC serial fornisce breakpoint (8 simultanei), esecuzione passo-passo, traccia di esecuzione, ispezione registri Z80, lettura/scrittura memoria e I/O, un disassemblatore e assemblatore Z80 integrati, imaging disco, diagnostica bus e monitoraggio dello stato del sistema.
• Partizioni firmware doppie
  - due slot firmware indipendenti da 5MB consentono aggiornamenti OTA sicuri; la partizione attiva viene selezionata dall'interfaccia web o dal bootloader.
• Aggiornamento firmware USB
  - il bootloader espone un bridge USB per il caricamento firmware senza richiedere un debugger hardware.

X (Twitter) anteprima del progetto — picoZ80 in azione

Il PCB picoZ80 (revisione 2.5) e' una scheda compatta e multi-layer progettata per rientrare nell'ingombro fisico del package Z80 DIP-40 e nello spazio disponibile all'interno dei tipici case di retro-computer. Tutta la logica opera a 3,3V; la conversione di livello e le considerazioni sulla corrente di pilotaggio per il bus host a 5V sono gestite nella progettazione schematica. La scheda integra cinque sottosistemi su un singolo PCB: il processore RP2350B, l'interfaccia bus Z80, il co-processore ESP32, l'alimentatore e un hub USB.

• RP2350B (Cortex-M33 dual-core)
  - processore principale, funzionante fino a 300MHz. Esegue il loop caldo dell'emulazione Z80 sul Core 1 e gestisce file I/O, USB e relay ESP32 sul Core 0. 512KB di SRAM on-chip. La variante RP2350B (rispetto all'RP2350A) fornisce i 48 pin GPIO necessari per il bus Z80 completo.
• 16MB SPI Flash
  - memorizza il bootloader, due slot firmware applicativo, due slot di configurazione e una partizione di configurazione generale. Il layout indirizzabile totale si estende da 0x10000000 a 0x11000000.
• 8MB PSRAM (SPI)
  - RAM pseudo-statica esterna che fornisce 64 banchi x 64KB di spazio di indirizzamento banked per la CPU emulata. Collegata all'RP2350 tramite una periferica SPI dedicata.
• Co-processore ESP32
  - fornisce WiFi (802.11 b/g/n, modalita' AP e client), Bluetooth, lettore scheda SD e web server. Comunica con l'RP2350 tramite un protocollo IPC binario su FSPI a 50MHz (con controllo di integrita' CRC32, canali DMA pre-allocati e trasferimenti burst di settori fino a 16 settori per transazione) e una UART a 460,8kbaud per i comandi di controllo.
• Slot scheda SD
  - FAT32, gestita dall'ESP32. Memorizza config.json, immagini ROM, immagini disco (DSK, QuickDisk, RAM disk) e alberi del file system TZFS/RFS.
• Hub USB
  - hub USB integrato per la connettivita' host e il bridging per l'aggiornamento firmware.
• Alimentatore 3.3V
  - convertitore buck efficiente che preleva dai 5V presenti sul pin VCC del socket Z80.

L'hardware del picoZ80 e' progettato in KiCad. La revisione corrente e' la v2.5. I file dello schema elettrico e del layout PCB sono disponibili nel repository del progetto sotto kicad/PICOZ80/. Lo schema elettrico e' suddiviso in cinque fogli:

Tutte le assegnazioni GPIO dell'RP2350B, disaccoppiamento, oscillatore a cristallo da 12MHz, Flash da 16MB e connessioni PSRAM da 8MB. Il package QFN-80 dell'RP2350B e' scelto specificamente per il suo conteggio di 48 GPIO — il bus Z80 completo (16 indirizzi + 8 dati + 12 segnali di controllo) piu' SPI/UART ESP32 e segnali USB consumano virtualmente ogni pin disponibile.

Modulo ESP32-S3-PICO-1, interfaccia scheda SD (SPI), antenna su chip, header di debug e linee di comunicazione inter-processore (bus FSPI a 50MHz, UART a 460,8kbaud). I segnali della scheda SD e le linee SPI/UART inter-processore sono chiaramente separati in questo foglio.

Le connessioni del socket DIP a 40 pin e la rete di resistenze dell'interfaccia bus. Le linee di indirizzo A0-A15, le linee dati D0-D7 e tutti i segnali di controllo Z80 (MREQ, IORQ, RD, WR, M1, RFSH, BUSREQ, BUSACK, HALT, INT, NMI, WAIT, CLK, RESET) sono instradati attraverso resistenze in serie a pin GPIO dedicati dell'RP2350 monitorati dalle macchine a stati PIO.

Convertitore buck sincrono TLV62590BV 5V-3,3V con condensatori di filtraggio ingresso/uscita. Il convertitore deve alimentare il carico combinato dell'RP2350B fino a 300MHz, 8MB di PSRAM, ESP32 e hub USB dal singolo pin VCC a 5V del socket Z80 DIP-40.

Controller hub USB CH334F con connettore Mini-B, cristallo da 12MHz e porte downstream instradate sia verso l'RP2350 (per il bridging di aggiornamento firmware) che verso l'ESP32 (per l'accesso USB diretto sulle revisioni piu' recenti della scheda).

Il PCB e' stato progettato il piu' piccolo possibile per ospitare tutta la circuiteria necessaria e rientrare nei limiti di un socket DIP-40. Sono stati utilizzati i componenti piu' piccoli assemblabili manualmente, cioe' dispositivi passivi 0402/0603 e spaziatura IC da 0,5mm per ridurre le dimensioni complessive, ed e' stato selezionato uno stackup a 6 layer per ospitare tutti i componenti necessari. I design iniziali, v2.0 e v2.1, sono stati assemblati manualmente con applicazione puntuale di saldatura, posizionamento manuale dei componenti e stazione di rilavorazione ad aria calda. La versione 2.2 e' stata assemblata manualmente con stencil e forno di rifusione. Le v2.3a e v2.5 sono state assemblate presso un fabbricante di PCB.

Clicca qui per visualizzare un diagramma interattivo di posizionamento componenti PCB e la Distinta Materiali.

I due core Cortex-M33 dell'RP2350B hanno responsabilita' completamente separate, comunicando attraverso una coda di messaggi intercore (queue_t). Il Core 0 gestisce tutti i task non in tempo reale: bridge USB e CDC serial, coordinamento dell'aggiornamento firmware, file I/O (inoltrato all'ESP32 via UART), dispatch dei comandi ESP32 (cambi immagine floppy/QuickDisk, ricaricamento configurazione, query versione), gestione partizioni e supervisione watchdog. Un timer watchdog hardware monitora la sequenza di boot e il loop principale, con il progresso del boot tracciato attraverso i registri scratch dell'RP2350 che sopravvivono ai reset watchdog. Gestori di fault completi catturano lo stato dei registri e le informazioni diagnostiche nella PSRAM, abilitando l'analisi post-reset di hard fault, bus fault e usage fault. Un log persistente in PSRAM (plogf) cattura i messaggi critici del boot prima che l'USB sia disponibile, complementando il sistema standard di output debug debugf. Il Core 1 esegue esclusivamente il loop caldo dell'emulazione CPU. Serve i FIFO PIO per elaborare le transazioni bus Z80, risolve ogni indirizzo rispetto alla mappa di memoria e passa la transazione all'hardware host fisico (tipo PHYSICAL), la serve dalla PSRAM (tipi RAM/ROM) o chiama una funzione handler di dispositivo virtuale (tipo FUNC). La latenza su questo percorso e' minimizzata mantenendo il loop interno nella SRAM e utilizzando la SRAM da 512KB dell'RP2350 come tabella di ricerca veloce per i puntatori ai blocchi di memoria.

L'interfaccia bus Z80 e' implementata interamente in assembly PIO dell'RP2350 (z80.pio). L'RP2350 fornisce tre blocchi PIO (PIO 0, PIO 1, PIO 2), ciascuno con quattro macchine a stati. Il firmware Z80 utilizza tutti e tre i blocchi PIO:

• PIO 0 — Bus di indirizzo e dati (GPIO 0-23)
  - gestisce il bus di indirizzo a 16 bit (A0-A15, GPIO 0-15) e il bus dati bidirezionale a 8 bit (D0-D7, GPIO 16-23). Le macchine a stati eseguono simultaneamente i programmi z80_addr e z80_data, inviando parole di indirizzo e pilotando o campionando byte di dati in sincronia.
• PIO 1 — Segnali di controllo, esecuzione ciclo e refresh DRAM (GPIO 16-47)
  - esegue i programmi principali di controllo bus sull'intervallo GPIO superiore: la macchina a stati del ciclo (z80_cycle) orchestra tutti i cicli bus Z80 inclusa la generazione integrata del refresh DRAM, richiesta/riconoscimento bus (z80_busrq), rilevamento NMI (z80_nmi), sincronizzazione clock (z80_clk_sync) e gestione interrupt-acknowledge (z80_int_ack).
• PIO 2 — Temporizzazione host, reset e stati di attesa
  - gestisce le interazioni time-critical tra l'RP2350 e il bus Z80 dell'host che devono rimanere corrette anche quando il Core 1 sta servendo memoria interna. Quattro macchine a stati dedicate funzionano nel PIO 2:
  • Rilevamento RESET (z80_reset) — monitora la linea RESET dell'host e segnala il Core 1 in modo che lo stato dell'emulazione possa essere reinizializzato in modo pulito ad ogni reset hardware.
  • Generatore di stati di attesa (z80_wait) — inserisce stati di attesa T-cycle configurabili (controllati dal parametro JSON tcycwait) asserendo /WAIT sul bus host, allungando i singoli cicli bus per soddisfare i requisiti di temporizzazione di periferiche piu' lente o ROM/RAM banked.
  • Sincronizzazione T1 (z80_sync) — rileva il fronte di salita di T1 su ogni ciclo bus (il punto in cui lo Z80 pone un indirizzo valido sul bus) e segnala il Core 1 via IRQ. Questa sincronizzazione e' essenziale per le applicazioni che dipendono dal clock dell'host per una temporizzazione precisa — inclusi i loop di ritardo software e l'I/O sensibile al tempo come il controllo del motore cassetta e il bit-banging seriale — assicurando che le operazioni di memoria interna dell'RP2350 non introducano derive di temporizzazione percepibili.

L'insieme completo dei programmi PIO in z80.pio, raggruppati per blocco PIO:

Le macchine a stati comunicano tramite flag IRQ PIO anziche' tramite polling, eliminando la latenza inter-macchina: IRQ 0 segnala l'inizio indirizzo/ciclo, IRQ 1 segnala la fase dati, IRQ 2 indica il rilevamento T1, IRQ 3 segnala un evento RESET, IRQ 4 segnala NMI e IRQ 6 segnala un BUSRQ attivo. Poiche' i programmi PIO vengono eseguiti indipendentemente dai core Cortex-M33, l'interfaccia bus continua a rispondere in modo deterministico anche quando il Core 1 e' occupato con accessi PSRAM o chiamate a dispositivi virtuali.

Gli accessi alla memoria vengono risolti attraverso tre livelli di latenza crescente: Livello 1 — SRAM RP2350 (512KB, zero stati di attesa)
Un array di 128 valori membankPtr a 32 bit, uno per ogni blocco da 512 byte dell'intero spazio di indirizzamento Z80 a 64KB, fornisce al Core 1 un lookup del tipo di blocco O(1) per ogni transazione bus. Questo array e' la tabella di dispatch interna: ogni voce codifica il tipo di blocco e, per i blocchi supportati da PSRAM, l'offset PSRAM. Livello 2 — PSRAM esterna (8MB, SPI)
La PSRAM contiene 64 banchi di immagini RAM o ROM da 64KB, piu' un array di puntatori memPtr da 64KB, un array di puntatori a funzione memioPtr da 64KB e un array di puntatori a funzione I/O ioPtr da 64KB. La latenza di accesso alla PSRAM e' deterministica e gestita tramite la periferica SPI dell'RP2350 con DMA. Livello 3 — Flash SPI da 16MB
Firmware, immagini ROM e il config.json minificato sono memorizzati nella Flash. Le immagini ROM vengono copiate dalla Flash alla PSRAM al momento del boot e vengono poi servite dalla PSRAM a runtime. La Flash non viene acceduta durante le normali transazioni bus Z80. I blocchi di memoria sono configurati con granularita' di 512 byte. I tipi di blocco disponibili sono:

La Flash da 16MB e' partizionata come segue:

Ogni slot di configurazione puo' contenere fino a 64 immagini ROM e una configurazione JSON minificata da 64KB. Lo slot attivo e' registrato nella tabella delle partizioni e puo' essere cambiato dall'interfaccia web o tenendo premuto il pulsante appropriato durante il boot.

La personalita' attiva viene selezionata tramite la pagina Personality dell'interfaccia web o modificando config.json.

Il firmware supporta un sistema di build mirato che produce binari specifici per macchina: pZ80-BaseZ80 include tutti i driver (Sharp + Amstrad + Tatung), pZ80-SharpZ80 include solo i driver Sharp MZ, pZ80-AmstradZ80 include solo i driver Amstrad PCW, pZ80-TatungZ80 include solo i driver Tatung Einstein e pZ80-OpenZ80 e' la personalita' vanilla/sperimentatore che espone solo le schede interfaccia machine-agnostic (vedi OpenZ80 — Personalita' Sperimentatore sotto). Ogni target e' controllato da define a tempo di compilazione (INCLUDE_SHARP_DRIVERS, INCLUDE_AMSTRAD_DRIVERS, INCLUDE_TATUNG_DRIVERS, INCLUDE_OPEN_DRIVERS). I seguenti driver periferici sono disponibili: Serie Sharp MZ Quando compilato con INCLUDE_SHARP_DRIVERS, i seguenti driver periferici Sharp vengono compilati e possono essere associati a qualsiasi personalita' hardware virtuale tramite la configurazione JSON:

• MZ700.c — Set periferiche Sharp MZ-700
  - gestisce il caratteristico bank-switching, video e I/O tastiera dell'MZ-700 a livello periferico.
• MZ80K.c — Set periferiche Sharp MZ-80K
  - emulazione del MZ-80K originale Sharp del 1978, modellato sul driver MZ-80A. Fornisce la ROM monitor SP-1002 (0x0000-0x0FFF), VRAM da 2KB (0xD000-0xD7FF), il PPI 8255, il PIT 8253 e lo scanner tastiera LS367 (0xE000-0xE7FF) e la regione della ROM di boot floppy nativa MZ-80FD/MZ-80FIO (0xF000-0xF3FF). Implementa lo scambio memoria MEMSW/MEMSWR (ricolloca la ROM monitor SP-1002 tra 0x0000 e 0xC000) in modo che il CP/M possa funzionare. Supporta sia il funzionamento fisico (sostituzione diretta in un MZ-80K reale) che virtuale (basato su PSRAM); il CP/M richiede la modalita' virtuale (o il percorso di remap memoria per-driver) perche' l'MZ-80K originale non dispone di hardware per lo scambio memoria. L'MZ-80K puo' associare l'intero set di schede interfaccia dell'MZ-80A oltre al proprio controller floppy nativo. Sono supportati due distinti percorsi floppy: (1) l'interfaccia nativa MZ80FIO (controller Toshiba T3444M) — l'interfaccia disco MZ-80FD originale — che effettua il boot e legge tutti i dischi MZ-80K, inclusi giochi, applicazioni, BASIC e CP/M; e (2) la scheda MZ80AFI (l'FDC dell'MZ-80A basato su WD), utilizzata dal CP/M — puo' avviare il CP/M dell'MZ-80K e leggere i dischi CP/M originali dell'MZ-80K da dentro il CP/M (montati come drive C:/D:). Utilizzare MZ80FIO per l'uso generale dei dischi MZ-80K e MZ80AFI quando si esegue il CP/M. Sub-interfacce: RFS, MZ80FIO (floppy nativo T3444M), MZ80AFI, MZ-1E14, MZ-1E19, MZ-1R12, MZ-1R18, MZ-1R37, PIO-3034.
• MZ80A.c — Set periferiche Sharp MZ-80A
  - emulazione completa della macchina MZ-80A inclusa la ROM monitor SA-1510, VRAM da 2KB, Intel 8253 PIT (Programmable Interval Timer con tutte e sei le modalita' contatore), Intel 8255 PPI (Programmable Peripheral Interface), scanner tastiera LS367 e il meccanismo di scambio memoria MEMSW/MEMSWR per il supporto CP/M (scambia la ROM monitor a 0x0000 con la RAM a 0xC000). Supporta sia il funzionamento fisico (hardware reale) che virtuale (basato su PSRAM), inclusa la modalita' mista in cui il driver funziona virtualmente ma viene utilizzato un controller floppy fisico. Sub-interfacce: RFS, MZ80AFI, MZ-1E14, MZ-1E19, MZ-1R12, MZ-1R18.
• MZ2000.c — Set periferiche Sharp MZ-2000
  - emulazione completa della macchina MZ-2000 con commutazione modalita' memoria boot/normal (BST/NST), overlay VRAM caratteri e grafica con selezione banco, Intel 8253 PIT (4 MHz), Intel 8255 PPI (controllo cassetta e modalita' memoria), Z80 PIO (tastiera e paginazione VRAM) e FDC MB8866. Supporta sia la modalita' fisica (sostituzione diretta dello Z80 in un MZ-2000 reale con rilevamento automatico della modalita' boot/normal) che la modalita' virtuale (emulazione completa basata su PSRAM con mirroring della ROM IPL). Sub-interfacce: RFS, MZ80AFI, MZ-1E14, MZ-1E19, MZ-1R12, MZ-1R18.
• MZ2200.c — Set periferiche Sharp MZ-2200
  - emulazione della macchina MZ-2200 basata sull'architettura MZ-2000 con 8253 PIT, 8255 PPI, Z80 PIO, FDC MB8866 e CRT a colori. Supporta la commutazione modalita' memoria BST/NST con overlay VRAM. Sub-interfacce: RFS, MZ-8BFI/E0054PA, MZ-1E14, MZ-1E19, MZ-1R12, MZ-1R18.
• MZ80B.c — Set periferiche Sharp MZ-80B
  - emulazione della macchina MZ-80B con ROM IPL da 2K, commutazione modalita' BST/NST, display monocromatico con pagine VRAM grafiche doppie, 8253 PIT (31,25 kHz), 8255 PPI, Z80 PIO e selezione pagina grafica. Tutte le 10 interfacce scheda di espansione supportate. Sub-interfacce: MZ-8BFI/E0054PA, MZ-1E14, MZ-1E19, MZ-1R12, MZ-1R18, MZ-1R23, MZ-1R37, PIO-3034, Celestite, MZ-1E30.
• MZ2500.c — Set periferiche Sharp MZ-2500 (SuperMZ)
  - emulazione della macchina MZ-2500 con MMU a 8 pagine (64 blocchi di memoria), modalita' di compatibilita' (MZ-2000, MZ-80B, nativa), sonoro OPN YM2203 FM+PSG, controller grafico G-CRTC, FDC MB8876, palette grafica a 16 voci, controller interrupt, RTC, porte joystick. La modalita' virtuale supporta software guidato da interrupt tramite handler personalizzati fetchByte e RETI che eseguono cicli bus M1 fisici (necessari per i clock interni temporizzati M1 del gate array), formato disco nativo D88 con auto-rilevamento sparse/contiguous e soppressione interrupt one-shot durante l'inizializzazione. Sub-interfacce: MZ-8BFI/E0054PA, MZ-1E14, MZ-1E19, MZ-1R12, MZ-1R18, MZ-1R23, MZ-1R37, PIO-3034, Celestite, MZ-1E30.
• MZ1500.c — Set periferiche Sharp MZ-1500
  - superset dell'MZ-700 con drive Quick Disk integrato, Programmable Character Generator (PCG), sonoro stereo PSG (SN76489AN), interfaccia stampante Z80 PIO, 8253 PIT e selezione modalita' MZ-700/MZ-1500 tramite DIP switch. Sub-interfacce: RFS, MZ-1E05, MZ-1E14, MZ-1E19, MZ-1R12, MZ-1R18, MZ-1R23, MZ-1R37, PIO-3034, Celestite.
• MZ800.c — Set periferiche Sharp MZ-800
  - driver a doppia modalita' che funziona in modalita' di compatibilita' MZ-700 o in modalita' MZ-800 nativa, commutando al volo tramite il registro Display-Mode del GDG (Graphics Display Generator) (porta 0xCE). La modalita' nativa aggiunge grafica 320×200 / 640×200 con una palette a 4 o 16 colori (piani VRAM a 0x8000–0xBFFF), sonoro PSG SN76489 (porta 0xF2), porte di banking memoria 0xE0–0xE6, FDC WD1773 e QuickDisk; la modalita' MZ-700 fornisce l'8255/8253 mappati in memoria e la VRAM testo per eseguire software MZ-700 e CP/M. Modalita' virtuale; riproduce un RETI fisico sul bus reale in modo che la daisy-chain interrupt dello Z80-PIO (IM2) continui a funzionare dalla PSRAM. Sub-interfacce: 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 — Controller floppy disk
  - emula un FDC WD1773 che supporta immagini disco a 80 tracce, 2 testine, 8 settori per traccia nei formati DSK, RAW e D88 memorizzati sulla scheda SD. I registri WD1773 sono mappati come blocchi I/O di tipo FUNC.
• T3444M.c — Controller floppy disk Toshiba T3444M/T3444A (MZ-80K)
  - emula l'FDC Toshiba T3444M/T3444A utilizzato dall'unita' floppy MZ-80FD del Sharp MZ-80K. Legge immagini CPC extended DSK con la geometria nativa dell'MZ-80K (35 tracce, 2 testine, 16 settori/traccia, settori FM da 128 byte), con fino a quattro immagini drive simultanee. Un parser DSK dedicato analizza le firme Track-Info su disco perche' la tabella delle dimensioni traccia CPC-DSK dell'MZ-80K e' inaffidabile. Utilizzato dall'interfaccia MZ80FIO — essendo il controller originale/nativo dell'MZ-80K, effettua il boot e legge ogni tipo di disco MZ-80K, non solo il CP/M.
• MZ80FIO.c — Interfaccia floppy disk MZ-80FD / MZ-80FIO (MZ-80K)
  - emula l'interfaccia Sharp MZ-80FD/MZ-80FIO — l'interfaccia disco originale dell'MZ-80K — utilizzando il controller Toshiba T3444M. Fornisce la ROM di boot FDIF a 0xF000-0xF3FF e le porte registro e comando del T3444M a 0xF8-0xFB. Effettua il boot e legge tutti i dischi MZ-80K (giochi, applicazioni, BASIC e CP/M), supporta fino a quattro drive e i cambi disco a runtime dall'interfaccia web. Per eseguire il CP/M, e' possibile utilizzare invece il controller MZ80AFI dell'MZ-80A — solo un'interfaccia floppy e' attiva alla volta e, se entrambe sono configurate, MZ80FIO ha la precedenza.
• QDDrive.c — Drive QuickDisk
  - emula il drive miniatura Sharp QuickDisk ad accesso sequenziale utilizzando file immagine QD sulla scheda SD. Il driver fornisce l'emulazione completa dello Z80 SIO/2 (Canale A per i dati della traccia a spirale, Canale B per il controllo motore/stato), completo di rilevamento byte di sincronizzazione nella fase di ricerca, controllo motore via RTS e operazioni file asincrone intercore per l'accesso alla scheda SD.
• RFS.c — ROM Filing System
  - implementa l'interfaccia di banking e filing RFS, consentendo il caricamento di file di programma MZF dalla scheda SD. La personalita' RFS include CP/M v2.23 (48K), l'interprete BASIC SA-1510 personalizzato e Microsoft BASIC v4.7, tutti potenziati con accesso in lettura/scrittura alla scheda SD in modo che programmi e dati possano essere caricati e salvati direttamente dalla scheda SD senza hardware cassetta o floppy.
• TZFS.c — TranZPUter Filing System
  - un monitor a basso livello multi-bank e file system funzionante, modellato sul TZFS del tranZPUter SW e sul suo processore I/O virtuale K64F, e offerto come interfaccia selezionabile sulla personalita' MZ-700 (registrato insieme a RFS in MZ700.c, e in pratica mutuamente esclusivo con esso). Potenzia il MONITOR 1Z-013A originale con accesso alla scheda SD, ROM banking, un assembler / disassembler e strumenti, ed effettua il boot del CP/M sotto il monitor. Le modalita' di memoria della macchina vengono commutate scrivendo le modalita' tranZPUter (TZMM_ORIG/BOOT/TZFS/TZFS2/TZFS3/TZFS4/CPM/CPM2/COMPAT) sulla porta I/O 0x60, che ri-punta i puntatori di bank; lo Z80 richiede i servizi di file system e CP/M con OUT (0x68), che accoda una richiesta di servizio al Core 0 (elenco directory, load-file e i servizi drive CP/M). Poiche' picoZ80 non ha accesso diretto alla SD, i settori CP/M da 512 byte vengono letti e scritti attraverso l'ESP32 su file immagine interi, con i percorsi immagine per drive presi dalle voci param[].file del JSON dell'interfaccia (template di fallback CPM/SDC16M/RAW/CPMDSK<nn>.RAW). La ROM TZFS e' roms/tzfs.bin sulla scheda SD, assemblata dal TZFS/asm/tzfs.asm del progetto complementare TZFS. Viene fornita in config_MZ-700_MZ-700.json con "enable": 0 — presente ma disattivata per impostazione predefinita — e viene attivata nel JSON o dalla pagina Configurazione della GUI web.
• MZ-1E05.c — Unita' interfaccia floppy disk
  - emula l'unita' controller floppy disk Sharp MZ-1E05, basata sul FDC WD1773.
• MZ8BFI.c — Interfaccia floppy disk MZ-8BFI / E0054PA (MZ-2000)
  - emula l'interfaccia floppy disk dell'MZ-2000 utilizzando il FDC compatibile MB8866/WD1773. A differenza dell'MZ-1E05, l'MZ-8BFI non ha ROM driver integrata — il codice FDC risiede nella ROM IPL dell'MZ-2000. Supporta il formato immagine disco D88. 40 cilindri, 2 testine, 16 settori/traccia, settori da 256 byte.
• MZ-1E14.c — Controller QuickDisk con BIOS ROM (MZ-700 / MZ-800)
  - emula il controller QuickDisk MZ-1E14, che include una BIOS ROM integrata per le macchine MZ-700 e MZ-800.
• MZ-1E19.c — Controller QuickDisk senza BIOS ROM (MZ-800 / MZ-2000 / MZ-2200 / MZ-2500)
  - emula il controller QuickDisk MZ-1E19, che non ha BIOS ROM integrata e si rivolge alle macchine MZ-800, MZ-2000, MZ-2200 e MZ-2500.
• MZ-1R12.c — Scheda RAM 32KB con batteria tampone
  - emula l'espansione RAM Sharp MZ-1R12 da 32KB con batteria tampone. Anziche' utilizzare una batteria reale, l'immagine RAM viene persistita e ripristinata dalla scheda SD. La scheda e' comunemente usata per memorizzare un'applicazione in modo che sia istantaneamente disponibile al boot, evitando i lunghi tempi di caricamento da cassetta.
• MZ-1R18.c — Scheda RAM 64KB
  - emula l'espansione RAM Sharp MZ-1R18 da 64KB, tipicamente usata come disco RAMFILE per la memorizzazione programmi o per fornire memoria aggiuntiva per applicazioni personalizzate che richiedono piu' dello spazio di indirizzamento standard.
• MZ-1R23.c — ROM Kanji MZ-1R23 / ROM Dizionario MZ-1R24
  - emula le schede ROM Kanji da 128KB (pattern JIS 16x16) e ROM Dizionario opzionale da 256KB. File ROM caricati dalla scheda SD. Porte I/O B8h-B9h con lettura auto-increment.
• MZ-1R37.c — EMM MZ-1R37 640KB (Expanded Memory Manager)
  - emula una scheda di memoria espansa da 640KB con spazio di indirizzamento a 20 bit e latching dell'indirizzo porta I/O.
• PIO-3034.c — EMM IO DATA PIO-3034 320KB
  - emula una scheda di memoria espansa da 320KB con contatore di indirizzo a 19 bit e porta dati auto-increment.
• Celestite.c — Scheda composita Celestite LAN / Memoria
  - emula un controller Ethernet Wiznet W5100 (file registri), controller interrupt, storage persistente UFM, RAM CMOS integrata MZ-1R12 da 32KB (espandibile a 64KB) ed EMM opzionale MZ-1R37 da 640KB. Porte I/O 60h-6Fh. L'indirizzo del file server netfs.py e' configurabile tramite il parametro JSON ip (es. "192.168.1.210:6800"). L'implementazione Fase 2 fornisce networking TCP/IP reale tramite il bridge ESP32 — i comandi socket W5100 (OPEN, CONNECT, LISTEN, SEND, RECV, CLOSE) vengono inoltrati all'ESP32 che esegue operazioni socket BSD effettive, consentendo alla scheda Celestite di comunicare con servizi di rete come il file server netfs.py.
• SASI.c + MZ1E30.c — Interfaccia hard disk SASI MZ-1E30
  - emula il controller hard disk SASI Sharp MZ-1E30 per MZ-2500/MZ-80B. Supporta fino a 4 target disco (~21,4 MB ciascuno, blocchi da 256 byte), ROM IPL da 32KB e I/O settori on-demand da immagini disco su scheda SD. Comandi SASI: TEST_UNIT_READY, REQUEST_SENSE, READ(6), WRITE(6), SEEK(6), INQUIRY. Porte I/O 0xA4-0xA5 (bus SASI), 0xA8-0xA9 (accesso ROM).
• MZ8BIO3.c / MZ1E24.c — Schede interfaccia seriale RS-232C
  - schede seriali a doppio canale costruite su uno Zilog Z80 SIO emulato. Porte 0xB0–0xB3 (base configurabile): canale A a 0xB0/0xB1, canale B a 0xB2/0xB3. Il canale A e' collegato alla porta seriale USB CDC 2 e il canale B alla porta seriale USB CDC 3, cosi' che un terminale, un modem o un programma di trasferimento file sul PC host comunichi con il software seriale Sharp. L'MZ-8BIO3 utilizza il cablaggio del connettore "BI", l'MZ-1E24 il cablaggio Sharp "ST"; per il resto sono identiche. Nessuna ROM. Disponibili sulle personalita' MZ-700, MZ-800, MZ-80B e MZ-1500.
• Z80SIO.c — Emulazione Zilog Z80 SIO/2
  - Z80 SIO register-accurate (WR0–WR7, RR0–RR2, interrupt vettorizzati Z80 mode-2 con daisy-chain in-service a 4 livelli), utilizzato dalle schede MZ-8BIO3 e MZ-1E24. Utilizza ring buffer lock-free single-producer/single-consumer per spostare byte tra l'emulazione Z80 (core 1) e il servizio USB CDC (core 0).

Serie Amstrad PCW Quando compilato con INCLUDE_AMSTRAD_DRIVERS, i seguenti driver periferici Amstrad vengono compilati:

• PCW9512.c + uPD765.c — Set periferiche Amstrad PCW-9512
  - emulazione completa dell'Amstrad PCW-9512 con gate array (ASIC), FDC NEC uPD765 (formato CPC DSK), RAM da 512KB con paginazione a 4 banchi da 16KB, controller stampante a margherita 8041, emulazione sequenza bootstrap e imaging disco fisico. Modalita' virtuale e fisica supportate.

Serie Tatung Einstein Quando compilato con INCLUDE_TATUNG_DRIVERS, i seguenti driver periferici Tatung vengono compilati:

• EinsteinTC01.c + EinsteinFDC.c + WD1770.c — Set periferiche Tatung Einstein TC-01
  - emulazione completa del Tatung Einstein TC-01 con Z80A @ 4MHz, 64KB RAM + 8KB ROM commutabile (X-TAL MOS), toggle ROM/RAM tramite porta 0x24 (qualsiasi accesso commuta; le scritture vanno sempre alla RAM), FDC WD1770 con supporto disco virtuale (40 tracce, 1 testina, 10 settori, 512 byte — dischi da 200KB), VDP TMS9129 (video display processor) con applicazione temporizzazione inter-accesso (~2us gap), PSG AY-3-8910 (sonoro 3 canali) alle porte 0x02-0x03, Z80 CTC (4 canali) alle porte 0x28-0x2B, Z80 PIO alle porte 0x30-0x33, interfaccia tastiera alla porta 0x20 e imaging disco fisico (lettura floppy fisico su DSK, scrittura DSK su floppy fisico). Modalita' virtuale e fisica supportate. Sub-interfaccia: EinsteinFDC (2 drive, supporto formato DSK/D88).

OpenZ80 — Personalita' Sperimentatore Quando compilato con INCLUDE_OPEN_DRIVERS (il target OpenZ80), il firmware fornisce una personalita' Z80 deliberatamente "vanilla" (src/drivers/Other/Open.c) che non ha alcun hardware specifico per macchina. Il suo valore principale e' che ti consente di aggiungere schede interfaccia virtuali prese in prestito da altre macchine Sharp, Amstrad e Tatung su un computer Z80 su misura o altrimenti non supportato — cosi' puoi scrivere nuovo software per quelle schede, o adattare software esistente per funzionare sulla tua macchina. E' pensata per due tipi di sperimentatore:

• Stai progettando la tua scheda Z80 — inserisci il picoZ80 nel socket a 40 pin e lascialo agire come un semplice Z80. In modalita' fisica l'intero spazio di indirizzamento e I/O da 64K passa direttamente alla tua scheda, e qualsiasi scheda interfaccia machine-agnostic che abiliti viene sovrapposta alle sue porte I/O. In modalita' virtuale OpenZ80 presenta una RAM piatta da 64K, nella quale puoi caricare una o piu' immagini ROM di tua proprieta' in sequenza a partire da 0x0000, cosi' da poter avviare una scheda che non dispone di memoria o ROM proprie.
• Hai un computer Z80 che non dispone di un driver picoZ80 dedicato — parti da OpenZ80 e da uno dei driver macchina esistenti come base, poi modificalo per la tua macchina (vedi sotto).

OpenZ80 espone solo le schede interfaccia che non necessitano di supporto specifico per personalita', e ognuna di esse puo' avere la propria porta I/O base rilocata per adattarsi alla tua scheda (vedi Porte I/O delle Interfacce Rilocabili): le schede di memoria / RAM-file / Kanji MZ-1R12, MZ-1R18, MZ-1R23 e MZ-1R37, l'EMM parallelo PIO-3034, le schede seriali RS-232C MZ-8BIO3 / MZ-1E24 (Z80 SIO), l'interfaccia floppy WD1773 MZ-1E05 e la scheda LAN ESP32 Celestite. Compilala con build_tzpuPico.sh open. Sviluppare a partire da un driver o BIOS esistente Per adattare il picoZ80 a una nuova macchina, prendi uno dei driver forniti come punto di partenza e modificalo. I driver delle personalita' risiedono sotto src/drivers/ — le macchine Sharp in src/drivers/Sharp/ (es. MZ700.c, MZ80A.c, MZ80K.c, MZ2000.c), l'Amstrad PCW in src/drivers/Amstrad/PCW9512.c, il Tatung Einstein in src/drivers/Tatung/EinsteinTC01.c e la personalita' vanilla in src/drivers/Other/Open.c. Scegli la macchina piu' vicina alla tua e modifica la sua mappa di memoria, gli handler I/O e il layout ROM. Le corrispondenti ROM di monitor, IPL, BIOS CP/M e boot floppy sono fornite come sorgente assembler Z80 commentato nei progetti complementari RFS e TZFS, nelle loro directory asm/, cosi' da poterle ricompilare o modificare per la tua macchina:

• ROM di monitor — RFS/asm/sp1002.asm (MZ-80K SP-1002), RFS/asm/sa1510.asm (MZ-80A SA-1510), RFS/asm/1z-013a.asm e TZFS/asm/1z-013a.asm (MZ-700), RFS/asm/mz800_iocs.asm (MZ-800 IOCS).
• Boot loader (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 e RFS/asm/cpm22-bios.asm (anche TZFS/asm/cbios.asm / cbiosII.asm).
• ROM di boot Floppy / 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 del file system — la ROM RFS stessa (RFS/asm/rfs.asm, banked) e la ROM TZFS (TZFS/asm/tzfs.asm, banked) possono essere prese come base per un file system in-ROM personalizzato.

Vedi la Guida dello Sviluppatore per un esempio pratico passo-passo su come scrivere o adattare un driver. Ulteriori personalita' Sharp MZ e supporto per altre macchine basate su Z80 verranno aggiunti in seguito. Piu' personalita' possono coesistere nella configurazione JSON, ciascuna associata a un diverso banco PSRAM. Cambiare personalita' modifica la mappa di memoria attiva e le immagini ROM caricate senza riavviare l'host.

Il progetto picoZ80 include un server file di rete basato su Python (tools/NetFileServer/netfs.py) che funziona su un PC Windows o Linux e serve file di programma MZF al dispositivo NETx: di Sharp MZ BASIC attraverso la rete. Quando il picoZ80 e' dotato di una scheda Celestite (o driver Celestite virtuale), i programmi BASIC in esecuzione sull'MZ possono caricare, salvare e elencare file dal filesystem del PC utilizzando i comandi BASIC standard con il prefisso dispositivo NETx:.

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

Il server supporta le unita' 1-7 (NET1: fino a NET7:), ciascuna mappata a una directory separata sul PC. Comandi supportati: DIR (elenco directory), READ (caricamento dati file), WRITE (salvataggio file), INFO (metadati file), DELETE e CLOSE. Il server e' multi-threaded, gestisce il parsing e la creazione degli header MZF e include un timeout di connessione di 30 secondi per il recupero da crash.

Il modo piu' semplice per compilare il firmware picoZ80 e' scaricare ed eseguire lo script di setup automatico per la propria piattaforma. Installa tutte le dipendenze, clona i repository, configura i percorsi e crea script di build pronti all'uso — non e' necessaria alcuna configurazione manuale.

Scaricare ed eseguire lo script di setup da qualsiasi directory. Chiedera' una posizione di installazione (default: ~/pico).

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

Lo script esegue quanto segue:

• Rileva il sistema operativo (Debian/Ubuntu, Fedora/RHEL, Arch/Manjaro, macOS) e installa i pacchetti richiesti — CMake, cross-compiler ARM, Git, Python, Perl, rsync.
• Clona il repository picoZ80, il Pico SDK (branch develop), Pico Examples e Pico Extras con tutti i submodule.
• Configura gli script di build con i percorsi corretti e installa l'header della scheda picoZ80 nell'SDK.
• Opzionalmente imposta Docker e scarica l'immagine espressif/idf:release-v5.4 per le compilazioni del firmware ESP32.
• Crea ~/picoZ80_env.sh — un file di ambiente da fare source nelle sessioni future. Imposta tutti i percorsi richiesti e fornisce la funzione helper idf54 per compilazioni ESP32 trasparenti tramite Docker (preferito) o un'installazione nativa di ESP-IDF (fallback).

Dopo il setup, fare source dell'ambiente e compilare:

# Aggiungere a ~/.bashrc o ~/.zshrc per il caricamento automatico:
source ~/picoZ80_env.sh

# Compilare tutti i target RP2350
build_tzpuPico.sh

# Compilare una specifica famiglia di target
build_tzpuPico.sh sharp              # Solo target Sharp MZ
build_tzpuPico.sh amstrad            # Solo target Amstrad PCW
build_tzpuPico.sh tatung             # Solo target Tatung Einstein
build_tzpuPico.sh open               # Solo persona sperimentatore OpenZ80

# Compilare con simboli di debug
build_tzpuPico.sh DEBUG

# Compilare tutto incluso il firmware ESP32
build_tzpuPico.sh ALL

# Compilare solo il firmware ESP32
build_esp32

Scaricare setup_picoZ80_windows.ps1 ed eseguirlo da un prompt PowerShell Amministratore:

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

Lo script Windows esegue gli stessi passi adattati all'ecosistema Windows:

• Installa gli strumenti richiesti tramite winget — Git, CMake, Ninja, Python, Perl e l'ARM GNU Toolchain. Fornisce URL di download manuale per gli strumenti che non possono essere installati automaticamente.
• Clona tutti i repository e configura i percorsi.
• Crea build_tzpuPico.bat e picoZ80_env.bat preconfigurati per la posizione di installazione.
• Offre tre opzioni per le compilazioni ESP32: Docker Desktop, l'installer offline Espressif ESP-IDF (~1.5 GB) o salta.

Dopo il setup, aprire un nuovo Prompt dei comandi:

picoZ80_env.bat
build_tzpuPico.bat                   REM compila tutti i target RP2350
build_tzpuPico.bat sharp             REM compila solo i target Sharp
build_tzpuPico.bat ALL               REM compila RP2350 + ESP32
build_tzpuPico.bat esp32             REM compila solo il firmware ESP32

Nota: non eseguire build_tzpuPico.bat da un prompt PowerShell/CMD di ESP-IDF — la toolchain ESP-IDF sovrascrive cmake e non puo' compilare gli strumenti host RP2350. Il file batch rileva questa situazione ed esce con un errore chiaro. L'attivazione di ESP-IDF e' gestita automaticamente dal passo di compilazione ESP32.

Il sistema di build produce binari firmware specifici per macchina per ridurre le dimensioni del firmware quando e' necessario solo un sottoinsieme di driver:

Ogni modello target ha la propria directory sotto src/model/ con un CMakeLists.txt dedicato, punto di ingresso e script del linker. Utilizzare il target BaseZ80 per la massima compatibilita' o selezionare un target specifico per macchina per un binario piu' piccolo che si adatta piu' comodamente nella partizione firmware da 5MB. La directory fw/uf2/ contiene le immagini UF2 del Bootloader (per il caricamento iniziale tramite mass-storage USB); la directory fw/bin/ contiene le immagini binarie (.bin) delle partizioni applicative per gli aggiornamenti OTA. Le partizioni applicative sono posizionate a indirizzi Flash non standard che il formato UF2 non puo' esprimere, percio' per tutti i trasferimenti OTA viene utilizzato il binario puro. Ogni target viene compilato nelle varianti standard e DBGSH — la variante DBGSH abilita la shell di debug ICE completa sul Canale 1 USB CDC.

Se si preferisce configurare l'ambiente manualmente anziche' utilizzare gli script di setup automatico, i passi sono:

1. Installare i prerequisiti: CMake 3.20+, arm-none-eabi-gcc (cross-compiler ARM), Git, Python 3, Perl e, opzionalmente, Docker o un'installazione nativa di ESP-IDF v5.4 per le compilazioni ESP32.
2. Clonare il repository principale: git clone https://git.eaw.app/eaw/pico.git <root>
3. Clonare il Pico SDK: git clone https://github.com/raspberrypi/pico-sdk.git --branch develop ed eseguire git submodule update --init al suo interno.
4. Clonare Pico Extras: git clone https://github.com/raspberrypi/pico-extras.git ed eseguire git submodule update --init al suo interno.
5. Modificare la variabile PICO_PATH all'inizio di build_tzpuPico.sh per puntare alla directory root.
6. Eseguire ./build_tzpuPico.sh per compilare il firmware RP2350, oppure ./build_tzpuPico.sh ALL per includere il firmware ESP32.

Vedere la sezione Guida dello Sviluppatore — Setup dell'Ambiente di Sviluppo per i dettagli completi su entrambe le procedure, automatica e manuale.

Non c'e' alcun pulsante fisico BOOTSEL o Reset sulla scheda picoZ80. Entrambi i segnali sono esposti sull'header di debug a 6 pin:

Per entrare nella modalita' mass-storage del bootloader RP2350, utilizzare un jumper o una sonda sull'header di debug:

1. Tenere Pin 6 (BOOTSEL) a livello basso.
2. Applicare l'alimentazione, oppure asserire Pin 3 (Reset RP2350) a livello basso poi rilasciarlo — l'RP2350 inizia l'avvio.
3. Rilasciare BOOTSEL prontamente dopo l'accensione o il reset. Tenerlo basso oltre il momento iniziale di boot impedisce all'RP2350 di accedere alla FlashRAM.
4. Collegare la porta USB del picoZ80 a un PC — l'RP2350 si enumera come dispositivo mass-storage USB.
5. Copiare Bootloader_<version>.uf2 sul drive montato. L'RP2350 effettua il self-flash del bootloader e si riavvia.

Tutti i successivi aggiornamenti firmware RP2350 possono essere effettuati tramite la pagina web OTA senza toccare l'header di debug.

L'ESP32 viene programmato utilizzando esptool tramite un ambiente virtuale Python. Sulle revisioni piu' recenti della scheda l'ESP32 appare come proprio dispositivo USB; sulle schede originali con una singola porta USB era accessibile solo attraverso l'RP2350 che agisce come bridge USB-UART. In entrambi i casi il Pin 4 (Reset ESP32) sull'header di debug viene utilizzato per tenere l'ESP32 in reset durante la sequenza di boot dell'RP2350 quando necessario. Configurare l'ambiente esptool una volta:

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

Poi caricare tutti e quattro i componenti firmware ESP32 in un singolo comando, regolando PORT per corrispondere al nodo dispositivo assegnato dal sistema operativo e BINPATH alla directory contenente i binari compilati:

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

Tutti i successivi aggiornamenti firmware ESP32 possono essere effettuati tramite la pagina web OTA (ota-esp32.htm) senza richiedere esptool. Nota sulla revisione della scheda: Le schede picoZ80 originali (v2.0 a v2.2) hanno una singola porta USB collegata all'RP2350. Su queste schede l'ESP32 deve essere programmato tramite l'RP2350 che agisce come bridge USB-UART. Le revisioni piu' recenti aggiungono una seconda porta USB collegata direttamente all'ESP32, consentendo a esptool di indirizzarlo indipendentemente.

• RP2350 OTA
  - navigare a http://<device-ip>/ota-rp2350.htm, selezionare il file .bin versionato da fw/bin/ e caricare. Le partizioni applicative si trovano a indirizzi Flash non standard, quindi e' richiesto il binario puro (non UF2). Il bootloader verifica il checksum dell'immagine prima di attivare la nuova partizione.
• ESP32 OTA
  - navigare a http://<device-ip>/ota-esp32.htm e caricare il binario firmware ESP32. L'ESP32 si riavvia automaticamente nel nuovo firmware. La stessa pagina accetta anche un archivio FilePack versionato che aggiorna il filesystem web ESP32 sulla scheda SD — vedi Caricamento FilePack di seguito.

Formattare la scheda SD come FAT32. Posizionare config.json nella directory root. Creare sottodirectory per le immagini ROM, le immagini disco e gli alberi del file system come referenziato nella configurazione. Una volta che la scheda e' in funzione, la scheda SD puo' anche essere gestita interamente attraverso la pagina web File Manager.

Il picoZ80 supporta il debug completo a livello sorgente di entrambi i core RP2350 e del co-processore ESP32. L'RP2350 viene debuggato tramite SWD utilizzando una sonda CMSIS-DAP, con OpenOCD che fornisce un server GDB a due target (una porta per core). L'ESP32-S3 viene debuggato tramite la sua interfaccia USB-JTAG integrata utilizzando il GDB della toolchain Xtensa.

Connessione hardware
Collegare una sonda ARM DAPLink / CMSIS-DAP (es. Raspberry Pi Debug Probe, Black Magic Probe o qualsiasi adattatore compatibile CMSIS-DAP) all'header di debug a 6 pin sulla scheda picoZ80. Sono necessarie solo tre connessioni:

Pin Header di Debug	Segnale	Funzione SWD
Pin 1	SWCLK	Serial Wire Clock
Pin 2	SWDIO	Serial Wire Data
Pin 5	GND	Riferimento di massa

Avvio di OpenOCD
OpenOCD espone due porte server GDB — porta 3333 per il Core 0 e porta 3334 per il Core 1. Il picoZ80 richiede una piccola modifica allo script target standard OpenOCD per RP2350 per abilitare il vero debug SMP con porte GDB separate per core. Copiare lo script standard e decommentare la riga target smp:

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

Poi modificare rp2350_tzpu.cfg — trovare la riga target smp all'interno del blocco if {[string compare $_USE_CORE SMP] == 0} e rimuovere il # iniziale:

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

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

Questa singola modifica attiva la modalita' SMP in modo che OpenOCD registri il Core 0 sulla porta GDB 3333 e il Core 1 sulla porta 3334, consentendo a ogni core di essere collegato e fatto avanzare passo-passo indipendentemente. Lanciare OpenOCD dalla root del progetto prima di avviare GDB:

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

Inizializzazione globale GDB (~/.gdbinit)
GDB richiede il permesso esplicito per il caricamento automatico dei file .gdbinit per directory. Aggiungere quanto segue a ~/.gdbinit, regolando i percorsi per corrispondere alla posizione del progetto (mostrati qui relativi alla root del progetto — utilizzare percorsi assoluti in ~/.gdbinit se si esegue GDB da directory diverse):

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

Copiare il file .gdbinit appropriato per core nella directory di build del Bootloader, poi lanciare gdb-multiarch. Il file .gdbinit.bootloader.3333 si connette al Core 0 (porta 3333) e registra l'output in gdb_core0.txt; .gdbinit.bootloader.3334 si connette al Core 1 (porta 3334) registrando in gdb_core1.txt. Aprire due terminali per debuggare entrambi i core simultaneamente:

# 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

I file .gdbinit del firmware principale (.gdbinit.3333 e .gdbinit.3334) definiscono un comando personalizzato xac <address> <count> che effettua il dump della memoria come output esadecimale e ASCII combinato, si connettono alla rispettiva porta GDB e continuano l'esecuzione. Questo e' utile per ispezionare il contenuto dei banchi PSRAM e lo stato dei dispositivi memory-mapped senza fermare il loop di emulazione:

# 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

Il co-processore ESP32-S3 ha un'interfaccia USB-JTAG integrata — non e' richiesta alcuna sonda di debug esterna. Collegare un cavo USB da un PC host direttamente alla porta USB ESP32 sulla scheda picoZ80. Avviare OpenOCD utilizzando la configurazione JTAG integrata dell'ESP32-S3:

openocd -f board/esp32s3-builtin.cfg

Poi lanciare il GDB Xtensa puntando all'ELF del firmware ESP32 (ubicato in esp32/build/main.elf relativamente alla root del progetto) e collegarsi al server GDB di OpenOCD:

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

Assicurarsi che l'ELF sia stato compilato dalla stessa revisione dei sorgenti del firmware caricato sul dispositivo in modo che simboli e indirizzi siano allineati correttamente.

Tutto il comportamento del picoZ80 e' controllato da config.json sulla scheda SD. L'RP2350 legge questo file all'avvio tramite l'ESP32, lo minifica e memorizza il risultato nella Flash. Se non e' presente alcuna scheda SD, viene utilizzata la configurazione precedentemente memorizzata. La configurazione puo' essere modificata direttamente nel browser utilizzando la pagina Config Editor. La struttura di primo livello e':

{
  "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'oggetto di primo livello esp32 configura il co-processore ESP32. Contiene due sotto-oggetti: core e wifi.

L'oggetto wifi fornisce un meccanismo per iniettare credenziali WiFi e impostazioni di rete da config.json, sovrascrivendo quanto memorizzato nell'NVS. Questo e' utile per il provisioning iniziale o per distribuire una configurazione di rete nota come funzionante senza utilizzare il WiFi Manager web. Impostare override a 0 per ignorare completamente il file di configurazione e affidarsi alle impostazioni NVS precedentemente persistite.

L'array memory definisce la mappa di memoria Z80. Ogni voce copre una regione contigua dello spazio di indirizzamento Z80 a 64KB, arrotondata ai confini dei blocchi da 512 byte.

"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
  }
]

L'array io mappa gli intervalli di porte I/O Z80 agli handler. I cicli I/O sono distinti dai cicli di memoria dal segnale Z80 IORQ, che la macchina a stati di controllo PIO monitora.

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

L'array drivers associa istanze di driver denominate al contesto Z80. Ogni driver ha una o piu' interfacce (elencate sotto la chiave "if"), ciascuna delle quali puo' caricare immagini ROM, rimappare intervalli di indirizzi, rimappare intervalli di porte I/O e ricevere file di parametri.

Affinche' le schede interfaccia machine-agnostic possano essere usate su schede personalizzate / sperimentali (vedi OpenZ80), diverse schede possono avere la propria porta I/O base rilocata. Una scheda rilocabile legge il proprio indirizzo base dal dstaddr della sua voce iomap (con srcaddr impostato sulla porta autentica della scheda), e usa come predefinita la sua porta originale quando non e' presente alcuna voce iomap. Il modo piu' semplice per impostarla e' il campo Base I/O Port nella pagina Configurazione GUI, che scrive per te la voce iomap corretta. Le schede rilocabili e le loro basi predefinite sono:

"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"
          }
        ]
      }
    ]
  }
]

Di seguito una configurazione minima che avvia un MZ-700 con ROM, 48KB di RAM, VRAM host e il controller floppy 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" }] }]
          }
        ]
      }
    ]
  }
}

Il picoZ80 include una shell di debug ICE (In-Circuit Emulator) interattiva integrata sul secondo canale seriale USB CDC. Collegare un emulatore di terminale (115200 baud, 8N1) alla porta seriale di debug — appare come la seconda porta COM/ttyACM quando il picoZ80 e' connesso via USB. Il prompt della shell e' dbg> . Il firmware e' disponibile in due varianti: una build standard senza la shell di debug e una build DBGSH che include il debugger ICE completo. La variante DBGSH e' identificata dal suffisso _DBGSH nel nome del file firmware.

La shell di debug fornisce 49 comandi per l'ispezione e il controllo in tempo reale dell'emulazione CPU Z80:

Breakpoint — fino a 8 breakpoint possono essere attivi simultaneamente. Quando un breakpoint viene raggiunto, la CPU viene automaticamente messa in pausa e l'indirizzo colpito viene visualizzato. Utilizzare go per continuare o step per avanzare passo-passo dal breakpoint. Traccia di esecuzione — quando abilitata, il PC, l'opcode e il registro flag di ogni istruzione eseguita vengono registrati in un buffer circolare a 512 voci. Utilizzare trace dump per ispezionare la cronologia di esecuzione recente con disassembly completo. Modalita' di accesso alla memoria — dm p legge la memoria tramite il bus Z80 fisico (attivando risposte hardware reali), dm f legge utilizzando cicli fetch (M1), dm v legge direttamente dalla PSRAM virtuale (zero attivita' bus) e dm r legge lo spazio di indirizzamento proprio dell'RP2350 (Flash, SRAM, periferiche).

Il picoZ80 supporta tre modalita' di rete, selezionabili a tempo di compilazione tramite file sdkconfig ESP32 pre-compilati. Ogni modalita' determina come l'interfaccia web e le pagine di configurazione vengono accedute.

USB NCM (Network Control Model) presenta un adattatore Ethernet virtuale sulla porta USB OTG dell'ESP32. Quando il picoZ80 e' collegato a un computer host via USB, l'host vede un'interfaccia di rete standard. Un server DHCP integrato nel picoZ80 assegna automaticamente all'host un indirizzo IP — non e' richiesta alcuna configurazione manuale. L'interfaccia web e' poi accessibile a http://192.168.7.1. La modalita' NCM Only e' il default raccomandato per le schede spedite senza certificazione WiFi. Fornisce la piena funzionalita' dell'interfaccia web (configurazione, aggiornamenti firmware, gestione file, selezione personalita') senza alcuna emissione di radiofrequenza. La rete di adattamento dell'antenna WiFi non deve essere popolata sul PCB. La modalita' WiFi + NCM abilita entrambe le interfacce simultaneamente. Il server HTTP si associa a tutte le interfacce, quindi le pagine web sono accessibili sia da WiFi che dalla connessione di rete USB. Il WiFi si connette in modo asincrono, quindi l'interfaccia USB NCM e' disponibile immediatamente all'accensione. Per cambiare modalita', copiare il file sdkconfig.mode_* appropriato come sdkconfig nella directory di build ESP32, ricompilare e caricare il firmware ESP32.

Importante: La scheda picoZ80 non e' stata sottoposta per la certificazione come radiatore intenzionale FCC (USA) o RED (UE). Come spedita, la scheda deve avere i componenti di adattamento dell'antenna WiFi non montati e il firmware ESP32 compilato con la configurazione NCM Only (sdkconfig.mode_ncm_only). In questa configurazione non viene emessa alcuna energia a radiofrequenza e la scheda non rientra nelle regolamentazioni per radiatori intenzionali. Gli utenti finali che desiderano utilizzare il WiFi possono montare la rete di adattamento dell'antenna sul PCB, compilare il firmware ESP32 con sdkconfig.mode_wifi_only o sdkconfig.mode_wifi_and_ncm e operare la scheda sotto l'esenzione hobbistica/sperimentale applicabile nella propria giurisdizione. Qualsiasi parte che desideri vendere la scheda commercialmente con WiFi abilitato deve prima ottenere la certificazione FCC e/o RED per l'assemblaggio completo.

Il co-processore ESP32 ospita un'interfaccia di gestione web costruita con Bootstrap 4. Connettersi alla rete WiFi del picoZ80 (o configurare la modalita' client per unirsi alla rete esistente) e navigare a http://<device-ip>/ — per default http://192.168.4.1/ in modalita' Access Point. In modalita' NCM, l'interfaccia web e' accessibile a http://192.168.7.1 tramite la connessione di rete USB. Vedi Rete sopra per i dettagli sulle modalita'. Al primo avvio in modalita' WiFi la scheda parte in modalita' AP. Utilizzare la pagina WiFi Manager per configurare la modalita' client e assegnare un indirizzo IP fisso sulla rete. Tutte le pagine condividono una barra di navigazione comune sul lato sinistro che fornisce accesso con un clic a Status, Config Editor, Config GUI, File Manager, Settings (Firmware -> ESP32 / RP2350, WiFi Manager) e Persona. In modalita' NCM Only, la pagina WiFi Manager non e' presente e la barra di navigazione mostra lo stesso set di pagine meno WiFi Manager.

La pagina principale mostra lo stato attuale della scheda attraverso tre pannelli:

• Configurazione WiFi / Configurazione di Rete
  - nelle modalita' WiFi questo pannello mostra l'SSID corrente, l'indirizzo IP assegnato, la netmask e il gateway. In modalita' NCM Only questo pannello e' intitolato Network Configuration e mostra invece lo stato della rete USB NCM (indirizzo IP, netmask) — non ci sono informazioni relative a SSID o WiFi. Il nome della scheda (tzpuPico) e la stringa di copyright vengono serviti come variabili template dal web server ESP32.
• Informazioni sulla Versione
  - tabella delle partizioni ESP32 che mostra tutti gli slot OTA con tipo, sotto-tipo, indirizzo Flash, dimensione, versione firmware, timestamp di build e quale slot e' attualmente in esecuzione. Questo rende semplice confermare quale firmware e' attivo dopo un aggiornamento OTA.
• Partizioni RP2350
  - la tabella delle partizioni Flash dell'RP2350 con numero di partizione, indirizzo, dimensione, checksum, flag attivo/in esecuzione, licenza, autore, descrizione, versione, data di build e copyright — fornendo un'istantanea completa dello stato del firmware RP2350 insieme alle informazioni ESP32.

Due menu a tendina nella barra di navigazione in alto a destra sono disponibili su ogni pagina:

• Menu Azioni
  - Change Floppy Disk 1 / 2 — seleziona un nuovo file immagine DSK dalla scheda SD e montalo nello slot 1 o 2 del controller floppy virtuale WD1773 senza riavviare. Il nome del file dell'immagine disco attualmente caricata e' visualizzato accanto a ogni voce (o "none" se nessuna immagine e' caricata).
  - Change QD Disk — scambia il file immagine QuickDisk attivo al volo. Il nome del file dell'immagine QD attualmente caricata e' mostrato accanto alla voce.
  - Reload RP2350 Config — invia un comando di ricaricamento all'RP2350 tramite la UART ESP32-RP2350; l'RP2350 rianalizza config.json e riapplica la mappa di memoria e la configurazione dei driver senza un ciclo di alimentazione completo.
• Menu Riavvio
  - ESP32 — riavvio soft del co-processore ESP32 (riavvia il web server e lo stack WiFi, l'RP2350 non e' influenzato).
  - RP2350B — reset del processore RP2350 (riesegue il bootloader e ricarica lo slot firmware attivo, la CPU host e' in pausa durante il reset).
  - Host — asserisce la linea di reset del computer host, riavviando il computer legacy nel socket Z80 senza influenzare la scheda picoZ80 stessa.
  - IPL Reset — esegue un reset IPL (Initial Program Load) commutando il bit 3 della Porta C del 8255 PPI, riportando la macchina in modalita' boot (BST). Disponibile sulle personalita' MZ-80B, MZ-2000, MZ-2200 e MZ-2500 — equivalente alla pressione del pulsante IPL sull'hardware originale.
  - RP2350 UF2 Boot — forza l'RP2350 nella modalita' boot USB ROM UF2 tramite il bootloader personalizzato. L'ESP32 resetta l'RP2350 con il pin BOOT tenuto, poi invia un ID magico tramite UART che fa si' che il bootloader chiami reset_usb_boot(). L'RP2350 si presenta come dispositivo mass-storage USB per il caricamento UF2 drag-and-drop. Questo e' il metodo di recupero primario quando l'applicazione principale e' difettosa (es. impostazioni clock/voltage errate) — il bootloader personalizzato funziona con valori di default sicuri e rimane reattivo.
  - RP2350 UF2 Boot (App) — richiede all'applicazione RP2350 in esecuzione di entrare nella modalita' boot USB UF2 tramite comando SPI. Questo e' un fallback per situazioni in cui il bootloader stesso necessita di sostituzione — l'applicazione in esecuzione chiama direttamente reset_usb_boot(). Funziona solo quando l'applicazione e' in esecuzione e reattiva ai comandi SPI.

La pagina Configuration Editor fornisce il pieno controllo di modifica sul file di configurazione JSON. Modifica la configurazione utilizzando l'editor wysiwyg, salva quando necessario e clicca Apply per rielaborare la configurazione. La scheda SD mantiene backup numerati automatici di ogni configurazione salvata (config.json;1, config.json;2, ... con il numero piu' alto che e' il piu' recente), quindi e' sempre possibile tornare a una configurazione funzionante precedente. Le configurazioni modificate vengono salvate sulla scheda SD; cliccando Apply o un'azione del menu "Reload" viene poi inviato un comando di ricaricamento all'RP2350 tramite la UART ESP32-RP2350, facendo si' che l'RP2350 rianaalizzi e riapplichi la nuova configurazione e facendo si' che l'ESP32 analizzi e ricarichi la sua configurazione.

La pagina GUI Configuration fornisce un editor grafico basato su form per la configurazione del picoZ80, complementando il Config Editor JSON grezzo. Anziche' modificare il JSON direttamente, tutte le impostazioni sono presentate come campi di input etichettati, menu a tendina e tabelle modificabili. Le modifiche vengono salvate in config.json sulla scheda SD (il file esistente viene automaticamente sottoposto a backup prima del salvataggio). Per la modifica avanzata, il Config Editor rimane disponibile per la manipolazione diretta del JSON. La pagina e' organizzata in quattro schede: RP2350 Global — impostazioni core globali che si applicano a entrambe le partizioni firmware a meno che non vengano sovrascritte a livello di partizione:

• Core Voltage — tensione core dell'RP2350 in volt (es. 1,10 V).
• CPU Frequency (MHz) — velocita' di clock dell'RP2350. L'intervallo valido e' visualizzato accanto al campo.
• PSRAM Frequency (MHz) — frequenza di clock SPI della PSRAM. Valori piu' alti migliorano la velocita' di emulazione ma possono ridurre la stabilita' su alcune schede.

Partition 1 / Partition 2 — configurazione per partizione. Ogni scheda di partizione ha lo stesso layout:

• Core Settings — sovrascritture specifiche per partizione per Core Voltage, CPU Frequency e PSRAM Frequency. Se impostate, queste hanno la precedenza sui valori globali per questa partizione.
• Memory Regions — una tabella modificabile che definisce la mappa di memoria Z80. Ogni riga specifica un blocco di memoria con: Address esadecimale, Size, Type (ROM, RAM, PHYSICAL o FUNC), T-States (stati di attesa), Bank (numero banco PSRAM), Track (flag di sincronizzazione T-cycle), File (nome file immagine ROM sulla scheda SD), File Offset e una casella Load. Le righe possono essere aggiunte o rimosse con i pulsanti Add Memory Region e delete.
• I/O Regions — una tabella modificabile che definisce la mappa porte I/O Z80. Ogni riga specifica: Address, Size, Type e Function (l'handler del driver). Aggiungere o rimuovere righe secondo necessita'.
• Drivers — elenca i driver periferici attivi (es. MZ80AFI, RFS, MZ-1E30, Celestite) con toggle abilita/disabilita. Il pulsante Add Driver presenta un menu a tendina dei driver validi per il firmware in esecuzione — la pagina legge la stringa di personalita' del firmware e offre solo i driver per quella serie (Sharp, Amstrad, Tatung o Open). Ogni driver elenca le proprie System ROMs (immagini ROM a livello di driver che sovrascrivono le ROM dell'host) e le proprie Interfaces; possono essere aggiunti controller floppy, QuickDisk, schede RAM/ROM, hard disk SASI, schede seriali RS-232C e interfacce LAN, e i file ROM, le immagini disco e i parametri di ogni interfaccia possono essere configurati inline.
  • Base I/O Port — per le schede interfaccia rilocabili (MZ-1R12, MZ-1R18, MZ-1R23, MZ-1R37, PIO-3034, MZ-8BIO3, MZ-1E24, MZ-1E05, Celestite) viene mostrato un singolo campo esadecimale Base I/O Port, pre-compilato con la base autentica della scheda. Modificalo per spostare le porte della scheda su una scheda personalizzata (vedi Porte I/O delle Interfacce Rilocabili); la GUI scrive automaticamente la voce iomap corrispondente e la omette quando lasci il valore al predefinito.
  • Parametro Port — le schede seriali RS-232C (MZ-8BIO3 / MZ-1E24) accettano anche un parametro numerico Port per la loro porta I/O base (predefinito 0xB0; canale A → USB CDC 2, canale B → USB CDC 3).

ESP32 — impostazioni del co-processore ESP32:

• Core — tipo di dispositivo ESP32 (es. S3S).
• Network Interfaces — controlli abilita/disabilita per entrambe le interfacce di rete WiFi e USB NCM:
  • WiFi Enable — casella per abilitare o disabilitare il WiFi (richiede riavvio; ignorata se il WiFi non e' compilato nel firmware).
  • NCM Enable — casella per abilitare o disabilitare la rete USB NCM (richiede riavvio).
  • NCM Retries — cicli massimi di tentativi di connessione (0 = riprova per sempre, 5-1000 = tentativi massimi).
  • NCM Retry Period — ritardo tra i tentativi in secondi (0 = backoff crescente da 1s fino a 60s, 1-120 = intervallo fisso).
  • NCM IP Address — l'indirizzo IP del gateway USB NCM (default: 192.168.7.1). Quando si collegano due schede picoZ80 allo stesso host, ciascuna deve utilizzare una subnet diversa (es. 192.168.7.1 e 192.168.8.1). Le modifiche hanno effetto dopo il riavvio e vengono persistite nell'NVS.
  • NCM Netmask — la subnet mask USB NCM (default: 255.255.255.0). Le modifiche hanno effetto dopo il riavvio.
  • USB Product Name — la stringa prodotto del dispositivo USB riportata al sistema operativo host. macOS utilizza questa come etichetta dell'interfaccia di rete NCM. Ogni scheda genera automaticamente un nome univoco dal proprio indirizzo MAC (es. "picoZ80-3C4E"); sovrascrivere qui per impostare un nome personalizzato (es. "picoZ80-MZ700"). Lasciare vuoto per la generazione automatica. Le modifiche hanno effetto dopo il riavvio.
• WiFi Configuration — SSID, password, indirizzo IP, netmask, modalita' WiFi (Access Point o Client), DHCP (Abilitato o Disabilitato), percorso directory WebFS, periodo di polling e potenza TX. Queste impostazioni rispecchiano la pagina WiFi Manager ma sono modificabili qui come parte della configurazione completa.

Cliccare Save Configuration per scrivere le modifiche in config.json sulla scheda SD (la versione precedente viene sottoposta a backup automaticamente) e inviare automaticamente un comando di ricaricamento all'RP2350, applicando la nuova configurazione senza un ciclo di alimentazione completo. Cliccare Reload per rileggere il config.json corrente dalla scheda SD — utile se si e' commesso un errore e si vogliono scartare le modifiche e ricominciare dall'ultimo stato salvato.

Il File Manager fornisce un browser file completo basato su web per la scheda SD, con un layout a elenco directory per visualizzare i file sulla scheda SD. E' destinato alla manutenzione generale della scheda SD: caricamento di immagini ROM, immagini floppy disk (DSK), immagini QuickDisk (QD), immagini RAM disk e aggiornamenti del filesystem web senza necessita' di rimuovere la scheda. Ogni voce ha pulsanti di azione per copiare, eliminare, scaricare o modificare file di testo, e un pulsante Select File per il caricamento in alto consente di trasferire nuovi file dal PC. La navigazione delle directory consente di scendere nelle sottodirectory come roms/, dsk/, qd/ e ram/. Il caricamento di file tar o gzip fara' si' che il file tar o gzip (o tar.gz) venga automaticamente spacchettato ed estratto nella directory SD corrente. Piu' file possono essere selezionati utilizzando le caselle nella colonna piu' a sinistra (o la casella "Select All" nell'intestazione). Quando uno o piu' elementi sono selezionati, i pulsanti Download N Items e Delete Selected appaiono nell'intestazione del pannello. La funzione di download recupera ogni file in sequenza con un modale di progresso — le directory vengono automaticamente scaricate come archivi tar. Un pulsante Backup SD scarica l'intero contenuto della scheda SD come singolo archivio sul computer locale. Queste funzionalita' sono particolarmente utili quando il picoZ80 e' installato all'interno di una macchina host e rimuovere fisicamente la scheda SD non e' pratico.

La pagina Persona configura la personalita' macchina attiva indipendentemente per ciascuna delle due partizioni firmware RP2350. Ogni partizione ha la propria colonna di pulsanti radio che copre ogni tipo di macchina Sharp MZ supportata:

• Basic CPU — emulazione Z80 base senza driver specifici per macchina; utile per lo sviluppo Z80 generico.
• MZ-80A e MZ-80B — serie Sharp MZ-80 (ROM monitor 1Z-013A, tastiera MZ-80, mappa di memoria standard).
• MZ-700 — Sharp MZ-700 con VRAM bank-switched, controller tastiera e driver floppy/QuickDisk opzionali.
• MZ-800 — Sharp MZ-800 con modalita' video estese e supporto QuickDisk.
• MZ-1500 — Sharp MZ-1500 con QuickDisk e floppy opzionale.
• MZ-2000, MZ-2200, MZ-2500 — serie Sharp MZ successive con video ad alta risoluzione e memoria estesa.

Selezionando una personalita' e cliccando Select Personae viene scritto il corrispondente config.json pre-compilato sulla scheda SD (eseguendo prima il backup del file corrente) e viene attivato un ricaricamento della configurazione. Poiche' ogni partizione firmware puo' contenere una personalita' diversa, la scheda puo' essere commutata, ad esempio, tra una personalita' MZ-700 sulla partizione 1 e una personalita' MZ-80A sulla partizione 2 senza alcuna modifica della scheda SD. La personalita' sperimentatore OpenZ80 (vedi OpenZ80 — Personalita' Sperimentatore) e' una build firmware dedicata anziche' un'opzione radio in questa pagina: carica il firmware OpenZ80 su una partizione tramite le pagine di aggiornamento firmware, poi configura le sue schede interfaccia e le loro porte I/O base nella pagina Configurazione GUI. Per un semplice Z80 in-socket senza risorse aggiuntive su una macchina supportata, l'opzione Basic CPU sopra rimane disponibile.

La pagina OTA ESP32 riporta l'inventario software completo dell'ESP32 prima di accettare un caricamento firmware:

• Pannello Modules
  - mostra la versione di ogni componente software ESP32: l'applicazione ESP32 principale, la libreria NVS (non-volatile storage), lo stack WiFi, il FilePack (impacchettatore filesystem web) e il WebFS (file system web in-flash). Questo rende facile confermare che tutti i componenti siano coerenti dopo un aggiornamento.
• Pannello ESP32 Partitions
  - mostra la tabella completa delle partizioni OTA ESP32 (otadata, nvs, phy_init, ota_0, ota_1) con indirizzi, dimensioni, versioni firmware, timestamp di build e quale slot OTA e' attualmente attivo (contrassegnato "Yes").
• Pannello ESP32 Firmware Upload
  - accetta il binario ESP32 (.bin) prodotto dalla compilazione ESP-IDF. Dopo il caricamento l'ESP32 si riavvia nel nuovo firmware e il vecchio slot viene mantenuto come fallback.
• Pannello FilePack Upload
  - carica un archivio FilePack versionato sulla scheda SD. Un FilePack raggruppa tutti gli asset web statici ESP32 (template HTML, CSS, JavaScript e file accessori) in un singolo archivio distribuibile. Al caricamento l'ESP32 spacchetta l'archivio nella directory del filesystem web della scheda SD; qualsiasi file sostituito viene automaticamente rinominato per includere il suo numero di versione precedente (es. webfs -> webfs.2.80), preservando la vecchia versione per il rollback. Questo corrisponde al versionamento stile VAX/VMS utilizzato altrove sulla scheda SD, dove ogni revisione successiva di un file modificabile viene preservata con un suffisso numerico: config.json;1, config.json;2 e cosi' via — assicurando che nessuna modifica venga mai sovrascritta silenziosamente.

La pagina OTA RP2350 gestisce le due partizioni firmware RP2350:

• Pannello RP2350 Partitions
  - elenca tutte e tre le partizioni: partizione 0 (Bootloader), partizione 1 (primo slot applicativo, es. "Z80 CPU Emulator") e partizione 2 (secondo slot). Ogni riga mostra l'indirizzo Flash, la dimensione, il checksum, il flag attivo/in esecuzione, la licenza, l'autore, la descrizione, la versione e la data di build. La partizione attualmente in esecuzione e' contrassegnata "Yes" nella colonna Active.
• Pannello RP2350 Firmware Upload
  - accetta un file firmware binario puro .bin da fw/bin/. UF2 non viene utilizzato qui — le partizioni applicative si trovano a indirizzi Flash non standard che UF2 non puo' esprimere, quindi il trasferimento OTA utilizza binario grezzo. Utilizzare i pulsanti radio Partition 1 / Partition 2 per selezionare lo slot di destinazione. Due caselle aggiuntive sono disponibili: Clear App Config cancella le immagini ROM e la partizione di configurazione JSON minificata associata allo slot di destinazione (utile quando si aggiorna a una versione firmware con uno schema di configurazione incompatibile), e Clear Flash Header resetta l'intestazione della partizione Flash ai valori di fabbrica, ricostruendo la tabella delle partizioni da zero preservando la configurazione del bootloader. Il caricamento viene verificato tramite checksum prima che la nuova partizione venga attivata.
• Pannello RP2350 Active Partition
  - commuta indipendentemente la partizione attiva senza caricare nuovo firmware. Selezionare una partizione qui attiva un riavvio automatico nello slot scelto — utile per alternare tra due varianti firmware pre-caricate (es. Z80 e una build di test) senza alcun trasferimento file.

Nota: La pagina WiFi Manager e' disponibile solo quando il firmware ESP32 e' compilato con WiFi abilitato (sdkconfig.mode_wifi_only o sdkconfig.mode_wifi_and_ncm). In modalita' NCM Only questa pagina non e' presente nella navigazione — la connettivita' di rete e' fornita automaticamente tramite USB NCM senza alcuna configurazione da parte dell'utente. Il WiFi Manager configura come il picoZ80 si connette a una rete wireless. Il pannello superiore mostra la configurazione WiFi attualmente attiva (SSID, IP assegnato, netmask e gateway). Il form Configure WiFi sottostante espone tutte le impostazioni:

• Modalita' WiFi
  - Access Point: il picoZ80 trasmette il proprio SSID e ci si connette direttamente ad esso (utile durante la configurazione iniziale o quando non e' disponibile una rete infrastrutturale). Client: il picoZ80 si unisce a una rete WiFi esistente come stazione.
• SSID e Password
  - il nome e la passphrase della rete a cui unirsi (modalita' client) o da trasmettere (modalita' AP).
• Modalita' DHCP
  - Abilitato: la scheda richiede un indirizzo dal server DHCP della rete. Disabilitato: utilizza un IP statico, netmask e gateway come inseriti nei campi sottostanti. Un IP fisso e' raccomandato in modo che l'indirizzo dell'interfaccia web sia sempre prevedibile.

Le impostazioni vengono salvate nell'NVS (non-volatile storage) dell'ESP32 cliccando Save e hanno effetto al prossimo riavvio.

I due menu a tendina nella barra di navigazione in alto a destra sono disponibili su ogni pagina dell'interfaccia web, fornendo accesso rapido alle operazioni runtime e alle funzioni di reset del sistema senza navigare via dalla pagina corrente. Il Menu Azioni (icona ingranaggio) fornisce operazioni runtime che hanno effetto immediato senza un riavvio: scambio delle immagini floppy disk o QuickDisk al volo e attivazione di un ricaricamento live della configurazione sull'RP2350. I nomi file delle immagini disco attualmente caricate sono visualizzati accanto a ogni voce in modo che l'operatore possa vedere a colpo d'occhio quali immagini sono montate. Il Menu Riavvio (icona rotazione) fornisce opzioni di reset mirate per ogni sottosistema — ESP32, RP2350, computer host e IPL — piu' due opzioni di recupero UF2 per ricaricare l'RP2350 tramite mass-storage USB quando la scheda e' fisicamente inaccessibile all'interno di una macchina host. Le due voci UF2 forniscono percorsi di recupero complementari: il percorso bootloader funziona anche quando l'applicazione principale e' difettosa, mentre il percorso app funziona anche quando il bootloader necessita di sostituzione.

La tabella seguente contiene tutti i siti referenziati nella progettazione e programmazione del picoZ80.

Sito	Lingua	Descrizione
RP2350 Datasheet	Inglese	Riferimento tecnico e datasheet ufficiale del Raspberry Pi RP2350.
Pico SDK	Inglese	Raspberry Pi Pico C/C++ SDK — sistema di build e astrazione hardware utilizzato dal firmware picoZ80.
Z80 CPU User Manual	Inglese	Manuale utente della famiglia CPU Zilog Z80 — temporizzazione bus, set di istruzioni e descrizioni dei segnali.
ESP-IDF	Inglese	Espressif IoT Development Framework utilizzato per il firmware del co-processore ESP32.
Sharp MZ Series	Inglese	Risorsa della comunita' per hardware, software e documentazione tecnica dei computer Sharp MZ.

La tabella seguente contiene tutti i datasheet e manuali referenziati nella progettazione e programmazione del picoZ80.

Datasheet	Lingua	Descrizione
RP2350	Inglese	Datasheet del microcontrollore Raspberry Pi RP2350.
ESP32-S3	Inglese	Datasheet del SoC Espressif ESP32-S3 — co-processore WiFi/BT sulla scheda picoZ80.
APS6404L PSRAM	Inglese	Datasheet PSRAM SPI da 8MB — la RAM estesa principale utilizzata per il banking di memoria.
W25Q128 Flash	Inglese	Datasheet Winbond 16MB SPI NOR Flash — memorizza firmware e immagini ROM.
TLV62590	Inglese	Convertitore buck sincrono Texas Instruments 5V->3,3V che alimenta il picoZ80 dal pin VCC del DIP-40 Z80.
CH334F	Inglese	Controller hub USB 2.0 a 4 porte CH334F — fornisce la funzionalita' hub USB per gli aggiornamenti firmware.

Anteprime di sviluppo iniziali del progetto picoZ80 sono state condivise su X (precedentemente Twitter). Il seguente post mostra la scheda in funzione per la prima volta: https://x.com/engineerswork1/status/1953171627065188841

Il picoZ80 installato in uno Sharp MZ-700, con la personalita' ROM Filing System (RFS) in esecuzione. Il video dimostra le capacita' di disco virtuale e banking di memoria della scheda.

Una breve clip che mostra una scheda Z80 CPU Tester che testa il picoZ80. Il tester verifica che il picoZ80 sia un genuino Z80, lo identifica come uno Z80 NMOS e esegue codice di test a 8 MHz per confermare il funzionamento corretto.

Il picoZ80 v2.5 installato in uno Sharp MZ-80A, caricando un programma da un nastro a cassetta fisico. Il caricamento da cassetta e' estremamente sensibile alla temporizzazione — lo Z80 deve effettuare il bit-bang del flusso dati seriale dall'hardware del nastro in tempo reale senza margine di errore nella temporizzazione. Questo video dimostra che il picoZ80 gestisce la temporizzazione CMT critica in modo identico a uno Z80 reale.

Il picoZ80 v2.5 in uno Sharp MZ-80A, leggendo da un controller floppy disk reale e un drive floppy fisico. L'accesso al floppy disk richiede un'interazione precisa e time-critical tra lo Z80 e l'hardware FDC WD1773 — il DRQ deve essere servito entro finestre di temporizzazione strette o i dati vengono persi. Questo video dimostra che il picoZ80 interagisce con hardware time-critical reale allo stesso modo di un genuino Z80.

Il picoZ80 v2.5a installato in uno Sharp MZ-2000, funzionante in modalita' completamente fisica — tutti gli accessi ROM, RAM e VRAM passano attraverso l'hardware reale dell'MZ-2000. Il controller floppy disk e' virtualizzato, con il picoZ80 che emula il FDC MB8866 e serve immagini disco dalla scheda SD mentre il resto della macchina funziona sul suo hardware originale.

Nessun uso commerciale consentito senza espressa autorizzazione scritta. Il design hardware del picoZ80 (schemi elettrici, layout PCB, file KiCad), il firmware e tutto il software associato sono resi disponibili esclusivamente per uso personale, educativo e non commerciale. Nessuna parte di questo design — inclusi ma non limitati a grafica PCB, distinta materiali, binari firmware, codice sorgente o documentazione — puo' essere utilizzata, riprodotta, fabbricata, venduta o incorporata in qualsiasi prodotto o servizio commerciale senza l'espressa autorizzazione scritta dell'autore (Philip D. Smart). Per richiedere una licenza commerciale o discutere gli usi consentiti, contattare l'autore tramite il sito web eaw.app.

Il progetto picoZ80 si basa sul lavoro di diversi individui e progetti open-source. I loro contributi vengono riconosciuti con gratitudine.

• Manuel Sainz de Baranda y Goni
  Autore della libreria emulatore CPU Z80 in linguaggio C (github.com/redcode/Z80). Questo core emulatore Z80 ad alta precisione e ciclo-accurato viene utilizzato dal firmware picoZ80 quando esegue istruzioni Z80 internamente sull'RP2350, fornendo un comportamento preciso dei flag e supporto per opcode non documentati. La libreria e' utilizzata secondo i termini della GNU General Public License v3.
• Raspberry Pi Ltd
  Autori del Pico SDK e dell'hardware RP2350. L'assemblatore PIO, il C SDK, l'integrazione della toolchain CMake e il silicio RP2350B rendono possibile l'interfaccia bus ciclo-accurata.
• Espressif Systems
  Autori del framework ESP-IDF e dell'hardware ESP32. Il co-processore ESP32, lo stack WiFi, la libreria OTA e il framework di storage NVS sono alla base dell'interfaccia di gestione web.
• Philip Smart
  Design hardware (schemi elettrici e layout PCB KiCad), firmware PIO RP2350, applicazione web ESP32, sistema di configurazione JSON, driver personalita' macchina Sharp MZ e tutta la documentazione del progetto.
• Grok (xAI)
  Assistente AI che ha fornito un aiuto prezioso durante il debug delle macchine a stati PIO — in particolare nella diagnosi di casi limite di temporizzazione e problemi di interazione bus ciclo-accurata nei programmi PIO dell'RP2350.
• Claude (Anthropic)
  Assistente AI che contribuisce a questo progetto in molteplici aree: redazione e strutturazione della documentazione del progetto, analisi dell'interfaccia FSPI/UART tra RP2350 e ESP32 con raccomandazioni per il miglioramento del firmware, e assistenza continua allo sviluppo del firmware.

Il progetto picoZ80 e' composto da diversi componenti, ciascuno coperto dalla propria licenza:

Componente	Licenza
Firmware RP2350 picoZ80 (PIO, sorgenti C)	GNU General Public License v3
Firmware ESP32 picoZ80 e interfaccia web	GNU General Public License v3
Libreria emulatore CPU Z80 (Manuel Sainz de Baranda y Goni)	GNU General Public License v3
File di design hardware KiCad (schemi, PCB, Gerber)	Creative Commons BY-NC-SA 4.0
Documentazione e guide utente	Creative Commons BY-NC-SA 4.0
Raspberry Pi Pico SDK	BSD 3-Clause
Framework ESP-IDF	Apache License 2.0
Bootstrap 4 (interfaccia web)	MIT License

In breve: il firmware e il software che si compilano dal codice sorgente di questo progetto sono open-source sotto la GPL v3; i design hardware e la documentazione sono licenziati sotto CC BY-NC-SA 4.0 (solo uso non commerciale — licenza commerciale disponibile su richiesta); le librerie di terze parti mantengono le proprie licenze come elencato sopra. Vedere i file LICENSE e NOTICE nel repository per i dettagli completi.

Copyright © 2019–2026 Philip Smart. Tutti i diritti riservati. Design Hardware — CC BY-NC-SA 4.0
Tutti i design hardware (schemi elettrici KiCad, layout PCB, file di fabbricazione Gerber, distinte materiali) sono licenziati sotto la Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. Siete liberi di condividere e adattare i design esclusivamente per scopi non commerciali, a condizione di dare l'appropriato credito e distribuire qualsiasi modifica sotto la stessa licenza. La fabbricazione o vendita commerciale richiede una licenza separata — contattare info@eaw.app. Firmware & Software — GNU GPL v3
Il firmware e il codice sorgente del software sono software libero sotto la GNU General Public License v3. Potete ridistribuire e modificare il codice secondo i termini della GPL v3. Qualsiasi modifica distribuita deve anch'essa essere licenziata sotto GPL v3 con il codice sorgente reso disponibile. Marchio & Attribuzione
I nomi picoZ80, pico6502 e engineers@work sono marchi di Philip Smart. Non potete utilizzare questi nomi per promuovere prodotti derivati senza autorizzazione scritta. Non potete rimuovere o alterare avvisi di copyright, attribuzione dell'autore o crediti nelle schermate di boot/splash. Ri-brandizzare questo progetto e presentarlo come proprio lavoro e' espressamente proibito. Vedere il file NOTICE nel repository per i dettagli completi. Licenza Commerciale
Se siete un produttore o distributore interessato a produrre schede picoZ80 o pico6502 per la vendita commerciale, contattare: info@eaw.app. L'uso personale, educativo e hobbistico/di club e' sempre consentito sotto le licenze open-source sopra indicate. I testi completi delle licenze sono inclusi nel repository come LICENSE, LICENSE-HARDWARE.txt e LICENSE-SOFTWARE.txt.

Questo dispositivo incorpora un modulo wireless ESP32-S3-PICO-1 capace di trasmettere nella banda ISM a 2,4 GHz, rendendolo un radiatore intenzionale secondo le normative sulle radiofrequenze a livello mondiale (incluso FCC Part 15 Subpart C negli Stati Uniti e la Direttiva sulle Apparecchiature Radio 2014/53/UE nell'Unione Europea) quando il WiFi e' abilitato. Default NCM-Only per Schede Non Certificate
Poiche' il picoZ80 come assemblaggio finito non ha superato la certificazione FCC o RED, le schede devono essere spedite con la rete di adattamento dell'antenna WiFi non montata e il firmware ESP32 compilato utilizzando la configurazione NCM Only (sdkconfig.mode_ncm_only). In questa configurazione non viene emessa alcuna energia a radiofrequenza e la scheda non e' soggetta alle normative per radiatori intenzionali. L'interfaccia web completa rimane accessibile tramite USB a http://192.168.7.1. Vedere la sezione Rete — Avviso Normativo FCC / RED sopra per ulteriori dettagli. Sebbene il modulo ESP32-S3-PICO-1 stesso abbia certificazioni normative pre-esistenti (FCC, CE e altre), quelle certificazioni a livello di modulo non si estendono automaticamente a un prodotto finito che incorpora il modulo. L'esenzione per moduli pre-certificati consente ai singoli hobbisti di costruire un numero limitato di dispositivi per uso personale, sperimentale o educativo senza ottenere un'autorizzazione separata per l'apparecchiatura. Limitazioni Importanti

• I dispositivi assemblati con WiFi abilitato non devono essere venduti, offerti in vendita, regalati o altrimenti distribuiti a terzi a meno che il prodotto finito non sia stato testato indipendentemente e abbia ottenuto la propria autorizzazione per l'apparecchiatura (es. FCC ID, marcatura CE con valutazione dell'Organismo Notificato) nella giurisdizione pertinente.
• Le schede spedite o distribuite ad altri devono utilizzare la configurazione firmware NCM Only con la rete di adattamento dell'antenna WiFi non montata.
• Costruire questo progetto per uso personale in quantita' limitate con WiFi abilitato e' generalmente consentito sotto le disposizioni per uso hobbistico e sperimentale (es. FCC § 15.23), a condizione che il dispositivo non causi interferenze dannose.
• I requisiti normativi variano da paese a paese. I costruttori al di fuori degli Stati Uniti dovrebbero consultare la propria autorita' nazionale per le radiofrequenze per le regole applicabili.

Responsabilita' del Costruttore
E' responsabilita' esclusiva del costruttore assicurare che qualsiasi dispositivo costruito da questi design sia conforme a tutte le normative sulle radiofrequenze applicabili nella propria giurisdizione. L'autore fornisce questi design per uso personale, educativo e hobbistico e non dichiara che un dispositivo costruito da essi soddisfi i requisiti normativi per la distribuzione commerciale.